From: Simon Josefsson Date: Wed, 19 Apr 2006 17:36:01 +0000 (+0000) Subject: Add. X-Git-Tag: gnutls_1_2_11~19 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=20d9fc12d00a72e4c9cc07bf37cdd317080034b4;p=thirdparty%2Fgnutls.git Add. --- diff --git a/doc/protocol/draft-santesson-tls-supp-01.txt b/doc/protocol/draft-santesson-tls-supp-01.txt new file mode 100644 index 0000000000..f0528f7b70 --- /dev/null +++ b/doc/protocol/draft-santesson-tls-supp-01.txt @@ -0,0 +1,448 @@ + + + + +INTERNET-DRAFT S. Santesson (Microsoft) +Updates: 2246, 4346 +Intended Category: Standards track +Expires October 2006 April 2006 + + + TLS Handshake Message for Supplemental Data + + + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + 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 a "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + +Abstract + + This specification specifies a TLS handshake message for exchange of + supplemental application data. TLS hello message extensions are used + to determine which supplemental data types are supported by both the + TLS client and the TLS server. Then, the supplemental data handshake + message is used to exchange the data. Other documents will define + the syntax of these extensions and the syntax of the associated + supplemental data types. + + + + + + + + +Santesson [Page 1] + +INTERNET DRAFT TLS Handshake Message for Supplemental Data April 2006 + + +1. Introduction + + Recent standards activities have proposed different mechanisms for + transmitting supplemental application data in the TLS handshake + message. For example, recent proposals transfer data that is not + processed by the TLS protocol itself, but assist the TLS-protected + application in the authentication and authorization decisions. One + proposal transfers user name hints for locating credentials, and + another proposal transfers attribute certificates and SAML assertions + for authorization checks. + + In order to avoid definition of multiple handshake messages, one for + each new type of application specific supplemental data, this + specification defines a new handshake message type that bundles all + such data objects together and sends them in a single handshake + message. + +1.1 Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [STDWORDS]. + + The syntax for the supplemental_data handshake message is defined + using the TLS Presentation Language, which is specified in Section 4 + of [N2]. + +2 Supplemental Data Handshake Message + + The new supplemental_data handshake message type is defined to + accommodate communication of supplemental data objects as agreed + during the exchange of extensions in the client and server hello + messages. See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3] + for other handshake message types. + + + enum { + supplemental_data(TBD), (255) + } HandshakeType; + + struct { + HandshakeType msg_type; /* handshake type */ + uint24 length; /* octets in message */ + select (HandshakeType) { + case supplemental_data: SupplementalData; + } body; + } Handshake; + + + + +Santesson [Page 2] + +INTERNET DRAFT TLS Handshake Message for Supplemental Data April 2006 + + + struct { + SupplementalDataEntry supp_data<1..2^24-1>; + } SupplementalData; + + struct { + SupplementalDataType supp_data_type; + select(SupplementalDataType) { } + } SupplementalDataEntry; + + enum { + (65535) + } SupplementalDataType; + + + If present, the SupplementalData handshake message MUST contain a + non-empty SupplementalDataEntry structure carrying data associated + with at least one defined SupplementalDataType. An explicit + agreement that governs presence of any supplemental data MUST be + concluded between client and server for each SupplementalDataType + using the TLS extensions in the client and server hello messages. + + Other documents will specify specific SupplementalDataType and their + associated data syntax and processing. These same specifications + must also specify the client and server hello message extensions that + are used to negotiate the support for the specified supplemental data + type. This document simply specifies the TLS Handshake Protocol + message that will carry the supplemental data objects. + + Different situations require the transfer of supplemental data from + the client to the server, require the transfer of supplemental data + from server to the client, or require the transfer of supplemental + data from the client to the server as well as the transfer from the + server to the client. All three situations are fully supported. + + + + + + + + + + + + + + + + + + +Santesson [Page 3] + +INTERNET DRAFT TLS Handshake Message for Supplemental Data April 2006 + + +4 Message flow + + The SupplementalData handshake message, if exchanged, MUST be sent as + the first handshake message as illustrated in Figure 1 below. + + Client Server + + ClientHello (with extensions) --------> + + ServerHello(with extensions) + SupplementalData* + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + + SupplementalData* + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + Application Data <-------> Application Data + + * Indicates optional or situation-dependent messages. + + Figure 1. Message flow with SupplementalData + + + + + + + + + + + + + + + + + + + + + + +Santesson [Page 4] + +INTERNET DRAFT TLS Handshake Message for Supplemental Data April 2006 + + +5 Security Considerations + + Each SupplementalDataType included in the handshake message defined + in this specification introduces its own unique set of security + properties and related considerations. Security considerations must + therefore be defined in each document that defines a supplemetal data + type. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Santesson [Page 5] + +INTERNET DRAFT TLS Handshake Message for Supplemental Data April 2006 + + +6 Normative References + + [N1] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [N2] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [N3] T. Dierks, E. Rescorla, "The TLS Protocol Version 1.1", + RFC 4346, January 2006. + + [N4] S. Blake-Wilson, M. Nystrom, D. Hopwood, J. Mikkelsen, + T. Wright, "Transport Layer Security (TLS) Extensions", + RFC 4366, February 2006. + + [N5] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", RFC 2434, October 1998 + + +7 IANA Considerations + + IANA needs to take the following actions: + + 1) Create an entry, supplemental_data(TBD), in the existing registry + for HandshakeType (defined in RFC 2246 [N2]). + + 2) Establish a registry for TLS Supplemental Data Formats + (SupplementalDataType). Values in the inclusive range 0-16385 + (decimal) are assigned via RFC 2434 [N5] Standards Action. Values + from the inclusive range 16386-65279 (decimal) are assigned via RFC + 2434 Specification Required. Values from the inclusive range + 65280-65535 (decimal) are reserved for RFC 2434 Private Use. + + + + + + + + + + + + + + + + + + + +Santesson [Page 6] + +INTERNET DRAFT TLS Handshake Message for Supplemental Data April 2006 + + +Author's Address + + Stefan Santesson + Microsoft + Finlandsgatan 30 + 164 93 KISTA + Sweden + + EMail: stefans(at)microsoft.com + + +Acknowledgements + + The fundamental architectural idea for the supplemental data + handshake message was provided by Russ Housley and Eric Rescorla. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Santesson [Page 7] + +INTERNET DRAFT TLS Handshake Message for Supplemental Data April 2006 + + +Disclaimer + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM 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. + + +Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + +Expires October 2006 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Santesson [Page 8]