CalNet Terms of Service for Proxied CalNet Authentication
Applications May Not Proxy CalNet Authentication Without a Security Review
Proxied authentication, the practice of providing a system with a user name and passphrases in the clear that are then passed to CalNet for authentication, is strongly discouraged. Our goal as a campus is to protect the integrity of CalNet credentials and we believe that this is best accomplished by having as few systems as possible handle user IDs and passphrases in the clear. It is important to reduce, to the greatest extent possible, the number of places where authentication information may be intercepted. There may be a compelling business need for a system to proxy CalNet authentication. Application owners should first consult the CalNet team and undergo a system/application security assessment to ensure that CalNet credentials are adequately protected.
Proxied CalNet authentication without an approved exception request is prohibited by the Campus Information Security and Privacy Committee. If you have not already done so, please review the CalNet Terms of Service. These documents contain a number of helpful suggestions for ways developers can avoid proxying CalNet authentication.
If, after reading these documents, you feel your only reasonable approach is to proxy CalNet authentication, please follow the instructions below to complete an exception request for your system or application.
If you do need to submit a request, please complete the CalNet Proxied Authentication Exception Request below (ultimately the MSS exception request application will be modified to handle these requests).
The CalNet Tech Team, an open group comprised of system administrators and developers from IST and a variety of campus departments, will review your request and make a recommendation to approve or deny the request to the Campus Information Security and Privacy Committee (CISPC). The CISPC has final authority to grant or deny an exception request.
The CalNet Tech Team and the CISPC typically meet the third Thursday of the month. Please plan on at least one month for review and response to your exception request.
You do not need to request an exception for:
- Remote desktop login for individual workstations
- Remote login for systems which handle less than 50 unique CalNet IDs per day
- Computer lab workstations or public kiosks
- Client based applications which use the NTLMv2 protocol because support for native Kerberos does not exist
You need to request an exception for:
- Web applications which use CalNet authentication, but do not use CAS
- Web applications using HTTP auth via campus AD accounts
- Web applications which conduct form-based authentication, including the use of modules such as mod_kerb for Apache or mod_pam to authenticate users against the KDCs.
- Systems that are most often accessed remotely and are exposed to more than 50 unique CalNet IDs per day, such as terminal services machines and UNIX systems where proxied authentication is used (including UNIX hosts which use a PAM plugin to authenticate remote user sessions against the KDCs).
- Systems that allow remote access via CalNet credentials to grant privileged access even if the systems handle a low volume of unique credentials per day.
To request an exception to the policy against proxied CalNet authentication, please complete the following exception request and submit it to firstname.lastname@example.org.
All applications/systems that proxy CalNet authentication must take appropriate mitigation measures to protect against compromise of CalNet credentials. Please review the list of requirements below and confirm that your application/system meets them all. In addition, please respond to the application/system information and mitigation questions below.
- Security Contact:
Please answer the following questions:
- Name of application/system:
- Function of application/system, including type of data housed/accessed:
- Who authenticates to this application/system? Are they in positions where their credentials are likely to be used to access sensitive data in other applications/systems?
- What volume of CalNet authentication requests is your application/system likely to handle (daily, weekly, monthly)?
- Will standard CalNet authentication to your application/system grant privileged access? If so, please keep in mind that the MSSEI requires CalNet Second-Level or second-factor authentication for applications/systems that house data requiring high confidentiality.
- Are you requesting permission to proxy CalNet authentication indefinitely or do you anticipate being able to modify your system or application in the future to not require proxied CalNet (and if so, when)?
Please answer the following questions:
- Please describe alternate authentication methods you have evaluated and explain why you feel proxied CalNet authentication is the best choice.
- Please describe how your application/system proxies CalNet authentication.
- What safeguards are employed to ensure that responses from campus Kerberos or LDAP servers cannot be spoofed (see Required Protection Measures #3 and #4 below)?
- What safeguards are in place to ensure that CalNet credentials are not exposed over the network or to unauthorized users on your system?
- Describe how you protect the device from compromise and what methods / software you use to detect whether a compromise has occurred.
- Is your device routinely scanned for network vulnerabilities? Who scans the device and how? Does your firewall allow scanner traffic in?
- How do you authenticate privileged (root, Administrator, etc.) access on the device? Is this authentication logged?
- What events are audited on the device? Where are the events logged? Are copies made of those logs? Where are they stored? Who has access to the logs and their copies (if any)?
Please confirm that your system has established the following required protective measures:
- A designated security contact for the device must respond to all SNS vulnerability and intrusion detection notifications within 4 business hours.
- A security incident response plan for the device must be developed, tested, and communicated to all system administrators.
- CalNet passphrases shall not be stored locally under any circumstances.
- All Kerberos proxy authenticators must protect against spoofed KDC responses by obtaining a service ticket with each TGT they obtain from the KDC and validating it against their service key obtained in advance from the KDC administrator.
- All LDAP based proxy authenticators must protect against spoofed LDAP server responses by validating responses against the LDAP server x.509 certificate.
- All users with privileged access to device must sign a Privileged Access Agreement and file the agreement with the appropriate campus official.
- Device must be registered in the Restricted Data Management application.
- The contents of the system's storage must be securely erased from all devices when equipment is retired/repurposed.
- Device must meet all minimum security standards and best practices for the device and/or operating system type.