summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorNikos Mavrogiannopoulos <nmav@gnutls.org>2001-10-08 07:10:38 +0000
committerNikos Mavrogiannopoulos <nmav@gnutls.org>2001-10-08 07:10:38 +0000
commit767e33eba3d47cff204d1141453b64cac6bc7f82 (patch)
treebe2bf72dd2513a62946324ce84d8f5528baa59bb
parentff88f1881e3c17fa58d182ad29780087332c7f00 (diff)
downloadgnutls-767e33eba3d47cff204d1141453b64cac6bc7f82.tar.gz
updated documents
Diffstat
-rw-r--r--doc/protocol/draft-ietf-tls-ciphersuite-05.txt (renamed from doc/protocol/draft-ietf-tls-ciphersuite-03.txt)68
-rw-r--r--doc/protocol/draft-ietf-tls-extensions-01.txt (renamed from doc/protocol/draft-ietf-tls-extensions-00.txt)554
-rw-r--r--doc/protocol/draft-ietf-tls-kerb-00.txt522
-rw-r--r--doc/protocol/rfc2712.txt395
4 files changed, 734 insertions, 805 deletions
diff --git a/doc/protocol/draft-ietf-tls-ciphersuite-03.txt b/doc/protocol/draft-ietf-tls-ciphersuite-05.txt
index ac0de90990..628f7a4ebd 100644
--- a/doc/protocol/draft-ietf-tls-ciphersuite-03.txt
+++ b/doc/protocol/draft-ietf-tls-ciphersuite-05.txt
@@ -6,7 +6,7 @@
Network Working Group Pete Chown
INTERNET DRAFT Skygate Technology
-<draft-ietf-tls-ciphersuite-03.txt> 22 January 2001
+<draft-ietf-tls-ciphersuite-05.txt> 14 August 2001
AES Ciphersuites for TLS
@@ -21,7 +21,7 @@ Status of this Memo
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
- months and may be updated, replaced, or obsoleted by other docu­
+ months and may be updated, replaced, or obsoleted by other docu¡
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in
progress.''
@@ -49,7 +49,7 @@ Overview
2. Triple DES is much less efficient than more modern ciphers.
- 3. Now the AES process is completed there will be commercial pres­
+ 3. Now the AES process is completed there will be commercial pres¡
sure to use the selected cipher. The AES is efficient and has
withstood extensive cryptanalytic efforts. The AES is
@@ -57,7 +57,7 @@ Overview
Chown [Page 1]
-ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
+ietf-tls-ciphersuite-05 AES Ciphersuites for TLS 14 August 2001
therefore a desirable choice.
@@ -72,7 +72,7 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
Cipher Usage
- The new ciphersuites proposed here are very similar to the follow­
+ The new ciphersuites proposed here are very similar to the follow¡
ing, defined in [TLS]:
TLS_RSA_WITH_3DES_EDE_CBC_SHA
@@ -113,7 +113,7 @@ Cipher Usage
Chown [Page 2]
-ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
+ietf-tls-ciphersuite-05 AES Ciphersuites for TLS 14 August 2001
CipherSuite Certificate type (if applicable)
@@ -138,7 +138,7 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
The AES supports key lengths of 128, 192 and 256 bits. However,
this document only defines ciphersuites for 128- and 256-bit keys.
- This is to avoid unnecessary proliferation of ciphersuites. Rijn­
+ This is to avoid unnecessary proliferation of ciphersuites. Rijn¡
dael actually allows for 192- and 256-bit block sizes as well as
the 128-bit blocks mandated by the AES process. The ciphersuites
defined here all use 128-bit blocks.
@@ -169,7 +169,7 @@ Security Considerations
Chown [Page 3]
-ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
+ietf-tls-ciphersuite-05 AES Ciphersuites for TLS 14 August 2001
secure, and it has withstood extensive cryptanalytic attack.
@@ -178,7 +178,7 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
without any known reduction in security in other areas. To obtain
the maximum benefit from these ciphersuites:
- 1. The ephemeral keys should only be used once. With the TLS pro­
+ 1. The ephemeral keys should only be used once. With the TLS pro¡
tocol as currently defined there is no significant efficiency
gain from reusing ephemeral keys.
@@ -186,7 +186,7 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
longer required.
3. The random number generator used to create ephemeral keys must
- not reveal past output even when its internal state is compro­
+ not reveal past output even when its internal state is compro¡
mised.
[TLS] describes the anonymous Diffie-Hellman (ADH) ciphersuites as
@@ -198,7 +198,7 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
parties must authenticate to each other by some means other
than TLS.
- 2. ADH is vulnerable to man-in-the-middle attacks, as a conse­
+ 2. ADH is vulnerable to man-in-the-middle attacks, as a conse¡
quence of the lack of authentication. The parties must have a
way of determining whether they are participating in the same
TLS connection. If they are not, they can deduce that they are
@@ -225,21 +225,21 @@ Copyright
Chown [Page 4]
-ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
+ietf-tls-ciphersuite-05 AES Ciphersuites for TLS 14 August 2001
Copyright (C) The Internet Society 2001. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
- it or assist in its implementation may be prepared, copied, pub­
+ it or assist in its implementation may be prepared, copied, pub¡
lished and distributed, in whole or in part, without restriction of
- any kind, provided that the above copyright notice and this para­
- graph are included on all such copies and derivative works. How­
+ any kind, provided that the above copyright notice and this para¡
+ graph are included on all such copies and derivative works. How¡
ever, this document itself may not be modified in any way, such as
by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
- purpose of developing Internet standards in which case the proce­
+ purpose of developing Internet standards in which case the proce¡
dures for copyrights defined in the Internet Standards process must
be followed, or as required to translate it into languages other
than English.
@@ -248,16 +248,16 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on
- an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI­
+ an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGI¡
NEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR­
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WAR¡
RANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
- intellectual property or other rights that might be claimed to per­
+ intellectual property or other rights that might be claimed to per¡
tain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
@@ -266,7 +266,7 @@ Intellectual Property
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
- to obtain a general license or permission for the use of such pro­
+ to obtain a general license or permission for the use of such pro¡
prietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
@@ -281,7 +281,7 @@ Intellectual Property
Chown [Page 5]
-ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
+ietf-tls-ciphersuite-05 AES Ciphersuites for TLS 14 August 2001
During the development of the AES, NIST published the following
@@ -292,7 +292,7 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
NIST reminds all interested parties that the adoption of
AES is being conducted as an open standards-setting
activity. Specifically, NIST has requested that all
- interested parties identify to NIST any patents or inven­
+ interested parties identify to NIST any patents or inven¡
tions that may be required for the use of AES. NIST
hereby gives public notice that it may seek redress under
the antitrust laws of the United States against any party
@@ -301,20 +301,20 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
NIST in response to this request for information.
One of the authors of Rijndael signed the following disclaimer when
- submitting the algorithm to NIST for consideration in the AES pro­
+ submitting the algorithm to NIST for consideration in the AES pro¡
cess:
I, Joan Daemen, do hereby declare that to the best of my
- knowledge the practice of the algorithm, reference imple­
+ knowledge the practice of the algorithm, reference imple¡
mentation, and mathematically optimized implementations,
I have submitted, known as Rijndael may be covered by the
following U.S. and/or foreign patents:
none
- I do hereby declare that I am aware of no patent applica­
- tions which may cover the practice of my submitted algo­
- rithm, reference implementation or mathematically opti­
+ I do hereby declare that I am aware of no patent applica¡
+ tions which may cover the practice of my submitted algo¡
+ rithm, reference implementation or mathematically opti¡
mized implementations.
I do hereby understand that my submitted algorithm may
@@ -329,7 +329,7 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
best of my knowledge, I have fully disclosed all patents
and patent applications relating to my algorithm. I also
understand that the U.S. Government may, during the
- course of the lifetime of the AES or during the FIPS pub­
+ course of the lifetime of the AES or during the FIPS pub¡
lic review process, modify the algorithm's specifications
(e.g., to protect against a newly discovered
@@ -337,7 +337,7 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
Chown [Page 6]
-ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
+ietf-tls-ciphersuite-05 AES Ciphersuites for TLS 14 August 2001
vulnerability). Should my submission be selected for
@@ -348,12 +348,12 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
I do hereby agree to provide the statements for any
patent or patent application identified to cover practice
- of my algorithm, reference implementation or mathemati­
+ of my algorithm, reference implementation or mathemati¡
cally optimized implementations and the right to use such
implementations for the purposes of the AES evaluation
process.
- I understand that NIST will announce the selected algo­
+ I understand that NIST will announce the selected algo¡
rithm(s) and proceed to publish the draft FIPS for public
comment. If my algorithm (or the derived algorithm) is
not selected for inclusion in the FIPS (including those
@@ -383,7 +383,7 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
application information, as provided to NIST with our
original submission in June 1998, has not changed. To
the best of our knowledge, there are no patents or patent
- applications covering the practice of the algorithm, ref­
+ applications covering the practice of the algorithm, ref¡
erence implementation or the mathematically optimized
implementations.
@@ -393,7 +393,7 @@ ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
Chown [Page 7]
-ietf-tls-ciphersuite-03 AES Ciphersuites for TLS 22 January 2001
+ietf-tls-ciphersuite-05 AES Ciphersuites for TLS 14 August 2001
[signed]
@@ -426,7 +426,7 @@ Author's Address
SW19 3TZ
United Kingdom
- Phone: +44 20 8542 0176
+ Phone: +44 20 8542 7856
Email: pc@skygate.co.uk
diff --git a/doc/protocol/draft-ietf-tls-extensions-00.txt b/doc/protocol/draft-ietf-tls-extensions-01.txt
index 38cd755b51..45869388cb 100644
--- a/doc/protocol/draft-ietf-tls-extensions-00.txt
+++ b/doc/protocol/draft-ietf-tls-extensions-01.txt
@@ -4,14 +4,14 @@
TLS Working Group Simon Blake-Wilson, Certicom
INTERNET-DRAFT Magnus Nystrom, RSA Security
-June 20, 2001 David Hopwood, Independent Consultant
-Expires December 20, 2001 Jan Mikkelsen, Transactionware
+September 27, 2001 David Hopwood, Independent Consultant
+Expires March 27, 2002 Jan Mikkelsen, Transactionware
Intended Category: Standards track Tim Wright, Vodafone
TLS Extensions
- <draft-ietf-tls-extensions-00.txt>
+ <draft-ietf-tls-extensions-01.txt>
Status of this Memo
@@ -53,9 +53,9 @@ Intended Category: Standards track Tim Wright, Vodafone
-Blake-Wilson et al. Expires: December 2001 [Page 1]
+Blake-Wilson et al. Expires: March 2002 [Page 1]
-INTERNET-DRAFT TLS Extensions June 2001
+INTERNET-DRAFT TLS Extensions September 2001
Please send comments on this document to the TLS mailing list.
@@ -69,22 +69,22 @@ INTERNET-DRAFT TLS Extensions June 2001
2.3. Hello Extensions ........................................ 5
2.4. Extensions to the handshake protocol .................... 6
3. Specific Extensions ....................................... 7
- 3.1. DNS Name Indication ..................................... 7
- 3.2. Maximum Record Size Negotiation ......................... 8
- 3.3. Client Certificate URLs ................................. 9
+ 3.1. Server Name Indication .................................. 7
+ 3.2. Maximum Record Size Negotiation ......................... 9
+ 3.3. Client Certificate URLs ................................ 10
3.4. Trusted CA Indication .................................. 11
- 3.5. Truncated HMAC ......................................... 12
- 3.6. OCSP Status Request..................................... 13
- 4. Error alerts ............................................. 14
- 5. Procedure for Defining New Extensions..................... 16
- 6. Security Considerations .................................. 17
- 6.1. Security of dns_name ................................... 17
- 6.2. Security of max_record_size ............................ 17
+ 3.5. Truncated HMAC ......................................... 13
+ 3.6. Certificate Status Request.............................. 14
+ 4. Error alerts ............................................. 15
+ 5. Procedure for Defining New Extensions..................... 17
+ 6. Security Considerations .................................. 18
+ 6.1. Security of server_name ................................ 18
+ 6.2. Security of max_record_size ............................ 18
6.3. Security of client_certificate_url ..................... 18
- 6.4. Security of trusted_ca_keys ............................ 18
- 6.5. Security of truncated_hmac ............................. 19
- 6.6. Security of status_request ............................. 19
- 7. Internationalisation Considerations .......................19
+ 6.4. Security of trusted_ca_keys ............................ 19
+ 6.5. Security of truncated_hmac ............................. 20
+ 6.6. Security of status_request ............................. 20
+ 7. Internationalisation Considerations .......................20
8. Intellectual Property Rights ............................. 20
9. Acknowledgments .......................................... 20
10. References ............................................... 20
@@ -109,9 +109,9 @@ INTERNET-DRAFT TLS Extensions June 2001
-Blake-Wilson et al. Expires: December 2001 [Page 2]
+Blake-Wilson et al. Expires: March 2002 [Page 2]
-INTERNET-DRAFT TLS Extensions June 2001
+INTERNET-DRAFT TLS Extensions September 2001
memory limitations, and battery life limitations.
@@ -123,7 +123,7 @@ INTERNET-DRAFT TLS Extensions June 2001
Specifically, the extensions described in this document are designed
to:
- - Allow TLS clients to provide to the TLS server the DNS name of the
+ - Allow TLS clients to provide to the TLS server the name of the
server they are contacting. This functionality is desirable to
facilitate secure connections to servers which host multiple
'virtual' servers at a single underlying network address.
@@ -148,9 +148,10 @@ INTERNET-DRAFT TLS Extensions June 2001
bandwidth in constrained access networks.
- Allow TLS clients and servers to negotiate that the server sends
- the client an OCSP [OCSP] response during a TLS handshake. This
- functionality is desirable in order to avoid sending a CRL over a
- constrained access network and therefore save bandwidth.
+ the client certificate status information (e.g. an OCSP [OCSP]
+ response) during a TLS handshake. This functionality is desirable
+ in order to avoid sending a CRL over a constrained access network
+ and therefore save bandwidth.
In order to support the extensions above, general extension
mechanisms for the client hello message and the server hello message
@@ -164,10 +165,9 @@ INTERNET-DRAFT TLS Extensions June 2001
-
-Blake-Wilson et al. Expires: December 2001 [Page 3]
+Blake-Wilson et al. Expires: March 2002 [Page 3]
-INTERNET-DRAFT TLS Extensions June 2001
+INTERNET-DRAFT TLS Extensions September 2001
Backwards compatibility is primarily achieved via two considerations:
@@ -209,24 +209,23 @@ INTERNET-DRAFT TLS Extensions June 2001
2.1. Extended Client Hello
- The extended client hello message format MAY be sent in place of the
- client hello message format when clients wish to request extended
- functionality from servers. The extended client hello message format
- is:
+ Clients MAY request extended functionality from servers by sending
+ the extended client hello message format in place of the client hello
+ message format. The extended client hello message format is:
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
+ CipherSuite cipher_suites<2..2^16-1>;
-Blake-Wilson et al. Expires: December 2001 [Page 4]
+Blake-Wilson et al. Expires: March 2002 [Page 4]
-INTERNET-DRAFT TLS Extensions June 2001
+INTERNET-DRAFT TLS Extensions September 2001
- CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>;
} ClientHello;
@@ -274,15 +273,15 @@ INTERNET-DRAFT TLS Extensions June 2001
struct {
ExtensionType extensionType;
+ opaque extension_data<0..2^16-1>;
-Blake-Wilson et al. Expires: December 2001 [Page 5]
+Blake-Wilson et al. Expires: March 2002 [Page 5]
-INTERNET-DRAFT TLS Extensions June 2001
+INTERNET-DRAFT TLS Extensions September 2001
- opaque extension_data<0..2^16-1>;
} Extension;
Here:
@@ -295,7 +294,7 @@ INTERNET-DRAFT TLS Extensions June 2001
The extension types defined in this document are:
enum {
- dns_name(0), max_record_size(1), client_certificate_url(2),
+ server_name(0), max_record_size(1), client_certificate_url(2),
trusted_ca_keys(3), truncated_hmac(4), status_request(5),
(65535)
} ExtensionType;
@@ -307,11 +306,14 @@ INTERNET-DRAFT TLS Extensions June 2001
an extension type in the extended server hello that they did not
request in the associated (extended) client hello.
+ Nonetheless "server initiated" extensions may be provided in the
+ future within this framework by requiring the client to first send an
+ empty extension to indicate that they support a particular extension.
+
Also note that when multiple extensions are present in the extended
- client hello or the extended server hello, the extensions must appear
- in the order identified in "ExtensionType". Thus clients and servers
- MUST abort the handshake if they receive an extended hello message in
- which the extensions are not in the correct order.
+ client hello or the extended server hello, the extensions may appear
+ in the order identified in "ExtensionType", or they may appear in
+ another order.
Finally note that all the extensions defined in this document are
relevant only when a session is initiated. Extensions appearing in
@@ -322,24 +324,25 @@ INTERNET-DRAFT TLS Extensions June 2001
2.4. Extensions to the handshake protocol
This document suggests the use of two new handshake messages,
- "CertificateURL" and "CertificateAndOCSPResponse". These messages are
+ "CertificateURL" and "CertificateStatus". These messages are
described in Section 3.3 and Section 3.6, respectively. The new
handshake message structure therefore becomes:
enum {
hello_request(0), client_hello(1), server_hello(2),
- certificate(11), server_key_exchange (12),
- certificate_request(13), server_hello_done(14),
-Blake-Wilson et al. Expires: December 2001 [Page 6]
+Blake-Wilson et al. Expires: March 2002 [Page 6]
-INTERNET-DRAFT TLS Extensions June 2001
+INTERNET-DRAFT TLS Extensions September 2001
+ certificate(11), server_key_exchange (12),
+ certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
- finished(20), certificate_url(21), ocsp_response(22), (255)
+ finished(20), certificate_url(21), certificate_status(22),
+ (255)
} HandshakeType;
struct {
@@ -357,7 +360,7 @@ INTERNET-DRAFT TLS Extensions June 2001
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case certificate_url: CertificateURL;
- case ocsp_response: CertificateAndOCSPResponse;
+ case certificate_status: CertificateStatus;
} body;
} Handshake;
@@ -377,29 +380,47 @@ INTERNET-DRAFT TLS Extensions June 2001
describes the extension to allow clients to indicate which CA root
keys they possess. Section 3.5 describes the extension to allow the
use of truncated HMAC. Section 3.6 describes the extension to
- support integration of OCSP into TLS handshakes.
+ support integration of certificate status information messages into
+ TLS handshakes.
- 3.1. DNS Name Indication
+ 3.1. Server Name Indication
- TLS does not provide a mechanism for clients to tell servers the DNS
- name of the server they are contacting. It may be desirable for
- clients to provide this information to facilitate secure connections
- to servers which host multiple 'virtual' servers at a single
- underlying network address.
+ TLS does not provide a mechanism for clients to tell servers the name
-Blake-Wilson et al. Expires: December 2001 [Page 7]
+Blake-Wilson et al. Expires: March 2002 [Page 7]
-INTERNET-DRAFT TLS Extensions June 2001
+INTERNET-DRAFT TLS Extensions September 2001
+
+
+ of the server they are contacting. It may be desirable for clients to
+ provide this information to facilitate secure connections to servers
+ which host multiple 'virtual' servers at a single underlying network
+ address.
+ In order to provide the server name, clients MAY include an extension
+ of type "server_name" in the (extended) client hello. The
+ "extension_data" field of this extension shall contain "ServerName"
+ where:
+
+ struct {
+ NameType name_type;
+ select (name_type) {
+ case dns_name: DNSName;
+ }
+ } ServerName;
- In order to provide the server DNS name, clients MAY include an
- extension of type "dns_name" in the (extended) client hello. The
- "extension_data" field of this extension shall contain:
+ enum {
+ dns_name(0), (255)
+ } NameType;
opaque DNSName<1..2^16-1>;
+ Currently the only server names supported are DNS names, however this
+ does not imply any dependency of TLS on DNS names, and other name
+ types may be added in the future.
+
"DNSName" contains the fully qualified domain name of the server, as
understood by the client. The domain name is represented as a byte
string using UTF-8 encoding [UTF8], without a trailing dot. (Note
@@ -408,20 +429,29 @@ INTERNET-DRAFT TLS Extensions June 2001
DNS protocol. The latter has yet to be decided by the IETF
International Domain Name Working Group.)
- Literal IPv4 and IPv6 addresses are not permitted.
+ Literal IPv4 and IPv6 addresses are not permitted in "DNSName".
- It is RECOMMENDED that clients include an extension of type "DNSName"
- in the client hello whenever they locate a server by its domain name.
+ It is RECOMMENDED that clients include an extension of type
+ "ServerName" in the client hello whenever they locate a server by its
+ domain name.
- Servers that receive a client hello containing the "dns_name"
+ Servers that receive a client hello containing the "server_name"
extension, MAY use the information contained in the extension to
guide their selection of an appropriate certificate to return to the
client. In this event, the server shall include an extension of type
- "dns_name" in the (extended) server hello. The "extension_data" field
- of this extension shall be empty.
+ "server_name" in the (extended) server hello. The "extension_data"
+ field of this extension shall be empty.
+
+
+
+
+Blake-Wilson et al. Expires: March 2002 [Page 8]
+
+INTERNET-DRAFT TLS Extensions September 2001
+
If the server understood the client hello extension but does not
- recognize the DNS name as belonging to a domain it is responsible
+ recognize the server name as belonging to a domain it is responsible
for, it should send an unrecognised_domain alert (which may or may
not be fatal).
@@ -443,13 +473,6 @@ INTERNET-DRAFT TLS Extensions June 2001
whose value is the desired maximum record size. The allowed values
for this field are: 2^9, 2^10, 2^11, and 2^12.
-
-
-Blake-Wilson et al. Expires: December 2001 [Page 8]
-
-INTERNET-DRAFT TLS Extensions June 2001
-
-
Servers that receive an extended client hello containing a
"max_record_size" extension, MAY accept the requested maximum record
size by including an extension of type "max_record_size" in the
@@ -475,6 +498,14 @@ INTERNET-DRAFT TLS Extensions June 2001
session resumptions.
The negotiated size limits the input that the record layer may
+
+
+
+Blake-Wilson et al. Expires: March 2002 [Page 9]
+
+INTERNET-DRAFT TLS Extensions September 2001
+
+
process without fragmentation. Note that the output of the record
layer may be larger. For example, if the negotiated size is 2^9=512,
then for currently defined cipher suites (those defined in [TLS],
@@ -498,14 +529,6 @@ INTERNET-DRAFT TLS Extensions June 2001
In order to negotiate to send certificate URLs to a server, clients
MAY include an extension of type "client_certificate_url" in the
-
-
-
-Blake-Wilson et al. Expires: December 2001 [Page 9]
-
-INTERNET-DRAFT TLS Extensions June 2001
-
-
(extended) client hello. The "extension_data" field of this extension
shall be empty.
@@ -532,13 +555,27 @@ INTERNET-DRAFT TLS Extensions June 2001
CertHash certificate_hash;
} URLAndHash;
- opaque CertHash[20];
- Here "url_and_hash_list" contains a sequence of URLs and SHA-1
- hashes, each URL referring to a single, DER-encoded X.509v3
- certificate, and the SHA-1 hash of that certificate. The URLs should
- occur in the list in the same order that the corresponding
- certificates appear in the certificate chain.
+
+Blake-Wilson et al. Expires: March 2002 [Page 10]
+
+INTERNET-DRAFT TLS Extensions September 2001
+
+
+ opaque CertHash<0..20>;
+
+ Here "url_and_hash_list" contains a sequence of URLs and hashes.
+
+ Each URL refers either to a single, DER-encoded X.509v3 certificate,
+ or to a PKCS7 certificate chain.
+
+ The hash corresponding to each URL at the clients discretion is
+ either empty or it contains the SHA-1 hash of the (DER-encoded)
+ certificate or certificate chain (DER-encoded CertificateSet, see
+ [CMS]).
+
+ URLs should occur in the list in the same order that the
+ corresponding certificates appear in the certificate chain.
Servers receiving "CertificateURL" shall attempt to retrieve the
client's certificate chain from the URLs, and then process the
@@ -546,22 +583,20 @@ INTERNET-DRAFT TLS Extensions June 2001
certificate chain from the URLs, and MUST be supported by servers
supporting this extension.
- Servers MUST check that the SHA-1 hash of any certificates retrieved
- from a CertificateURL matches the given hash, and then process the
- certificate chain as usual.
+ In general, the format of the certificates retrieved by the server
+ will depend on the protocol used by the server to retrieve them, as
+ recommended by the PKIX working group. In the case of HTTP, the
+ response MUST be a MIME formatted response. When a single certificate
+ is returned, the Content-type is application/pkix-cert. When a
+ certificate chain is returned, the Content-type is
+ application/pkcs7-mime.
- If any retrieved certificate does not have the correct SHA-1 hash,
- the server MUST abort the handshake with a bad_certificate alert.
+ Servers MUST check that the SHA-1 hash of any certificates retrieved
+ from a CertificateURL matches the given hash if it is present. If
+ any retrieved certificate does not have the correct SHA-1 hash, the
+ server MUST abort the handshake with a bad_certificate alert.
Note that clients may choose to send either "Certificate" or
-
-
-
-Blake-Wilson et al. Expires: December 2001 [Page 10]
-
-INTERNET-DRAFT TLS Extensions June 2001
-
-
"CertificateURL" after successfully negotiating the option to send
certificate URLs. The option to send a certificate is included to
provide flexibility to clients possessing multiple certificates.
@@ -575,6 +610,14 @@ INTERNET-DRAFT TLS Extensions June 2001
Constrained clients which, due to memory limitations, possess only a
small number of CA root keys, may wish to indicate to servers which
root keys they possess, in order to avoid repeated handshake
+
+
+
+Blake-Wilson et al. Expires: March 2002 [Page 11]
+
+INTERNET-DRAFT TLS Extensions September 2001
+
+
failures.
In order to indicate which CA root keys they possess, clients MAY
@@ -589,14 +632,14 @@ INTERNET-DRAFT TLS Extensions June 2001
struct {
IdentifierType identifier_type;
select (identifier_type) {
- case null: struct {};
+ case pre_agreed: struct {};
case key_hash_sha: KeyHash;
case x509_name: DistinguishedName;
case cert_hash: CertHash;
} Identifier;
} TrustedAuthority;
- enum { null(0), key_hash_sha(1), x509_name(2), cert_hash(3),
+ enum { pre_agreed(0), key_hash_sha(1), x509_name(2), cert_hash(3),
(255)}
IdentifierType;
@@ -607,17 +650,9 @@ INTERNET-DRAFT TLS Extensions June 2001
Here "TrustedAuthorities" provides a list of CA root key identifiers
that the client possesses. Each CA root key is identified via either:
- - "null" - no CA root key identity supplied.
+ - "pre_agreed" - no CA root key identity supplied.
- "key_hash_sha" - contains the SHA-1 hash of the CA root key. For
-
-
-
-Blake-Wilson et al. Expires: December 2001 [Page 11]
-
-INTERNET-DRAFT TLS Extensions June 2001
-
-
DSA and ECDSA keys, this is the hash of the "subjectPublicKey"
value. For RSA keys, this is the hash of the byte string
representation of the modulus (without any initial 0-valued
@@ -632,6 +667,13 @@ INTERNET-DRAFT TLS Extensions June 2001
Note that clients may include none, some, or all of the CA root keys
they possess in this extension.
+
+
+Blake-Wilson et al. Expires: March 2002 [Page 12]
+
+INTERNET-DRAFT TLS Extensions September 2001
+
+
Note also that it is possible that a key hash or a distinguished name
alone may not uniquely identify a certificate issuer - for example if
a particular CA has multiple key pairs - however here we assume this
@@ -666,14 +708,6 @@ INTERNET-DRAFT TLS Extensions June 2001
Note that if new ciphersuites are added that do not use HMAC, and the
session negotiates one of these ciphersuites, this extension will
have no effect. It is strongly recommended that any new cipher suites
-
-
-
-Blake-Wilson et al. Expires: December 2001 [Page 12]
-
-INTERNET-DRAFT TLS Extensions June 2001
-
-
using other MACs consider the MAC size as an integral part of the
cipher suite definition, taking into account both security and
bandwidth considerations.
@@ -689,86 +723,103 @@ INTERNET-DRAFT TLS Extensions June 2001
The negotiated HMAC truncation size applies for the duration of the
session including session resumptions.
- 3.6. OCSP Status Request
- Constrained clients may wish to use OCSP [OCSP] to check the validity
- of server certificates, in order to avoid transmission of CRLs and
- therefore save bandwidth on constrained networks.
- In order to indicate their desire to use OCSP, clients MAY include an
- extension of type "status_request" in the (extended) client hello.
- The "extension_data" field of this extension shall contain
- "StatusRequest" where:
+Blake-Wilson et al. Expires: March 2002 [Page 13]
+
+INTERNET-DRAFT TLS Extensions September 2001
+
+
+ 3.6. Certificate Status Request
+
+ Constrained clients may wish to use a certificate-status protocol
+ such as OCSP [OCSP] to check the validity of server certificates, in
+ order to avoid transmission of CRLs and therefore save bandwidth on
+ constrained networks. This extension allows for such information to
+ be sent in the TLS handshake, saving roundtrips and resources.
+
+ In order to indicate their desire to receive certificate status
+ information, clients MAY include an extension of type
+ "status_request" in the (extended) client hello. The "extension_data"
+ field of this extension shall contain "CertificateStatusRequest"
+ where:
+
+ struct {
+ CertificateStatusType status_type;
+ select (status_type) {
+ case ocsp: OCSPStatusRequest;
+ }
+ } CertificateStatusRequest;
+
+ enum { ocsp(1), 255) } CertificateStatusType;
struct {
ResponderID responder_id_list<0..2^16-1>;
Extensions request_extensions;
- } StatusRequest;
+ } OCSPStatusRequest;
opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;
- Here "ResponderIDs" provides a list of OCSP responders that the
- client trusts. A zero-length "responder_id_list" sequence has the
- special meaning that the responders are implicitly known to the
- server - e.g. by prior arrangement. "Extensions" is a DER encoding of
- the OCSP request extensions.
+ In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
+ responders that the client trusts. A zero-length "responder_id_list"
+ sequence has the special meaning that the responders are implicitly
+ known to the server - e.g. by prior arrangement. "Extensions" is a
+ DER encoding of OCSP request extensions.
Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
defined in [OCSP].
Servers that receive a client hello containing the "status_request"
- extension, MAY return an OCSP response to the client along with their
- certificate. If so, they SHOULD use the information contained in the
- extension when selecting an OCSP responder, and SHOULD include
- request_extensions in the OCSP request.
+ extension, MAY return a suitable certificate status response to the
+ client along with their certificate. If OCSP is requested, they
+ SHOULD use the information contained in the extension when selecting
+ an OCSP responder, and SHOULD include request_extensions in the OCSP
+ request.
+ Servers return a certificate response along with their certificate by
-Blake-Wilson et al. Expires: December 2001 [Page 13]
+
+Blake-Wilson et al. Expires: March 2002 [Page 14]
-INTERNET-DRAFT TLS Extensions June 2001
+INTERNET-DRAFT TLS Extensions September 2001
- Servers return an OCSP response along with their certificate by
- sending "CertificateAndOCSPResponse" in place of the "Certificate"
- message. If a server returns an OCSP response, then the server MUST
- have included an extension of type "status_request" with empty
- "extension_data" in the extended server hello.
+ sending a "CertificateStatus" message immediately after the
+ "Certificate" message (and before any "ServerKeyExchange" or
+ "CertificateRequest" messages). If a server returns a
+ "CertificateStatus" message, then the server MUST have included an
+ extension of type "status_request" with empty "extension_data" in the
+ extended server hello.
struct {
- ASN.1Cert certificate_list<0..2^24-1>;
- OCSPResponse ocsp_response;
- } CertificateAndOCSPResponse;
-
- opaque ASN.1Cert<1..2^24-1>;
+ CertificateStatusType status_type;
+ select (status_type) {
+ case ocsp: OCSPResponse ocsp_response;
+ }
+ } CertificateStatus;
opaque OCSPResponse<1..2^24-1>;
- Here "ocsp_response" contains a complete, DER-encoded OCSP response
+ An "ocsp_response" contains a complete, DER-encoded OCSP response
(using the ASN.1 type OCSPResponse defined in [OCSP]). Note that only
one OCSP response may be sent.
- The "CertificateAndOCSPResponse" message is conveyed using the
- handshake message type "ocsp_response".
+ The "CertificateStatus" message is conveyed using the handshake
+ message type "certificate_status".
- Note that a server MAY also choose not to send the
- "CertificateAndOCSPResponse" message, and instead send the
- "Certificate" message, even if it receives a "status_request"
- extension in the client hello message.
+ Note that a server MAY also choose not to send a "CertificateStatus"
+ message, even if it receives a "status_request" extension in the
+ client hello message.
- Note in addition that servers MUST NOT send the
- "CertificateAndOCSPResponse" message unless it received a
- "status_request" extension in the client hello message.
+ Note in addition that servers MUST NOT send the "CertificateStatus"
+ message unless it received a "status_request" extension in the client
+ hello message.
Clients requesting an OCSP response, and receiving an OCSP response
- in a "CertificateAndOCSPResponse" field:
-
- - MUST process the certificate as if it was received in a
- "Certificate" message, and;
-
- - SHOULD check the OCSP response and abort the handshake if the
- response is not satisfactory.
+ in a "CertificateStatus" message SHOULD check the OCSP response and
+ abort the handshake if the response is not satisfactory.
4. Error Alerts
@@ -778,37 +829,36 @@ INTERNET-DRAFT TLS Extensions June 2001
The following new error alerts are defined. To avoid "breaking"
existing clients and servers, these alerts MUST NOT be sent unless
the sending party has received an extended hello message from the
+ party they are communicating with.
+
+ - "unsupported_extension" - this alert is sent by clients that
+ receive an extended server hello containing an extension that
+ they did not put in the corresponding client hello (see Section
-Blake-Wilson et al. Expires: December 2001 [Page 14]
+Blake-Wilson et al. Expires: March 2002 [Page 15]
-INTERNET-DRAFT TLS Extensions June 2001
+INTERNET-DRAFT TLS Extensions September 2001
- party they are communicating with.
-
- - "unsupported_extension" - this alert is sent by clients that
- receive an extended server hello containing an extension that
- they did not put in the corresponding client hello (see Section
2.3). This message is always fatal.
- - "bad_extension_order" - this alert is sent by clients or servers
- that receive an extended hello with the extensions in the wrong
- order (see Section 2.3). This message is always fatal.
-
- "unrecognised_domain" - this alert is sent by servers that
- receive a dns_name extension request, but do not recognize the
- DNS name as belonging to a domain they are responsible for.
+ receive a server_name extension request, but do not recognize the
+ server name as belonging to a domain they are responsible for.
This message MAY be fatal.
- "certificate_unobtainable" - this alert is sent by servers who are
unable to retrieve a certificate chain from the URL supplied by
- the client (see Section 3.3). This message is always fatal.
+ the client (see Section 3.3). This message MAY be fatal - for
+ example if client authentication is required by the server for the
+ handshake to continue and the server is unable to retrieve the
+ certificate chain, it may send a fatal alert.
- - "bad_ocsp_response" - this alert is sent by clients that receive
- an invalid OCSP response (see Section 3.6). This message is always
- fatal.
+ - "bad_certificate_status_response" - this alert is sent by clients
+ that receive an invalid certificate status response (see Section
+ 3.6). This message is always fatal.
These error alerts are conveyed using the following syntax:
@@ -820,7 +870,7 @@ INTERNET-DRAFT TLS Extensions June 2001
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
- certificate_unobtainable(41), /* new */
+ certificate_unobtainable(41), /* new */
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
@@ -834,21 +884,20 @@ INTERNET-DRAFT TLS Extensions June 2001
export_restriction(60),
protocol_version(70),
insufficient_security(71),
+ internal_error(80),
+ user_canceled(90),
+ no_renegotiation(100),
+ unsupported_extension(110), /* new */
+ unrecognised_domain(112), /* new */
+ bad_certificate_status_response(113), /* new */
-Blake-Wilson et al. Expires: December 2001 [Page 15]
+Blake-Wilson et al. Expires: March 2002 [Page 16]
-INTERNET-DRAFT TLS Extensions June 2001
+INTERNET-DRAFT TLS Extensions September 2001
- internal_error(80),
- user_canceled(90),
- no_renegotiation(100),
- unsupported_extension(110), /* new */
- bad_extension_order(111), /* new */
- unrecognised_domain(112), /* new */
- bad_ocsp_response(113), /* new */
(255)
} AlertDescription;
@@ -890,14 +939,6 @@ INTERNET-DRAFT TLS Extensions June 2001
inputs to the Finished message hashes will be sufficient,
but extreme care is needed when the extension changes the
meaning of messages sent in the handshake phase.
-
-
-
-Blake-Wilson et al. Expires: December 2001 [Page 16]
-
-INTERNET-DRAFT TLS Extensions June 2001
-
-
Designers and implementors should be aware of the fact that
until the handshake has been authenticated, active attackers
can modify messages and insert, remove, or replace extensions.
@@ -905,6 +946,14 @@ INTERNET-DRAFT TLS Extensions June 2001
- It would be technically possible to use extensions to change
major aspects of the design of TLS; for example the design of
ciphersuite negotiation. This is not recommended; it
+
+
+
+Blake-Wilson et al. Expires: March 2002 [Page 17]
+
+INTERNET-DRAFT TLS Extensions September 2001
+
+
would be more appropriate to define a new version of TLS -
particularly since the TLS handshake algorithms have specific
protection against version rollback attacks based on the
@@ -925,11 +974,11 @@ INTERNET-DRAFT TLS Extensions June 2001
Additional security considerations are described in the TLS 1.0 RFC
[TLS].
- 6.1. Security of dns_name
+ 6.1. Security of server_name
If a single server hosts several domains, then clearly it is
necessary for the owners of each domain to ensure that this satisfies
- their security needs. Apart from this, dns_name does not appear to
+ their security needs. Apart from this, server_name does not appear to
introduce significant security issues.
The length of the domain name should be checked for buffer overflow
@@ -946,36 +995,37 @@ INTERNET-DRAFT TLS Extensions June 2001
Note that as described in section 3.2, once a non-null ciphersuite
has been activated, the effective maximum record size depends on the
ciphersuite, as well as on the negotiated max_record_size. This must
+ be taken into account when sizing buffers, and checking for buffer
+ overflow.
+ 6.3. Security of client_certificate_url
+ The major issue with this extension is whether or not clients should
+ include certificate hashes when they send certificate URLs.
-Blake-Wilson et al. Expires: December 2001 [Page 17]
-
-INTERNET-DRAFT TLS Extensions June 2001
- be taken into account when sizing buffers, and checking for buffer
- overflow.
+Blake-Wilson et al. Expires: March 2002 [Page 18]
+
+INTERNET-DRAFT TLS Extensions September 2001
- 6.3. Security of client_certificate_url
When client authentication is used *without* the
client_certificate_url extension, the client certificate chain is
- covered by the Finished message hashes. The purpose of checking a
- SHA-1 hash of the certificate chain contents, is to ensure that the
- same property holds when this extension is used - i.e. that all of
- the information in the certificate chain retrieved by the server is
- as the client intended.
-
- (The attack that this protects against is admittedly fairly
- unrealistic: the attacker would have to get a valid certificate on
- the client's key which is different from the client's certificate.
- Nevertheless, including this hash guarantees that there can be no
- unexpected problems due to the certificate chain not being directly
- covered by the Finished hashes.)
-
- A similar approach should also be taken if possible for any future
- extensions that involve fetching information from external sources.
+ covered by the Finished message hashes. The purpose of including
+ certificate hashes and checking them against the retrieved
+ certificate chain, is to ensure that the same property holds when
+ this extension is used - i.e. that all of the information in the
+ certificate chain retrieved by the server is as the client intended.
+
+ On the other hand, omitting certificate hashes enables functionality
+ which is desirable is some circumstances - for example clients can be
+ issued daily certificates which are stored at a fixed URL and need
+ not be provided to the client. Clients which choose to omit
+ certificate hashes should be aware of the possibility of an attack in
+ which the attacker obtains a valid certificate on the client's key
+ which is different from the certificate the client intended to
+ provide.
Note that although TLS uses both MD5 and SHA-1 hashes in several
other places, this was not believed to be necessary here. The
@@ -984,7 +1034,7 @@ INTERNET-DRAFT TLS Extensions June 2001
Support for client_certificate_url involves the server acting as a
client in another protocol (usually HTTP, but other URL schemes are
not prohibited). It is therefore subject to many of the same security
- considerations that apply to a publically accessible HTTP proxy
+ considerations that apply to a publicly accessible HTTP proxy
server. This includes the possibility that an attacker might use the
server to indirectly attack another host that is vulnerable to some
security flaw. It also includes potentially increased exposure to
@@ -1002,20 +1052,20 @@ INTERNET-DRAFT TLS Extensions June 2001
6.4. Security of trusted_ca_keys
It is possible that which CA root keys a client possesses could be
-
-
-
-Blake-Wilson et al. Expires: December 2001 [Page 18]
-
-INTERNET-DRAFT TLS Extensions June 2001
-
-
regarded as confidential information. As a result, the CA root key
indication extension should be used with care.
The use of the SHA-1 certificate hash alternative ensures that each
certificate is specified unambiguously. As for the previous
extension, it was not believed necessary to use both MD5 and SHA-1
+
+
+
+Blake-Wilson et al. Expires: March 2002 [Page 19]
+
+INTERNET-DRAFT TLS Extensions September 2001
+
+
hashes.
6.5. Security of truncated_hmac
@@ -1057,15 +1107,6 @@ INTERNET-DRAFT TLS Extensions June 2001
extensions use text strings, then internationalisation should be
considered in their design.
-
-
-
-
-Blake-Wilson et al. Expires: December 2001 [Page 19]
-
-INTERNET-DRAFT TLS Extensions June 2001
-
-
8. Intellectual Property Rights
The IETF invites any interested party to bring to its attention any
@@ -1074,6 +1115,13 @@ INTERNET-DRAFT TLS Extensions June 2001
this document. Please address the information to the IETF Executive
Director.
+
+
+Blake-Wilson et al. Expires: March 2002 [Page 20]
+
+INTERNET-DRAFT TLS Extensions September 2001
+
+
9. Acknowledgments
The authors wish to thank the TLS Working Group and the WAP Security
@@ -1081,6 +1129,9 @@ INTERNET-DRAFT TLS Extensions June 2001
10. References
+ [CMS] R. Housley, "Cryptographic Message Syntax," IETF RFC 2630, June
+ 1999.
+
[HMAC] Krawczyk, H., Bellare, M., and Canetti, R. - HMAC: Keyed-
hashing for message authentication. IETF RFC 2104, February 1997.
@@ -1117,9 +1168,14 @@ INTERNET-DRAFT TLS Extensions June 2001
-Blake-Wilson et al. Expires: December 2001 [Page 20]
+
+
+
+
+
+Blake-Wilson et al. Expires: March 2002 [Page 21]
-INTERNET-DRAFT TLS Extensions June 2001
+INTERNET-DRAFT TLS Extensions September 2001
11. Authors' Addresses
@@ -1138,7 +1194,7 @@ INTERNET-DRAFT TLS Extensions June 2001
Jan Mikkelsen
Transactionware
- jam@transactionware.com
+ janm@transactionware.com
Tim Wright
Vodafone
@@ -1173,4 +1229,4 @@ INTERNET-DRAFT TLS Extensions June 2001
-Blake-Wilson et al. Expires: December 2001 [Page 21]
+Blake-Wilson et al. Expires: March 2002 [Page 22]
diff --git a/doc/protocol/draft-ietf-tls-kerb-00.txt b/doc/protocol/draft-ietf-tls-kerb-00.txt
deleted file mode 100644
index 56d037f748..0000000000
--- a/doc/protocol/draft-ietf-tls-kerb-00.txt
+++ /dev/null
@@ -1,522 +0,0 @@
-INTERNET-DRAFT Matthew Hur
-Transport Layer Security Working Group Cisco Systems
-draft-ietf-tls-kerb-00.txt Ari Medvinsky
-Obsoletes: RFC 2712 Keen.com
-November 06, 2000 (Expires May 06, 2001)
-
-
-
-
- Kerberos Cipher Suites in Transport Layer Security (TLS)
-
-
-
-
-0. Status Of this Memo
-
- This document is an Internet-Draft and is in full conformance with
- all provisions of Section 10 of RFC 2026. Internet-Drafts are
- working documents of the Internet Engineering Task Force (IETF), its
- areas, and its working groups. Note that other groups may also
- distribute working documents as Internet-Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet- Drafts as reference
- material or to cite them other than as ``work in progress.''
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt
-
- The list of Internet-Draft Shadow Directories can be accessed at
- 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
-
- RFC 2712 [KERBTLS] introduced mechanisms for supporting Kerberos
- [KERB] authentication within the TLS protocol [TLS]. This document
- extends RFC 2712 to support delegation of Kerberos credentials. In
- 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
- authentication within a multi-tier architecture. This draft also
- proposes a mechanism for a TLS server to indicate Kerberos-specific
- information to the client within the certificate request message in
- the initial exchange.
-
-
-2. Introduction
-
- Flexibility is one of the main strengths of the TLS protocol. Clients
- and servers can negotiate cipher suites to meet specific security and
- administrative policies. RFC 2712 specified how TLS could be
- extended to support organizations with heterogeneous security
- deployments that include authentication systems based on symmetric
- cryptography. Kerberos, originally developed at MIT, is based on an
- open standard and is the most widely deployed symmetric key
- authentication system. Just as other documents specify hybrid
- asymmetric/symmetric key protocols [PKINIT] [PKCROSS] [PKTAPP], this
- document specifies how TLS may incorporate both symmetric and
- asymmetric key crypto systems.
-
- This document describes the use of Kerberos authentication within
- the TLS framework. This achieves mutual authentication and the
- establishment of a master secret using Kerberos credentials.
- Additionally, this document specifies support for delegation of
- Kerberos credentials, which enables end to end authentication within
- an n-tier architecture. The proposed changes are minimal and, in
- fact, no different from adding a new public key algorithm to the TLS
- framework.
-
-
-3. Kerberos Authentication Option In TLS
-
- This section describes the addition of the Kerberos authentication
- option to the TLS protocol. Throughout this document, we refer to
- the basic SSL handshake shown in Figure 1. For a review of the TLS
- handshake see [TLS].
-
- +-------------------------------------------------------------------+
- | CLIENT SERVER |
- | ------ ------ |
- | ClientHello |
- | ---------------------------> |
- | ServerHello |
- | Certificate * |
- | ServerKeyExchange* |
- | CertificateRequest* |
- | ServerHelloDone |
- | <--------------------------- |
- | Certificate* |
- | ClientKeyExchange |
- | CertificateVerify* |
- | change cipher spec |
- | Finished |
- | | ---------------------------> |
- | | change cipher spec |
- | | Finished |
- | | | |
- | | | |
- | Application Data <--------------------------> Application Data |
- +-------------------------------------------------------------------+
- FIGURE 1: The TLS protocol. All messages followed by a star are
- optional. Note: This figure was taken from RFC 2246.
-
- The TLS security context is negotiated in the client and server hello
- messages. For example: TLS_RSA_WITH_RC4_MD5 means the initial
- 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
- algorithm. Thus, to facilitate the Kerberos authentication option,
- we must start by defining Kerberos cipher suites including (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_NULL_MD5 = { 0x00,0x?? };
- CipherSuite TLS_KRB5_WITH_NULL_NULL = { 0x00,0x?? };
-
- To establish a Kerberos-based security context, one or more of the
- above cipher suites must be specified in the client hello message. If
- the TLS server supports the Kerberos authentication option, the
- server hello message, sent to the client, will confirm the Kerberos
- cipher suite selected by the server. The server's certificate and
- the ServerKeyExchange shown in Figure 1 will be omitted since
- authentication and the establishment of a master secret will be done
- using the client's Kerberos credentials for the TLS server. Note
- that these messages are specified as optional in the TLS protocol;
- therefore, omitting them is permissible.
-
- The Kerberos option affects three of the TLS messages: the
- CertificateRequest, the client Certificate, and the
- ClientKeyExchange. However, only the client Certificate and the
- ClientKeyExchange are required.
-
-
-3.1. Usage of the CertificateRequest Message
-
- If the server accepts a Kerberos-based ciphersuite, then it MUST send
- the CertificateRequest message to the client. This message conveys
- Kerberos-specific characteristics such as realm name or attributes
- such as forwarded ticket.
-
- RFC 2246 defines the CertificateRequest message as follows:
- +-------------------------------------------------------------------+
- | |
- | enum { |
- | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), |
- | (255) |
- | } ClientCertificateType; |
- | |
- | opaque DistinguishedName<1..2^16-1>; |
- | |
- | struct { ClientCertificateType certificate_types<1..2^8-1>; |
- | DistinguishedName certificate_authorities<3..2^16-1>; |
- | } CertificateRequest; |
- | |
- +-------------------------------------------------------------------+
- FIGURE 2: CertificateRequest message from RFC 2246
-
- This specification defines a new ClientCertificateType for a Kerberos
- certificate. This enables a client to respond to the
- CertificateRequest message when using Kerberos ciphersuites. Thus
- the following change for ClientCertificateType is required
- (Figure 3).
-
- +-------------------------------------------------------------------+
- | |
- | enum { |
- | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4), |
- | kerberos(5), (255) |
- | } ClientCertificateType; |
- | |
- +-------------------------------------------------------------------+
- FIGURE 3: New Kerberos ClientCertificateType
-
- In the case of a public key based authentication algorithm, the
- opaque DistinguishedName field is derived from [X509], and it
- contains the name of an acceptable certification authority (This is
- as specified in [TLS]). In the case of a Kerberos
- ClientCertificateType, the DistinguishedName field is defined to
- represent Kerberos information (KerbInfo) as shown in Figure 4.
-
- +-------------------------------------------------------------------+
- | |
- | enum |
- | { |
- | srv_tkt(1), fwd_tgt(2), (255) |
- | } KerbInfoType; |
- | |
- | enum |
- | { |
- | initial_tkt_required(1), (255) |
- | } AttrType; /* This may be extended to include attributes */ |
- | /* such as forwardable or renewable for example */ |
- | |
- | struct |
- | { |
- | AttrType attr_type; |
- | opaque attr_data <0..2^16-1>; |
- | } AttrInfoType |
- | |
- | struct |
- | { |
- | uint32 length; /* length of this struct */ |
- | KerbInfoType type; |
- | opaque sname <0..2^16-1>; |
- | opaque srealm <0..2^16-1>; |
- | opaque cname <0..2^16-1>; |
- | opaque crealm <0..2^16-1>; |
- | AttrInfoType attr_info <0..2^16-1>; /* sequence of */ |
- | /* attributes */ |
- | uint32 etypes <0..2^16-1>; /* list of supported */ |
- | /* Kerberos etypes */ |
- | /* for authentication */ |
- | } TktInfo; |
- | |
- | struct |
- | { |
- | uint16 num; /* number of TktInfo structs */ |
- | TktInfo tkt_info <1..2^20-1>; /* MUST have at least */ |
- | /* 1 TktInfo structs */ |
- | } KerbInfo |
- | |
- +-------------------------------------------------------------------+
- FIGURE 4: Kerberos Information for CertificateRequest Message
-
-
-3.2. Usage of the Client Certificate Message
-
- As specified by [TLS], when the client receives the
- CertificateRequest message, it MUST respond with the client
- Certificate message. As stated above, this specification defines a
- Kerberos certificate type. The format for the Kerberos certificate
- is specified in figure 5 below. This structure consists of a
- Kerberos AP-REQ message that is used for authenticating the client to
- he server. It optionally contains a series of Kerberos KRB-CRED
- messages to convey delegated credentials.
-
- 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
- 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
- in the service ticket.
-
- +-------------------------------------------------------------------+
- | |
- | opaque KrbCred <1..2^16-1>; /* Kerberos-defined KRB-CRED */ |
- | |
- | struct |
- | { |
- | opaque ap_req <1..2^16-1>; |
- | uint16 num; /* number of KrbCred structs */ |
- | KrbCred krb_cred <0..2^20-1>; |
- | } KerberosCert; |
- | |
- +-------------------------------------------------------------------+
- FIGURE 5: Kerberos Certificate Type
-
-
-3.3. Usage of the ClientKeyExchange Message
-
-
- The Kerberos option must be added to the ClientKeyExchange message as
- shown in Figure 6.
-
- +-------------------------------------------------------------------+
- | |
- | struct |
- | { |
- | select (KeyExchangeAlgorithm) |
- | { |
- | case krb: KerbEncryptedPreMasterSecret; |
- | case rsa: EncryptedPreMasterSecret; |
- | case diffie_hellman: ClientDiffieHellmanPublic; |
- | } Exchange_keys; |
- | } ClientKeyExchange; |
- | |
- | KerbEncryptedPreMasterSecret contains the PreMasterSecret |
- | encrypted within a Kerberos-defined EncryptedData structure. |
- | The encryption key is sealed in the ticket sent in the Client |
- | Certificate message. |
- | |
- +-------------------------------------------------------------------+
- FIGURE 6: The Kerberos option in the ClientKeyExchange.
-
- To use the Kerberos authentication option, the TLS client must obtain
- a service ticket for the TLS server. In TLS, the ClientKeyExchange
- message is used to pass a random 48-byte pre-master secret to the
- server.
-
- The client and server then use the pre-master secret to independently
- derive the master secret, which in turn is used for generating
- session keys and for MAC computations. Thus, if the Kerberos option
- is selected, the pre-master secret structure is the same as that used
- in the RSA case; it is encrypted under the Kerberos session key and
- sent to the TLS server along with the Kerberos credentials (see
- Figure 2). The ticket and authenticator are encoded per RFC 1510
- (ASN.1 encoding). Once the ClientKeyExchange message is received,
- the server's secret key is used to unwrap the credentials and extract
- the pre-master secret.
-
- Lastly, the client and server exchange the finished messages to
- complete the handshake. At this point we have achieved the
- following:
-
- 1) A master secret, used to protect all subsequent communication, is
- securely established.
-
- 2) Mutual client-server authentication is achieved, since the TLS
- server proves knowledge of the master secret in the finished
- message.
-
- Kerberos fits seamlessly into TLS, without adding any new messages.
-
-
-4. Naming Conventions:
-
- To obtain an appropriate service ticket, the TLS client must
- determine the principal name of the TLS server. The Kerberos service
- naming convention is used for this purpose, as follows:
-
- host/MachineName@Realm
- where:
- - The literal, "host", follows the Kerberos convention when not
- concerned about the protection domain on a particular machine.
- - "MachineName" is the particular instance of the service.
- - The Kerberos "Realm" is the domain name of the machine.
-
- As specified above, in the CertificateRequest message, the server may
- indicate the appropriate principal name and realm.
-
-
-5. Summary
-
- The proposed Kerberos authentication option is added in exactly the
- same manner as a new public key algorithm would be added to TLS.
- Furthermore, it establishes the master secret in exactly the same
- manner.
-
-
-6. Security Considerations
-
- Kerberos ciphersuites are subject to the same security considerations
- as the TLS protocol. In addition, just as a public key
- implementation must take care to protect the private key (for example
- the PIN for a smartcard), a Kerberos implementation must take care to
- protect the long lived secret that is shared between the principal
- and the KDC. In particular, a weak password may be subject to a
- dictionary attack. In order to strengthen the initial authentication
- to a KDC, an implementor may choose to utilize secondary
- authentication via a token card, or one may utilize initial
- authentication to the KDC based on public key cryptography (commonly
- known as PKINIT - a product of the Kerberos working group of the
- IETF).
-
- The unauthenticated CertificateRequest message, specified above,
- enables the server to request a particular client principal name as
- well as a particular service principal name. In the event that a
- service principal name is specified, there is a risk that the client
- may be tricked into requesting a ticket for a rogue server.
- Furthermore, if delegation is requested, the client may be tricked
- 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
- rely on a combination of its own local policy, local configuration
- information, and information supplied by the KDC. The client may
- choose to use only the naming convention specified in section 4. The
- client may rely on the KDC performing name cannonicalization (this is
- a matter that is adressed in revisions to RFC 1510).
-
- The client must apply its local policy to determine whether or not to
- forward its credentials. As previously stated, the client should
- incorporate information from the KDC, in particular the ok-as-
- delegate ticket flag, in making such a policy decision.
-
- A forwarded TGT presents more vulnerabilities in the event of a rogue
- server or the compromise of the session key. An attacker would be
- able to impersonate the client to obtain new service tickets. Such
- an attack may be mitigated by the use of restrictions, such as those
- described in [Neuman].
-
-
-7. Acknowledgements
-
- We would like to thank the following people for their input for this
- document:
- Clifford Neuman from ISI
- John Brezak and David Mowers from Microsoft
-
-
-8. References
-
- [KERBTLS] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher
- Suites to Transport Layer Security (TLS)", RFC 2712,
- October 1999.
-
- [KERB] J. Kohl and C. Neuman, "The Kerberos Network
- Authentication Service (V5)", RFC 1510, September 1993.
-
- [TLS] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0",
- RFC 2246, January 1999.
-
- [PKINIT] B. Tung, C. Neuman, M. Hur, A. Medvinsky, S. Medvinsky,
- J. Wray, J. Trostle. Public Key Cryptography for Initial
- Authentication in Kerberos.
- draft-ietf-cat-kerberos-pk-init-12.txt
-
- [PKTAPP] A. Medvinsky, M. Hur, S. Medvinsky, C. Neuman.
- Public Key Utilizing Tickets for Application
- Servers (PKTAPP). draft-ietf-cat-kerberos-pk-tapp-03.txt
-
- [PKCROSS] M. Hur, B. Tung, T. Ryutov, C. Neuman, G. Tsudik,
- A. Medvinsky, B. Sommerfeld. Public Key Cryptography for
- Cross-Realm Authentication in Kerberos.
- draft-ietf-cat-kerberos-pk-cross-06.txt
-
- [X509] ITU-T (formerly CCITT) Information technology - Open
- Systems Interconnection - The Directory: Authentication
- Framework Recommendation X.509 ISO/IEC 9594-8
-
- [NEUMAN] B.C. Neuman, "Proxy-Based Authorization and Accounting for
- Distributed Systems". Proceedings of the 13th
- International Conference on Distributed Computing Systems,
- May 1993
-
-
-9. Authors' Addresses
-
- Matthew Hur
- Cisco Systems
- 500 108th Ave. NE, Suite 500
- Bellevue, WA 98004
- Phone:
- EMail: mhur@cisco.com
- http://www.cisco.com
-
- Ari Medvinsky
- Keen.com
- 2480 Sand Hill Road, Suite 200
- Menlo Park, CA 94025
- Phone: +1 415 284 4085
- EMail: ari@keen.com
- http://www.keen.com
-
-
-10. Full Copyright Statement
-
- Copyright (C) The Internet Society (1999). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-Appendices
-
-A. Changes from RFC 2712
-
- Added new cipher suites with NULL confidentiality:
- TLS_KRB5_WITH_NULL_SHA
- TLS_KRB5_WITH_NULL_MD5
- TLS_KRB5_WITH_NULL_NULL
-
- RFC 2712 utilized only the ClientKeyExchange message for conveying
- the Kerberos credentials and encrypted premaster-secret. This
- specification moves the Kerberos credentials to the client
- certificate message, and it allows the client to pass delegated
- credentials as well. Additionally, this specification allows the
- server to specify Kerberos-specific information (realm, delegation
- 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.
diff --git a/doc/protocol/rfc2712.txt b/doc/protocol/rfc2712.txt
new file mode 100644
index 0000000000..4888e2e2d7
--- /dev/null
+++ b/doc/protocol/rfc2712.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group A. Medvinsky
+Request for Comments: 2712 Excite
+Category: Standards Track M. Hur
+ CyberSafe Corporation
+ October 1999
+
+
+ Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+IESG Note:
+
+ 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.
+
+1. Abstract
+
+ This document proposes the addition of new cipher suites to the TLS
+ protocol [1] to support Kerberos-based authentication. Kerberos
+ credentials are used to achieve mutual authentication and to
+ establish a master secret which is subsequently used to secure
+ client-server communication.
+
+2. Introduction
+
+ Flexibility is one of the main strengths of the TLS protocol.
+ Clients and servers can negotiate cipher suites to meet specific
+ security and administrative policies. However, to date,
+ authentication in TLS is limited only to public key solutions. As a
+ result, TLS does not fully support organizations with heterogeneous
+ security deployments that include authentication systems based on
+ symmetric cryptography. Kerberos, originally developed at MIT, is
+
+
+
+Medvinsky & Hur Standards Track [Page 1]
+
+RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
+
+
+ based on an open standard [2] and is the most widely deployed
+ symmetric key authentication system. This document proposes a new
+ option for negotiating Kerberos authentication within the TLS
+ framework. This achieves mutual authentication and the establishment
+ of a master secret using Kerberos credentials. The proposed changes
+ are minimal and, in fact, no different from adding a new public key
+ algorithm to the TLS framework.
+
+3. Kerberos Authentication Option In TLS
+
+ This section describes the addition of the Kerberos authentication
+ option to the TLS protocol. Throughout this document, we refer to
+ the basic SSL handshake shown in Figure 1. For a review of the TLS
+ handshake see [1].
+
+ CLIENT SERVER
+ ------ ------
+ ClientHello
+ -------------------------------->
+ ServerHello
+ Certificate *
+ ServerKeyExchange*
+ CertificateRequest*
+ ServerHelloDone
+ <-------------------------------
+ Certificate*
+ ClientKeyExchange
+ CertificateVerify*
+ change cipher spec
+ Finished
+ | -------------------------------->
+ | change cipher spec
+ | Finished
+ | |
+ | |
+ Application Data <------------------------------->Application Data
+
+ FIGURE 1: The TLS protocol. All messages followed by a star are
+ optional. Note: This figure was taken from an IETF document
+ [1].
+
+ The TLS security context is negotiated in the client and server hello
+ messages. For example: TLS_RSA_WITH_RC4_MD5 means the initial
+ 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
+ algorithm. Thus, to facilitate the Kerberos authentication option,
+ we must start by defining new cipher suites including (but not
+ limited to):
+
+
+
+Medvinsky & Hur Standards Track [Page 2]
+
+RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
+
+
+ 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 };
+
+ To establish a Kerberos-based security context, one or more of the
+ above cipher suites must be specified in the client hello message.
+ If the TLS server supports the Kerberos authentication option, the
+ server hello message, sent to the client, will confirm the Kerberos
+ cipher suite selected by the server. The server's certificate, the
+ client
+
+ CertificateRequest, and the ServerKeyExchange shown in Figure 1 will
+ be omitted since authentication and the establishment of a master
+ secret will be done using the client's Kerberos credentials for the
+ TLS server. The client's certificate will be omitted for the same
+ reason. Note that these messages are specified as optional in the
+ TLS protocol; therefore, omitting them is permissible.
+
+ The Kerberos option must be added to the ClientKeyExchange message as
+ shown in Figure 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Medvinsky & Hur Standards Track [Page 3]
+
+RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
+
+
+ struct
+ {
+ select (KeyExchangeAlgorithm)
+ {
+ case krb5: KerberosWrapper; /* new addition */
+ case rsa: EncryptedPreMasterSecret;
+ case diffie_hellman: ClientDiffieHellmanPublic;
+ } Exchange_keys;
+
+ } ClientKeyExchange;
+
+ struct
+ {
+ opaque Ticket;
+ opaque authenticator; /* optional */
+ opaque EncryptedPreMasterSecret; /* encrypted with the session key
+ which is sealed in the ticket */
+ } KerberosWrapper; /* new addition */
+
+ FIGURE 2: The Kerberos option in the ClientKeyExchange.
+
+ To use the Kerberos authentication option, the TLS client must obtain
+ a service ticket for the TLS server. In TLS, the ClientKeyExchange
+ message is used to pass a random 48-byte pre-master secret to the
+ server.
+
+ The client and server then use the pre-master secret to independently
+ derive the master secret, which in turn is used for generating
+ session keys and for MAC computations. Thus, if the Kerberos option
+ is selected, the pre-master secret structure is the same as that used
+ in the RSA case; it is encrypted under the Kerberos session key and
+ sent to the TLS server along with the Kerberos credentials (see
+ Figure 2). The ticket and authenticator are encoded per RFC 1510
+ (ASN.1 encoding). Once the ClientKeyExchange message is received,
+ the server's secret key is used to unwrap the credentials and extract
+ the pre-master secret.
+
+ Note that a Kerberos authenticator is not required, since the master
+ secret derived by the client and server is seeded with a random value
+ passed in the server hello message, thus foiling replay attacks.
+ However, the authenticator may still prove useful for passing
+ authorization information and is thus allotted an optional field (see
+ Figure 2).
+
+ Lastly, the client and server exchange the finished messages to
+ complete the handshake. At this point we have achieved the
+ following:
+
+
+
+
+Medvinsky & Hur Standards Track [Page 4]
+
+RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
+
+
+ 1) A master secret, used to protect all subsequent communication, is
+ securely established.
+
+ 2) Mutual client-server authentication is achieved, since the TLS
+ server proves knowledge of the master secret in the finished
+ message.
+
+ Note that the Kerberos option fits in seamlessly, without adding any
+ new messages.
+
+4. Naming Conventions:
+
+ To obtain an appropriate service ticket, the TLS client must
+ determine the principal name of the TLS server. The Kerberos service
+ naming convention is used for this purpose, as follows:
+
+ host/MachineName@Realm
+ where:
+ - The literal, "host", follows the Kerberos convention when not
+ concerned about the protection domain on a particular machine.
+ - "MachineName" is the particular instance of the service.
+ - The Kerberos "Realm" is the domain name of the machine.
+
+5. Summary
+
+ The proposed Kerberos authentication option is added in exactly the
+ same manner as a new public key algorithm would be added to TLS.
+ Furthermore, it establishes the master secret in exactly the same
+ manner.
+
+6. Security Considerations
+
+ Kerberos ciphersuites are subject to the same security considerations
+ as the TLS protocol. In addition, just as a public key
+ implementation must take care to protect the private key (for example
+ the PIN for a smartcard), a Kerberos implementation must take care to
+ protect the long lived secret that is shared between the principal
+ and the KDC. In particular, a weak password may be subject to a
+ dictionary attack. In order to strengthen the initial authentication
+ to a KDC, an implementor may choose to utilize secondary
+ authentication via a token card, or one may utilize initial
+ authentication to the KDC based on public key cryptography (commonly
+ known as PKINIT - a product of the Common Authentication Technology
+ working group of the IETF).
+
+
+
+
+
+
+
+Medvinsky & Hur Standards Track [Page 5]
+
+RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
+
+
+7. Acknowledgements
+
+ We would like to thank Clifford Neuman for his invaluable comments on
+ earlier versions of this document.
+
+8. References
+
+ [1] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC
+ 2246, January 1999.
+
+ [2] Kohl J. and C. Neuman, "The Kerberos Network Authentication
+ Service (V5)", RFC 1510, September 1993.
+
+9. Authors' Addresses
+
+ Ari Medvinsky
+ Excite
+ 555 Broadway
+ Redwood City, CA 94063
+
+ Phone: +1 650 569 2119
+ EMail: amedvins@excitecorp.com
+ http://www.excite.com
+
+
+ Matthew Hur
+ CyberSafe Corporation
+ 1605 NW Sammamish Road
+ Issaquah WA 98027-5378
+
+ Phone: +1 425 391 6000
+ EMail: matt.hur@cybersafe.com
+ http://www.cybersafe.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Medvinsky & Hur Standards Track [Page 6]
+
+RFC 2712 Addition of Kerberos Cipher Suites to TLS October 1999
+
+
+10. Full Copyright Statement
+
+ Copyright (C) The Internet Society (1999). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Medvinsky & Hur Standards Track [Page 7]
+
View Lorry Controller Status