idnits 2.17.1 draft-ietf-tls-kerb-cipher-suites-04.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-25) 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: ---------------------------------------------------------------------------- ** 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? == 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 1) being 248 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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) ** Obsolete normative reference: RFC 2246 (ref. '1') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 1510 (ref. '2') (Obsoleted by RFC 4120, RFC 6649) Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 3 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 Excite 3 draft-ietf-tls-kerb-cipher-suites-04.txt Matthew Hur 4 August 21, 1999 (Expires January 22, 2000) CyberSafe Corporation 6 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) 8 0. Status Of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of section 10 of RFC 2026. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), 13 its areas, and its working groups. Note that other groups may 14 also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as 20 ``work in progress.'' 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 To learn the current status of any Internet-Draft, please check 29 the ``1id-abstracts.txt'' listing contained in the Internet- 30 Drafts Shadow Directories on ftp.is.co.za (Africa), 31 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), 32 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 34 1. Abstract 36 This document proposes the addition of new cipher suites to the TLS 37 protocol [1] to support Kerberos-based authentication. Kerberos 38 credentials are used to achieve mutual authentication and to establish 39 a master secret which is subsequently used to secure client-server 40 communication. 42 2. Introduction 44 Flexibility is one of the main strengths of the TLS protocol. 45 Clients and servers can negotiate cipher suites to meet specific 46 security and administrative policies. However, to date, authentication 47 in TLS is limited only to public key solutions. As a result, TLS does 48 not fully support organizations with heterogeneous security deployments 49 that include authentication systems based on symmetric cryptography. 50 Kerberos, originally developed at MIT, is based on an open standard[2] 51 and is the most widely deployed symmetric key authentication system. 52 This document proposes a new option for negotiating Kerberos 53 authentication within the TLS framework. This achieves mutual 54 authentication and the establishment of a master secret using Kerberos 55 credentials. The proposed changes are minimal and, in fact, no 56 different from adding a new public key algorithm to the TLS framework. 58 3. Kerberos Authentication Option In TLS 60 This section describes the addition of the Kerberos authentication 61 option to the TLS protocol. Throughout this document, we refer to the 62 basic SSL handshake shown in Figure 1. For a review of the TLS 63 handshake see [1]. 65 CLIENT SERVER 66 ------ ------ 67 ClientHello 68 --------------------------------> 69 ServerHello 70 Certificate * 71 ServerKeyExchange* 72 CertificateRequest* 73 ServerHelloDone 74 <------------------------------- 75 Certificate* 76 ClientKeyExchange 77 CertificateVerify* 78 change cipher spec 79 Finished 80 | --------------------------------> 81 | change cipher spec 82 | Finished 83 | | 84 | | 85 Application Data <------------------------------->Application Data 87 FIGURE 1: The TLS protocol. All messages followed by a star are 88 optional. Note: This figure was taken from an IETF draft [1]. 90 The TLS security context is negotiated in the client and server hello 91 messages. For example: TLS_RSA_WITH_RC4_MD5 means the initial 92 authentication will be done using the RSA public key algorithm, RC4 will 93 be used for the session key, and MACs will be based on the MD5 94 algorithm. Thus, to facilitate the Kerberos authentication option, we 95 must start by defining new cipher suites including (but not limited to): 97 CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E }; 98 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F }; 99 CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 }; 100 CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 }; 101 CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 }; 102 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 }; 103 CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 }; 104 CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 }; 106 CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 }; 107 CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 }; 108 CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 }; 109 CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 }; 110 CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A }; 111 CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B }; 113 To establish a Kerberos-based security context, one or more of the above 114 cipher suites must be specified in the client hello message. If the TLS 115 server supports the Kerberos authentication option, the server hello 116 message, sent to the client, will confirm the Kerberos cipher suite 117 selected by the server. The server's certificate, the client 119 CertificateRequest, and the ServerKeyExchange shown in Figure 1 will be 120 omitted since authentication and the establishment of a master secret 121 will be done using the client's Kerberos credentials for the TLS server. 122 The client's certificate will be omitted for the same reason. Note that 123 these messages are specified as optional in the TLS protocol; therefore, 124 omitting them is permissible. 126 The Kerberos option must be added to the ClientKeyExchange message as 127 shown in Figure 2. 129 struct 130 { 131 select (KeyExchangeAlgorithm) 132 { 133 case krb5: KerberosWrapper; /* new addition */ 134 case rsa: EncryptedPreMasterSecret; 135 case diffie_hellman: ClientDiffieHellmanPublic; 136 } Exchange_keys; 138 } ClientKeyExchange; 140 struct 141 { 142 opaque Ticket; 143 opaque authenticator; /* optional */ 144 opaque EncryptedPreMasterSecret; /* encrypted with the session key 145 which is sealed in the ticket */ 146 } KerberosWrapper; /* new addition */ 148 FIGURE 2: The Kerberos option in the ClientKeyExchange. 150 To use the Kerberos authentication option, the TLS client must obtain a 151 service ticket for the TLS server. In TLS, the ClientKeyExchange 152 message is used to pass a random 48-byte pre-master secret to the server. 154 The client and server then use the pre-master secret to independently 155 derive the master secret, which in turn is used for generating session 156 keys and for MAC computations. Thus, if the Kerberos option is selected, 157 the pre-master secret structure is the same as that used in the RSA case; 158 it is encrypted under the Kerberos session key and sent to the TLS server 159 along with the Kerberos credentials (see Figure 2). The ticket and 160 authenticator are encoded per RFC 1510 (ASN.1 encoding). Once the 161 ClientKeyExchange message is received, the server's secret key is used to 162 unwrap the credentials and extract the pre-master secret. 164 Note that a Kerberos authenticator is not required, since the master 165 secret derived by the client and server is seeded with a random value 166 passed in the server hello message, thus foiling replay attacks. 167 However, the authenticator may still prove useful for passing 168 authorization information and is thus allotted an optional field (see 169 Figure 2). 171 Lastly, the client and server exchange the finished messages to complete 172 the handshake. At this point we have achieved the following: 173 1) A master secret, used to protect all subsequent communication, is 174 securely established. 176 2) Mutual client-server authentication is achieved, since the TLS 177 server proves knowledge of the master secret in the finished message. 179 Note that the Kerberos option fits in seamlessly, without adding any new 180 messages. 182 4. Naming Conventions: 184 To obtain an appropriate service ticket, the TLS client must determine 185 the principal name of the TLS server. The Kerberos service naming 186 convention is used for this purpose, as follows: 187 host/MachineName@Realm 188 where: 189 - The literal, "host", follows the Kerberos convention when not 190 concerned about the protection domain on a particular machine. 191 - "MachineName" is the particular instance of the service. 192 - The Kerberos "Realm" is the domain name of the machine. 194 5. Summary 196 The proposed Kerberos authentication option is added in exactly the 197 same manner as a new public key algorithm would be added to TLS. 198 Furthermore, it establishes the master secret in exactly the same manner. 200 6. Security Considerations 202 Kerberos ciphersuites are subject to the same security considerations as 203 the TLS protocol. In addition, just as a public key implementation must 204 take care to protect the private key (for example the PIN for a 205 smartcard), a Kerberos implementation must take care to protect the long 206 lived secret that is shared between the principal and the KDC. In 207 particular, a weak password may be subject to a dictionary attack. In 208 order to strengthen the initial authentication to a KDC, an implementor 209 may choose to utilize secondary authentication via a token card, or one 210 may utilize initial authentication to the KDC based on public key 211 cryptography (commonly known as PKINIT - a product of the Common 212 Authentication Technology working group of the IETF). 214 7. Acknowledgements 216 We would like to thank Clifford Neuman for his invaluable comments on 217 earlier versions of this document. 219 8. References 221 [1] T. Dierks, C. Allen. 222 The TLS Protocol, Version 1.0 - RFC 2246. 224 [2] J. Kohl and C. Neuman 225 The Kerberos Network Authentication Service (V5) RFC 1510. 227 Authors' Addresses 229 Ari Medvinsky 230 Excite 231 555 Broadway 232 Redwood City, CA 94063 233 Phone +1 650 569 2119 234 E-mail: amedvins@excitecorp.com 235 http://www.excite.com 237 Matthew Hur 238 CyberSafe Corporation 239 1605 NW Sammamish Road 240 Issaquah WA 98027-5378 241 Phone: +1 425 391 6000 242 E-mail: matt.hur@cybersafe.com 243 http://www.cybersafe.com