diff options
Diffstat (limited to 'doc/protocol/draft-santesson-tls-gssapi-02.txt')
| -rw-r--r-- | doc/protocol/draft-santesson-tls-gssapi-02.txt | 504 |
1 files changed, 0 insertions, 504 deletions
diff --git a/doc/protocol/draft-santesson-tls-gssapi-02.txt b/doc/protocol/draft-santesson-tls-gssapi-02.txt deleted file mode 100644 index ddf76b67c1..0000000000 --- a/doc/protocol/draft-santesson-tls-gssapi-02.txt +++ /dev/null @@ -1,504 +0,0 @@ - - -NETWORK WORKING GROUP L. Zhu -Internet-Draft Microsoft Corporation -Updates: 4279 (if approved) July 9, 2007 -Intended status: Standards Track -Expires: January 10, 2008 - - - Flexible Key Agreement for Transport Layer Security (FKA-TLS) - draft-santesson-tls-gssapi-02 - -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/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on January 10, 2008. - -Copyright Notice - - Copyright (C) The IETF Trust (2007). - -Abstract - - This document defines extensions to RFC 4279 to enable dynamic key - sharing in distributed environments. By using these extensions, the - client and the server can use off-shelf libraries to exchange tokens - and establish a shared secret, based on a Generic Security Service - Application Program Interface (GSS-API) mechanism such as Kerberos as - defined in RFC 4121, and then proceed according to RFC 4279 to - complete the authentication and provide data protection. - - - -Zhu Expires January 10, 2008 [Page 1] - -Internet-Draft FKA-TLS July 2007 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 - 3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . . 3 - 4. Choosing GSS-API Mechanisms . . . . . . . . . . . . . . . . . . 6 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 - 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 - Intellectual Property and Copyright Statements . . . . . . . . . . 9 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Zhu Expires January 10, 2008 [Page 2] - -Internet-Draft FKA-TLS July 2007 - - -1. Introduction - - [RFC4279] defines Transport Layer Security (TLS) based on pre-shared - keys (PSK). This assumes a pair-wise key sharing scheme that is less - scalable and more costly to manage in comparison with a trusted third - party scheme such as Kerberos [RFC4120]. In addition, off-shelf GSS- - API libraries that allow dynamic key sharing are not currently - accessible to TLS applications. For example, Kerberos [RFC4121] is a - GSS-API mechanism that can establish a shared key between a client - and a server based on either asymmetric keys [RFC4556] or symmetric - keys [RFC4120]. - - This document extends [RFC4279] to allow the client and the server - establish a shared key on demand by using off-shelf GSS-API - libraries, and then proceed according to RFC 4279. This is a modular - approach to leverage Kerberos alike trust infrastructures in securing - TLS connections. - - -2. Conventions Used in This Document - - 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 [RFC2119]. - - -3. Protocol Definition - - The GSS-API TLS extension is defined according to [RFC3546]. The - extension data carries GSS-API token within the TLS hello messages. - - enum { - GSS-API(TBD), (65535) - } ExtensionType; - - Initially the client calls GSS_Init_sec_context() [RFC2743] to - establish a security context, it MUST set the mutual_req_flag and - identify the server by targ_name so that mutual authentication is - performed in the course of context establishment. If the mutual - authentication is not available when the context is established - successfully, the GSS-API security context MUST be discarded. The - extension_data from the client contains the output token of - GSS_Init_sec_context(). If a GSS-API context cannot be established, - the GSS-API TLS extension MUST NOT be included in the client hello - message and it is a matter of local policy on the client whether to - continue or reject the TLS authentication as if the GSS-API TLS - extension is not supported. - - - - -Zhu Expires January 10, 2008 [Page 3] - -Internet-Draft FKA-TLS July 2007 - - - Upon receipt of the GSS-API TLS extension from the client, and if the - server supports the GSS-API TLS extension, the server calls - GSS_Accept_sec_context() with the client GSS-API output token in the - client's extension data as the input token. If - GSS_Accept_sec_context() returns a token successfully, the server - responds with a GSS-API TLS extension and places the output token in - the extension_data. If GSS_Accept_sec_context() fails, it is a - matter of local policy on the server whether to continue or reject - the TLS authentication as if the GSS-API TLS extension is not - supported. - - The server MUST NOT include a GSS-API TLS extension in the hello - message if the cipher_suite in the ServerHello message is not a PSK - ciphersuite [RFC4279]. - - If the server expects at least one more token to be accepted from the - client in order to establish the security context, the additional - GSS-API tokens are carried in a new handshake message called the - token-transfer message. - - enum { - token_transfer(TBD), (255) - } HandshakeType; - - struct { - HandshakeType msg_type; /* handshake type */ - uint24 length; /* bytes in message */ - select (HandshakeType) { - case token_transfer: /* NEW */ - TokenTranfer; - } body; - } Handshake; - - enum { - gss-api-token(1), (255) - } TokenTransferType; - - struct { - TokenTransferType token_type; /* token type */ - opaque token<0..2^16-1>; - } TokenTranfer; - - The TokenTranfer structure is filled out as follows: - - o The token_type is gss-api-token. - - - - - - -Zhu Expires January 10, 2008 [Page 4] - -Internet-Draft FKA-TLS July 2007 - - - o The token field contains the GSS-API context establishment tokens - from the client and the server. - - The client calls GSS_Init_sec_context() with the token in the - TokenTranfer stucture from the server as the input token, and then - places the output token, if any, into the TokenTranfer message and - sends the handshake message to the server. The server calls - GSS_Accept_sec_context() with the token in the TokenTranfer structure - from the client as the input token, and then places the output token, - if any, into the TokenTranfer message and sends the handshake message - to the client. This loop repeats until either the context fails to - establish or the context is established successfully. To prevent an - infinite loop, both the client and the server MUST have a policy to - limit the maximum number of GSS-API context establishment calls for a - given session. The recommended value is 5. If the GSS-API context - fails to establish, it is a matter of local policy whether to - continue or reject the TLS authentication as if the GSS-API TLS - extension is not supported. - - When the last GSS-API context establishment token is sent by the - client or when the GSS-API context fails to establish on the client - side and the local policy allows the TLS authentication to proceed as - if the TLS GSS-API extension is not supported, the client sends an - empty TokenTransfer handshake message. - - If the GSS-API context fails to establish and local policy allows the - TLS authentication continue as if the GSS-API TLS extension is not - supported, the server MAY send another ServerHello message in order - to choose a different cipher suite. The client then MUST expect the - second ServerHello message from the server before the session is - established. The second ServerHello message MUST differ from the - first ServerHello message in the cipher_suite field and only in that - field. - - If the client and the server establish a security context - successfully, both the client and the server call GSS_Pseudo_random() - [RFC4401] to compute a sufficiently long shared secret with the same - value based on the negotiated ciphersuite, and then proceed according - to [RFC4279] using this shared secret value as the "PSK". Both - psk_identity and psk_identity_hint are empty in the handshake - messages when the shared key is established using a GSS-API mechanism - as described in this document. - - The following text art summaries the protocol message flow. - - - - - - - -Zhu Expires January 10, 2008 [Page 5] - -Internet-Draft FKA-TLS July 2007 - - - Client Server - - ClientHello --------> - ServerHello - <-------- TokenTransfer* - . - . - . - TokenTransfer* --------> - - ServerHello* - Certificate* - ServerKeyExchange* - CertificateRequest* - <-------- ServerHelloDone - Certificate* - ClientKeyExchange - CertificateVerify* - [ChangeCipherSpec] - Finished --------> - [ChangeCipherSpec] - <-------- Finished - Application Data <--------> Application Data - - Fig. 1. Message flow for a full handshake - - * Indicates optional or situation-dependent messages that are - not always sent. - - There could be multiple TokenTransfer handshake messages, and the - last TokenTranster message, if present, is always sent from the - client to the server and it can carry an empty token. - - -4. Choosing GSS-API Mechanisms - - If more than one GSS-API mechanism is shared between the client and - the server, it is RECOMMENDED to deploy a pseudo GSS-API mechanism - such as [RFC4178] to choose a mutually preferred GSS-API mechanism. - - If the Kerberos client does not have access to the KDC but the server - does, [IAKERB] can be chosen to tunnel the Kerberos authentication - exchange within the TLS handshake messages. - - -5. Security Considerations - - When Kerberos as defined in [RFC4120] is used to establish the share - - - -Zhu Expires January 10, 2008 [Page 6] - -Internet-Draft FKA-TLS July 2007 - - - key, it is vulnerable to offline dictionary attacks. The threat is - mitigated by deploying kerberos FAST [KRB-FAST]. - - -6. Acknowledgements - - Stefan Santesson, Ari Medvinsky and Jeffery Altman helped editing the - earlier revisions of this document. - - -7. IANA Considerations - - A new handshake message token_transfer is defined according to - [RFC4346] and a new TLS extension called the GSS-API extension is - defined according to [RFC3546]. The registry need to be updated to - include these new types. - - This document defines the type of the transfer tokens in Section 3, a - registry need to be setup and the allocation policy is "Specification - Required". - - -8. References - -8.1. Normative References - - [IAKERB] Zhu, L., "Initial and Pass Through Authentication Using - Kerberos V5 and the GSS-API", draft-zhu-ws-kerb-03.txt - (work in progress), 2007. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - - [RFC2743] Linn, J., "Generic Security Service Application Program - Interface Version 2, Update 1", RFC 2743, January 2000. - - [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., - and T. Wright, "Transport Layer Security (TLS) - Extensions", RFC 3546, June 2003. - - [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The - Simple and Protected Generic Security Service Application - Program Interface (GSS-API) Negotiation Mechanism", - RFC 4178, October 2005. - - [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites - for Transport Layer Security (TLS)", RFC 4279, - December 2005. - - - -Zhu Expires January 10, 2008 [Page 7] - -Internet-Draft FKA-TLS July 2007 - - - [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.1", RFC 4346, April 2006. - - [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API - Extension for the Generic Security Service Application - Program Interface (GSS-API)", RFC 4401, February 2006. - -8.2. Informative References - - [KRB-FAST] - Zhu, L. and S. Hartman, "A Generalized Framework for - Kerberos Pre-Authentication", - draft-ietf-krb-wg-preauth-framework-06.txt (work in - progress), 2007. - - [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The - Kerberos Network Authentication Service (V5)", RFC 4120, - July 2005. - - [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos - Version 5 Generic Security Service Application Program - Interface (GSS-API) Mechanism: Version 2", RFC 4121, - July 2005. - - [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial - Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. - - -Author's Address - - Larry Zhu - Microsoft Corporation - One Microsoft Way - Redmond, WA 98052 - US - - Email: lzhu@microsoft.com - - - - - - - - - - - - - - -Zhu Expires January 10, 2008 [Page 8] - -Internet-Draft FKA-TLS July 2007 - - -Full Copyright Statement - - Copyright (C) The IETF Trust (2007). - - 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, THE IETF TRUST 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. - - -Acknowledgment - - Funding for the RFC Editor function is provided by the IETF - Administrative Support Activity (IASA). - - - - - -Zhu Expires January 10, 2008 [Page 9] - - |