diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/protocol/draft-santesson-tls-gssapi-03.txt | 900 |
1 files changed, 900 insertions, 0 deletions
diff --git a/doc/protocol/draft-santesson-tls-gssapi-03.txt b/doc/protocol/draft-santesson-tls-gssapi-03.txt new file mode 100644 index 0000000000..98a615c3d5 --- /dev/null +++ b/doc/protocol/draft-santesson-tls-gssapi-03.txt @@ -0,0 +1,900 @@ + + +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] + + |