idnits 2.17.1 draft-ietf-tls-kerb-01.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 538 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 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([KERB], [KERBTLS], [TLS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 134: '...s-based ciphersuite, then it MUST send...' RFC 2119 keyword, line 159: '...tCertificateType MUST NOT be included ...' RFC 2119 keyword, line 221: '... <1..2^20-1>; /* MUST have at least */...' RFC 2119 keyword, line 231: '...uest message, it MUST respond with the...' RFC 2119 keyword, line 244: '...rded credential, MUST be of equal or g...' (1 more instance...) == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2712, but the abstract doesn't seem to directly say this. It does mention RFC2712 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 207 has weird spacing: '...nfoType type...' == Line 212 has weird spacing: '...nfoType attr...' == Line 255 has weird spacing: '... opaque ap_...' == Line 256 has weird spacing: '...KrbCred krb_...' -- 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) == Missing Reference: 'Neuman' is mentioned on line 380, but not defined == Unused Reference: 'NEUMAN' is defined on line 422, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1510 (ref. 'KERB') (Obsoleted by RFC 4120, RFC 6649) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) == Outdated reference: A later version (-34) exists of draft-ietf-cat-kerberos-pk-init-14 == Outdated reference: A later version (-04) exists of draft-ietf-cat-kerberos-pk-tapp-03 -- Possible downref: Normative reference to a draft: ref. 'PKTAPP' == Outdated reference: A later version (-08) exists of draft-ietf-cat-kerberos-pk-cross-07 -- Possible downref: Normative reference to a draft: ref. 'PKCROSS' -- Possible downref: Non-RFC (?) normative reference: ref. 'X509' -- Possible downref: Non-RFC (?) normative reference: ref. 'NEUMAN' -- Possible downref: Non-RFC (?) normative reference: ref. 'DESCRACK' Summary: 12 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Matthew Hur 3 Transport Layer Security Working Group Joseph Salowey 4 draft-ietf-tls-kerb-01.txt Cisco Systems 5 Obsoletes: RFC 2712 Ari Medvinsky 6 November 8, 2001 (Expires May 8, 2001) Liberate 8 Kerberos Cipher Suites in Transport Layer Security (TLS) 10 0. Status Of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. Internet-Drafts are 14 working 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. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/1id-abstracts.html 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 1. Abstract 31 RFC 2712 [KERBTLS] introduced mechanisms for supporting Kerberos 32 [KERB] authentication within the TLS protocol [TLS]. This document 33 extends RFC 2712 to support delegation of Kerberos credentials. In 34 this way, a TLS server may obtain a Kerberos service ticket on behalf 35 of the TLS client. Thus, a single client identity may be used for 36 authentication within a multi-tier architecture. This draft also 37 proposes a mechanism for a TLS server to indicate Kerberos-specific 38 information to the client within the certificate request message in 39 the initial exchange. 41 2. Introduction 43 Flexibility is one of the main strengths of the TLS protocol. Clients 44 and servers can negotiate cipher suites to meet specific security and 45 administrative policies. RFC 2712 specified how TLS could be 46 extended to support organizations with heterogeneous security 47 deployments that include authentication systems based on symmetric 48 cryptography. Kerberos, originally developed at MIT, is based on an 49 open standard and is the most widely deployed symmetric key 50 authentication system. Just as other documents specify hybrid 51 asymmetric/symmetric key protocols [PKINIT] [PKCROSS] [PKTAPP], this 52 document specifies how TLS may incorporate both symmetric and 53 asymmetric key crypto systems. 55 This document describes the use of Kerberos authentication within 56 the TLS framework. This achieves mutual authentication and the 57 establishment of a master secret using Kerberos credentials. 58 Additionally, this document specifies support for delegation of 59 Kerberos credentials, which enables end to end authentication within 60 an n-tier architecture. The proposed changes are minimal and, in 61 fact, no different from adding a new public key algorithm to the TLS 62 framework. 64 3. Kerberos Authentication Option In TLS 66 This section describes the addition of the Kerberos authentication 67 option to the TLS protocol. Throughout this document, we refer to 68 the basic SSL handshake shown in Figure 1. For a review of the TLS 69 handshake see [TLS]. 71 +-------------------------------------------------------------------+ 72 | CLIENT SERVER | 73 | ------ ------ | 74 | ClientHello | 75 | ---------------------------> | 76 | ServerHello | 77 | Certificate * | 78 | ServerKeyExchange* | 79 | CertificateRequest* | 80 | ServerHelloDone | 81 | <--------------------------- | 82 | Certificate* | 83 | ClientKeyExchange | 84 | CertificateVerify* | 85 | change cipher spec | 86 | Finished | 87 | | ---------------------------> | 88 | | change cipher spec | 89 | | Finished | 90 | | | | 91 | | | | 92 | Application Data <--------------------------> Application Data | 93 +-------------------------------------------------------------------+ 94 FIGURE 1: The TLS protocol. All messages followed by a star are 95 optional. Note: This figure was taken from RFC 2246. 97 The TLS security context is negotiated in the client and server hello 98 messages. For example: TLS_RSA_WITH_RC4_128_MD5 means the initial 99 authentication will be done using the RSA public key algorithm, RC4 100 will be used with a 128 bit session key, and MACs will be based on 101 the MD5 algorithm. Thus, to facilitate the Kerberos authentication 102 option, we must start by defining Kerberos cipher suites including 103 (but not limited to): 105 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x70 }; 106 CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x71 }; 107 CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x72 }; 108 CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x73 }; 109 CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x74 }; 110 CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x75 }; 111 CipherSuite TLS_KRB5_WITH_AES_128_CBC_SHA = { 0x00,0x76 }; 112 CipherSuite TLS_KRB5_WITH_AES_256_CBC_SHA = { 0x00,0x77 }; 113 CipherSuite TLS_KRB5_WITH_NULL_SHA = { 0x00,0x78 }; 114 CipherSuite TLS_KRB5_WITH_NULL_MD5 = { 0x00,0x79 }; 116 To establish a Kerberos-based security context, one or more of the 117 above cipher suites must be specified in the client hello message. If 118 the TLS server supports the Kerberos authentication option, the 119 server hello message, sent to the client, will confirm the Kerberos 120 cipher suite selected by the server. The server's certificate and 121 the ServerKeyExchange shown in Figure 1 will be omitted since 122 authentication and the establishment of a master secret will be done 123 using the client's Kerberos credentials for the TLS server. Note 124 that these messages are specified as optional in the TLS protocol; 125 therefore, omitting them is permissible. 127 The Kerberos option affects three of the TLS messages: the 128 CertificateRequest, the client Certificate, and the 129 ClientKeyExchange. However, only the client Certificate and the 130 ClientKeyExchange are required. 132 3.1. Usage of the CertificateRequest Message 134 If the server accepts a Kerberos-based ciphersuite, then it MUST send 135 the CertificateRequest message to the client. This message conveys 136 Kerberos-specific characteristics such as realm name or attributes 137 such as forwarded ticket. 139 RFC 2246 defines the CertificateRequest message as follows: 140 +-------------------------------------------------------------------+ 141 | | 142 | enum { | 143 | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | 144 | (255) | 145 | } ClientCertificateType; | 146 | | 147 | opaque DistinguishedName<1..2^16-1>; | 148 | | 149 | struct { ClientCertificateType certificate_types<1..2^8-1>; | 150 | DistinguishedName certificate_authorities<3..2^16-1>; | 151 | } CertificateRequest; | 152 | | 153 +-------------------------------------------------------------------+ 154 FIGURE 2: CertificateRequest message from RFC 2246 156 This specification defines a new ClientCertificateType for a Kerberos 157 certificate. This enables a client to respond to the 158 CertificateRequest message when using Kerberos ciphersuites. The 159 Kerberos ClientCertificateType MUST NOT be included in 160 certificate_types for non-Kerberos ciphersuites. Thus the following 161 change for ClientCertificateType is required (Figure 3). 163 +-------------------------------------------------------------------+ 164 | | 165 | enum { | 166 | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | 167 | kerberos(5), (255) | 168 | } ClientCertificateType; | 169 | | 170 +-------------------------------------------------------------------+ 171 FIGURE 3: New Kerberos ClientCertificateType 173 In the case of a public key based authentication algorithm, the 174 opaque DistinguishedName field is derived from [X509], and it 175 contains the name of an acceptable certification authority (This is 176 as specified in [TLS]). In the case of a Kerberos 177 ClientCertificateType, the DistinguishedName field is defined to 178 represent Kerberos information (KerbInfo) as shown in Figure 4. The 179 srv_tgt attribute type is used by the server to send a TGT that the 180 client presents to the KDC in the case of user-to-user 181 authentication. The KDC uses the session key from this ticket to 182 encrypt a service ticket for the server. In this case the attr_data 183 must be of non-zero length and contain the server's TGT. 185 +-------------------------------------------------------------------+ 186 | | 187 | enum | 188 | { | 189 | srv_tkt(1), fwd_tgt(2), (255) | 190 | } KerbInfoType; | 191 | | 192 | enum | 193 | { | 194 | initial_tkt_required(1), srv_tgt(2), (255) | 195 | } AttrType; /* This may be extended to include attributes */ | 196 | /* such as forwardable or renewable for example */ | 197 | | 198 | struct | 199 | { | 200 | AttrType attr_type; | 201 | opaque attr_data <0..2^16-1>; | 202 | } AttrInfoType | 203 | | 204 | struct | 205 | { | 206 | uint32 length; /* length of this struct */ | 207 | KerbInfoType type; | 208 | opaque sname <0..2^16-1>; | 209 | opaque srealm <0..2^16-1>; | 210 | opaque cname <0..2^16-1>; | 211 | opaque crealm <0..2^16-1>; | 212 | AttrInfoType attr_info <0..2^16-1>; /* sequence of */ | 213 | /* attributes */ | 214 | uint32 etypes <0..2^16-1>; /* list of supported */ | 215 | /* Kerberos etypes */ | 216 | /* for authentication */ | 217 | } TktInfo; | 218 | | 219 | struct | 220 | { | 221 | TktInfo tkt_info <1..2^20-1>; /* MUST have at least */ | 222 | /* 1 TktInfo structs */ | 223 | } KerbInfo | 224 | | 225 +-------------------------------------------------------------------+ 226 FIGURE 4: Kerberos Information for CertificateRequest Message 228 3.2. Usage of the Client Certificate Message 230 As specified by [TLS], when the client receives the 231 CertificateRequest message, it MUST respond with the client 232 Certificate message. As stated above, this specification defines a 233 Kerberos certificate type. The format for the Kerberos certificate 234 is specified in figure 5 below. This structure consists of a 235 Kerberos AP-REQ message that is used for authenticating the client to 236 he server. It optionally contains a series of Kerberos KRB-CRED 237 messages to convey delegated credentials. 239 Note that the client may determine the type of credentials to send to 240 the server, based on local policy. Part of the input to a client's 241 decision may come from the Kerberos KDC. For example, The client may 242 convey a delegated ticket based on the ok-as-delegate ticket flag set 243 in the service ticket. Also, the session key used to protect a 244 forwarded credential, MUST be of equal or greater strength than the 245 key used to protect the ticket when originally sent to the client 246 (typically, this key is the client principal key, shared with the 247 Kerberos KDC). 249 +-------------------------------------------------------------------+ 250 | | 251 | opaque KrbCred <1..2^16-1>; /* Kerberos-defined KRB-CRED */ | 252 | | 253 | struct | 254 | { | 255 | opaque ap_req <1..2^16-1>; | 256 | KrbCred krb_cred <0..2^20-1>; | 257 | } KerberosCert; | 258 | | 259 +-------------------------------------------------------------------+ 260 FIGURE 5: Kerberos Certificate Type 262 3.3. Usage of the ClientKeyExchange Message 264 The Kerberos option must be added to the ClientKeyExchange message as 265 shown in Figure 6. 267 +-------------------------------------------------------------------+ 268 | | 269 | struct | 270 | { | 271 | select (KeyExchangeAlgorithm) | 272 | { | 273 | case krb: KerbEncryptedPreMasterSecret; | 274 | case rsa: EncryptedPreMasterSecret; | 275 | case diffie_hellman: ClientDiffieHellmanPublic; | 276 | } Exchange_keys; | 277 | } ClientKeyExchange; | 278 | | 279 | KerbEncryptedPreMasterSecret contains the PreMasterSecret | 280 | encrypted within a Kerberos-defined EncryptedData structure. | 281 | The encryption key is sealed in the ticket sent in the Client | 282 | Certificate message. | 283 | | 284 +-------------------------------------------------------------------+ 285 FIGURE 6: The Kerberos option in the ClientKeyExchange. 287 To use the Kerberos authentication option, the TLS client must obtain 288 a service ticket for the TLS server. In TLS, the ClientKeyExchange 289 message is used to pass a random 48-byte pre-master secret to the 290 server. 292 The client and server then use the pre-master secret to independently 293 derive the master secret, which in turn is used for generating 294 session keys and for MAC computations. Thus, if the Kerberos option 295 is selected, the pre-master secret structure is the same as that used 296 in the RSA case; it is encrypted under the Kerberos session key and 297 sent to the TLS server along with the Kerberos credentials (see 298 Figure 2). The ticket and authenticator are encoded per RFC 1510 299 (ASN.1 encoding). Once the ClientKeyExchange message is received, 300 the server's secret key is used to unwrap the credentials and extract 301 the pre-master secret. 303 Lastly, the client and server exchange the finished messages to 304 complete the handshake. At this point we have achieved the 305 following: 307 1) A master secret, used to protect all subsequent communication, is 308 securely established. 310 2) Mutual client-server authentication is achieved, since the TLS 311 server proves knowledge of the master secret in the finished 312 message. 314 Kerberos fits seamlessly into TLS, without adding any new messages. 316 4. Naming Conventions: 318 To obtain an appropriate service ticket, the TLS client must 319 determine the principal name of the TLS server. The Kerberos service 320 naming convention is as follows: 322 host/MachineName@Realm 323 where: 324 - The literal, "host", follows the Kerberos convention when not 325 concerned about the protection domain on a particular machine. 326 - "MachineName" is the particular instance of the service. 327 - The Kerberos "Realm" is the domain name of the machine. 329 As specified above, in the CertificateRequest message, the server may 330 indicate the appropriate principal name and realm. 332 5. Summary 334 The proposed Kerberos authentication option is added in exactly the 335 same manner as a new public key algorithm would be added to TLS. 336 Furthermore, it establishes the master secret in exactly the same 337 manner. 339 6. Security Considerations 341 Kerberos ciphersuites are subject to the same security considerations 342 as the TLS protocol. In addition, just as a public key implementation 343 must take care to protect the private key (for example the PIN for a 344 smartcard), a Kerberos implementation must take care to protect the 345 long lived secret that is shared between the principal and the KDC. 346 In particular, a weak password may be subject to a dictionary attack. 347 In order to strengthen the initial authentication to a KDC, an 348 implementor may choose to utilize secondary authentication via a token 349 card, or one may utilize initial authentication to the KDC based on 350 public key cryptography (commonly known as PKINIT - a product of the 351 Kerberos working group of the IETF). 353 The unauthenticated CertificateRequest message, specified above, 354 enables the server to request a particular client principal name as 355 well as a particular service principal name. In the event that a 356 service principal name is specified, there is a risk that the client 357 may be tricked into requesting a ticket for a rogue server. 358 Furthermore, if delegation is requested, the client may be tricked 359 into forwarding its TGT to a rogue server. In order to assure that a 360 service ticket is obtained for the correct server, the client should 361 rely on a combination of its own local policy, local configuration 362 information, and information supplied by the KDC. The client may 363 choose to use only the naming convention specified in section 4. The 364 client may rely on the KDC performing name cannonicalization (this is 365 a matter that is adressed in revisions to RFC 1510). 367 The client must apply its local policy to determine whether or not to 368 forward its credentials. As previously stated, the client should 369 incorporate information from the KDC, in particular the ok-as- 370 delegate ticket flag, in making such a policy decision. 372 The forwarded credential MUST be protected in a key that is at least 373 the same strength as the principal key that originally protected the 374 TGT. 376 A forwarded TGT presents more vulnerabilities in the event of a rogue 377 server or the compromise of the session key. An attacker would be 378 able to impersonate the client to obtain new service tickets. Such 379 an attack may be mitigated by the use of restrictions, such as those 380 described in [Neuman]. 382 It has been shown that 56-bit DES keys are relatively easy to 383 compromise [DESCRACK]; therefore, use of 56-bit DES is discouraged. 385 7. Acknowledgements 387 We would like to thank the following people for their input for this 388 document: 389 Clifford Neuma - ISI 390 John Brezak and David Mowers - Microsoft 392 8. References 394 [KERBTLS] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher 395 Suites to Transport Layer Security (TLS)", RFC 2712, 396 October 1999. 398 [KERB] J. Kohl and C. Neuman, "The Kerberos Network 399 Authentication Service (V5)", RFC 1510, September 1993. 401 [TLS] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0", 402 RFC 2246, January 1999. 404 [PKINIT] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, 405 J. Wray, J. Trostle. Public Key Cryptography for Initial 406 Authentication in Kerberos. 407 draft-ietf-cat-kerberos-pk-init-14.txt 409 [PKTAPP] A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman. 410 Public Key Utilizing Tickets for Application 411 Servers (PKTAPP). draft-ietf-cat-kerberos-pk-tapp-03.txt 413 [PKCROSS] M. Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik, 414 A. Medvinsky, B. Sommerfeld. Public Key Cryptography for 415 Cross-Realm Authentication in Kerberos. 416 draft-ietf-cat-kerberos-pk-cross-07.txt 418 [X509] ITU-T (formerly CCITT) Information technology - Open 419 Systems Interconnection - The Directory: Authentication 420 Framework Recommendation X.509 ISO/IEC 9594-8 422 [NEUMAN] B.C. Neuman, "Proxy-Based Authorization and Accounting for 423 Distributed Systems". Proceedings of the 13th 424 International Conference on Distributed Computing Systems, 425 May 1993 427 [DESCRACK] Electronic Frontier Foundation, "Cracking DES: Secrets of 428 Encryption Research, Wiretap Politics, and Chip Design". 429 May 1998, Electronic Frontier Foundation. 431 9. Authors' Addresses 433 Matthew Hur 434 Cisco Systems 435 2901 Third Avenue 436 Seattle, WA 98121 437 Phone: +1 206 256 3197 438 EMail: mhur@cisco.com 439 http://www.cisco.com 441 Joseph Salowey 442 Cisco Systems 443 2901 Third Avenue 444 Seattle, WA 98121 445 Phone: +1 206 256 3380 446 EMail: jsalowey@cisco.com 447 http://www.cisco.com 449 Ari Medvinsky 450 Liberate 451 2 Circle Star Way 452 San Carlos, CA 94070-6200 453 Phone: +1 650 701 4000 454 EMail: ari@liberate.com 455 http://www.liberate.com 457 10. Full Copyright Statement 459 Copyright (C) The Internet Society (1999). All Rights Reserved. 461 This document and translations of it may be copied and furnished to 462 others, and derivative works that comment on or otherwise explain it 463 or assist in its implementation may be prepared, copied, published 464 and distributed, in whole or in part, without restriction of any 465 kind, provided that the above copyright notice and this paragraph are 466 included on all such copies and derivative works. However, this 467 document itself may not be modified in any way, such as by removing 468 the copyright notice or references to the Internet Society or other 469 Internet organizations, except as needed for the purpose of 470 developing Internet standards in which case the procedures for 471 copyrights defined in the Internet Standards process must be 472 followed, or as required to translate it into languages other than 473 English. 475 The limited permissions granted above are perpetual and will not be 476 revoked by the Internet Society or its successors or assigns. 478 This document and the information contained herein is provided on an 479 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 480 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 481 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 482 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 483 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 485 11. Appendix 487 Changes from RFC 2712 489 Added new cipher suites with NULL confidentiality: 490 TLS_KRB5_WITH_NULL_SHA 491 TLS_KRB5_WITH_NULL_MD5 493 Added new cipher suites to support AES: 494 TLS_KRB5_WITH_AES_128_CBC_SHA 495 TLS_KRB5_WITH_AES_256_CBC_SHA 497 40 bit ciphers have been removed, and AES ciphers have been added. 499 All of the ciphersuites have been renumbered to avoid conflicts with 500 exisiting implementations of RFC 2712. 502 RFC 2712 utilized only the ClientKeyExchange message for conveying 503 the Kerberos credentials and encrypted premaster-secret. This 504 specification moves the Kerberos credentials to the client 505 certificate message, and it allows the client to pass delegated 506 credentials as well. Additionally, this specification allows the 507 server to specify Kerberos-specific information (realm, delegation 508 required, etc.) in the CertificateRequest message.