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-00.txt < prev    next >
Text File  |  1996-11-08  |  10KB  |  247 lines
  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) 
  5.  
  6.  
  7. Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) 
  8.  
  9.  
  10. 0. Status Of this Memo
  11.  
  12. This document is an Internet-Draft.  Internet-Drafts are working
  13. documents of the Internet Engineering Task Force (IETF), its
  14. areas, and its working groups.  Note that other groups may also
  15. distribute working documents as Internet-Drafts.
  16.  
  17. Internet-Drafts are draft documents valid for a maximum of six
  18. months and may be updated, replaced, or obsoleted by other
  19. documents at any time.  It is inappropriate to use Internet-
  20. Drafts as reference material or to cite them other than as
  21. ``work in progress.''
  22.  
  23. To learn the current status of any Internet-Draft, please check
  24. the ``1id-abstracts.txt'' listing contained in the Internet-
  25. Drafts Shadow Directories on ftp.is.co.za (Africa),
  26. nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
  27. ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).
  28.  
  29.  
  30. 1. Abstract
  31.  
  32. This document proposes the addition of new cipher suites to the TLS 
  33. protocol (SSL 3.0) to support Kerberos-based authentication.  Kerberos 
  34. credentials are used to achieve mutual authentication and to establish 
  35. a master secret which is subsequently used to secure client-server 
  36. communication.         
  37.  
  38.  
  39. 2. Introduction 
  40.  
  41. Flexibility is one of the main strengths of the TLS (SSL 3.0) protocol. 
  42. Clients and servers can negotiate cipher suites to meet specific 
  43. security and administrative policies.  However, to date, authentication 
  44. in TLS is limited only to public key solutions.  As a result, TLS does 
  45. not fully support organizations with heterogeneous security deployments 
  46. that include authentication systems based on symmetric cryptography.  
  47. Kerberos, originally developed at MIT, is based on an open standard[2] 
  48. and is the most widely deployed symmetric key authentication system.  
  49. This document proposes a new option for negotiating Kerberos 
  50. authentication within the TLS framework.  This achieves mutual 
  51. authentication and the establishment of a master secret using Kerberos 
  52. credentials.  The proposed changes are minimal and, in fact, no 
  53. different from adding a new public key algorithm to the TLS framework.  
  54.  
  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 (SSL v3.0).  Throughout this document, we 
  61. refer to the basic SSL handshake shown in Figure 1.  For a review of 
  62. the SSL handshake see [1].        
  63.  
  64.  
  65.  CLIENT                                             SERVER
  66.  ------                                             ------
  67.  
  68. ClientHello        -------------------------------->
  69.                                                     ServerHello
  70.                                                     Certificate *
  71.                                                     CertificateRequest*
  72.                                                     ServerKeyExchange*
  73.                    <-------------------------------
  74. Certificate*
  75. ClientKeyExchange
  76. CertificateVerify*
  77. change cipher spec
  78. Finished      
  79.                    -------------------------------->
  80.                                                     change cipher spec
  81.     |                                               Finished
  82.     |                                                   |
  83.     |                                                   |
  84. Application Data   <------------------------------->Application Data
  85.  
  86.  
  87. FIGURE 1: The SSL protocol.  All messages followed by a star are 
  88.           optional.  Note: This figure was taken from an IETF draft [1].
  89.  
  90.  
  91. The TLS security context is negotiated in the client and server hello 
  92. messages.  For example: SSL_RSA_WITH_RC4_MD5 means the initial 
  93. authentication will be done using the RSA public key algorithm, RC4 will 
  94. be used for the session key, and MACs will be based on the MD5 
  95. algorithm.  Thus, to facilitate the Kerberos authentication option, we 
  96. must start by defining new cipher suites including (but not limited to): 
  97.  
  98. CipherSuite      SSL_KRB5_EXPORT_WITH_DES40_CBC_SHA
  99. CipherSuite      SSL_KRB5_WITH_DES_CBC_SHA
  100. CipherSuite      SSL_KRB5_WITH_3DES_EDE_CBC_SHA
  101. CipherSuite      SSL_KRB5_EXPORT_WITH_RC4_40_MD5
  102. CipherSuite      SSL_KRB5_WITH_RC4_128_MD5
  103. CipherSuite      SSL_KRB5_WITH_RC4_128_SHA
  104. CipherSuite      SSL_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
  105. CipherSuite      SSL_KRB5_WITH_IDEA_CBC_SHA
  106.  
  107. To establish a Kerberos-based security context, one or more of the above 
  108. cipher suites must be specified in the client hello message.  If the TLS 
  109. server supports the Kerberos authentication option, the server hello 
  110. message, sent to the client, will confirm the Kerberos cipher suite 
  111. selected by the server.  The server's certificate, the client 
  112.  
  113.  
  114.  
  115. CertificateRequest, and the ServerKeyExchange shown in Figure 1 will be 
  116. omitted since authentication and the establishment of a master secret 
  117. will be done using the client's Kerberos credentials for the TLS server. 
  118. The client's certificate will be omitted for the same reason.  Note that 
  119. these messages are specified as optional in the TLS protocol; therefore, 
  120. omitting them is permissible.
  121.  
  122.  
  123. The Kerberos option must be added to the ClientKeyExchange message as 
  124. shown in Figure 2.
  125.  
  126. struct
  127. { 
  128.     select (KeyExchangeAlgorithm)
  129.     {
  130.         case krb5:            KerberosWrapper;       /* new addition */
  131.         case rsa:             EncryptedPreMasterSecret;
  132.         case diffie_hellman:  ClientDiffieHellmanPublic;
  133.         case fortezza_dms:    ForTezzaKeys;  
  134.     } Exchange_keys;
  135.  
  136. } ClientKeyExchange;
  137.  
  138. struct
  139. {
  140.     opaque Ticket;  
  141.     opaque authenticator;            /* optional */
  142.     opaque EncryptedPreMasterSecret; /* encrypted with the session key
  143.                                         which is sealed in the ticket */
  144. } KerberosWrapper;                   /* new addition */
  145.  
  146. FIGURE 2: The Kerberos option in the ClientKeyExchange.
  147.  
  148.  
  149. To use the Kerberos authentication option, the TLS client must obtain a 
  150. service ticket for the TLS server.  In TLS, the ClientKeyExchange 
  151. message is used to pass a random 48-byte pre-master secret to the server.  
  152. The client and server then use the pre-master secret to independently 
  153. derive the master secret, which in turn is used for generating session 
  154. keys and for MAC computations.  Thus, if the Kerberos option is selected, 
  155. the pre-master secret is encrypted under the Kerberos session key and 
  156. sent to the TLS server along with the Kerberos credentials (see Figure 2).  
  157. Once the ClientKeyExchange message is received, the server's secret key 
  158. is used to unwrap the credentials and extract the pre-master secret.
  159.  
  160. Note that a Kerberos authenticator is not required, since the master 
  161. secret derived by the client and server is seeded with a random value 
  162. passed in the server hello message, thus foiling replay attacks.  
  163. However, the authenticator may still prove useful for passing 
  164. authorization information and is thus allotted an optional field (see 
  165. Figure 2). 
  166.  
  167. Lastly, the client and server exchange the finished messages to complete 
  168. the handshake.  At this point we have achieved the following:
  169. 1) A master secret, used to protect all subsequent communication, is 
  170. securely established.
  171.  
  172.  
  173.  
  174. 2) Mutual client-server authentication is achieved, since the TLS 
  175. server proves knowledge of the master secret in the finished message.
  176.  
  177. Note that the Kerberos option fits in seamlessly, without adding any new 
  178. messages.
  179.  
  180.  
  181. 4. Discussion 
  182.  
  183. 4.1 Naming Conventions:
  184.  
  185. To obtain an appropriate service ticket, the TLS client must determine 
  186. the principal name of the TLS server.  The Kerberos service naming 
  187. convention is used for this purpose, as follows:
  188.   TLS/MachineName@Realm
  189.    where:
  190.      - The "TLS" component represents the service name.
  191.      - "MachineName" is the particular instance of the service.
  192.      - The Kerberos "Realm" is the domain name of the machine.
  193.  
  194. Open issue:
  195. To allow some TLS-enabled services to run in a different protection
  196. domain, a port number may optionally be part of the service principal
  197. name; for example, TLS/MachineName/port@Realm.
  198. One solution for negotiating the servce port number is as follows:
  199. The client requests the ticket for a specific port.  If the principal
  200. name for that port is not registered, then the client requests the
  201. generic ticket for TLS on the host.    
  202.  
  203. 4.2 Passing Kerberos Tickets
  204.  
  205. Clifford Neuman suggested the following approach as a topic for
  206. discussion:           
  207. Conceptually, the client's Kerberos ticket may be viewed as a custom
  208. certificate, recognized only by the TLS server.  Therefore, the
  209. client's certificate message may be used for passing the client's
  210. Kerberos credentials to the TLS server.
  211.  
  212.  
  213. 5. Summary 
  214.  
  215. The proposed Kerberos authentication option is added in exactly the 
  216. same manner as a new public key algorithm would be added to TLS.
  217. Furthermore, it establishes the master secret in exactly the same manner.
  218.  
  219.  
  220. 6. Acknowledgements
  221.  
  222. We would like to thank Clifford Neuman for his invaluable comments on
  223. earlier versions of this document.
  224.  
  225.  
  226.  
  227. 7. References
  228.  
  229. [1] Alan O. Freier, Philip Karlton and Paul C. Kocher.
  230. The SSL Protocol, Version 3.0 - IETF Draft. 
  231.  
  232. [2] J. Kohl and C. Neuman
  233. The Kerberos Network Authentication Service (V5) RFC 1510.
  234.  
  235. Authors' Addresses
  236.  
  237. Ari Medvinsky <arim@cybersafe.com>  
  238. Matthew Hur   <matth@cybersafe.com>
  239.  
  240. CyberSafe Corporation 
  241. 1605 NW Sammamish Raod
  242. Suite 310
  243. Issaquah, WA 98027-5378
  244. Phone: (206) 391-6000
  245. Fax:   (206) 391-0508
  246. http:/www.cybersafe.com
  247.