NETWORK WORKING GROUP L. Zhu Internet-Draft G. Chander Updates: 4279 (if approved) Microsoft Corporation Intended status: Standards Track J. Altman Expires: January 26, 2008 Secure Endpoints Inc. S. Santesson Microsoft Corporation July 25, 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 26, 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 26, 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. Protecting GSS-API Authentication Data . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.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 January 26, 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 26, 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 26, 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..2^16-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 26, 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 26, 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 26, 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. Protecting GSS-API Authentication Data 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. For example, Kerberos is a GSS-API mechanism defined in [RFC4121]. It is possible to design a GSS-API mechanism that can be used with FKA-TLS in order to, for example, provide client authentication, and is so weak that its GSS- API token MUST NOT be in clear text over the open network. A good example is a GSS-API mechanism that implements basic authentication. Although such mechanisms are unlikely to be standardized and will be encouraged in no circumstance, they exist for practical reasons. In addition, it is generally beneficial to provide privacy protection for mechanisms that send client identities in the clear. In order to provide a standard way for protecting weak GSS-API data for use over FKA-TLS, TLSWrap is defined in this section as a pseudo GSS-API mechanism that wraps around the real GSS-API authentication context establishment tokens. This pseudo GSS-API mechanism does not provide per-message security. The real GSS-API mechanism protected by TLSWrap may provide per-message security after the context is established. Zhu, et al. Expires January 26, 2008 [Page 8] Internet-Draft FKA-TLS July 2007 The syntax of the initial TLSWrap token follows the initialContextToken syntax defined in Section 3.1 of [RFC2743]. The TLSWrap pseudo mechanism is identified by the Object Identifier iso.org.dod.internet.security.mechanism.tls-wrap (1.3.6.1.5.5.16). Subsequent TLSWrap tokens MUST NOT be encapsulated in this GSS-API generic token framing. TLSWrap encapsulates the TLS handshake and data protection in its context establishment tokens. The innerContextToken [RFC2743] for the initial TLSWrap context token contains the ClientHello message encoded according to [RFC4346]. No PSK ciphersuite can be included in the client hello message. The targ_name is used by the client to identify the server and it follows the name forms defined in Section 4 of [PKU2U]. Upon receipt of the initial TLSWrap context token, the GSS-API server processes the client hello message. The output GSS-API context token for TLSWrap contains the ServerHello message and the ServerHelloDone potentially with the optional handshake messages in the order as defined in [RFC4346]. The GSS-API client then processes the server reply and returns the ClientKeyExchange message and the Finished message potentially with the optional handshake messages in the order as defined in [RFC4346]. The client places the real GSS-API authentication mechanism token as an application data record right after the TLS Finished message in the same GSS-API context token for TLSWrap. Because the real mechanism token is placed after the ChangeCipherSpec message, the GSS-API data for the real mechanism is encrypted. If the GSS-API server is not authenticated at this point of the TLS handshake for TLSWrap, the TLSWrap context establishment MUST fail and the real authentication mechanism token MUST not be returned. The GSS-API server in turn processes the client reply and returns the TLS Finished message, the server places the reply token from the real authentication mechanism, if present, as an application data record. If additional TLS messages are needed before the application data, these additional TLS messages are encapsulated in the context token of TLSWrap in the same manner how the client hello message and the server hello message are encapsulated as described above. If additional tokens are required by the real authentication mechanism in order to establish the context, these tokens are placed as an application data record, encoded according to [RFC4346] and then returned as TLSWrap GSS-API context tokens, with one TLSWrap context token per each real mechanism context token. The real Zhu, et al. Expires January 26, 2008 [Page 9] Internet-Draft FKA-TLS July 2007 mechanism context tokens are decrypted by TLSWrap and then supply to the real mechanism to complete the context establishment. 7. 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. 8. 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. 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. 9. IANA Considerations A new handshake message token_transfer is defined according to [RFC4346] and a new TLS extension called the gss_api extension is Zhu, et al. Expires January 26, 2008 [Page 10] Internet-Draft FKA-TLS July 2007 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". 10. References 10.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. 10.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. Zhu, et al. Expires January 26, 2008 [Page 11] Internet-Draft FKA-TLS July 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. [PKU2U] Zhu, L., Altman, J., and A. Medvinsky, "Public Key Cryptography Based User-to-User Authentication - (PKU2U)", draft-zhu-pku2u-02.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 January 26, 2008 [Page 12] Internet-Draft FKA-TLS July 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 5 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 January 26, 2008 [Page 13] Internet-Draft FKA-TLS July 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 January 26, 2008 [Page 14] Internet-Draft FKA-TLS July 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 January 26, 2008 [Page 15] 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 26, 2008 [Page 16]