NETWORK WORKING GROUP L. Zhu Internet-Draft G. Chander Updates: 4279 (if approved) Microsoft Corporation Intended status: Standards Track J. Altman Expires: March 17, 2008 Secure Endpoints Inc. S. Santesson Microsoft Corporation September 14, 2007 Flexible Key Agreement for Transport Layer Security (FKA-TLS) draft-santesson-tls-gssapi-04 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 March 17, 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 March 17, 2008 [Page 1] Internet-Draft FKA-TLS September 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. Client Authentication . . . . . . . . . . . . . . . . . . . . 8 5. Choosing GSS-API Mechanisms . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. An FKA-TLS Example: Kerberos TLS . . . . . . . . . . 13 Appendix B. Additional Use Cases for FXA-TLS . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 16 Zhu, et al. Expires March 17, 2008 [Page 2] Internet-Draft FKA-TLS September 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 March 17, 2008 [Page 3] Internet-Draft FKA-TLS September 2007 extended ClientHello message. The gss_api TLS extension is defined according to [RFC3546]. The extension data for the gss_api extension type contains a GSS-API context establishment token. GSS-API tokens are thus carried within the TLS hello messages. enum { gss_api(54321), (65535) } ExtensionType; The payload of the gss_api extension is an GSS-API token. In other words, the length of the byte vector (the TLS type opaque) for the extension data is the length of the GSS-API token and the content of the byte vector contains exactly the content of the GSS-API token. The size of the length field is 2 in octets according to Section 2.3 of [RFC3546]. 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. Unless otherwise specified, the PSK key exchange described in Section 2 of [RFC4279] MUST NOT be selected if the mutual authentication MAY NOT be available on the established GSS-API context, and the DHE_PSK or RSA_PSK key exchange MUST be negotiated instead in order to authenticate the server. Because mutual authentication (if requested) cannot be guaranteed until GSS_S_COMPLETE is returned, typically through multiple invocations of GSS_Init_sec_context() calls, the PSK key exchange is allowed only through additional specifications unless the server authentication is provided a-priori and outside of the GSS-API exchange. For example, when FKA-TLS is negotiated via TLS-renegotiation per Section 5, the server authentication may be provided before the initial GSS-API context establishment token. Zhu, et al. Expires March 17, 2008 [Page 4] Internet-Draft FKA-TLS September 2007 The PSK key exchange can be selected when Kerberos is negotiated to establish the shared key per the FKA-TLS protocol defined in this document. 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. 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 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(231), (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..2^16-1>; } TokenTransfer; The TokenTransfer structure is filled out as follows: Zhu, et al. Expires March 17, 2008 [Page 5] Internet-Draft FKA-TLS September 2007 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 TokenTransferType field allows future extensions of the TokenTransfer handshake message. The gss_api_token type is the only value defined in this document. A new value of TokenTransferType type corresponds to a new structure contained in the TokenTransfer handshake message (therefore a "new" handshake message). 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() 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 As implied by GSS-API, no GSS-API context establishment token SHOULD be received after the context is established (GSS_S_COMPLETE is returned), unless otherwise specified, the receiver MUST tear down the connection if a context established token is received after the context is established. If the GSS-API context fails to establish, it is a matter of local policy whether to continue or reject the TLS authentication. When the server hello message is produced, if the server supports the gss_api extension but the gss_api extension is not utilized to establish the shared secret using GSS-API as defined in this document, the server MUST respond with a gss_api TLS extension with an empty token in the extension data, in order to indicate to the client that it supports FKA-TLS. 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 Zhu, et al. Expires March 17, 2008 [Page 6] Internet-Draft FKA-TLS September 2007 side and the local policy allows the TLS authentication to proceed, the client sends back an empty GSS-API token in a TokenTransfer handshake message. If the GSS-API context fails to establish and local policy allows the TLS authentication to continue, 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 the gss_api extension data. An empty TLS gss_api extension (with no data) MUST be included in the second server hello message. 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 SHOULD be ignored by the client. The input parameters to GSS_Pseudo_random() to compute the shared secret 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". Zhu, et al. Expires March 17, 2008 [Page 7] Internet-Draft FKA-TLS September 2007 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. 4. Client Authentication If the GSS-API mechanism in the gss_api TLS extension provides client authentication [RFC2743], the CertificateRequest, in order to avoid security weakness due to conflicting client identities, the client Certificate and the CertificateVerify handshake messages SHOULD NOT be present. This is illustrated in Appendix A. Zhu, et al. Expires March 17, 2008 [Page 8] Internet-Draft FKA-TLS September 2007 If client authentication is provided via the GSS-API data, and the CertificateVerify handshake message is present, the client identity is determined solely based on the GSS-API context. The client identity provided in the CertificateVerify handshake message MUST be ignored. 5. Choosing GSS-API Mechanisms This section provides general guidelines for choosing a GSS-API mechanism for use in FKA-TLS. GSS-API [RFC2743] provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. 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. It is generally beneficial to provide privacy protection for mechanisms that send client identifiers in the clear. Furthermore, encrypting the GSS-API data can improve the strength of the overall systems, and when applicable complicate offline dictionary attacks against users' secrets based on which the keying materials are derived. Therefore unless otherwise specified, TLS-renegotiation as defined in section 7.4.1.1 of [RFC4346] MUST be used to encrypt the GSS data in FXA-TLS gss_api extension. In many cases, this implies that the client and server negotiate FKA-TLS after completing a certificate-based TLS-handshake, typically to facilitate client authentication. 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. 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 Zhu, et al. Expires March 17, 2008 [Page 9] Internet-Draft FKA-TLS September 2007 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. The primary motivation of this specification is to use the Kerberos protocol for the TLS key agreement. The following security considerations are specific for Kerberos when Kerberos is selected in the gss-api extension for the TLS key exchange. o 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]. o 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. o When Kerberos as defined in [RFC4120] is tunneled by using the [IAKERB] extension to establish the shared key, offline dictionary attacks are possible against cipher texts contained in the client- server traffic. This threat is mitigated by deploying Kerberos FAST [KRB-FAST]. The Kerberos FAST extension provides a secure channel between the client and the KDC that protects the client authentication data from the application server, while the method using TLS-renegotiation defined in Section 5 only protects the client-server traffic, not the traffic between the server and the DC. Hence Kerberos FAST is preferable even when GSS Kerberos data in the FKA-TLS protocol is present only within the TLS- renegotiation handshake messages. 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. Simon Josefsson and Raghu Malpani provided insightful comments, and they are instrumental in the development of this specification. Ryan Hurst contributed significantly to the use cases of FKA-TLS. Love Hornquist Astrand, Nicolas Williams and Martin Rex provided helpful comments while reviewing early revisions of this document. Zhu, et al. Expires March 17, 2008 [Page 10] Internet-Draft FKA-TLS September 2007 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. [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. Zhu, et al. Expires March 17, 2008 [Page 11] Internet-Draft FKA-TLS September 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. [RFC2487] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 2487, January 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004. [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. [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006. [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. Zhu, et al. Expires March 17, 2008 [Page 12] Internet-Draft FKA-TLS September 2007 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows", RFC 4559, June 2006. Appendix A. An FKA-TLS Example: Kerberos TLS This section provides a 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. 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 4 none of the CertificateRequest, the client Certificate or the CertificateVerify handshake messages is present. Appendix B. Additional Use Cases for FXA-TLS TLS runs on layers beneath a wide range of application protocols such Zhu, et al. Expires March 17, 2008 [Page 13] Internet-Draft FKA-TLS September 2007 as LDAP [RFC4510], SMTP [RFC2487], and XMPP [RFC3920] and above a reliable transport protocol. TLS can add security to any protocol that uses reliable connections (such as TCP). TLS is also increasingly being used as the standard method for protecting SIP [RFC3261] application signaling. TLS can provide authentication and encryption of the SIP signaling associated with VOIP (Voice over IP) and other SIP-based applications. Today these applications use public key certificates to verify the identity of endpoints. However, it is overwhelmingly complex to manage the assurance level of the certificates when deploying PKI and such complexity has gradually eroded the confidence for the PKI-based systems in general. In addition, the perceived overhead of deploying and managing certificates is fairly high. As a result, the industry badly needs the ability to secure TLS connections by leveraging the existing credential infrastructure. For many customers that means Kerberos. It is highly desirable to enable PKI-less deployments yet still offer strong authentication. Having Kerberos/GSS-API in the layer above TLS means all TLS applications need to be changed in the protocol level. In many cases, such changes are not technically feasible. For example, [RFC4559] provides integration with Kerberos in the HTTP level. It suffers from a couple of drawbacks, most notably it only supports single-round-trip GSS-API mechanisms and it lacks of channel bindings to the underlying TLS connection which makes in unsuitable for deployment in situations where proxies exists. Furthermore, [RFC4559] lacks of session-based re-authentication (comparing with TLS). The root causes of these problems are inherent to the HTTP protocol and can't be fixed trivially. Consequently, It is a better solution to integrate Kerberos/GSS-API in the TLS layer. Such integration allows the existing infrastructure work seamlessly with TLS for the products based on them in ways that were not practical to do before. For instance, an increasing number of client and server products support TLS natively, but many still lack support. As an alternative, users may wish to use standalone TLS products that rely on being able to obtain a TLS connection immediately, by simply connecting to a separate port reserved for the purpose. For example, by default the TCP port for HTTPS is 443, to distinguish it from HTTP on port 80. TLS can also be used to tunnel an entire network stack to create a VPN, as is the case with OpenVPN. Many vendors now marry TLS's encryption and authentication capabilities with authorization. There has also been substantial development since the late 1990s in creating client technology outside of the browser to enable support for client/server Zhu, et al. Expires March 17, 2008 [Page 14] Internet-Draft FKA-TLS September 2007 applications. When compared against traditional IPSec VPN technologies, TLS has some inherent advantages in firewall and NAT traversal that make it easier to administer for large remote-access populations. PSK-TLS as defined in [RFC4279] is a good start but this document finishes the job by making it more deployable. FKA-TLS also fixes the mutual-authentication problem in [RFC4279] in the cases where the PSK can be shared among services on the same host. Authors' Addresses Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US Email: lzhu@microsoft.com 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 March 17, 2008 [Page 15] Internet-Draft FKA-TLS September 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 March 17, 2008 [Page 16]