draft-ietf-tls-kerb-00.txt   draft-ietf-tls-kerb-01.txt 
INTERNET-DRAFT Matthew Hur INTERNET-DRAFT Matthew Hur
Transport Layer Security Working Group Cisco Systems Transport Layer Security Working Group Joseph Salowey
draft-ietf-tls-kerb-00.txt Ari Medvinsky draft-ietf-tls-kerb-01.txt Cisco Systems
Obsoletes: RFC 2712 Keen.com Obsoletes: RFC 2712 Ari Medvinsky
November 06, 2000 (Expires May 06, 2001) November 8, 2001 (Expires May 8, 2001) Liberate
Kerberos Cipher Suites in Transport Layer Security (TLS) Kerberos Cipher Suites in Transport Layer Security (TLS)
0. Status Of this Memo 0. Status Of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are all provisions of Section 10 of RFC 2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), its working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
1. Abstract 1. Abstract
RFC 2712 [KERBTLS] introduced mechanisms for supporting Kerberos RFC 2712 [KERBTLS] introduced mechanisms for supporting Kerberos
[KERB] authentication within the TLS protocol [TLS]. This document [KERB] authentication within the TLS protocol [TLS]. This document
extends RFC 2712 to support delegation of Kerberos credentials. In extends RFC 2712 to support delegation of Kerberos credentials. In
this way, a TLS server may obtain a Kerberos service ticket on behalf this way, a TLS server may obtain a Kerberos service ticket on behalf
of the TLS client. Thus, a single client identity may be used for of the TLS client. Thus, a single client identity may be used for
authentication within a multi-tier architecture. This draft also authentication within a multi-tier architecture. This draft also
proposes a mechanism for a TLS server to indicate Kerberos-specific proposes a mechanism for a TLS server to indicate Kerberos-specific
skipping to change at line 103 skipping to change at line 98
| | change cipher spec | | | change cipher spec |
| | Finished | | | Finished |
| | | | | | | |
| | | | | | | |
| Application Data <--------------------------> Application Data | | Application Data <--------------------------> Application Data |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
FIGURE 1: The TLS protocol. All messages followed by a star are FIGURE 1: The TLS protocol. All messages followed by a star are
optional. Note: This figure was taken from RFC 2246. optional. Note: This figure was taken from RFC 2246.
The TLS security context is negotiated in the client and server hello The TLS security context is negotiated in the client and server hello
messages. For example: TLS_RSA_WITH_RC4_MD5 means the initial messages. For example: TLS_RSA_WITH_RC4_128_MD5 means the initial
authentication will be done using the RSA public key algorithm, RC4 authentication will be done using the RSA public key algorithm, RC4
will be used for the session key, and MACs will be based on the MD5 will be used with a 128 bit session key, and MACs will be based on
algorithm. Thus, to facilitate the Kerberos authentication option, the MD5 algorithm. Thus, to facilitate the Kerberos authentication
we must start by defining Kerberos cipher suites including (but not option, we must start by defining Kerberos cipher suites including
limited to): (but not limited to):
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x1E };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x1F };
CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x20 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_SHA = { 0x00,0x21 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x22 };
CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x23 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x24 };
CipherSuite TLS_KRB5_WITH_IDEA_CBC_MD5 = { 0x00,0x25 };
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA = { 0x00,0x26 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA = { 0x00,0x27 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_SHA = { 0x00,0x28 };
CipherSuite TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5 = { 0x00,0x29 };
CipherSuite TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5 = { 0x00,0x2A };
CipherSuite TLS_KRB5_EXPORT_WITH_RC4_40_MD5 = { 0x00,0x2B };
CipherSuite TLS_KRB5_WITH_NULL_SHA = { 0x00,0x?? }; CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_SHA = { 0x00,0x70 };
CipherSuite TLS_KRB5_WITH_NULL_MD5 = { 0x00,0x?? }; CipherSuite TLS_KRB5_WITH_3DES_EDE_CBC_MD5 = { 0x00,0x71 };
CipherSuite TLS_KRB5_WITH_NULL_NULL = { 0x00,0x?? }; CipherSuite TLS_KRB5_WITH_RC4_128_SHA = { 0x00,0x72 };
CipherSuite TLS_KRB5_WITH_RC4_128_MD5 = { 0x00,0x73 };
CipherSuite TLS_KRB5_WITH_DES_CBC_SHA = { 0x00,0x74 };
CipherSuite TLS_KRB5_WITH_DES_CBC_MD5 = { 0x00,0x75 };
CipherSuite TLS_KRB5_WITH_AES_128_CBC_SHA = { 0x00,0x76 };
CipherSuite TLS_KRB5_WITH_AES_256_CBC_SHA = { 0x00,0x77 };
CipherSuite TLS_KRB5_WITH_NULL_SHA = { 0x00,0x78 };
CipherSuite TLS_KRB5_WITH_NULL_MD5 = { 0x00,0x79 };
To establish a Kerberos-based security context, one or more of the To establish a Kerberos-based security context, one or more of the
above cipher suites must be specified in the client hello message. If above cipher suites must be specified in the client hello message. If
the TLS server supports the Kerberos authentication option, the the TLS server supports the Kerberos authentication option, the
server hello message, sent to the client, will confirm the Kerberos server hello message, sent to the client, will confirm the Kerberos
cipher suite selected by the server. The server's certificate and cipher suite selected by the server. The server's certificate and
the ServerKeyExchange shown in Figure 1 will be omitted since the ServerKeyExchange shown in Figure 1 will be omitted since
authentication and the establishment of a master secret will be done authentication and the establishment of a master secret will be done
using the client's Kerberos credentials for the TLS server. Note using the client's Kerberos credentials for the TLS server. Note
that these messages are specified as optional in the TLS protocol; that these messages are specified as optional in the TLS protocol;
skipping to change at line 172 skipping to change at line 158
| | | |
| struct { ClientCertificateType certificate_types<1..2^8-1>; | | struct { ClientCertificateType certificate_types<1..2^8-1>; |
| DistinguishedName certificate_authorities<3..2^16-1>; | | DistinguishedName certificate_authorities<3..2^16-1>; |
| } CertificateRequest; | | } CertificateRequest; |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
FIGURE 2: CertificateRequest message from RFC 2246 FIGURE 2: CertificateRequest message from RFC 2246
This specification defines a new ClientCertificateType for a Kerberos This specification defines a new ClientCertificateType for a Kerberos
certificate. This enables a client to respond to the certificate. This enables a client to respond to the
CertificateRequest message when using Kerberos ciphersuites. Thus CertificateRequest message when using Kerberos ciphersuites. The
the following change for ClientCertificateType is required Kerberos ClientCertificateType MUST NOT be included in
(Figure 3). certificate_types for non-Kerberos ciphersuites. Thus the following
change for ClientCertificateType is required (Figure 3).
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| | | |
| enum { | | enum { |
| rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), | | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), |
| kerberos(5), (255) | | kerberos(5), (255) |
| } ClientCertificateType; | | } ClientCertificateType; |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
FIGURE 3: New Kerberos ClientCertificateType FIGURE 3: New Kerberos ClientCertificateType
In the case of a public key based authentication algorithm, the In the case of a public key based authentication algorithm, the
opaque DistinguishedName field is derived from [X509], and it opaque DistinguishedName field is derived from [X509], and it
contains the name of an acceptable certification authority (This is contains the name of an acceptable certification authority (This is
as specified in [TLS]). In the case of a Kerberos as specified in [TLS]). In the case of a Kerberos
ClientCertificateType, the DistinguishedName field is defined to ClientCertificateType, the DistinguishedName field is defined to
represent Kerberos information (KerbInfo) as shown in Figure 4. represent Kerberos information (KerbInfo) as shown in Figure 4. The
srv_tgt attribute type is used by the server to send a TGT that the
client presents to the KDC in the case of user-to-user
authentication. The KDC uses the session key from this ticket to
encrypt a service ticket for the server. In this case the attr_data
must be of non-zero length and contain the server's TGT.
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| | | |
| enum | | enum |
| { | | { |
| srv_tkt(1), fwd_tgt(2), (255) | | srv_tkt(1), fwd_tgt(2), (255) |
| } KerbInfoType; | | } KerbInfoType; |
| | | |
| enum | | enum |
| { | | { |
| initial_tkt_required(1), (255) | | initial_tkt_required(1), srv_tgt(2), (255) |
| } AttrType; /* This may be extended to include attributes */ | | } AttrType; /* This may be extended to include attributes */ |
| /* such as forwardable or renewable for example */ | | /* such as forwardable or renewable for example */ |
| | | |
| struct | | struct |
| { | | { |
| AttrType attr_type; | | AttrType attr_type; |
| opaque attr_data <0..2^16-1>; | | opaque attr_data <0..2^16-1>; |
| } AttrInfoType | | } AttrInfoType |
| | | |
| struct | | struct |
skipping to change at line 229 skipping to change at line 221
| opaque crealm <0..2^16-1>; | | opaque crealm <0..2^16-1>; |
| AttrInfoType attr_info <0..2^16-1>; /* sequence of */ | | AttrInfoType attr_info <0..2^16-1>; /* sequence of */ |
| /* attributes */ | | /* attributes */ |
| uint32 etypes <0..2^16-1>; /* list of supported */ | | uint32 etypes <0..2^16-1>; /* list of supported */ |
| /* Kerberos etypes */ | | /* Kerberos etypes */ |
| /* for authentication */ | | /* for authentication */ |
| } TktInfo; | | } TktInfo; |
| | | |
| struct | | struct |
| { | | { |
| uint16 num; /* number of TktInfo structs */ |
| TktInfo tkt_info <1..2^20-1>; /* MUST have at least */ | | TktInfo tkt_info <1..2^20-1>; /* MUST have at least */ |
| /* 1 TktInfo structs */ | | /* 1 TktInfo structs */ |
| } KerbInfo | | } KerbInfo |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
FIGURE 4: Kerberos Information for CertificateRequest Message FIGURE 4: Kerberos Information for CertificateRequest Message
3.2. Usage of the Client Certificate Message 3.2. Usage of the Client Certificate Message
As specified by [TLS], when the client receives the As specified by [TLS], when the client receives the
skipping to change at line 252 skipping to change at line 243
Kerberos certificate type. The format for the Kerberos certificate Kerberos certificate type. The format for the Kerberos certificate
is specified in figure 5 below. This structure consists of a is specified in figure 5 below. This structure consists of a
Kerberos AP-REQ message that is used for authenticating the client to Kerberos AP-REQ message that is used for authenticating the client to
he server. It optionally contains a series of Kerberos KRB-CRED he server. It optionally contains a series of Kerberos KRB-CRED
messages to convey delegated credentials. messages to convey delegated credentials.
Note that the client may determine the type of credentials to send to Note that the client may determine the type of credentials to send to
the server, based on local policy. Part of the input to a client's the server, based on local policy. Part of the input to a client's
decision may come from the Kerberos KDC. For example, The client may decision may come from the Kerberos KDC. For example, The client may
convey a delegated ticket based on the ok-as-delegate ticket flag set convey a delegated ticket based on the ok-as-delegate ticket flag set
in the service ticket. in the service ticket. Also, the session key used to protect a
forwarded credential, MUST be of equal or greater strength than the
key used to protect the ticket when originally sent to the client
(typically, this key is the client principal key, shared with the
Kerberos KDC).
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
| | | |
| opaque KrbCred <1..2^16-1>; /* Kerberos-defined KRB-CRED */ | | opaque KrbCred <1..2^16-1>; /* Kerberos-defined KRB-CRED */ |
| | | |
| struct | | struct |
| { | | { |
| opaque ap_req <1..2^16-1>; | | opaque ap_req <1..2^16-1>; |
| uint16 num; /* number of KrbCred structs */ |
| KrbCred krb_cred <0..2^20-1>; | | KrbCred krb_cred <0..2^20-1>; |
| } KerberosCert; | | } KerberosCert; |
| | | |
+-------------------------------------------------------------------+ +-------------------------------------------------------------------+
FIGURE 5: Kerberos Certificate Type FIGURE 5: Kerberos Certificate Type
3.3. Usage of the ClientKeyExchange Message 3.3. Usage of the ClientKeyExchange Message
The Kerberos option must be added to the ClientKeyExchange message as The Kerberos option must be added to the ClientKeyExchange message as
shown in Figure 6. shown in Figure 6.
skipping to change at line 326 skipping to change at line 320
2) Mutual client-server authentication is achieved, since the TLS 2) Mutual client-server authentication is achieved, since the TLS
server proves knowledge of the master secret in the finished server proves knowledge of the master secret in the finished
message. message.
Kerberos fits seamlessly into TLS, without adding any new messages. Kerberos fits seamlessly into TLS, without adding any new messages.
4. Naming Conventions: 4. Naming Conventions:
To obtain an appropriate service ticket, the TLS client must To obtain an appropriate service ticket, the TLS client must
determine the principal name of the TLS server. The Kerberos service determine the principal name of the TLS server. The Kerberos service
naming convention is used for this purpose, as follows: naming convention is as follows:
host/MachineName@Realm host/MachineName@Realm
where: where:
- The literal, "host", follows the Kerberos convention when not - The literal, "host", follows the Kerberos convention when not
concerned about the protection domain on a particular machine. concerned about the protection domain on a particular machine.
- "MachineName" is the particular instance of the service. - "MachineName" is the particular instance of the service.
- The Kerberos "Realm" is the domain name of the machine. - The Kerberos "Realm" is the domain name of the machine.
As specified above, in the CertificateRequest message, the server may As specified above, in the CertificateRequest message, the server may
indicate the appropriate principal name and realm. indicate the appropriate principal name and realm.
skipping to change at line 348 skipping to change at line 342
5. Summary 5. Summary
The proposed Kerberos authentication option is added in exactly the The proposed Kerberos authentication option is added in exactly the
same manner as a new public key algorithm would be added to TLS. same manner as a new public key algorithm would be added to TLS.
Furthermore, it establishes the master secret in exactly the same Furthermore, it establishes the master secret in exactly the same
manner. manner.
6. Security Considerations 6. Security Considerations
Kerberos ciphersuites are subject to the same security considerations Kerberos ciphersuites are subject to the same security considerations
as the TLS protocol. In addition, just as a public key as the TLS protocol. In addition, just as a public key implementation
implementation must take care to protect the private key (for example must take care to protect the private key (for example the PIN for a
the PIN for a smartcard), a Kerberos implementation must take care to smartcard), a Kerberos implementation must take care to protect the
protect the long lived secret that is shared between the principal long lived secret that is shared between the principal and the KDC.
and the KDC. In particular, a weak password may be subject to a In particular, a weak password may be subject to a dictionary attack.
dictionary attack. In order to strengthen the initial authentication In order to strengthen the initial authentication to a KDC, an
to a KDC, an implementor may choose to utilize secondary implementor may choose to utilize secondary authentication via a token
authentication via a token card, or one may utilize initial card, or one may utilize initial authentication to the KDC based on
authentication to the KDC based on public key cryptography (commonly public key cryptography (commonly known as PKINIT - a product of the
known as PKINIT - a product of the Kerberos working group of the Kerberos working group of the IETF).
IETF).
The unauthenticated CertificateRequest message, specified above, The unauthenticated CertificateRequest message, specified above,
enables the server to request a particular client principal name as enables the server to request a particular client principal name as
well as a particular service principal name. In the event that a well as a particular service principal name. In the event that a
service principal name is specified, there is a risk that the client service principal name is specified, there is a risk that the client
may be tricked into requesting a ticket for a rogue server. may be tricked into requesting a ticket for a rogue server.
Furthermore, if delegation is requested, the client may be tricked Furthermore, if delegation is requested, the client may be tricked
into forwarding its TGT to a rogue server. In order to assure that a into forwarding its TGT to a rogue server. In order to assure that a
service ticket is obtained for the correct server, the client should service ticket is obtained for the correct server, the client should
rely on a combination of its own local policy, local configuration rely on a combination of its own local policy, local configuration
information, and information supplied by the KDC. The client may information, and information supplied by the KDC. The client may
choose to use only the naming convention specified in section 4. The choose to use only the naming convention specified in section 4. The
client may rely on the KDC performing name cannonicalization (this is client may rely on the KDC performing name cannonicalization (this is
a matter that is adressed in revisions to RFC 1510). a matter that is adressed in revisions to RFC 1510).
The client must apply its local policy to determine whether or not to The client must apply its local policy to determine whether or not to
forward its credentials. As previously stated, the client should forward its credentials. As previously stated, the client should
incorporate information from the KDC, in particular the ok-as- incorporate information from the KDC, in particular the ok-as-
delegate ticket flag, in making such a policy decision. delegate ticket flag, in making such a policy decision.
The forwarded credential MUST be protected in a key that is at least
the same strength as the principal key that originally protected the
TGT.
A forwarded TGT presents more vulnerabilities in the event of a rogue A forwarded TGT presents more vulnerabilities in the event of a rogue
server or the compromise of the session key. An attacker would be server or the compromise of the session key. An attacker would be
able to impersonate the client to obtain new service tickets. Such able to impersonate the client to obtain new service tickets. Such
an attack may be mitigated by the use of restrictions, such as those an attack may be mitigated by the use of restrictions, such as those
described in [Neuman]. described in [Neuman].
It has been shown that 56-bit DES keys are relatively easy to
compromise [DESCRACK]; therefore, use of 56-bit DES is discouraged.
7. Acknowledgements 7. Acknowledgements
We would like to thank the following people for their input for this We would like to thank the following people for their input for this
document: document:
Clifford Neuman from ISI Clifford Neuma - ISI
John Brezak and David Mowers from Microsoft John Brezak and David Mowers - Microsoft
8. References 8. References
[KERBTLS] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher [KERBTLS] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher
Suites to Transport Layer Security (TLS)", RFC 2712, Suites to Transport Layer Security (TLS)", RFC 2712,
October 1999. October 1999.
[KERB] J. Kohl and C. Neuman, "The Kerberos Network [KERB] J. Kohl and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993. Authentication Service (V5)", RFC 1510, September 1993.
[TLS] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0", [TLS] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[PKINIT] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky, [PKINIT] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky,
J. Wray, J. Trostle. Public Key Cryptography for Initial J. Wray, J. Trostle. Public Key Cryptography for Initial
Authentication in Kerberos. Authentication in Kerberos.
draft-ietf-cat-kerberos-pk-init-12.txt draft-ietf-cat-kerberos-pk-init-14.txt
[PKTAPP] A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman. [PKTAPP] A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman.
Public Key Utilizing Tickets for Application Public Key Utilizing Tickets for Application
Servers (PKTAPP). draft-ietf-cat-kerberos-pk-tapp-03.txt Servers (PKTAPP). draft-ietf-cat-kerberos-pk-tapp-03.txt
[PKCROSS] M. Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik, [PKCROSS] M. Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik,
A. Medvinsky, B. Sommerfeld. Public Key Cryptography for A. Medvinsky, B. Sommerfeld. Public Key Cryptography for
Cross-Realm Authentication in Kerberos. Cross-Realm Authentication in Kerberos.
draft-ietf-cat-kerberos-pk-cross-06.txt draft-ietf-cat-kerberos-pk-cross-07.txt
[X509] ITU-T (formerly CCITT) Information technology - Open [X509] ITU-T (formerly CCITT) Information technology - Open
Systems Interconnection - The Directory: Authentication Systems Interconnection - The Directory: Authentication
Framework Recommendation X.509 ISO/IEC 9594-8 Framework Recommendation X.509 ISO/IEC 9594-8
[NEUMAN] B.C. Neuman, "Proxy-Based Authorization and Accounting for [NEUMAN] B.C. Neuman, "Proxy-Based Authorization and Accounting for
Distributed Systems". Proceedings of the 13th Distributed Systems". Proceedings of the 13th
International Conference on Distributed Computing Systems, International Conference on Distributed Computing Systems,
May 1993 May 1993
[DESCRACK] Electronic Frontier Foundation, "Cracking DES: Secrets of
Encryption Research, Wiretap Politics, and Chip Design".
May 1998, Electronic Frontier Foundation.
9. Authors' Addresses 9. Authors' Addresses
Matthew Hur Matthew Hur
Cisco Systems Cisco Systems
500 108th Ave. NE, Suite 500 2901 Third Avenue
Bellevue, WA 98004 Seattle, WA 98121
Phone: Phone: +1 206 256 3197
EMail: mhur@cisco.com EMail: mhur@cisco.com
http://www.cisco.com http://www.cisco.com
Joseph Salowey
Cisco Systems
2901 Third Avenue
Seattle, WA 98121
Phone: +1 206 256 3380
EMail: jsalowey@cisco.com
http://www.cisco.com
Ari Medvinsky Ari Medvinsky
Keen.com Liberate
2480 Sand Hill Road, Suite 200 2 Circle Star Way
Menlo Park, CA 94025 San Carlos, CA 94070-6200
Phone: +1 415 284 4085 Phone: +1 650 701 4000
EMail: ari@keen.com EMail: ari@liberate.com
http://www.keen.com http://www.liberate.com
10. Full Copyright Statement 10. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
skipping to change at line 473 skipping to change at line 485
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendices 11. Appendix
A. Changes from RFC 2712 Changes from RFC 2712
Added new cipher suites with NULL confidentiality: Added new cipher suites with NULL confidentiality:
TLS_KRB5_WITH_NULL_SHA TLS_KRB5_WITH_NULL_SHA
TLS_KRB5_WITH_NULL_MD5 TLS_KRB5_WITH_NULL_MD5
TLS_KRB5_WITH_NULL_NULL
Added new cipher suites to support AES:
TLS_KRB5_WITH_AES_128_CBC_SHA
TLS_KRB5_WITH_AES_256_CBC_SHA
40 bit ciphers have been removed, and AES ciphers have been added.
All of the ciphersuites have been renumbered to avoid conflicts with
exisiting implementations of RFC 2712.
RFC 2712 utilized only the ClientKeyExchange message for conveying RFC 2712 utilized only the ClientKeyExchange message for conveying
the Kerberos credentials and encrypted premaster-secret. This the Kerberos credentials and encrypted premaster-secret. This
specification moves the Kerberos credentials to the client specification moves the Kerberos credentials to the client
certificate message, and it allows the client to pass delegated certificate message, and it allows the client to pass delegated
credentials as well. Additionally, this specification allows the credentials as well. Additionally, this specification allows the
server to specify Kerberos-specific information (realm, delegation server to specify Kerberos-specific information (realm, delegation
required, etc.) in the CertificateRequest message. required, etc.) in the CertificateRequest message.
B. IESG Note from RFC 2712
The 40-bit ciphersuites defined in this memo are included only for
the purpose of documenting the fact that those ciphersuite codes have
already been assigned. 40-bit ciphersuites were designed to comply
with US-centric, and now obsolete, export restrictions. They were
never secure, and nowadays are inadequate even for casual
applications. Implementation and use of the 40-bit ciphersuites
defined in this document, and elsewhere, is strongly discouraged.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/