[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-josefsson-sasl-gs2) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 RFC 5801

Network Working Group                                       S. Josefsson
Internet-Draft                                             June 26, 2006
Expires: December 28, 2006


       Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
                         draft-ietf-sasl-gs2-01

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 December 28, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes how to use a Generic Security Service
   Application Program Interface (GSS-API) mechanism in the the Simple
   Authentication and Security Layer (SASL) framework.

   See <http://josefsson.org/sasl-gs2-*/> for more information.







Josefsson               Expires December 28, 2006               [Page 1]

Internet-Draft                 SASL GS2-*                      June 2006


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in this Document  . . . . . . . . . . . . . .  3
   3.  Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Generating SASL Mechanism Names From GSS-API OIDs  . . . .  3
     3.2.  Computing Mechanism Names Manually . . . . . . . . . . . .  4
     3.3.  Example  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Packet Format  . . . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  SASL Tokens  . . . . . . . . . . . . . . . . . . . . . . .  4
     4.2.  Flags  . . . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.3.  Context Token  . . . . . . . . . . . . . . . . . . . . . .  6
     4.4.  Wrap Token . . . . . . . . . . . . . . . . . . . . . . . .  7
       4.4.1.  Wrap Token Input For Client Requests . . . . . . . . .  7
       4.4.2.  WraP Token Input For Server Responses  . . . . . . . .  8
       4.4.3.  Wrap Token Input For Server Requests . . . . . . . . .  9
       4.4.4.  Wrap Token Input For Client Responses  . . . . . . . .  9
   5.  Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  Name Of Tls Channel For Use As Channel Binding . . . . . . 11
   6.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Authentication Conditions  . . . . . . . . . . . . . . . . . . 14
   8.  GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 14
   9.  Security Layer Bits  . . . . . . . . . . . . . . . . . . . . . 15
   10. Interoperability With The Gssapi Mechanism . . . . . . . . . . 15
     10.1. The Interoperability problem . . . . . . . . . . . . . . . 15
     10.2. Resolving the problem  . . . . . . . . . . . . . . . . . . 15
     10.3. Additional recommendations . . . . . . . . . . . . . . . . 15
   11. Mechanisms That Negotiate Other Mechanisms . . . . . . . . . . 16
     11.1. The Interoperability Problem . . . . . . . . . . . . . . . 16
     11.2. Security Problem . . . . . . . . . . . . . . . . . . . . . 16
     11.3. Resolving the Problems . . . . . . . . . . . . . . . . . . 16
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
   15. Copying Conditions . . . . . . . . . . . . . . . . . . . . . . 18
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     16.2. Informative References . . . . . . . . . . . . . . . . . . 19
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
   Intellectual Property and Copyright Statements . . . . . . . . . . 21











Josefsson               Expires December 28, 2006               [Page 2]

Internet-Draft                 SASL GS2-*                      June 2006


1.  Introduction

   Generic Security Service Application Program Interface (GSS-API) [3]
   is a framework that provide security services to applications.
   Simple Authentication and Security Layer (SASL) [2] is a framework to
   provide authentication and security layers for connection based
   protocols.  This document describe how to use a GSS-API mechanism in
   a connection-based protocol using the SASL framework.

   All GSSAPI mechanisms are implicitly registered for use within SASL
   by this specification.  The SASL mechanism defined in this document
   is known as the GS2 family.

   The "Kerberos V5 GSS-API mechanism" [9] is also supported in SASL
   through "SASL GSSAPI mechanisms" [11].  The difference between that
   protocol and the one described here, is that this protocol offer more
   features (i.e., channel bindings and round-trip optimizations) while
   the other protocol is more widely deployed.  There are
   interoperability concerns by having the same GSS-API mechanism
   available under more than one SASL mechanism name, see the section
   "Interoperability with the GSSAPI mechanism" below.

   There are interoperability and security concerns if this SASL
   mechanism is used together with a GSS-API mechanism that negotiate
   other GSS-API mechanisms (such as SPNEGO [10]), see the section
   "Mechanisms that negotiate other mechanisms" below.

   SASL mechanism names starting with "GS2-" are reserved for SASL
   mechanisms which conform to this document.

   The IESG is considered to be the owner of all SASL mechanisms which
   conform to this document.  This does not necessarily imply that the
   IESG is considered to be the owner of the underlying GSSAPI
   mechanism.


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


3.  Mechanism Name

3.1.  Generating SASL Mechanism Names From GSS-API OIDs

   The SASL mechanism name for a GSS-API mechanism is the concatenation



Josefsson               Expires December 28, 2006               [Page 3]

Internet-Draft                 SASL GS2-*                      June 2006


   of the string "GS2-" and the Base32 encoding [5] (with an upper case
   alphabet) of the first ten bytes of the binary SHA-1 hash [4] string
   computed over the ASN.1 DER encoding [7] of the GSS-API mechanism's
   Object Identifier.  The Base32 rules on padding characters and
   characters outside of the base32 alphabet are not relevant to this
   use of Base32.  If any padding or non-alphabet characters are
   encountered, the name is not a GS2 family mechanism name.

3.2.  Computing Mechanism Names Manually

   The SASL mechanism name may be computed manually.  This is useful
   when the set of supported GSS-API mechanisms is known in advance.  It
   also obliterate the need to implement Base32, SHA-1 and DER in the
   SASL mechanism.  The computed mechanism name can be used directly in
   the implementation, and the implementation need not concern itself
   with that the mechanism is part of a mechanism family.

3.3.  Example

   For example, the OID for the SPKM-1 mechanism [12] is
   1.3.6.1.5.5.1.1.  The ASN.1 DER encoding of the OID is 06 07 2b 06 01
   05 05 01 01.  The SHA-1 hash of the ASN.1 DER encoding is
   1cf8f42b5a9f80fae9f831226d5d9d56278661ad.  The Base32 encoding of the
   first ten bytes of this is "dt4pik22t6epv2py".  Thus the SASL
   mechanism name for the SPKM-1 GSSAPI mechanism is "GS2-
   DT4PIK22T6EPV2PY".


4.  Packet Format

4.1.  SASL Tokens

   All top-level SASL packets for the GS2 mechanism family follow the
   following format:

















Josefsson               Expires December 28, 2006               [Page 4]

Internet-Draft                 SASL GS2-*                      June 2006


                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Context length                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Flags                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               /
      /                         Context token                         /
      /                                           --------------------/
      /                     ---------------------/                    /
      /--------------------/                                          /
      /                          [Wrap token]                         /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The "Context length" field is a 4 octet (32 bit) integer encoded in
   network byte order, it indicate the length of the "Context token"
   field.

   The "Flags" field is a 4 octet (32 bit) bitmask that holds flags that
   influence the authentication process.

   The "Context token" field contain a GSS-API context establishment
   token generated by GSS_Init_sec_context or GSS_Accept_sec_context.

   The "Wrap token" field is optional, and if present will contain the
   output generated by GSS_Wrap.

   The length field does not include the length of the length field
   itself.  Whether the "Wrap token" field is included or not can be
   infered from the length field; if the length field is shorter than
   the entire packet size minus 4 octets, the "Wrap token" field is
   present and begins after length+4 octets into the packet.  The tokens
   need not be aligned to 32-bit a boundary.  There is no padding
   between the tokens.

   Packets shorter than 4 octets are invalid.  If the length field is
   longer than the entire packet size, minus 4 octets, the packet is
   invalid.

4.2.  Flags

   Bit 0 signal whether GSS-API Channel bindings are used.  It is only
   useful in the first token sent from the client, and MUST be set to 0
   in all other tokens.  The bit is called the "Native Channel Bindings"
   bit.  The client chooses whether to set this bit or not depending on
   local policy or user requests.



Josefsson               Expires December 28, 2006               [Page 5]

Internet-Draft                 SASL GS2-*                      June 2006


   The other bits are not specified and MUST be zero.  If a bit is set
   that is not understood by the implementation, it MUST be ignored.

4.3.  Context Token

   The format of the "Context token" field inside the SASL token are
   defined by the GSS-API specifications, and the data is computed by
   the GSS_Init_sec_context and GSS_Accept_sec_context functions.

   The client calls GSS_Init_sec_context, passing in
   input_context_handle of 0 (initially), mech_type of the GSSAPI
   mechanism for which this SASL mechanism is registered, the
   chan_binding is set to NULL or the channel binding data depending on
   the Native Channel Binding flag, and targ_name equal to output_name
   from GSS_Import_Name called with input_name_type of
   GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
   "service@hostname" where "service" is the service name specified in
   the protocol's profile, and "hostname" is the fully qualified host
   name of the server.  If the client will be requesting a security
   layer, it MUST also supply to the GSS_Init_sec_context a
   mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
   integ_req_flag of TRUE.  If the client will be requesting a security
   layer providing confidentiality protection, it MUST also supply to
   the GSS_Init_sec_context a conf_req_flag of TRUE.  If
   GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
   should expect the server to issue a token in a subsequent challenge
   or as additional information to the outcome of the authentication.
   The client must pass the context token to another call to
   GSS_Init_sec_context, repeating the actions in this paragraph, until
   GSS_S_COMPLETE is returned or authentication is aborted.  If the
   server supply data beyond the context token, the context token should
   be processed first, and then the overflow data should be passed to
   GSS_Unwrap and the unwrapped data should be interpreted.  During the
   authentication exchange, the client will generate one Wrap token
   using GSS_Wrap.

   The server passes the first client response to GSS_Accept_sec_context
   as input_token, setting input_context_handle to 0 (initially),
   mech_type of the GSSAPI mechanism for which this SASL mechanism is
   registered, the chan_binding set to NULL or the channel binding data
   depending on the Native Channel Binding bit, and acceptor_cred_handle
   equal to output_cred_handle from GSS_Acquire_cred called with
   desired_name equal to output_name from GSS_Import_name with
   input_name_type of GSS_C_NT_HOSTBASED_SERVICE and input_name_string
   of "service@hostname" where "service" is the service name specified
   in the protocol's profile, and "hostname" is the fully qualified host
   name of the server.  The server must pass any resulting challenge
   from the client to another call to GSS_Accept_sec_context, repeating



Josefsson               Expires December 28, 2006               [Page 6]

Internet-Draft                 SASL GS2-*                      June 2006


   the actions in this paragraph, until GSS_S_COMPLETE is returned or
   authentication is aborted.  If the client supply data beyond the
   context token, the context token should be processed first, and then
   the overflow data should be passed to GSS_Unwrap and the unwrapped
   data should be interpreted.  During the authentication exchange, the
   server will generate one Wrap token using GSS_Wrap.

4.4.  Wrap Token

   The Wrap token MUST NOT be sent before the PROT_READY flag has been
   set locally (by GSS_Init_sec_context or Gss_Accept_sec_context), or
   if the PROT_READY flag is never set, before the context has been
   fully established.  The GSS_Wrap token does not have to be sent
   directly when the PROT_READY flag is set.  During any exchange,
   exactly one GSS_Wrap token is sent in each direction.  The input to
   the GSS_Wrap function MUST follow the format described below.  If not
   exactly one GSS_Wrap token is received by the client and by the
   server, the authentication MUST fail.

   If PROT_READY is never set by GSS_Init_sec_context or
   GSS_Accept_sec_context, the flag is implied by successful context
   negotiation.  This is for GSS-API v1 mechanisms that do not support
   PROT_READY.  This may result in a SASL token consisting of a context
   token length of 0 and a Wrap token.

   The entity that sends its first Wrap token will have to specify a
   bitmap of supported and preferred quality of protection schemes.  The
   entity that reply to the Wrap tokens will pick a scheme, based on the
   bitmask and local policy.

   Four input formats to the GSS_Wrap function are defined.  The first
   two input formats are used when the client sends the GSS_Wrap token
   first and the server reponds.  The other two input formats are used
   when the server sends the GSS_Wrap token first and the client
   responds.

   The input formats below are passed to GSS_Wrap with conf_flag set to
   FALSE, and the Wrap token output will be the generated
   output_message.

   Some fields in the input formats are optional, indicated by brackets
   ("[" and "]") and explained by the text below.

4.4.1.  Wrap Token Input For Client Requests

   The input to GSS_Wrap when the client sends the GSS_Wrap token first
   is as follows.




Josefsson               Expires December 28, 2006               [Page 7]

Internet-Draft                 SASL GS2-*                      June 2006


                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  client_qops  |               client_maxbuf                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   channel_binding_length                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |[client_cbqops]|          [channel_binding_data]               /
      /                                                               /
      /                         /      [authzid]                      /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The "client_qops" integer indicate the client's preferred quality of
   protection if channel bindings are absent or the negotiation of the
   channel binding fails.

   The "client_maxbuf" field indicate the maximum protected buffer size
   the client can receive.

   The "channel_binding_length" is a network byte order integer that
   indicate the length of the "channel_binding_data" field.

   The optional field "client_cbqops" is present only if
   "channel_binding_length" is non-zero, and indicate the client's
   preferred quality of protection if channel binding negotiation
   succeeds.

   The optional field "channel_binding_data" is present only if
   "channel_binding_length" is non-zero, and contain the actual channel
   binding data.

   The optional field "authzid" contain the authorization identity.  The
   authorization identity is encoded using UTF-8 [6].  The authorization
   identity is not terminated with the NUL (U+0000) character.  Servers
   MUST validate that the authorization identity is valid UTF-8.

4.4.2.  WraP Token Input For Server Responses

   The data format for input to GSS_Wrap when the server responds to the
   previous GSS_Wrap token data is as follows.

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  server_qop   |               server_maxbuf                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The "server_qop" field integer indicate the selected quality of



Josefsson               Expires December 28, 2006               [Page 8]

Internet-Draft                 SASL GS2-*                      June 2006


   protection.

   The "server_maxbuf" field indicate the maximum data buffer size the
   server can receive.  It MUST be 0 if the server doesn't advertise
   support for any security layer, the client MUST verify this.

4.4.3.  Wrap Token Input For Server Requests

   The data format for input to GSS_Wrap when the server sends the
   GSS_Wrap token first is as follows.

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  server_qops  |               server_maxbuf                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   channel_binding_length                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |[server_cbqops]|          [channel_binding_data]               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The "server_qops" field is an integer indicating the server's
   preferred quality of protection if channel bindings are absent or the
   negotiation of the channel binding fails.

   The "server_maxbuf" is the same as above.

   The "channel_binding_length" is a network byte order integer that
   indicate the length of the "channel_binding_data" field.

   The optional field "server_cbqops" is present only if
   "channel_binding_length" is non-zero, and indicate the server's
   preferred quality of protection if channel binding negotiation
   succeeds.

   The optional field "channel_binding_data" is present only if
   "channel_binding_length" is non-zero, and contain the actual channel
   binding data.

4.4.4.  Wrap Token Input For Client Responses

   The data format for input to GSS_Wrap when the client responds to the
   previous token is as follows.








Josefsson               Expires December 28, 2006               [Page 9]

Internet-Draft                 SASL GS2-*                      June 2006


                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  client_qop   |               client_maxbuf                   |
      /             [authzid]                                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The "client_qop" field is the selected quality of protection.

   The "client_maxbuf" and "authzid" fields are as above.


5.  Channel Bindings

   [[This section is tentative further discussion on the topic.  This
   was written to provide an example of how the details of how one
   approach to this concept could look like.  There are other approaches
   that may be preferable.]]

   The GS2 mechanism provide its own token field for channel bindings,
   in addition to the "chan_binding" parameter in the GSS-API context
   functions.  The reason for this is that the GS2 mechanism wish to
   provide an option to proceed even if the channel bindings does not
   match.  The GSS-API framework specifies that authentication cannot
   proceed if channel bindings does not match.  The GSS-API framework
   also does not specify the kind of privacy layer the channel binding
   should be transferred under, thus making it possible for attackers to
   modify it to always make channel binding negotiation succeed.

   The client can select, using the "Native Channel Bindings" bit,
   whether it wishes to use the "chan_bindings" parameter in the GSS-API
   layer or not.  If it wishes to use this, it is not possible to
   continue after a failed channel binding negotiation.

   A client that wish to continue with the authentication even if the
   channel bindings does not match, set the "Native Channel Binding" bit
   to 0.  It MUST use the channel binding field in the GS2 token.  It
   MUST set the "chan_binding" parameter in the calls to
   GSS_Init_sec_context to GSS_Accept_sec_context to NULL.  The
   application MUST set the "client_qops" field to include privacy
   protection (to protect the SASL application data), and MAY set the
   "client_cbqops" to no security layer (to avoid performance
   degradation due to two security layers).

   If a client do not wish to continue the authentication if channel
   binding negotiation fails, or wishes to use the channel binding in
   the GSS-API layer, it will set the "Native Channel Binding" bit to 1
   in its first token.  It MUST use both the channel binding field in



Josefsson               Expires December 28, 2006              [Page 10]

Internet-Draft                 SASL GS2-*                      June 2006


   the GS2 token and the "chan_binding" parameter in the calls to
   GSS_Init_sec_context and GSS_Accept_sec_context.  The authentication
   will fail in the GSS-API layer if the channel bindings does not
   match, and thus the "client_qops" and "client_cbqops" MUST be set to
   the same value.  It MAY be set to no security layer (to avoid
   performance degradation due to two security layers).

   For TLS, the channel binding data is specified in the next section.
   For other security layers, channel binding data will have to
   specified elsewhere, and this specification will have to be updated
   with explicit considerations.

   [[All channel bindings should go into a separate document.]]

5.1.  Name Of Tls Channel For Use As Channel Binding

   The TLS Pseudo-Random Function (PRF) generate, using the constant
   string "TLS channel binding", and based on the master secret and the
   random values established during a TLS handshake, a 64 octet string
   that make up the SASL channel binding data.

   Using the terminology of TLS [13], the channel binding data is
   computed as follows:

          SASL_channel_binding =
             PRF(SecurityParameters.master_secret,
                "TLS channel binding",
                SecurityParameters.server_random +
                SecurityParameters.client_random) [0..64];

   The derived data is intended to be used as a name of the TLS channel
   that is cryptographically bound to the channel, for use in
   authentication mechanisms tunneled over TLS.


6.  Protocol Overview

   This section describe several high-level protocol exchanges.  The
   descriptions do not assume any properties of the actual GSS-API
   mechanism.  Protocol profiles, GSS-API mechanism specific behaviour,
   and to some extent implementation and policy choices, will dictate
   which packets are sent in what order.  The protocol exchanges are
   examples and other exchanges are permitted and will occur.

   An authentication exchange using GS2 may look like:






Josefsson               Expires December 28, 2006              [Page 11]

Internet-Draft                 SASL GS2-*                      June 2006


         C: Request authentication exchange
         S: Send [length=0] token
         C: Send [length, GSS_Init_sec_context] token
         ...
         S: After PROT_READY is set,
            send [length, GSS_Accept_sec_context,
                  GSS_Wrap(server_qops, server_maxbuf,
                           channel_binding_length=0)]
         ...
         C: After PROT_READY is set,
            send [length, GSS_Init_sec_context,
                  GSS_Wrap (client_qop, client_maxbuf, authzid)]
         S: Send [length, GSS_Accept_sec_context] token
         C: Send [length, GSS_Init_sec_context] token
         ...
         S: Outcome of authentication exchange

   Because GSS-API authentication is initiated by the client, the length
   field will be 0 in the initial token from the server to the client
   when the protocol profile do not support additional information to be
   sent together with the authentication request.

   The next example illustrate when the client sends its Wrap token
   first.

         C: Request authentication exchange
         S: Send [length=0] token
         C: Send [length, GSS_Init_sec_context] token
         ...
         C: After PROT_READY is set,
            send [length, GSS_Init_sec_context,
                  GSS_Wrap(client_qops, client_maxbuf,
                           channel_binding_length=0, authzid)]
         ...
         S: After PROT_READY is set,
            send [length, GSS_Accept_sec_context,
                  GSS_Wrap (server_qop, server_maxbuf)]
         C: Send [length, GSS_Init_sec_context] token
         S: Send [length, GSS_Accept_sec_context] token
         ...
         S: Outcome of authentication exchange

   If the protocol profile support the optional initial client response,
   the first empty message can be optimized away, and then the protocol
   exchange will look like:






Josefsson               Expires December 28, 2006              [Page 12]

Internet-Draft                 SASL GS2-*                      June 2006


         C: Request authentication exchange and
            send [length, GSS_Init_sec_context] token
         S: Send [length, GSS_Accept_sec_context] token
         ...
         S: Outcome of authentication exchange

   If the protocol profile can also send additional information when
   indicating the outcome of the authentication, then the protocol
   exchange will look like:

         C: Request authentication exchange and
            send [length, GSS_Init_sec_context] token
         S: Send [length, GSS_Accept_sec_context] token
         ...
         C: Send [length, GSS_Init_sec_context] token
         S: Indicate successful authentication and
            send [length, GSS_Accept_sec_context] token
            as additional information.

   If the PROT_READY flag is never set by the GSS-API mechanism, the
   GSS_Wrap message will be sent after the context has been established.
   The protocol may look like:

         C: Request authentication exchange
         ...
         S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs
            a token, send [length, context token,
                           GSS_Wrap(server_qops, server_maxbuf,
                                    channel_binding_length=0)]
         C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not
            output a token, send
            [length=0, context token,
                  GSS_Wrap(client_qop, client_maxbuf,
                           channel_binding_length=0, authzid)]
         S: Outcome of authentication exchange

   Alternatively, if the client finishes first, it may look like:

         C: Request authentication exchange
         ...
         C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
            token, send [length, context token,
                    GSS_Wrap(client_qops, client_maxbuf,
                             channel_binding_length=0, authzid)]
         S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not
            output a token, send [length, context token,
                                  GSS_Wrap(server_qop, server_maxbuf,
                                           channel_binding_length=0)]



Josefsson               Expires December 28, 2006              [Page 13]

Internet-Draft                 SASL GS2-*                      June 2006


         S: Outcome of authentication exchange

   If the protocol support initial data from the client, and the
   PROT_READY flag is set in the client after the first call to
   GSS_Init_sec_context, and the server can send additional data to the
   client when indicating successful authentication, the following
   protocol exchange will occur.

         C: Request authentication exchange and
            send [length, GSS_Init_sec_context,
                  GSS_Wrap (client_qops, client_maxbuf,
                            channel_binding_length=0, authzid)] token
         S: Indicate successful authentication and
            send [length, GSS_Accept_sec_context,
                  GSS_Wrap(server_qop, server_maxbuf)] token
            as additional information.

   The last example illustrate the optimal (round-trip wise)
   authentication possible using this protocol.


7.  Authentication Conditions

   Authentication MUST NOT succeed if any one of the following
   conditions are true:
   o  An invalid SASL token is received (i.e., length shorter than 4
      octets).
   o  GSS_Init/Accept_sec_context() return anything other than
      GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
   o  GSS_Wrap() returns anything other than GSS_S_COMPLETE.
   o  GSS_Unwrap() returns anything other than GSS_S_COMPLETE.  (There
      can't be supplementary status codes in GS2 at this point, so any
      indications of out of order processing or replays should be
      fatal.)
   o  The token returned from GSS_Unwrap fail to parse correctly (e.g.,
      too short, invalid maximum buffer size) as the expected Wrap
      token.
   o  Local policy reject the attempt.  For example, client and server
      can't agree on qop proposal.
   o  (server-side) Authorization of client principal (i.e., src_name in
      GSS_Acecpt_sec_context) to requested authzid failed.


8.  GSS-API Parameters

   The implementation MAY set any GSSAPI flags or arguments not
   mentioned in this specification as is necessary for the
   implementation to enforce its security policy.



Josefsson               Expires December 28, 2006              [Page 14]

Internet-Draft                 SASL GS2-*                      June 2006


9.  Security Layer Bits

   The security layers and their corresponding bit-masks are as follows:

     1 No security layer
     2 Integrity protection.
       Sender calls GSS_Wrap with conf_flag set to FALSE
     4 Confidentiality protection.
       Sender calls GSS_Wrap with conf_flag set to TRUE

   Other bit-masks may be defined in the future; bits which are not
   understood must be negotiated off.

   Note that SASL negotiates the maximum size of the output_message to
   send.  Implementations can use the GSS_Wrap_size_limit call to
   determine the corresponding maximum size input_message.


10.  Interoperability With The Gssapi Mechanism

   The GSSAPI mechanism [11] describe how the Kerberos V5 GSS-API
   mechanism [9] is used in SASL under the mechanism name "GSSAPI".  The
   same mechanism may also be used with the GS2 family.  This causes an
   interopability problem, which is discussed and resolved below.

10.1.  The Interoperability problem

   If a client (or server) only support Kerberos V5 under the "GSSAPI"
   name and the server (or client) only support Kerberos V5 under the
   GS2 family, the authentication negotiation will fail.

10.2.  Resolving the problem

   If the Kerberos V5 mechanism is supported under GS2 in a server, the
   server SHOULD also support Kerberos V5 through the "GSSAPI"
   mechanism, to avoid interoperability problems with older clients.

   Reasons for violating this recommendation may include security
   considerations regarding the absent features in the GS2 mechanism.
   The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which
   could enable certain tunnel attacks [16].

10.3.  Additional recommendations

   It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism
   rather than through the "GSSAPI" mechanism, if both are available,
   because of the additional features in the GS2 mechanism.




Josefsson               Expires December 28, 2006              [Page 15]

Internet-Draft                 SASL GS2-*                      June 2006


11.  Mechanisms That Negotiate Other Mechanisms

   A GSS-API mechanism that negotiate other mechanisms interact badly
   with the SASL mechanism negotiation.  There are two problems.  The
   first is an interoperability problem and the second is a security
   concern.  The problems are described and resolved below.

11.1.  The Interoperability Problem

   If a client implement GSS-API mechanism X, potentially negotiated
   through a GSS-API mechanism Y, and the server also implement GSS-API
   mechanism X negotiated through a GSS-API mechanism Z, the
   authentication negotiation will fail.

11.2.  Security Problem

   If a client's policy is to first prefer GSSAPI mechanism X, then non-
   GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
   mechanisms Y and Z but not X, then if the client attempts to
   negotiate mechanism X by using a GSS-API mechanism that negotiate
   other mechanisms (such as SPNEGO), it may end up using mechanism Z
   when it should have used mechanism Y. For this reason, the use of
   GSS-API mechanisms that negotiate other mechanisms are disallowed
   under GS2.

11.3.  Resolving the Problems

   GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
   with the GS2 SASL mechanism.  This specifically exclude negotiating
   SPNEGO [10] under GS2.

   The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() [15]
   can be used to identify such mechanisms.


12.  IANA Considerations

   The IANA is advised that SASL mechanism names starting with "GS2-"
   are reserved for SASL mechanisms which conform to this document.  The
   IANA is directed to place a statement to that effect in the sasl-
   mechanisms registry.










Josefsson               Expires December 28, 2006              [Page 16]

Internet-Draft                 SASL GS2-*                      June 2006


     Subject: Registration of SASL mechanism GS2-*
     Family of SASL mechanisms: YES
     SASL mechanism prefix: GS2-
     Security considerations: RFC [THIS-DOC]
     Published specification: RFC [THIS-DOC]
     Person & email address to contact for further information:
       Simon Josefsson <simon@josefsson.org>
     Intended usage: COMMON
     Owner/Change controller: iesg@ietf.org
     Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.


13.  Security Considerations

   Security issues are discussed throughout this memo.

   When a server or client supports multiple authentication mechanisms,
   each of which has a different security strength, it is possible for
   an active attacker to cause a party to use the least secure mechanism
   supported.  There are several ways to mitigate this problem:

   1.  Integrity protected transports can be used, e.g., TLS [13].  To
       protect against certain tunnel attacks [16] with that solution, a
       mechanism that support channel bindings that can bind the
       security layer (e.g., the TLS session id) to the authentication
       is required.
   2.  A client or server which supports mechanisms of different
       strengths should have a configurable minimum strength that it
       will use.  It is not sufficient for this minimum strength check
       to only be on the server, since an active attacker can change
       which mechanisms the client sees as being supported, causing the
       client to send authentication credentials for its weakest
       supported mechanism.

   Because the negotiation of a GSS-API mechanism may be done in the
   clear, it is important for the GSS-API mechanisms to be designed such
   that an active attacker cannot obtain an authentication with weaker
   security properties by modifying the challenges and responses.

   The integrity protection provided by the security layer is useless to
   the client unless the client also requests mutual authentication.
   Therefore, a client wishing to benefit from the integrity protection
   of a security layer MUST pass to the GSS_Init_sec_context call a
   mutual_req_flag of TRUE.

   When constructing the input_name_string, the client should not
   canonicalize the server's fully qualified domain name using an
   insecure or untrusted directory service, e.g., the Domain Name System



Josefsson               Expires December 28, 2006              [Page 17]

Internet-Draft                 SASL GS2-*                      June 2006


   [8] without DNSSEC [14].

   Additional security considerations are in the SASL and GSSAPI
   specifications.  Additional security considerations for the Kerberos
   V5 GSSAPI mechanism can be found in [9].  We stress that service
   names should not be canonicalized using an unsecured directory
   service such as the DNS without DNSSEC.


14.  Acknowledgements

   This document is a revision of RFC 2222.  This version was derived
   from draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov
   with significant contributions from John G. Myers, although this
   document has been rewritten by the current author.

   Contributions of many members of the SASL mailing list are gratefully
   acknowledged.  In particular, ideas from Sam Hartman, Jeffrey
   Hutzelman, and Nicolas Williams influenced the design of this
   protocol.


15.  Copying Conditions

   Regarding the portion of this document that was written by Simon
   Josefsson ("the author", for the remainder of this section), the
   author makes no guarantees and is not responsible for any damage
   resulting from its use.  The author grants irrevocable permission to
   anyone to use, modify, and distribute it in any way that does not
   diminish the rights of anyone else to use, modify, and distribute it,
   provided that redistributed derivative works do not contain
   misleading author or version information.  Derivative works need not
   be licensed under similar terms.  Contact the author to confirm which
   sections are available under this license.


16.  References

16.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Myers, J., "Simple Authentication and Security Layer (SASL)",
        RFC 2222, October 1997.

   [3]  Linn, J., "Generic Security Service Application Program
        Interface Version 2, Update 1", RFC 2743, January 2000.



Josefsson               Expires December 28, 2006              [Page 18]

Internet-Draft                 SASL GS2-*                      June 2006


   [4]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
        RFC 3174, September 2001.

   [5]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
        draft-josefsson-rfc3548bis-04 (work in progress), May 2006.

   [6]  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
        STD 63, RFC 3629, November 2003.

   [7]  "Information Processing Systems - Open Systems Interconnection -
        Specification of Abstract Syntax Notation One (ASN.1)", ISO
        Standard 8824.

16.2.  Informative References

   [8]   Mockapetris, P., "Domain names - concepts and facilities",
         STD 13, RFC 1034, November 1987.

   [9]   Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
         June 1996.

   [10]  Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
         Negotiation Mechanism", RFC 2478, December 1998.

   [11]  Melnikov, A., "SASL GSSAPI mechanisms",
         draft-ietf-sasl-gssapi-03 (work in progress), September 2005.

   [12]  Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
         RFC 2025, October 1996.

   [13]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
         RFC 2246, January 1999.

   [14]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
         "DNS Security Introduction and Requirements", RFC 4033,
         March 2005.

   [15]  Williams, N., "Extended Generic Security Service Mechanism
         Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-01 (work
         in progress), October 2005.

   [16]  Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in
         Tunneled Authentication",
         WWW http://www.saunalahti.fi/~asokan/research/mitm.html.







Josefsson               Expires December 28, 2006              [Page 19]

Internet-Draft                 SASL GS2-*                      June 2006


Author's Address

   Simon Josefsson

   Email: simon@josefsson.org














































Josefsson               Expires December 28, 2006              [Page 20]

Internet-Draft                 SASL GS2-*                      June 2006


Intellectual Property Statement

   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.


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2006).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Josefsson               Expires December 28, 2006              [Page 21]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/