summaryrefslogtreecommitdiff
path: root/doc/protocol
diff options
context:
space:
mode:
authorSimon Josefsson <simon@josefsson.org>2007-08-02 20:35:42 +0200
committerSimon Josefsson <simon@josefsson.org>2007-08-02 20:35:42 +0200
commitd86f140d8547e32a7ada6a6d55de2f836e9b694c (patch)
tree9434a89c0462967fe20d4ae5afa32232f3cd42d8 /doc/protocol
parenta276622091f33c0dfd7324fc8271006934152391 (diff)
downloadgnutls-d86f140d8547e32a7ada6a6d55de2f836e9b694c.tar.gz
Add.
Diffstat (limited to 'doc/protocol')
-rw-r--r--doc/protocol/draft-santesson-tls-gssapi-03.txt900
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]
+
+