Add.

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]
+
+