diff options
Diffstat (limited to 'doc/protocol/draft-santesson-tls-gssapi-01.txt')
| -rw-r--r-- | doc/protocol/draft-santesson-tls-gssapi-01.txt | 504 |
1 files changed, 0 insertions, 504 deletions
diff --git a/doc/protocol/draft-santesson-tls-gssapi-01.txt b/doc/protocol/draft-santesson-tls-gssapi-01.txt deleted file mode 100644 index 9f38e49ea1..0000000000 --- a/doc/protocol/draft-santesson-tls-gssapi-01.txt +++ /dev/null @@ -1,504 +0,0 @@ - - - - -INTERNET-DRAFT S. Santesson (Microsoft) -Intended Category: Standards Track A. Medvinsky (Microsoft) -Expires June 2007 J. Altman (Secure Endpoints) - December 2006 - - Generic Security Service Application Program Interface (GSS-API) - Extension for Transport Layer Security (TLS) - <draft-santesson-tls-gssapi-01.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 as "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 document defines protocol extensions to the Transport Layer - Security (TLS) protocol for user authentication and key negotiation - based on the Generic Security Service Application Program Interface - (GSS-API). - - Full flexibility for negotiation of GSS-API mechanisms is provided, - allowing use of arbitrary GSS-API mechanisms provided that they - support the GSS-API PRF. - - This document supersedes RFC 2712 [ref] as the mechanism to support - Kerberos based authentication and key establishment for a TLS - session. - - - - -Santesson, et. all [Page 1] - -INTERNET DRAFT DNS SRV RR otherName November 2006 - - -Table of Contents - - 1 Introduction ................................................ n - 2 GSS-API TLS extension ....................................... n - 3 GSS-API Handshake message ................................... n - 4 Cipher Suites ............................................... n - 4 Message Flow ............................................... n - 5 Key Derivation .............................................. n - 6 Security Considerations ..................................... n - 7 IANA Considerations ......................................... n - 8 References .................................................. n - Appendix A (if needed) ........................................ n - Authors' Addresses ............................................. n - Full Copyright Statement ....................................... n - Intellectual Property .......................................... n - -1. Introduction - - This document defines protocol extensions to the Transport Layer - Security (TLS) [N5] protocol for user authentication and key - negotiation based on the Generic Security Service Application Program - Interface (GSS-API). The extensions to TLS include a new - ExtensionType "gss_api" (section 2), a new HandshakeType "gss_token" - (section 3), a new KeyExchangeAlgorithm "gss_prf" (section 5), and - new "TLS_GSS" cipher suites (section 4). - - Full flexibility for negotiation of GSS-API mechanisms is provided, - allowing use of arbitrary GSS-API mechanisms provided that they - support the GSS-API PRF. - - This document supersedes RFC 2712 [ref] as the mechanism to support - Kerberos based authentication and key establishment for a TLS - session. - -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 [N1]. - - The syntax for the supplemental_data handshake message is defined - using the TLS Presentation Language, which is specified in Section 4 - of [N4]. - - - - - - - - -Santesson, et. all [Page 2] - -INTERNET DRAFT DNS SRV RR otherName November 2006 - - -2. GSS-API TLS extension - - This section defines a new TLS extension that conveys a list of GSS - mechanism OIDS in ClientHello and ServerHello messages. The client - uses this extension to transmit a list of supported GSS mechanisms to - the server. If the server chooses one of the GSS mechanisms, it - returns the selected OID to the client. The client includes this - extension in the ClientHello only if one or more GSS based - ciphersuites (defined in section X) are included in the list of - supported cipher suites. Similarly, the server includes this - extension in the ServerHello message only if it selected one of the - GSS cipher suites. - - - enum { - gss_api(n), (65535) - } ExtensionType; - - The "extension_data" field of this extension SHALL contain - "GssOIDList" where: - - struct{ - GssOID gss_oid_list<0..2^24-1> // list of supported OIDs - }GssOIDList; - - unit16 GssOID<2..254>; - - GssOID contains a sequence of integers of an OBJECT IDENTIFIER (OID) - [ref] where the first integer in the sequence specifies the top node - of the OID. - - Each OID specifies a specific GSS token exchange scheme. - - -3. GSS-API Handshake Message - - This section defines a new handshake message to carry GSS tokens. - The message is used to send GSS tokens from TLS client to TLS server - and vice versa. - - enum { - gss_token (nn), (255) - } HandshakeType; - - struct { - HandshakeType msg_type; /* handshake type */ - uint24 length; /* octets in message */ - select (HandshakeType) { - - - -Santesson, et. all [Page 3] - -INTERNET DRAFT DNS SRV RR otherName November 2006 - - - case gss_token: GssToken; - } body; - } Handshake; - - Struct { - opaque GssPayload<1..2^16-1>; - opaque GssStatus[1] - } GssToken; - - - The GssStatus contains a status byte for the GssPayload: - - GssStatus GSS_NORMAL = { 0x00 }; - GssStatus GSS_LAST_PAYLOAD = { 0x01 }; - GssStatus GSS_ERROR = { 0x02 }; - - - GSS_NORMAL is set for all GssPayload that does not match the - conditions for any other status bytes. - - GSS_LAST_PAYLOAD is set for the last GssPayload in the exchange of - GSS-API payloads and signals that the exchange was successfully - concluded. - - GSS_ERROR is set if an error state was reached in the exchange of GSS - tokens. Receiving a GssToken with this status set results in a fatal - error, and the receiver MUST close the connection with a - handshake_failure alert. Immediately following the transmission of a - GssToken with this status set, the sender MUST close the connection - with a handshake_failure alert. - - -4. Cipher suites - - This document defines the following new cipher suites - - CipherSuite TLS_GSS_API_WITH_RC4_128_SHA = { 0xnn,0x00 }; - CipherSuite TLS_GSS_API_WITH_AES_128_CBC_SHA = { 0xnn,0x01 }; - CipherSuite TLS_GSS_API_WITH_AES_256_CBC_SHA = { 0xnn,0x02 }; - - - -5. Key Derivation - - After successful completion of the gss_token messages, the client and - server each obtain 46 bytes of key random data using the GSS-API PRF. - This data is the TLS pre-master secret. - - - - -Santesson, et. all [Page 4] - -INTERNET DRAFT DNS SRV RR otherName November 2006 - - - If the GSS-API PRF fails, the connection MUST be closed with a - handshake_failure alert. - - -6. Message flow - - Client Server - - ClientHello - /* with GSS-API extension */ -----> - - ServerHello - /* with GSS-API extension */ - <-------- ServerHelloDone - - <----- gss_token Handskake messages -----> - /* multiple iterations with GssPayload */ - - ClientKeyExchange [ChangeCipherSpec] Finished - --------> - [ChangeCipherSpec] - <-------- Finished - Application Data <-------> Application Data - - - If the client is sending the GSSToken message with the - GSS_LAST_PAYLOAD flag set then the third leg of the protocol would - look like this: - - GSSToken ClientKeyExchange [ChangeCipherSpec] Finished - - However, for a GSS scheme where the server is sending the last GSS - token to the client (and the client has no more GSS tokens to send - then the third leg of the protocol will be just: - - ClientKeyExchange [ChangeCipherSpec] Finished - - -7 IANA Considerations - - IANA needs to take the following actions: - - 1) Create an entry, gss_api (TBD), in the existing registry for - ExtensionType (defined in RFC 4366 [N7]). - - 2) Create an entry, gss_token (TBD), in the existing registry for - HandshakeType (defined in RFC 2246 [N7]). - - - - -Santesson, et. all [Page 5] - -INTERNET DRAFT DNS SRV RR otherName November 2006 - - - Cipher suite IANA actions TBD - -8 References - - Normative references: - - [N1] S. Bradner, "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [N2] Linn, J., "Generic Security Service Application Program - Interface Version 2, Update 1", RFC 2743, January 2000. - - [N3] N. Williams, "A Pseudo-Random Function (PRF) API Extension - for theGeneric Security Service Application Program - Interface (GSS-API)",RFC 4401, February 2006. - - [N4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC - 2246, January 1999. - - [N5] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.1", RFC 4346, April 2006. - - [N6] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., - and T. Wright, "Transport Layer Security (TLS) Extensions", - RFC 4366, April 2006. - - [N7] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - - - - - - - - - - - - - - - - - - - - - - -Santesson, et. all [Page 6] - -INTERNET DRAFT DNS SRV RR otherName November 2006 - - -Appendix A. - - Appednix text - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Santesson, et. all [Page 7] - -INTERNET DRAFT DNS SRV RR otherName November 2006 - - -Authors' Addresses - - - Stefan Santesson - - Microsoft - Tuborg Boulevard 12 - 2900 Hellerup - Denmark - - EMail: stefans@microsoft.com - - - Ari Medvinsky - - Microsoft - One Microsoft Way - Redmond, WA 98052-6399 - USA - - Email: arimed(at)microsoft.com - - - Jeffrey E. Altman - - Secure Endpoints Inc. - 255 West 94th Street - New York NY 10025 - USA - - EMail:jaltman@columbia.edu - - - - - - - - - - - - - - - - - - - - -Santesson, et. all [Page 8] - -INTERNET DRAFT DNS SRV RR otherName November 2006 - - -Full 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. - - 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. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat 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 proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at ietf- - ipr@ietf.org." - - -Expires June 2007 - - - - - - - - - -Santesson, et. all [Page 9] |