home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-tls-kerb-cipher-suites-01.txt < prev    next >
Text File  |  1997-07-25  |  10KB  |  237 lines

  1.  
  2. INTERNET-DRAFT                                        Ari Medvinsky 
  3. Transport Layer Security Working Group                  Matthew Hur 
  4. draft-ietf-tls-kerb-cipher-suites-01.txt      CyberSafe Corporation 
  5.                                            July 97 (Expires Feb-98)
  6.  
  7.  
  8. Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) 
  9.  
  10.  
  11. 0. Status Of this Memo
  12.  
  13. This document is an Internet-Draft.  Internet-Drafts are working
  14. documents of the Internet Engineering Task Force (IETF), its
  15. areas, and its working groups.  Note that other groups may also
  16. distribute working documents as Internet-Drafts.
  17.  
  18. Internet-Drafts are draft documents valid for a maximum of six
  19. months and may be updated, replaced, or obsoleted by other
  20. documents at any time.  It is inappropriate to use Internet-
  21. Drafts as reference material or to cite them other than as
  22. ``work in progress.''
  23.  
  24. To learn the current status of any Internet-Draft, please check
  25. the ``1id-abstracts.txt'' listing contained in the Internet-
  26. Drafts Shadow Directories on ftp.is.co.za (Africa),
  27. nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  28. ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  29.  
  30.  
  31. 1. Abstract
  32.  
  33. This document proposes the addition of new cipher suites to the TLS 
  34. protocol [1] to support Kerberos-based authentication.  Kerberos 
  35. credentials are used to achieve mutual authentication and to establish 
  36. a master secret which is subsequently used to secure client-server 
  37. communication.         
  38.  
  39.  
  40. 2. Introduction 
  41.  
  42. Flexibility is one of the main strengths of the TLS protocol. 
  43. Clients and servers can negotiate cipher suites to meet specific 
  44. security and administrative policies.  However, to date, authentication 
  45. in TLS is limited only to public key solutions.  As a result, TLS does 
  46. not fully support organizations with heterogeneous security deployments 
  47. that include authentication systems based on symmetric cryptography.  
  48. Kerberos, originally developed at MIT, is based on an open standard[2] 
  49. and is the most widely deployed symmetric key authentication system.  
  50. This document proposes a new option for negotiating Kerberos 
  51. authentication within the TLS framework.  This achieves mutual 
  52. authentication and the establishment of a master secret using Kerberos 
  53. credentials.  The proposed changes are minimal and, in fact, no 
  54. different from adding a new public key algorithm to the TLS framework.  
  55.  
  56.  
  57. 3. Kerberos Authentication Option In TLS
  58.  
  59. This section describes the addition of the Kerberos authentication
  60. option to the TLS protocol.  Throughout this document, we refer to the
  61. basic SSL handshake shown in Figure 1.  For a review of the TLS
  62. handshake see [1].        
  63.  
  64.  
  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
  86.  
  87.  
  88. FIGURE 1: The TLS protocol.  All messages followed by a star are 
  89.           optional.  Note: This figure was taken from an IETF draft [1].
  90.  
  91.  
  92. The TLS security context is negotiated in the client and server hello 
  93. messages.  For example: TLS_RSA_WITH_RC4_MD5 means the initial 
  94. authentication will be done using the RSA public key algorithm, RC4 will 
  95. be used for the session key, and MACs will be based on the MD5 
  96. algorithm.  Thus, to facilitate the Kerberos authentication option, we 
  97. must start by defining new cipher suites including (but not limited to): 
  98.  
  99.  
  100. CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1C };
  101. CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1D };
  102. CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x1E };
  103. CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x1F };
  104. CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x20 };
  105. CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x21 };
  106. CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x22 };
  107. CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x23 };
  108.  
  109. CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x24 };
  110. CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x25 };
  111. CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x26 };
  112. CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x27 };
  113. CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x28 };
  114. CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x29 };
  115.  
  116.  
  117. To establish a Kerberos-based security context, one or more of the above 
  118. cipher suites must be specified in the client hello message.  If the TLS 
  119. server supports the Kerberos authentication option, the server hello 
  120. message, sent to the client, will confirm the Kerberos cipher suite 
  121. selected by the server.  The server's certificate, the client 
  122.  
  123.  
  124. CertificateRequest, and the ServerKeyExchange shown in Figure 1 will be 
  125. omitted since authentication and the establishment of a master secret 
  126. will be done using the client's Kerberos credentials for the TLS server. 
  127. The client's certificate will be omitted for the same reason.  Note that 
  128. these messages are specified as optional in the TLS protocol; therefore, 
  129. omitting them is permissible.
  130.  
  131.  
  132. The Kerberos option must be added to the ClientKeyExchange message as 
  133. shown in Figure 2.
  134.  
  135. struct
  136.     select (KeyExchangeAlgorithm)
  137.     {
  138.         case krb5:            KerberosWrapper;       /* new addition */
  139.         case rsa:             EncryptedPreMasterSecret;
  140.         case diffie_hellman:  ClientDiffieHellmanPublic;
  141.     } Exchange_keys;
  142.  
  143. } ClientKeyExchange;
  144.  
  145. struct
  146. {
  147.     opaque Ticket;  
  148.     opaque authenticator;            /* optional */
  149.     opaque EncryptedPreMasterSecret; /* encrypted with the session key
  150.                                         which is sealed in the ticket */
  151. } KerberosWrapper;                   /* new addition */
  152.  
  153. FIGURE 2: The Kerberos option in the ClientKeyExchange.
  154.  
  155.  
  156. To use the Kerberos authentication option, the TLS client must obtain a 
  157. service ticket for the TLS server.  In TLS, the ClientKeyExchange 
  158. message is used to pass a random 48-byte pre-master secret to the server.  
  159. The client and server then use the pre-master secret to independently 
  160. derive the master secret, which in turn is used for generating session 
  161. keys and for MAC computations.  Thus, if the Kerberos option is selected, 
  162. the pre-master secret structure is the same as that used in the RSA case;
  163. it is encrypted under the Kerberos session key and sent to the TLS server
  164. along with the Kerberos credentials (see Figure 2).  The ticket and
  165. authenticator are encoded per RFC 1510 (ASN.1 encoding).  Once the
  166. ClientKeyExchange message is received, the server's secret key is used to
  167. unwrap the credentials and extract the pre-master secret.
  168.  
  169. Note that a Kerberos authenticator is not required, since the master 
  170. secret derived by the client and server is seeded with a random value 
  171. passed in the server hello message, thus foiling replay attacks.  
  172. However, the authenticator may still prove useful for passing 
  173. authorization information and is thus allotted an optional field (see 
  174. Figure 2). 
  175.  
  176. Lastly, the client and server exchange the finished messages to complete 
  177. the handshake.  At this point we have achieved the following:
  178. 1) A master secret, used to protect all subsequent communication, is 
  179. securely established.
  180.  
  181.  
  182. 2) Mutual client-server authentication is achieved, since the TLS 
  183. server proves knowledge of the master secret in the finished message.
  184.  
  185. Note that the Kerberos option fits in seamlessly, without adding any new 
  186. messages.
  187.  
  188.  
  189. 4. Naming Conventions: 
  190.  
  191. To obtain an appropriate service ticket, the TLS client must determine 
  192. the principal name of the TLS server.  The Kerberos service naming 
  193. convention is used for this purpose, as follows:
  194.   host/MachineName@Realm
  195.    where:
  196.      - The literal, "host", follows the Kerberos convention when not
  197.        concerned about the protection domain on a particular machine.
  198.      - "MachineName" is the particular instance of the service.
  199.      - The Kerberos "Realm" is the domain name of the machine.
  200.  
  201.  
  202. 5. Summary 
  203.  
  204. The proposed Kerberos authentication option is added in exactly the 
  205. same manner as a new public key algorithm would be added to TLS.
  206. Furthermore, it establishes the master secret in exactly the same manner.
  207.  
  208.  
  209. 6. Acknowledgements
  210.  
  211. We would like to thank Clifford Neuman for his invaluable comments on
  212. earlier versions of this document.
  213.  
  214.  
  215. 7. References
  216.  
  217. [1] T. Dierks, C. Allen.
  218. The TLS Protocol, Version 1.0 - IETF Draft. 
  219.  
  220. [2] J. Kohl and C. Neuman
  221. The Kerberos Network Authentication Service (V5) RFC 1510.
  222.  
  223. Authors' Addresses
  224.  
  225. Ari Medvinsky <arim@cybersafe.com>  
  226. Matthew Hur   <matth@cybersafe.com>
  227.  
  228. CyberSafe Corporation 
  229. 1605 NW Sammamish Raod
  230. Suite 310
  231. Issaquah, WA 98027-5378
  232. Phone: (206) 391-6000
  233. Fax:   (206) 391-0508
  234. http://www.cybersafe.com
  235.  
  236.