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]