draft-ietf-tls-kerb-cipher-suites-00.txt   draft-ietf-tls-kerb-cipher-suites-01.txt 
INTERNET-DRAFT Ari Medvinsky INTERNET-DRAFT Ari Medvinsky
Transport Layer Security Working Group Matthew Hur Transport Layer Security Working Group Matthew Hur
draft-ietf-tls-kerb-cipher-suites-00.txt CyberSafe Corporation draft-ietf-tls-kerb-cipher-suites-01.txt CyberSafe Corporation
Nov. 96 (Expires May-97) July 97 (Expires Feb-98)
Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
0. Status Of this Memo 0. Status Of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
skipping to change at line 30 skipping to change at line 31
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet- the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), Drafts Shadow Directories on ftp.is.co.za (Africa),
nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
1. Abstract 1. Abstract
This document proposes the addition of new cipher suites to the TLS This document proposes the addition of new cipher suites to the TLS
protocol (SSL 3.0) to support Kerberos-based authentication. Kerberos protocol [1] to support Kerberos-based authentication. Kerberos
credentials are used to achieve mutual authentication and to establish credentials are used to achieve mutual authentication and to establish
a master secret which is subsequently used to secure client-server a master secret which is subsequently used to secure client-server
communication. communication.
2. Introduction 2. Introduction
Flexibility is one of the main strengths of the TLS (SSL 3.0) protocol. Flexibility is one of the main strengths of the TLS protocol.
Clients and servers can negotiate cipher suites to meet specific Clients and servers can negotiate cipher suites to meet specific
security and administrative policies. However, to date, authentication security and administrative policies. However, to date, authentication
in TLS is limited only to public key solutions. As a result, TLS does in TLS is limited only to public key solutions. As a result, TLS does
not fully support organizations with heterogeneous security deployments not fully support organizations with heterogeneous security deployments
that include authentication systems based on symmetric cryptography. that include authentication systems based on symmetric cryptography.
Kerberos, originally developed at MIT, is based on an open standard[2] Kerberos, originally developed at MIT, is based on an open standard[2]
and is the most widely deployed symmetric key authentication system. and is the most widely deployed symmetric key authentication system.
This document proposes a new option for negotiating Kerberos This document proposes a new option for negotiating Kerberos
authentication within the TLS framework. This achieves mutual authentication within the TLS framework. This achieves mutual
authentication and the establishment of a master secret using Kerberos authentication and the establishment of a master secret using Kerberos
credentials. The proposed changes are minimal and, in fact, no credentials. The proposed changes are minimal and, in fact, no
different from adding a new public key algorithm to the TLS framework. different from adding a new public key algorithm to the TLS framework.
3. Kerberos Authentication Option In TLS 3. Kerberos Authentication Option In TLS
This section describes the addition of the Kerberos authentication This section describes the addition of the Kerberos authentication
option to the TLS protocol (SSL v3.0). Throughout this document, we option to the TLS protocol. Throughout this document, we refer to the
refer to the basic SSL handshake shown in Figure 1. For a review of basic SSL handshake shown in Figure 1. For a review of the TLS
the SSL handshake see [1]. handshake see [1].
CLIENT SERVER CLIENT SERVER
------ ------ ------ ------
ClientHello
ClientHello --------------------------------> -------------------------------->
ServerHello ServerHello
Certificate * Certificate *
CertificateRequest*
ServerKeyExchange* ServerKeyExchange*
CertificateRequest*
ServerHelloDone
<------------------------------- <-------------------------------
Certificate* Certificate*
ClientKeyExchange ClientKeyExchange
CertificateVerify* CertificateVerify*
change cipher spec change cipher spec
Finished Finished
--------------------------------> | -------------------------------->
change cipher spec | change cipher spec
| Finished | Finished
| | | |
| | | |
Application Data <------------------------------->Application Data Application Data <------------------------------->Application Data
FIGURE 1: The SSL protocol. All messages followed by a star are FIGURE 1: The TLS protocol. All messages followed by a star are
optional. Note: This figure was taken from an IETF draft [1]. optional. Note: This figure was taken from an IETF draft [1].
The TLS security context is negotiated in the client and server hello The TLS security context is negotiated in the client and server hello
messages. For example: SSL_RSA_WITH_RC4_MD5 means the initial messages. For example: TLS_RSA_WITH_RC4_MD5 means the initial
authentication will be done using the RSA public key algorithm, RC4 will 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 be used for the session key, and MACs will be based on the MD5
algorithm. Thus, to facilitate the Kerberos authentication option, we algorithm. Thus, to facilitate the Kerberos authentication option, we
must start by defining new cipher suites including (but not limited to): must start by defining new cipher suites including (but not limited to):
CipherSuite SSL_KRB5_EXPORT_WITH_DES40_CBC_SHA CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1C };
CipherSuite SSL_KRB5_WITH_DES_CBC_SHA CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1D };
CipherSuite SSL_KRB5_WITH_3DES_EDE_CBC_SHA CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x1E };
CipherSuite SSL_KRB5_EXPORT_WITH_RC4_40_MD5 CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x1F };
CipherSuite SSL_KRB5_WITH_RC4_128_MD5 CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x20 };
CipherSuite SSL_KRB5_WITH_RC4_128_SHA CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x21 };
CipherSuite SSL_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x22 };
CipherSuite SSL_KRB5_WITH_IDEA_CBC_SHA CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x24 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x25 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x26 };
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x27 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x28 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x29 };
To establish a Kerberos-based security context, one or more of the above 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 cipher suites must be specified in the client hello message. If the TLS
server supports the Kerberos authentication option, the server hello server supports the Kerberos authentication option, the server hello
message, sent to the client, will confirm the Kerberos cipher suite message, sent to the client, will confirm the Kerberos cipher suite
selected by the server. The server's certificate, the client selected by the server. The server's certificate, the client
CertificateRequest, and the ServerKeyExchange shown in Figure 1 will be CertificateRequest, and the ServerKeyExchange shown in Figure 1 will be
omitted since authentication and the establishment of a master secret omitted since authentication and the establishment of a master secret
will be done using the client's Kerberos credentials for the TLS server. will be done using the client's Kerberos credentials for the TLS server.
skipping to change at line 121 skipping to change at line 130
The Kerberos option must be added to the ClientKeyExchange message as The Kerberos option must be added to the ClientKeyExchange message as
shown in Figure 2. shown in Figure 2.
struct struct
{ {
select (KeyExchangeAlgorithm) select (KeyExchangeAlgorithm)
{ {
case krb5: KerberosWrapper; /* new addition */ case krb5: KerberosWrapper; /* new addition */
case rsa: EncryptedPreMasterSecret; case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic; case diffie_hellman: ClientDiffieHellmanPublic;
case fortezza_dms: ForTezzaKeys;
} Exchange_keys; } Exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
struct struct
{ {
opaque Ticket; opaque Ticket;
opaque authenticator; /* optional */ opaque authenticator; /* optional */
opaque EncryptedPreMasterSecret; /* encrypted with the session key opaque EncryptedPreMasterSecret; /* encrypted with the session key
which is sealed in the ticket */ which is sealed in the ticket */
} KerberosWrapper; /* new addition */ } KerberosWrapper; /* new addition */
FIGURE 2: The Kerberos option in the ClientKeyExchange. FIGURE 2: The Kerberos option in the ClientKeyExchange.
To use the Kerberos authentication option, the TLS client must obtain a To use the Kerberos authentication option, the TLS client must obtain a
service ticket for the TLS server. In TLS, the ClientKeyExchange 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. 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 The client and server then use the pre-master secret to independently
derive the master secret, which in turn is used for generating session derive the master secret, which in turn is used for generating session
keys and for MAC computations. Thus, if the Kerberos option is selected, keys and for MAC computations. Thus, if the Kerberos option is selected,
the pre-master secret is encrypted under the Kerberos session key and the pre-master secret structure is the same as that used in the RSA case;
sent to the TLS server along with the Kerberos credentials (see Figure 2). it is encrypted under the Kerberos session key and sent to the TLS server
Once the ClientKeyExchange message is received, the server's secret key along with the Kerberos credentials (see Figure 2). The ticket and
is used to unwrap the credentials and extract the pre-master secret. 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 Note that a Kerberos authenticator is not required, since the master
secret derived by the client and server is seeded with a random value secret derived by the client and server is seeded with a random value
passed in the server hello message, thus foiling replay attacks. passed in the server hello message, thus foiling replay attacks.
However, the authenticator may still prove useful for passing However, the authenticator may still prove useful for passing
authorization information and is thus allotted an optional field (see authorization information and is thus allotted an optional field (see
Figure 2). Figure 2).
Lastly, the client and server exchange the finished messages to complete Lastly, the client and server exchange the finished messages to complete
the handshake. At this point we have achieved the following: the handshake. At this point we have achieved the following:
1) A master secret, used to protect all subsequent communication, is 1) A master secret, used to protect all subsequent communication, is
securely established. securely established.
2) Mutual client-server authentication is achieved, since the TLS 2) Mutual client-server authentication is achieved, since the TLS
server proves knowledge of the master secret in the finished message. server proves knowledge of the master secret in the finished message.
Note that the Kerberos option fits in seamlessly, without adding any new Note that the Kerberos option fits in seamlessly, without adding any new
messages. messages.
4. Discussion 4. Naming Conventions:
4.1 Naming Conventions:
To obtain an appropriate service ticket, the TLS client must determine To obtain an appropriate service ticket, the TLS client must determine
the principal name of the TLS server. The Kerberos service naming the principal name of the TLS server. The Kerberos service naming
convention is used for this purpose, as follows: convention is used for this purpose, as follows:
TLS/MachineName@Realm host/MachineName@Realm
where: where:
- The "TLS" component represents the service name. - 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. - "MachineName" is the particular instance of the service.
- The Kerberos "Realm" is the domain name of the machine. - The Kerberos "Realm" is the domain name of the machine.
Open issue:
To allow some TLS-enabled services to run in a different protection
domain, a port number may optionally be part of the service principal
name; for example, TLS/MachineName/port@Realm.
One solution for negotiating the servce port number is as follows:
The client requests the ticket for a specific port. If the principal
name for that port is not registered, then the client requests the
generic ticket for TLS on the host.
4.2 Passing Kerberos Tickets
Clifford Neuman suggested the following approach as a topic for
discussion:
Conceptually, the client's Kerberos ticket may be viewed as a custom
certificate, recognized only by the TLS server. Therefore, the
client's certificate message may be used for passing the client's
Kerberos credentials to the TLS server.
5. Summary 5. Summary
The proposed Kerberos authentication option is added in exactly the The proposed Kerberos authentication option is added in exactly the
same manner as a new public key algorithm would be added to TLS. same manner as a new public key algorithm would be added to TLS.
Furthermore, it establishes the master secret in exactly the same manner. Furthermore, it establishes the master secret in exactly the same manner.
6. Acknowledgements 6. Acknowledgements
We would like to thank Clifford Neuman for his invaluable comments on We would like to thank Clifford Neuman for his invaluable comments on
earlier versions of this document. earlier versions of this document.
7. References 7. References
[1] Alan O. Freier, Philip Karlton and Paul C. Kocher. [1] T. Dierks, C. Allen.
The SSL Protocol, Version 3.0 - IETF Draft. The TLS Protocol, Version 1.0 - IETF Draft.
[2] J. Kohl and C. Neuman [2] J. Kohl and C. Neuman
The Kerberos Network Authentication Service (V5) RFC 1510. The Kerberos Network Authentication Service (V5) RFC 1510.
Authors' Addresses Authors' Addresses
Ari Medvinsky <arim@cybersafe.com> Ari Medvinsky <arim@cybersafe.com>
Matthew Hur <matth@cybersafe.com> Matthew Hur <matth@cybersafe.com>
CyberSafe Corporation CyberSafe Corporation
1605 NW Sammamish Raod 1605 NW Sammamish Raod
Suite 310 Suite 310
Issaquah, WA 98027-5378 Issaquah, WA 98027-5378
Phone: (206) 391-6000 Phone: (206) 391-6000
Fax: (206) 391-0508 Fax: (206) 391-0508
http:/www.cybersafe.com http://www.cybersafe.com
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/