idnits 2.17.1 draft-ietf-tls-kerb-cipher-suites-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1510 (ref. '2') (Obsoleted by RFC 4120, RFC 6649) Summary: 13 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Ari Medvinsky 2 Transport Layer Security Working Group Matthew Hur 3 draft-ietf-tls-kerb-cipher-suites-00.txt CyberSafe Corporation 4 Nov. 96 (Expires May-97) 6 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) 8 0. Status Of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), 24 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 25 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 27 1. Abstract 29 This document proposes the addition of new cipher suites to the TLS 30 protocol (SSL 3.0) to support Kerberos-based authentication. Kerberos 31 credentials are used to achieve mutual authentication and to establish 32 a master secret which is subsequently used to secure client-server 33 communication. 35 2. Introduction 37 Flexibility is one of the main strengths of the TLS (SSL 3.0) protocol. 38 Clients and servers can negotiate cipher suites to meet specific 39 security and administrative policies. However, to date, authentication 40 in TLS is limited only to public key solutions. As a result, TLS does 41 not fully support organizations with heterogeneous security deployments 42 that include authentication systems based on symmetric cryptography. 43 Kerberos, originally developed at MIT, is based on an open standard[2] 44 and is the most widely deployed symmetric key authentication system. 45 This document proposes a new option for negotiating Kerberos 46 authentication within the TLS framework. This achieves mutual 47 authentication and the establishment of a master secret using Kerberos 48 credentials. The proposed changes are minimal and, in fact, no 49 different from adding a new public key algorithm to the TLS framework. 51 3. Kerberos Authentication Option In TLS 53 This section describes the addition of the Kerberos authentication 54 option to the TLS protocol (SSL v3.0). Throughout this document, we 55 refer to the basic SSL handshake shown in Figure 1. For a review of 56 the SSL handshake see [1]. 58 CLIENT SERVER 59 ------ ------ 61 ClientHello --------------------------------> 62 ServerHello 63 Certificate * 64 CertificateRequest* 65 ServerKeyExchange* 66 <------------------------------- 67 Certificate* 68 ClientKeyExchange 69 CertificateVerify* 70 change cipher spec 71 Finished 72 --------------------------------> 73 change cipher spec 74 | Finished 75 | | 76 | | 77 Application Data <------------------------------->Application Data 79 FIGURE 1: The SSL protocol. All messages followed by a star are 80 optional. Note: This figure was taken from an IETF draft [1]. 82 The TLS security context is negotiated in the client and server hello 83 messages. For example: SSL_RSA_WITH_RC4_MD5 means the initial 84 authentication will be done using the RSA public key algorithm, RC4 will 85 be used for the session key, and MACs will be based on the MD5 86 algorithm. Thus, to facilitate the Kerberos authentication option, we 87 must start by defining new cipher suites including (but not limited to): 89 CipherSuite SSL_KRB5_EXPORT_WITH_DES40_CBC_SHA 90 CipherSuite SSL_KRB5_WITH_DES_CBC_SHA 91 CipherSuite SSL_KRB5_WITH_3DES_EDE_CBC_SHA 92 CipherSuite SSL_KRB5_EXPORT_WITH_RC4_40_MD5 93 CipherSuite SSL_KRB5_WITH_RC4_128_MD5 94 CipherSuite SSL_KRB5_WITH_RC4_128_SHA 95 CipherSuite SSL_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 96 CipherSuite SSL_KRB5_WITH_IDEA_CBC_SHA 98 To establish a Kerberos-based security context, one or more of the above 99 cipher suites must be specified in the client hello message. If the TLS 100 server supports the Kerberos authentication option, the server hello 101 message, sent to the client, will confirm the Kerberos cipher suite 102 selected by the server. The server's certificate, the client 103 CertificateRequest, and the ServerKeyExchange shown in Figure 1 will be 104 omitted since authentication and the establishment of a master secret 105 will be done using the client's Kerberos credentials for the TLS server. 106 The client's certificate will be omitted for the same reason. Note that 107 these messages are specified as optional in the TLS protocol; therefore, 108 omitting them is permissible. 110 The Kerberos option must be added to the ClientKeyExchange message as 111 shown in Figure 2. 113 struct 114 { 115 select (KeyExchangeAlgorithm) 116 { 117 case krb5: KerberosWrapper; /* new addition */ 118 case rsa: EncryptedPreMasterSecret; 119 case diffie_hellman: ClientDiffieHellmanPublic; 120 case fortezza_dms: ForTezzaKeys; 121 } Exchange_keys; 123 } ClientKeyExchange; 125 struct 126 { 127 opaque Ticket; 128 opaque authenticator; /* optional */ 129 opaque EncryptedPreMasterSecret; /* encrypted with the session key 130 which is sealed in the ticket */ 131 } KerberosWrapper; /* new addition */ 133 FIGURE 2: The Kerberos option in the ClientKeyExchange. 135 To use the Kerberos authentication option, the TLS client must obtain a 136 service ticket for the TLS server. In TLS, the ClientKeyExchange 137 message is used to pass a random 48-byte pre-master secret to the server. 138 The client and server then use the pre-master secret to independently 139 derive the master secret, which in turn is used for generating session 140 keys and for MAC computations. Thus, if the Kerberos option is selected, 141 the pre-master secret is encrypted under the Kerberos session key and 142 sent to the TLS server along with the Kerberos credentials (see Figure 2). 143 Once the ClientKeyExchange message is received, the server's secret key 144 is used to unwrap the credentials and extract the pre-master secret. 146 Note that a Kerberos authenticator is not required, since the master 147 secret derived by the client and server is seeded with a random value 148 passed in the server hello message, thus foiling replay attacks. 149 However, the authenticator may still prove useful for passing 150 authorization information and is thus allotted an optional field (see 151 Figure 2). 153 Lastly, the client and server exchange the finished messages to complete 154 the handshake. At this point we have achieved the following: 155 1) A master secret, used to protect all subsequent communication, is 156 securely established. 158 2) Mutual client-server authentication is achieved, since the TLS 159 server proves knowledge of the master secret in the finished message. 161 Note that the Kerberos option fits in seamlessly, without adding any new 162 messages. 164 4. Discussion 166 4.1 Naming Conventions: 168 To obtain an appropriate service ticket, the TLS client must determine 169 the principal name of the TLS server. The Kerberos service naming 170 convention is used for this purpose, as follows: 171 TLS/MachineName@Realm 172 where: 173 - The "TLS" component represents the service name. 174 - "MachineName" is the particular instance of the service. 175 - The Kerberos "Realm" is the domain name of the machine. 177 Open issue: 178 To allow some TLS-enabled services to run in a different protection 179 domain, a port number may optionally be part of the service principal 180 name; for example, TLS/MachineName/port@Realm. 181 One solution for negotiating the servce port number is as follows: 182 The client requests the ticket for a specific port. If the principal 183 name for that port is not registered, then the client requests the 184 generic ticket for TLS on the host. 186 4.2 Passing Kerberos Tickets 188 Clifford Neuman suggested the following approach as a topic for 189 discussion: 190 Conceptually, the client's Kerberos ticket may be viewed as a custom 191 certificate, recognized only by the TLS server. Therefore, the 192 client's certificate message may be used for passing the client's 193 Kerberos credentials to the TLS server. 195 5. Summary 197 The proposed Kerberos authentication option is added in exactly the 198 same manner as a new public key algorithm would be added to TLS. 199 Furthermore, it establishes the master secret in exactly the same manner. 201 6. Acknowledgements 203 We would like to thank Clifford Neuman for his invaluable comments on 204 earlier versions of this document. 206 7. References 208 [1] Alan O. Freier, Philip Karlton and Paul C. Kocher. 209 The SSL Protocol, Version 3.0 - IETF Draft. 211 [2] J. Kohl and C. Neuman 212 The Kerberos Network Authentication Service (V5) RFC 1510. 214 Authors' Addresses 216 Ari Medvinsky 217 Matthew Hur 219 CyberSafe Corporation 220 1605 NW Sammamish Raod 221 Suite 310 222 Issaquah, WA 98027-5378 223 Phone: (206) 391-6000 224 Fax: (206) 391-0508 225 http:/www.cybersafe.com