path: root/doc/protocol/draft-santesson-tls-gssapi-02.txt

NETWORK WORKING GROUP                                             L. Zhu
Internet-Draft                                     Microsoft Corporation
Updates: 4279 (if approved)                                 July 9, 2007
Intended status: Standards Track
Expires: January 10, 2008


     Flexible Key Agreement for Transport Layer Security (FKA-TLS)
                     draft-santesson-tls-gssapi-02

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 10, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines extensions to RFC 4279 to enable dynamic key
   sharing in distributed environments.  By using these extensions, the
   client and the server can use off-shelf libraries to exchange tokens
   and establish a shared secret, based on a Generic Security Service
   Application Program Interface (GSS-API) mechanism such as Kerberos as
   defined in RFC 4121, and then proceed according to RFC 4279 to
   complete the authentication and provide data protection.



Zhu                     Expires January 10, 2008                [Page 1]

Internet-Draft                   FKA-TLS                       July 2007


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
   3.  Protocol Definition . . . . . . . . . . . . . . . . . . . . . . 3
   4.  Choosing GSS-API Mechanisms . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   Intellectual Property and Copyright Statements  . . . . . . . . . . 9





































Zhu                     Expires January 10, 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.  For example, Kerberos [RFC4121] is a
   GSS-API mechanism that can establish a shared key between a client
   and a server based on either asymmetric keys [RFC4556] or symmetric
   keys [RFC4120].

   This document extends [RFC4279] to allow the client and the server
   establish a shared key on demand by using off-shelf GSS-API
   libraries, and then proceed according to RFC 4279.  This is a modular
   approach to leverage Kerberos alike trust infrastructures in securing
   TLS connections.


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

   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;

   Initially the client calls GSS_Init_sec_context() [RFC2743] to
   establish a security context, it 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.  If the mutual
   authentication is not available when the context is established
   successfully, the GSS-API security context MUST be discarded.  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.




Zhu                     Expires January 10, 2008                [Page 3]

Internet-Draft                   FKA-TLS                       July 2007


   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 with a GSS-API TLS extension 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 NOT include a GSS-API TLS extension in the hello
   message if the cipher_suite in the ServerHello message is not a PSK
   ciphersuite [RFC4279].

   If the server expects at least one more token to be accepted from the
   client in order to establish the security context, the additional
   GSS-API tokens are carried in a new 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 */
                       TokenTranfer;
             } body;
         } Handshake;

          enum {
             gss-api-token(1), (255)
         } TokenTransferType;

         struct {
               TokenTransferType token_type; /* token type */
               opaque token<0..2^16-1>;
         } TokenTranfer;

   The TokenTranfer structure is filled out as follows:

   o  The token_type is gss-api-token.






Zhu                     Expires January 10, 2008                [Page 4]

Internet-Draft                   FKA-TLS                       July 2007


   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
   TokenTranfer stucture from the server as the input token, and then
   places the output token, if any, into the TokenTranfer message and
   sends the handshake message to the server.  The server calls
   GSS_Accept_sec_context() with the token in the TokenTranfer structure
   from the client as the input token, and then places the output token,
   if any, into the TokenTranfer 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 5.  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 second ServerHello message MUST differ from the
   first ServerHello message in the cipher_suite field and only in that
   field.

   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 ciphersuite, and then proceed according
   to [RFC4279] using this shared secret value as the "PSK".  Both
   psk_identity and psk_identity_hint are empty in the handshake
   messages when the shared key is established using a GSS-API mechanism
   as described in this document.

   The following text art summaries the protocol message flow.







Zhu                     Expires January 10, 2008                [Page 5]

Internet-Draft                   FKA-TLS                       July 2007


       Client                                               Server

       ClientHello                  -------->
                                                       ServerHello
                                   <--------        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 TokenTranster message, if present, is always sent from the
   client to the server and it can carry an empty token.


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.

   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.  Security Considerations

   When Kerberos as defined in [RFC4120] is used to establish the share



Zhu                     Expires January 10, 2008                [Page 6]

Internet-Draft                   FKA-TLS                       July 2007


   key, it is vulnerable to offline dictionary attacks.  The threat is
   mitigated by deploying kerberos FAST [KRB-FAST].


6.  Acknowledgements

   Stefan Santesson, Ari Medvinsky and Jeffery Altman helped editing the
   earlier revisions of this document.


7.  IANA Considerations

   A new handshake message token_transfer is defined according to
   [RFC4346] and a new TLS extension called the GSS-API extension is
   defined according to [RFC3546].  The registry need 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".


8.  References

8.1.  Normative 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.

   [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.



Zhu                     Expires January 10, 2008                [Page 7]

Internet-Draft                   FKA-TLS                       July 2007


   [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.

8.2.  Informative References

   [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.

   [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.

   [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
              Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.


Author's Address

   Larry Zhu
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052
   US

   Email: lzhu@microsoft.com














Zhu                     Expires January 10, 2008                [Page 8]

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                     Expires January 10, 2008                [Page 9]