Network Working Group A. Medvinsky Request for Comments: 2712 Excite Category: Standards Track M. Hur CyberSafe Corporation October 1999
Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
IESG Note:
The 40-bit ciphersuites defined in this memo are included only for the purpose of documenting the fact that those ciphersuite codes have already been assigned. 40-bit ciphersuites were designed to comply with US-centric, and now obsolete, export restrictions. They were never secure, and nowadays are inadequate even for casual applications. Implementation and use of the 40-bit ciphersuites defined in this document, and elsewhere, is strongly discouraged.
This document proposes the addition of new cipher suites to the TLS protocol [1] to support Kerberos-based authentication. Kerberos credentials are used to achieve mutual authentication and to establish a master secret which is subsequently used to secure client-server communication.
Flexibility is one of the main strengths of the TLS protocol. Clients and servers can negotiate cipher suites to meet specific security and administrative policies. However, to date, authentication in TLS is limited only to public key solutions. As a result, TLS does not fully support organizations with heterogeneous security deployments that include authentication systems based on symmetric cryptography. Kerberos, originally developed at MIT, is
Medvinsky & Hur Standards Track [Page 1]
RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
based on an open standard [2] and is the most widely deployed symmetric key authentication system. This document proposes a new option for negotiating Kerberos authentication within the TLS framework. This achieves mutual authentication and the establishment of a master secret using Kerberos credentials. The proposed changes are minimal and, in fact, no different from adding a new public key algorithm to the TLS framework.
This section describes the addition of the Kerberos authentication option to the TLS protocol. Throughout this document, we refer to the basic SSL handshake shown in Figure 1. For a review of the TLS handshake see [1].
FIGURE 1: The TLS protocol. All messages followed by a star are optional. Note: This figure was taken from an IETF document [1].
The TLS security context is negotiated in the client and server hello messages. For example: TLS_RSA_WITH_RC4_MD5 means the initial authentication will be done using the RSA public key algorithm, RC4 will be used for the session key, and MACs will be based on the MD5 algorithm. Thus, to facilitate the Kerberos authentication option, we must start by defining new cipher suites including (but not limited to):
Medvinsky & Hur Standards Track [Page 2]
RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
To establish a Kerberos-based security context, one or more of the above cipher suites must be specified in the client hello message. If the TLS server supports the Kerberos authentication option, the server hello message, sent to the client, will confirm the Kerberos cipher suite selected by the server. The server's certificate, the client
CertificateRequest, and the ServerKeyExchange shown in Figure 1 will be omitted since authentication and the establishment of a master secret will be done using the client's Kerberos credentials for the TLS server. The client's certificate will be omitted for the same reason. Note that these messages are specified as optional in the TLS protocol; therefore, omitting them is permissible.
The Kerberos option must be added to the ClientKeyExchange message as shown in Figure 2.
Medvinsky & Hur Standards Track [Page 3]
RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
struct { select (KeyExchangeAlgorithm) { case krb5: KerberosWrapper; /* new addition */ case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic; } Exchange_keys;
} ClientKeyExchange;
struct { opaque Ticket; opaque authenticator; /* optional */ opaque EncryptedPreMasterSecret; /* encrypted with the session key which is sealed in the ticket */ } KerberosWrapper; /* new addition */
FIGURE 2: The Kerberos option in the ClientKeyExchange.
To use the Kerberos authentication option, the TLS client must obtain a service ticket for the TLS server. In TLS, the ClientKeyExchange message is used to pass a random 48-byte pre-master secret to the server.
The client and server then use the pre-master secret to independently derive the master secret, which in turn is used for generating session keys and for MAC computations. Thus, if the Kerberos option is selected, the pre-master secret structure is the same as that used in the RSA case; it is encrypted under the Kerberos session key and sent to the TLS server along with the Kerberos credentials (see Figure 2). The ticket and authenticator are encoded per RFC 1510 (ASN.1 encoding). Once the ClientKeyExchange message is received, the server's secret key is used to unwrap the credentials and extract the pre-master secret.
Note that a Kerberos authenticator is not required, since the master secret derived by the client and server is seeded with a random value passed in the server hello message, thus foiling replay attacks. However, the authenticator may still prove useful for passing authorization information and is thus allotted an optional field (see Figure 2).
Lastly, the client and server exchange the finished messages to complete the handshake. At this point we have achieved the following:
Medvinsky & Hur Standards Track [Page 4]
RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
1) A master secret, used to protect all subsequent communication, is securely established.
2) Mutual client-server authentication is achieved, since the TLS server proves knowledge of the master secret in the finished message.
Note that the Kerberos option fits in seamlessly, without adding any new messages.
To obtain an appropriate service ticket, the TLS client must determine the principal name of the TLS server. The Kerberos service naming convention is used for this purpose, as follows:
host/MachineName@Realm where: - The literal, "host", follows the Kerberos convention when not concerned about the protection domain on a particular machine. - "MachineName" is the particular instance of the service. - The Kerberos "Realm" is the domain name of the machine.
The proposed Kerberos authentication option is added in exactly the same manner as a new public key algorithm would be added to TLS. Furthermore, it establishes the master secret in exactly the same manner.
Kerberos ciphersuites are subject to the same security considerations as the TLS protocol. In addition, just as a public key implementation must take care to protect the private key (for example the PIN for a smartcard), a Kerberos implementation must take care to protect the long lived secret that is shared between the principal and the KDC. In particular, a weak password may be subject to a dictionary attack. In order to strengthen the initial authentication to a KDC, an implementor may choose to utilize secondary authentication via a token card, or one may utilize initial authentication to the KDC based on public key cryptography (commonly known as PKINIT - a product of the Common Authentication Technology working group of the IETF).
Medvinsky & Hur Standards Track [Page 5]
RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.