CalNet Authentication Guidelines

Please read the guidelines below before you integrate your application with central campus authentication services. If you have questions or need support, please contact the CalNet team at calnet-admin@lists.berkeley.edu

Consider Risk When Choosing an Authentication Method

When choosing an authentication approach, System Administrators should consider the risk of compromising CalNet credentials first and ease of implementation next. In cases where fully kerberizing a client application through the use of native Kerberos authentication is extremely difficult or costly, application owners may have a good business case for having that application pass user credentials to a Kerberos proxy for authentication. Non-Kerberos based methods of authentication, such as NTLM and LDAP, should be considered using the same criteria when used with CalNet.

Some factors to consider when evaluating proxy authentication include:

  • Volume of credentials a machine/application will handle. For remote desktop login, exposure/risk is minimal. For machines with high volume use, like UNIX servers and Windows Terminal servers with many users authenticating, a comprehensive security review is critical prior to implementation.
  • Security of machine/application that handles credentials (see Minimum Security Standards)
  • Method in which credentials are handled
  • Impact of compromise if credentials exposed
  • The need for different credentials for gaining privileged access vs. non privileged access
  • The reality that a user must expose some device to their credentials in order to authenticate

System Administrators considering proxy authentication must consult with the campus IT security team before proxying CalNet authentication.

General Guidelines and Expectations for Authentication

Native Kerberos Authentication

The CalNet team strongly recommends the use of native Kerberos authentication against the authoritative MIT KDCs and recommends the use of native Kerberos authentication against the AD KDCs in certain circumstances (see discussion above and examples below). The use of native Kerberos authentication prevents the unnecessary exposure of CalNet passphrases to the application.

Proxy Kerberos Authentication

IST strongly discourages proxied Kerberos authentication as a compromise of a host through which credentials pass could result in a compromise of all of the credentials. (One of the strengths of the Kerberos protocol is that a user's credentials never transit the network as part of the protocol.) Applications making use of proxy authentication must not store CalNet credentials or transmit them unencrypted. All 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.

Central Authentication System (CAS) is an IST supported proxy authentication system for web applications also used by our SAML2 Shibboleth service. When an application requires a user to authenticate, it redirects the user to CAS. The user types their CalNet credentials into a web form submitted to the CAS server. If their credentials are valid, they are redirected back to the original application. One way that CAS differs from other proxy authentication systems is that the user types credentials into a web form that is submitted directly to the CAS server; the users credentials are not passed through the web application the user wishes to use. CAS also provides single sign-on for all web applications that use it. Use CAS or SAML2 (Shibboleth) for web application authentication whenever possible.

NTLM Authentication

NTLM is a legacy Microsoft protocol with an authentication component. For authentication, NTLM uses a challenge-response method of authentication which does not send the user's password in any form over the network. Two versions of NTLM exist; NTLMv2 was developed by Microsoft to deal with various weaknesses in NTLMv1. With regard to the concerns raised in this document, NTLMv2 may be considered equivalent to Kerberos in terms of how it handles passwords. Administrators should use Kerberos whenever possible given the legacy status of NTLMv2.

LDAP Authentication

LDAP directories, including Active Directory, may be used to authenticate individual users. This is typically achieved by binding to the LDAP directory with the user's credentials; the success or failure of the bind determines the success or failure of the user's attempt to authenticate. This method of authentication is classified as proxy authentication as it requires transmission of the user's password in some form from the user's device to the intermediate application server and on through to the LDAP server. The additional transmission of the user's password from the application server to the LDAP server is not present in proxied Kerberos authentication. For this reason the use of proxy Kerberos authentication is preferred over LDAP based authentication. IST strongly discourages LDAP based authentication as a compromise of a host through which credentials pass could result in a compromise of all of the credentials. (One of the strengths of the Kerberos protocol is that a user's credentials never transit the network as part of the protocol.) All applications making use of proxy authentication must not store CalNet credentials or transmit them unencrypted. All LDAP based proxy authenticators must protect against spoofed LDAP server responses by validating responses against the LDAP server x509 certificate.

Native vs. Proxy Kerberos Authentication

The preferred method of authenticating users is to use native Kerberos 1 authentication, where the user invokes a Kerberos client running on their local device to obtain a ticket granting ticket (TGT) from the Key Distribution Center (KDC). The TGT is then used to obtain service tickets so that the user may authenticate to various applications. Service tickets are obtained without the user having to reenter their passphrase, thus providing single sign-on. This method of authentication limits exposure of the user's passphrase to the local device since the Kerberos protocol does not require the transmission of the user's passphrase to applications or the KDC in order for the user to authenticate to applications. Many applications have not historically supported native Kerberos for authentication (some application vendors have begun to support native Kerberos in response to Microsoft's decision to use Kerberos as its authentication protocol in AD).

Proxy authentication allows an application to avoid native implementation of Kerberos by prompting the user to enter their username and passphrase (as opposed to using service tickets). Once the application is in possession of the user's credentials (in this document credentials are a user's CalNet ID and passphrase), either the application itself or a separate service, as a proxy for the user, obtains a TGT. (Proxy authentication is also known as pass through authentication as the application passes the users credentials through to the process used to obtain a TGT.) Depending on the complexity of the proxy service, single sign-on may or may not be available. The disadvantage of proxy authentication as compared to native Kerberos authentication is the additional exposure of the user's credentials to the application and the proxy service.

To reiterate the key difference between native Kerberos and proxy authentication, in native Kerberos the user's passphrase never leaves the device into which it is input while in proxy authentication the user's passphrase is transmitted over the network.

When evaluating the risks associated with proxy authentication vs. native Kerberos authentication, the key factors to consider are the scope and scale of credential exposure. The scope of exposure comprises the systems exposed to the credentials, their composition, security, etc. The scale of credential exposure is the number of unique credentials the system is exposed to over a period of time and the rate of exposure during that time.

Authentication Examples

Web Applications

IST encourages campus developers to take advantage of central campus authentication services when developing and integrating new applications. CAS is the IST sanctioned web-proxied Kerberos authentication (against the authoritative MIT KDC) and should be the first external authentication choice for campus developers. Our SAML2 IdP based on Shibboleth also uses CAS and is primarily used for applications (SPs) requiring federation with non-Berkeley IdPs. Extensive documentation is available on the CalNet developer's site to aid developers in integrating CAS authentication (or SAML2 using Shibboleth) with their applications, and the CalNet team is available for consultation.

  • If a new web application is under development, use CAS. If it requires federation with non-Berkeley IdPs, consider SAML2 using Shibboleth.
  • A Windows-based web server that is part of the campus AD, runs a web application. This application supports authenticating users via HTTP auth using AD accounts and CAS authentication. CAS authentication is strongly preferred over HTTP auth as the later can expose the server to CalNet IDs and passphrases.
  • A number of IST applications (TMS, BearFacts, ...) were written in Java before CAS was available. AWS 2 was not compatible with the Java security model, so IST approved the addition of code which allowed these applications to handle and pass user credentials to Kerberos. CAS is fully Java security compliant and these web applications should migrate to CAS authentication in the future.
  • .Net application developers may be interested in authenticating directly against the AD KDC. Some browser configurations allow fully integrated native Kerberos authentication (no credentials are handled by the applicaiton or passed over network). Where native Kerberos authentication support is not possible due to a lack of client support, the application should use CAS to authenticate users.
  • Form based authentication in which applications handle and transmit credentials must undergo a comprehensive security review prior to implementation. This includes the use of modules such as mod_kerb for Apache, or mod_pam where pam is configured to authenticate users against the KDCs. Also included in this category is IIS when configured for compatibility mode when SPNEGO is not supported by the user's browser.
  • IST encourages campus developers to integrate CAS authentication for third party web applications. This can sometimes be more difficult than with homegrown apps. The CalNet team hopes to expand its documentation to help developers integrate CAS with third party applications.
  • For third party web applications running under Apache, authentication shims (such as mod_auth_cas) allow applications to integrate with CAS provided they support http basic authentication.
  • At least one shim solution exists for IIS. System administrators are encouraged to explore solutions in this area.
  • If it is not feasible to use CAS with a web application, proxy authentication methods (via Kerberos or LDAP) may be used, but only after a comprehensive security review by the campus IT security team.

Client Based Applications

  • Locally developed and third party client based applications should use native Kerberos.
  • Client based applications may use the legacy NTLMv2 protocol if no support for native Kerberos exists.
  • If a third party client based application does not support native Kerberos, proxy authentication (via Kerberos or LDAP) may be used if approved by the campus IT security team.

System login

  • A Unix host uses a PAM plugin to authenticate remote user sessions against the KDCs. In this configuration, pass through authentication occurs when ssh is used to log into the machine remotely. Many implementations of ssh support native use of Kerberos; as long as the ssh server and clients used support native Kerberos this method of authentication is strongly preferred over pass through configurations. All uses of a pass through configuration must go through a comprehensive review by the campus IT security team.
  • Workstation login - Remote login to a desktop or workstation is a form of proxied authentication, but for individual workstations with a very low volume of users, the risk of credential exposure is low due to the use of different credentials for privileged access to systems or to sensitive data.
  • No special security review is required for remote workstation login (e.g. RDP on Windows and PAM on UNIX workstations).
  • Systems that are most often accessed remotely and are exposed to a significant volume of user credentials (50 or more unique CalNet IDs per day) should undergo a review by the campus IT security team. Examples include terminal services machines and UNIX systems where proxy authentication is used.
  • Systems that are most often accessed directly (i.e. a public kiosk or lab workstation using CalNet for user log in) do not require explicit review and approval, regardless of the volume of user credentials the systems are exposed to. The reason this case differs from the previous one stems from the fact that the user must type their credentials in somewhere. Without an additional factor or the use of one time passwords, in terms of the risks associated with the authentication method employed one can't do any better in this case. In the case of proxy authentication, one can do better in terms of the risks by not using proxy authentication. This is the essential difference between these two cases and why this document treats them differently.

1 Kerberos is the service upon which all other CalNet authentication services are based. Kerberos is also a protocol, for which multiple vendors offer implementations (both commercial and open source).

2 The locally developed Authentication Web Service (AWS) is deprecated in favor of the community developed and supported CAS. Applications using AWS should be reworked to use CAS instead.