Kerberos in TLS: Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
Lets a TLS connection authenticate with Kerberos tickets instead of public-key certificates.
Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, DOI 10.17487/RFC2712, October 1999, <https://www.rfc-editor.org/info/rfc2712>.
@misc{rfc2712,
series = {Request for Comments},
number = 2712,
howpublished = {RFC 2712},
publisher = {RFC Editor},
doi = {10.17487/RFC2712},
url = {https://www.rfc-editor.org/info/rfc2712},
author = {A. Medvinsky and M. Hur},
title = {{Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)}},
pagetotal = 7,
year = 1999,
month = oct,
} RFC text
Contents
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.
1. Abstract
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.
2. Introduction
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
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.
3. Kerberos Authentication Option In TLS
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].
CLIENT SERVER
------ ------
ClientHello
-------------------------------->
ServerHello
Certificate *
ServerKeyExchange*
CertificateRequest*
ServerHelloDone
<-------------------------------
Certificate*
ClientKeyExchange
CertificateVerify*
change cipher spec
Finished
| -------------------------------->
| change cipher spec
| Finished
| |
| |
Application Data <------------------------------->Application Data
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):
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 };
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B };
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.
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:
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.
4. Naming Conventions:
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.
5. Summary
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.
6. Security Considerations
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).
7. Acknowledgements
We would like to thank Clifford Neuman for his invaluable comments on
earlier versions of this document.
8. References
[1] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC
2246, January 1999.
[2] Kohl J. and C. Neuman, "The Kerberos Network Authentication
Service (V5)", RFC 1510, September 1993.
9. Authors' Addresses
Ari Medvinsky
Excite
555 Broadway
Redwood City, CA 94063
Phone: +1 650 569 2119
EMail: amedvins@excitecorp.com
http://www.excite.com
Matthew Hur
CyberSafe Corporation
1605 NW Sammamish Road
Issaquah WA 98027-5378
Phone: +1 425 391 6000
EMail: matt.hur@cybersafe.com
http://www.cybersafe.com
10. Full Copyright Statement
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.
AI ELI5
On this page
§1Kerberos Meets TLS
TLS lets clients and servers negotiate cipher suites to match their security and administrative policies. Until this RFC, though, authentication in TLS was limited to public key solutions, so organizations with authentication systems based on symmetric cryptography were not fully served.
Kerberos, which the RFC calls the most widely deployed symmetric key authentication system, is described in RFC 1510. This document adds a Kerberos option to the TLS framework (RFC 2246). The RFC calls the change minimal, no different from adding a new public key algorithm.
Some places check ID cards and others use tickets. This lets the secure-connection system work with places that use tickets too.
§2New Cipher Suites
The TLS security context is chosen in the client and server hello messages. The RFC defines new cipher suites whose names start with TLS_KRB5. They use DES, 3DES, RC4 with 128 bits, or IDEA for the bulk cipher, and SHA or MD5 for the MAC. Their codes run from 0x00,0x1E through 0x00,0x25. Six more export suites, with 40-bit keys, take codes 0x00,0x26 through 0x00,0x2B.
To use Kerberos, the client lists one or more of these suites in its client hello. A server that supports the option confirms the chosen Kerberos suite in its server hello.
An IESG note says the 40-bit suites are included only to document that their codes were already assigned. They were designed for now-obsolete export restrictions, were never secure, and implementing or using them is strongly discouraged.
The client shows a menu of secret-code styles, and the server picks one. This RFC adds new menu items that use Kerberos tickets.
§3The Kerberos ClientKeyExchange
The ClientKeyExchange message gets a new case. When the key exchange algorithm is krb5, the message carries a KerberosWrapper instead of an RSA-encrypted or Diffie-Hellman value.
The wrapper holds three parts: the Kerberos Ticket, an optional authenticator, and the EncryptedPreMasterSecret, encrypted with the session key sealed in the ticket. The ticket and authenticator are encoded per RFC 1510 (ASN.1 encoding).
The client hands over a sealed envelope with its ticket and a secret note that only the ticket's owner and the server can open.
struct
{
opaque Ticket;
opaque authenticator; /* optional */
opaque EncryptedPreMasterSecret; /* encrypted with the session key
which is sealed in the ticket */
} KerberosWrapper;§4How the Handshake Changes
To use this option, the client must first obtain a service ticket for the TLS server. In TLS, the ClientKeyExchange passes a random 48-byte pre-master secret to the server. Both sides then derive the master secret from it independently, and use that for session keys and MAC computations. With Kerberos the pre-master secret has the same structure as in the RSA case, but it is encrypted under the Kerberos session key. The server uses its secret key to unwrap the credentials and extract the pre-master secret.
Several optional TLS messages are left out: the server's Certificate, the ServerKeyExchange, the CertificateRequest and the client's Certificate. Authentication and the master secret come from the client's Kerberos credentials, and TLS already marks those messages optional. The authenticator is not required, because the master secret is seeded with a random value from the server hello, which foils replay attacks. It remains optional because it can carry authorization information.
After the Finished messages are exchanged, the master secret is established and mutual authentication is achieved, because the server proves it knows the master secret in its Finished message. No new messages are added.
The client and server both use the ticket to agree on a shared secret. The server proves it knows the secret, so each side knows who the other is.
§5Naming the Server
To get the right service ticket, the client must know the Kerberos principal name of the TLS server. The RFC uses the form host/MachineName@Realm. The literal host follows the Kerberos convention when the protection domain on a machine does not matter, MachineName is the particular instance of the service, and Realm is the domain name of the machine.
To get the right ticket, the client has to spell the server's name in the exact way Kerberos expects.
§6Security Considerations
The Kerberos cipher suites are subject to the same security considerations as TLS. Just as a public key implementation must protect its private key, a Kerberos implementation must protect the long lived secret shared between the principal and the KDC. A weak password may be open to a dictionary attack.
To strengthen the first authentication to the KDC, an implementor may use secondary authentication with a token card, or initial authentication based on public key cryptography, commonly known as PKINIT.
A ticket system is only as safe as the secret behind it. A guessable password is like a lock that opens with the first key you try.