diff options
Diffstat (limited to 'doc/protocol/draft-santesson-tls-supp-00.txt')
| -rw-r--r-- | doc/protocol/draft-santesson-tls-supp-00.txt | 448 |
1 files changed, 0 insertions, 448 deletions
diff --git a/doc/protocol/draft-santesson-tls-supp-00.txt b/doc/protocol/draft-santesson-tls-supp-00.txt deleted file mode 100644 index 7c72a91a0e..0000000000 --- a/doc/protocol/draft-santesson-tls-supp-00.txt +++ /dev/null @@ -1,448 +0,0 @@ - - - - -INTERNET-DRAFT S. Santesson (Microsoft) -Updates: 2246, 4346 -Intended Category: Standards track -Expires September 2006 March 2006 - - - TLS Handshake Message for Supplemental Data - <draft-santesson-tls-supp-00.txt> - - -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 March 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 March 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 associated data MUST be concluded - between client and server for each SupplementalDataType. This - agreement MUST be concluded through the use of 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 March 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 March 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 March 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. - - -7 IANA Considerations - - IANA needs to establish a registry for TLS Supplemental Data Formats. - TLS Authorization Data Format identifiers with values in the - inclusive range 0-16385 (decimal) are assigned via RFC 2434 [IANA] - Standards Action. Values from the inclusive range 16385-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 March 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 March 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 September 2006 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Santesson [Page 8] |