From: Larry Zhu [mailto:lzhu@windows.microsoft.com] Sent: Friday, July 13, 2007 4:46 PM To: tls@ietf.org Subject: [TLS] GSS based PSK-TLS We would like to request for comments for the GSS based PSK-TLS ID: http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt We have a few comments that came after the draft submission that we felt it is important to bring up some of them to the list here. Jeff Altman will make -03 available before ITTF69 that would merge the changes so far. 1) Why the GSS handshake does not come before the hello message? Having the GSS handshake before the hello is not backward compatible with the TLS protocols. 2) Why the GSS handshake does not come after the key exchange message? We do not want to pay for the cost of the DHE or RSA in this case. The main motivation for us is to enable Kerberos to secure TLS connections. Kerberos is a lot faster, and we intend to keep it that way. 3) why it is not an issue to have arbitrary number of GSS round trips? This has been raised previously. The arguments that EKR made starting on 3/8/2007 on the old thread may not apply given that we are doing the Kerberos AP-REQ and AP-REP in the hello messages using TLS extensions, and the Kerberos shared key is then imported to PSK-TLS. We (Jeff, Stefan and I) would like to have folks to review the new ID and see if your opinions have changed. We believe the revised ID has minimal impact to the TLS state machine By importing the GSS key as PSK. Also the handshake loop could be a stretch for mobile devices that have limited computing capabilities or in situations where the network latency is large such as satellite links. To address that concern, we introduce a policy that limit the # of GSS hand shake messages. In addition, the TLS client does not choose a GSS mechanism that can potentially have a large number of round-trips in the above circumstances. The TLS client chooses which set of cipher suites to support as it does today, and it can choose which GSS mechanism set is supported according to RFC4178. 4) client authentication The client and server authentication as defined in -02 need clarity. The following text describes the mechanism. The client MUST NOT include a gss_api TLS extension if there is no PSK ciphersuite [RFC4279] included in the cipher_suites field of the client hello message. Initially the client computes the gss_api TLS extention data by calling GSS_Init_sec_context() [RFC2743] to establish a security context. The TLS client 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 on the established GSS- API context, the PSK key exchange described in Section 2 of [RFC4279] MUST NOT be selected, and the DHE_PSK or RSA_PSK key exchange MUST be negotiated instead in order to authenticate the server. If the GSS-API mechanism in the gss_api TLS extension provides client authentication [RFC2743], the CertificateRequest, the client Certificate and the CertificateVerify handshake messages MUST NOT be present. This is illustrated in Appendix A. Client Server ClientHello(with AP-REQ) --------> ServerHello(with AP-REP) <-------- ServerHelloDone ClientKeyExchange [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <--------> Application Data Fig. 2. Kerberos FKA-TLS example message flow 5) what are the parameters to GSS PRF? The input parameters to GSS_Pseudo_random() to compute the shared scret value MUST be provided as follows: o The context is the handle to the GSS-API context established in the given session. o The prf_key is GSS_C_PRF_KEY_FULL. o The prf_in contains the UTF8 encoding of the string "GSS-API TLS PSK". o The desired_output_len is 64. In other words, the output keying mastering size is 64 in bytes. 6) how are the GSS mechanisms negotiated? This logic is encapsulated in GSS. SPNEGO as defined in RFC4178 can do it. The concern is that such negotiation can be suboptimal when there are two layers of negotiation, one in the TLS hello message, and the other in the GSS layer. We believe such concern can be addressed by allowing additional input to GSS negotiation to share the negotiation hint. That can be accomplished, for example, by extending RFC4178. As long as the cipher suite decision is made in one round-trip that the fact that the GSS OID options are carried in a GSS token instead of the TLS cipher list does not result in a two-layer negotiation. -- Larry Zhu on behalf of Larry, Jeff and Stefan. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls NETWORK WORKING GROUP L. Zhu Internet-Draft G. Chander Updates: 4279 (if approved) Microsoft Corporation Intended status: Standards Track J. Altman Expires: January 18, 2008 Secure Endpoints Inc. S. Santesson Microsoft Corporation July 17, 2007 Flexible Key Agreement for Transport Layer Security (FKA-TLS) draft-santesson-tls-gssapi-03 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 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines extensions to RFC 4279, "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", to enable dynamic key sharing in distributed environments using a Generic Security Service Application Program Interface (GSS-API) mechanism, and then Zhu, et al. Expires January 18, 2008 [Page 1] Internet-Draft FKA-TLS July 2007 import that shared key as the "Pre-Shared Key" to complete the TLS handshake. This is a modular approach to perform authentication and key exchange based on off-shelf libraries. And it obviates the need of pair-wise key sharing by enabling the use of the widely-deployed Kerberos alike trust infrastructures that are highly scalable and robust. Furthermore, conforming implementations can provide server authentication without the use of certificates. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. Protocol Definition . . . . . . . . . . . . . . . . . . . . . 3 4. Choosing GSS-API Mechanisms . . . . . . . . . . . . . . . . . 8 5. Client Authentication . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 10 Appendix A. An FKA-TLS Example: Kerberos TLS . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Zhu, et al. Expires January 18, 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. Lastly, [RFC4279] does not provide true mutual authentication against the server. This document extends [RFC4279] to establish a shared key, and optionally provide client or server authentication, by using off- shelf GSS-API libraries, and the established shared key is then imported as "PSK" to [RFC4279]. No new key cipher suite is defined in this document. As an example usage scenario, Kerberos [RFC4121] is a GSS-API mechanism that can be selected to establish a shared key between a client and a server based on either asymmetric keys [RFC4556] or symmetric keys [RFC4120]. By using the extensions defined in this document, a TLS connection is secured using the Kerberos version 5 mechanism exposed as a generic security service via GSS-API. With regard to the previous work for the Kerberos support in TLS, [RFC2712] defines "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)" which has not been widely implemented due to violations of Kerberos Version 5 library abstraction layers, incompatible implementations from two major distributions (Sun Java and OpenSSL), and its lack of support for credential delegation. This document defines a generic extensible method that addresses the limitations associated with [RFC2712] and integrates Kerberos and TLS. Relying on [RFC4121] for Kerberos Version 5 support will significantly reduce the challenges associated with implementing this protocol as a replacement for [RFC2712]. 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 In this protocol, the on-demand key exchange is implemented by encapsulating the GSS security context establishment within the TLS handshake messages when PSK cipher suites are requested in the Zhu, et al. Expires January 18, 2008 [Page 3] Internet-Draft FKA-TLS July 2007 extended ClientHello message. 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; The client MUST NOT include a gss_api TLS extension if there is no PSK ciphersuite [RFC4279] included in the cipher_suites field of the client hello message. Initially the client computes the gss_api TLS extension data by calling GSS_Init_sec_context() [RFC2743] to establish a security context. The TLS client 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. 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. If the mutual authentication is not available on the established GSS- API context, the PSK key exchange described in Section 2 of [RFC4279] MUST NOT be selected, and the DHE_PSK or RSA_PSK key exchange MUST be negotiated instead in order to authenticate the server. 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 by including a gss_api TLS extension in the server hello message 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 ignore a TLS gss_api extension in the extended ClientHello if its selected CipherSuite is not a PSK CipherSuite [RFC4279], and the server MUST NOT include a gss_api TLS extension in the server hello message. If after the exchange of extended ClientHello and extended ServerHello with the gss_api extension, at least one more additional Zhu, et al. Expires January 18, 2008 [Page 4] Internet-Draft FKA-TLS July 2007 GSS token is required in order to complete the GSS security context establishment, the additional GSS-API token is encapsulated in a new TLS 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 */ TokenTransfer; } body; } Handshake; enum { gss_api_token(1), (255) } TokenTransferType; struct { TokenTransferType token_type; /* token type */ opaque token<0..216-1>; } TokenTransfer; The TokenTransfer structure is filled out as follows: o The token_type is gss_api_token. 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 TokenTransfer stucture from the server as the input token, and then places the output token, if any, into the TokenTransfer message and sends the handshake message to the server. The server calls GSS_Accept_sec_context() with the token in the TokenTransfer structure from the client as the input token, and then places the output token, if any, into the TokenTransfer 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 a total of five (5) calls including the GSS_Init_sec_context() and GSS_Accept_sec_context() Zhu, et al. Expires January 18, 2008 [Page 5] Internet-Draft FKA-TLS July 2007 from both the client and server. Exceeding the maximum number of calls is to be treated as a GSS security context establishment failure. It is RECOMMENDED that the client and server enforce the same maximum number 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 additional ServerHello message MUST only differ from the first ServerHello message in the choice of CipherSuite and it MUST NOT include a TLS gss_api extension. The second ServerHello MUST NOT be present if there is no TokenTransfer message. 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 cipher suite (see details below), and then proceed according to [RFC4279] using this shared secret value as the "PSK". When the shared key is established using a GSS-API mechanism as described in this document, the identity of the server and the identity of the client MUST be obtained from the GSS security context. In this case, the PSK identity MUST be processed as follows: o The PSK identity as defined in Section 5.1 of [RFC4279] MUST be specified as an empty string. o If the server key exchange message is present, the PSK identity hint as defined in Section 5.2 of [RFC4279] MUST be empty, and it MUST be ignored by the client. The input parameters to GSS_Pseudo_random() to compute the shared secret value MUST be provided as follows: Zhu, et al. Expires January 18, 2008 [Page 6] Internet-Draft FKA-TLS July 2007 o The context is the handle to the GSS-API context established in the given session. o The prf_key is GSS_C_PRF_KEY_FULL. o The prf_in contains the UTF8 encoding of the string "GSS-API TLS PSK". o The desired_output_len is 64. In other words, the output keying mastering size is 64 in bytes. Note that this is the maximum PSK length required to be supported by implementations conforming to [RFC4279]. The following text art summaries the protocol message flow. Client Server ClientHello --------> <--------* ServerHello TokenTransfer* --------> <-------- 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 TokenTransfer message, if present, is always sent from the client to the server and it can carry an empty token. Zhu, et al. Expires January 18, 2008 [Page 7] Internet-Draft FKA-TLS July 2007 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. When Kerberos is selected as the GSS-API mechanism, the extensions defined in [KRB-ANON] can perform server authentication without client authentication, thus provide the functional equivalence to the certificate-based TLS [RFC4346]. 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. Client Authentication If the GSS-API mechanism in the gss_api TLS extension provides client authentication [RFC2743], the CertificateRequest, the client Certificate and the CertificateVerify handshake messages MUST NOT be present. This is illustrated in Appendix A. 6. Security Considerations As described in Section 3, when the shared key is established using a GSS-API mechanism as described in this document, the identity of the server MUST be obtained from the GSS security context and the identity of the client MUST be obtained from the GSS security context. Authentication methods such as GSS security context and X.509 certificate mixed MUST NOT conflict. Such confusion about the identity will interfere with the ability to properly determine the client's authorization privileges, thus potentially result in a security weakness. When Kerberos as defined in [RFC4120] is used to establish the share key, it is vulnerable to offline dictionary attacks. The threat is mitigated by deploying Kerberos FAST [KRB-FAST]. Shared symmetric keys obtained from mutual calls to GSS_Pseudo_random() are not susceptible to off-line dictionary attacks in the same way that traditional pre-shared keys are. The strength of the generated keys are determined based upon the security properties of the selected GSS mechanism. Implementers MUST take into account the Security Considerations associated with the GSS mechanisms they decide to support. Zhu, et al. Expires January 18, 2008 [Page 8] Internet-Draft FKA-TLS July 2007 7. Acknowledgements Ari Medvinsky was one of the designers of the original TLS Kerberos version 5 CipherSuite and contributed to the first two revisions of this protocol specification. Raghu Malpani provided insightful comments and was very helpful along the way. 8. 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 needs 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". 9. References 9.1. Normative References [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. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. Zhu, et al. Expires January 18, 2008 [Page 9] Internet-Draft FKA-TLS July 2007 [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)", RFC 4401, February 2006. 9.2. Informative 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. [KRB-ANON] Zhu, L. and P. Leach, "Kerberos Anonymity Support", draft-ietf-krb-wg-anon-04.txt (work in progress), 2007. [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. [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. [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. [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism", RFC 4402, February 2006. [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. Appendix A. An FKA-TLS Example: Kerberos TLS This section provides an non-normative description of the message flow when Kerberos Version 5 is used to established the shared secret according to [RFC4121] and that shared secret is then used to secure the TLS connection according to FKA-TLS defined in this document. Zhu, et al. Expires January 18, 2008 [Page 10] Internet-Draft FKA-TLS July 2007 Client Server ClientHello(with AP-REQ) --------> ServerHello(with AP-REP) <-------- ServerHelloDone ClientKeyExchange [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <--------> Application Data Fig. 2. Kerberos FKA-TLS example message flow In this successful authentication sample, the TLS client sends the Kerberos AP-REQ [RFC4120] in the inital context token according to [RFC4121]. The initial GSS-API context token from the GSS-API client contains the Object Identifier that signifies the Kerberos mechanism and it is encapsulated in the gss_api TLS extension in the client hello message. The TLS client always requests mutual authentication, and the TLS server then sends a GSS-API context token that contains the AP-REP [RFC4120] according to [RFC4121]. The TLS server's GSS- API context token is encapsulated in the gss_api TLS extension in the server hello message. The GSS-API context is established at that point and both sides can derive the shared secret value according to [RFC4402]. In this example, the ServerKeyExchange handshake message is not needed and it is not present. And according to Section 5 none of the CertificateRequest, the client Certificate or the CertificateVerify handshake messages is present. Authors' Addresses Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US Email: lzhu@microsoft.com Zhu, et al. Expires January 18, 2008 [Page 11] Internet-Draft FKA-TLS July 2007 Girish Chander Microsoft Corporation One Microsoft Way Redmond, WA 98052 US Email: gchander@microsoft.com Jeffrey Altman Secure Endpoints Inc. 255 W 94th St New York, NY 10025 US Email: jaltman@secure-endpoints.com Stefan Santesson Microsoft Corporation Tuborg Boulevard 12 2900 Hellerup, WA Denmark Email: stefans@microsoft.com Zhu, et al. Expires January 18, 2008 [Page 12] 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, et al. Expires January 18, 2008 [Page 13] draft-santesson-tls-gssapi-03.txt Content-Description: draft-santesson-tls-gssapi-03.txt Content-Type: text/plain Content-Encoding: base64