[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                       S. Josefsson
Internet-Draft                                         November 17, 2005
Expires: May 21, 2006


       Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
                      draft-josefsson-sasl-gs2-00

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 May 21, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes how to use a Generic Security Service
   Application Program Interface mechanism in the the Simple
   Authentication and Security Layer framework.

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







Josefsson                 Expires May 21, 2006                  [Page 1]

Internet-Draft                 SASL GS2-*                  November 2005


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.  Protocol specification . . . . . . . . . . . . . . . . . . . .  4
     4.1.  Packet format  . . . . . . . . . . . . . . . . . . . . . .  4
     4.2.  Protocol overview  . . . . . . . . . . . . . . . . . . . .  5
     4.3.  GSS-API parameters . . . . . . . . . . . . . . . . . . . .  9
     4.4.  Security layer bits  . . . . . . . . . . . . . . . . . . .  9
     4.5.  Authorization identity format  . . . . . . . . . . . . . . 10
     4.6.  Client side of authentication protocol exchange  . . . . . 10
     4.7.  Server side of authentication protocol exchange  . . . . . 12
   5.  SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  Copying conditions . . . . . . . . . . . . . . . . . . . . . . 16
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19

























Josefsson                 Expires May 21, 2006                  [Page 2]

Internet-Draft                 SASL GS2-*                  November 2005


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 mechanism is implicitly registered by this specification
   for use within SASL.  The SASL mechanism defined in this document is
   known as the GS2 family.

   The "Kerberos V5 GSS-API mechanism" [9] and "The Simple and Protected
   GSS-API Negotiation Mechanism" [10] are 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 with supporting GSS-API mechanisms through
   more than one SASL mechanism, see the section on SPNEGO 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
   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



Josefsson                 Expires May 21, 2006                  [Page 3]

Internet-Draft                 SASL GS2-*                  November 2005


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

   Each SASL mechanism conforming to this document uses the following
   specification.

4.1.  Packet format

   All messages follow the following format:

                           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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             length                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               /
      /                      GSS_Init_sec_context or                  /
      /                   GSS_Accept_sec_context token,               /
      /                     of given length                           /
      /                                           --------------------/
      /                     ---------------------/                    /
      /--------------------/                                          /
      /                              Optional GSS_Wrap token          /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Josefsson                 Expires May 21, 2006                  [Page 4]

Internet-Draft                 SASL GS2-*                  November 2005


   The "length" field is a 4 octet (32 bit) integer encoded in network
   byte order, indicating the length of the next field, containing a
   GSS-API context establishment token.  The length field does not
   include the length of the length field itself.  The GSS_Wrap token is
   optional.  Whether it 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 GSS_Wrap is present and begins after
   length+4 octets into the packet.  The GSS_Wrap token need not be
   aligned to 32-bit a boundary.  There is no padding between the
   context establishment token and the GSS_Wrap token.

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

4.2.  Protocol overview

   This section describe several examples of 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.

   An authentication exchange using GS2 may look like:

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

   The length field contain the length of the GSS_Init_sec_context or
   GSS_Accept_sec_context token.  The receiver can distinguish the case
   where the GSS_Wrap token is present by comparing the length field
   value with the total length of the token.  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), because GSS-API authentication is
   initiated by the client.



Josefsson                 Expires May 21, 2006                  [Page 5]

Internet-Draft                 SASL GS2-*                  November 2005


   If the PROT_READY flag become set in the client before the server,
   the client can send the GSS_Wrap token first.  In this case, the
   client must send a bitmap of supported/preferred quality of
   protection schemes, rather than one single quality of protection
   method.

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

   The GSS_Wrap tokens can only be sent by the client and server after
   the PROT_READY flag has been set by GSS_Init_sec_context and
   GSS_Accept_sec_context, respectively.  During any exchange, exactly
   one GSS_Wrap token is sent in each direction.  If more than one
   GSS_Wrap token is received by either the client or the server, the
   authentication MUST fail.  The GSS_Wrap token does not have to be
   sent directly whenever the PROT_READY flag is set.

   If PROT_READY is never set by GSS_Init_sec_context or
   GSS_Accept_sec_context, the GSS_Wrap messages can be sent after the
   context has been established.  In this case, the length field will
   encode the integer 0, indicating that the context token is absent.
   If the context has not been established at that point, the
   authentication MUST fail.

   If the protocol profile support the optional initial client response,
   then the protocol exchange will look like:













Josefsson                 Expires May 21, 2006                  [Page 6]

Internet-Draft                 SASL GS2-*                  November 2005


         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: Send [length, GSS_Accept_sec_context,
                  GSS_Wrap(server_qops, server_maxbuf)] token
         C: Send [length, GSS_Init_sec_context,
                  GSS_Wrap (client_qop, client_maxbuf, authzid)] token
         S: Send [length, GSS_Accept_sec_context] token
         C: Send [length, GSS_Init_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: Send [length, GSS_Accept_sec_context,
                  GSS_Wrap(server_qops, server_maxbuf)] token
         C: Send [length, GSS_Init_sec_context,
                  GSS_Wrap (client_qop, client_maxbuf, authzid)] token
         S: Send [length, GSS_Accept_sec_context] token
         C: Send [length, GSS_Init_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.

   The client MUST verify that GSS_Init_context return GSS_S_COMPLETE
   rather than trust the server's signaling of whether the
   authentication was successful or not.  If the server report
   successful authentication and GSS_Init_sec_context did not return
   GSS_S_COMPLETE on the last token, the authentication MUST be aborted
   by the client.

   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:






Josefsson                 Expires May 21, 2006                  [Page 7]

Internet-Draft                 SASL GS2-*                  November 2005


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

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

         C: Request authentication exchange
         ...
         C: GSS_Init_sec_context return GSS_S_COMPLETE,
            send [length, GSS_Init_sec_context] token
         S: GSS_Accept_sec_context return GSS_S_COMPLETE,
            send [length, GSS_Accept_sec_context] token
         C: Send [length=0,
                  GSS_Wrap(client_qops, client_maxbuf, authzid)] token
         S: Send [length=0, GSS_Wrap(server_qop, server_maxbuf)] token
         C: Empty Response
         S: Outcome of authentication exchange

   If the entity the finish first does not wish to send its GSS_Wrap
   message first, it send an empty token to indicate this.  Only one
   empty token is permitted, more than one MUST lead to authentication
   failure.  Empty tokens are not permitted during the initial conext
   establishment.  The following figure illustrate this scenario:

         C: Request authentication exchange
         ...
         C: GSS_Init_sec_context return GSS_S_COMPLETE,
            send [length, GSS_Init_sec_context] token
         S: GSS_Accept_sec_context return GSS_S_COMPLETE,
            send [length, GSS_Accept_sec_context] token
         C: Empty Response
         S: Send [length=0, GSS_Wrap(server_qops, server_maxbuf)] token
         C: Send [length=0,
                  GSS_Wrap(client_qop, client_maxbuf, authzid)] token
         S: Outcome of authentication exchange

   This alter which side chose the resulting quality of protection.
   Earlier, the client sent a bit mask of which quality of protection he
   support/prefer and the server chose one.  Now, the server send a bit
   mask of which quality of protections it support/prefer, and the
   client chose one.  Implementations are encouraged to pick the



Josefsson                 Expires May 21, 2006                  [Page 8]

Internet-Draft                 SASL GS2-*                  November 2005


   strongest available method if there is a choice, but local policy may
   dictate that a weaker method is to be used.  If the client_qop or
   server_qop received by the server or client does not match the
   server_qops or client_qops bitmask, the semantic is that the
   indicated (i.e., through client_qop or server_qop) quality of
   protection is required by the other end to complete the
   authentication.  The entity receiving such a message may decide using
   local policy whether to continue authentication or not.  Normally,
   the authentication is aborted (because the other end did not meet the
   supported/preferred quality of protections announced by the local
   end), but in some cases, accepting the other ends decision may be
   acceptable.  Note that the quality of protection fields are both
   integrity and privacy protected, thus protecting this negotiation.

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

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

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



Josefsson                 Expires May 21, 2006                  [Page 9]

Internet-Draft                 SASL GS2-*                  November 2005


   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.

4.5.  Authorization identity format

   The authorization identity is encoded using UTF-8 [6].  The
   authorization identity is not terminated with the NUL (U+0000)
   character.

4.6.  Client side of authentication protocol exchange

   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, any
   chan_binding if requested by the application, 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.  The client then
   send a four-octet network byte order integer encoding the length of
   the resulting output_token, concatenated with the actual token.  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 token received from the server will be prefixed with a four-octet
   network byte-order integer encoding the length of the context token.
   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 as described
   below.

   When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines
   the context to ensure that it provides a level of protection
   permitted by the client's security policy.  If the context is
   unacceptable, the client abort the authentication.  Otherwise, if the
   last call to GSS_Init_sec_context returned an output_token, that



Josefsson                 Expires May 21, 2006                 [Page 10]

Internet-Draft                 SASL GS2-*                  November 2005


   token is returned to the server (prefixed with the length integer)
   together with a GSS_Wrap token, unless the client already sent the
   GSS_Wrap token earlier.  If the call to GSS_Init_sec_context did not
   return any additional token in output_token, it will respond with an
   empty context token (i.e., a length field value of 0) and a GSS_Wrap
   token, unless the client already sent the GSS_Wrap token earlier.

   When the context has been established, or if the PROT_READY flag is
   set by the call to GSS_Init_sec_context, the client may send, in
   addition to the length field and output_token (if any), a GSS_Wrap
   token.  The client passes data to GSS_Wrap with conf_flag set to
   FALSE, and responds with the generated output_message.

   If the client has not received a GSS_Wrap token from the server yet,
   the data will contain one octet with a bit-mask indicating the
   client's supported/preferred security layer ("client_qops"), then
   three octets encoding, in network byte order, an integer indicating
   the maximum message size ("client_maxbuf") that the client can
   receive (set to 0 if no integrity or privacy layer is requested), and
   the remaining data is the UTF-8 [6] encoded authorization identity
   ("authzid") which may be empty.  The client will later expect a
   GSS_Wrap token from the server.  The client passes this token to
   GSS_Unwrap and interprets the first octet of resulting cleartext as
   the selected security layer ("server_qop"), and the second through
   fourth octets as the network byte order maximum size output_message
   to send to the server ("server_maxbuf").  The client will verify that
   the selected security layer is acceptable, it may be different from
   what was requested in "client_qops".

   If the client has received a GSS_Wrap token from the server earlier,
   the client passes that token to GSS_Unwrap and interprets the first
   octet of resulting cleartext as a bit-mask indicating the supported/
   preferred security layer that the server wish to use ("server_qops"),
   and the second through fourth octets as the network byte order
   integer indicating the maximum size output_message to send to the
   server ("server_maxbuf").  The client then proceed to create the data
   used as input to GSS_Wrap.  The data will contain one octet
   indicating the selected quality of protection level ("client_qop"),
   which should be one of those indicated in the bit-mask received from
   the server (but may be different if the client would abort
   authentication here and want to give the server a chance to use a
   different security method), three octets encoding, in network byte
   order, an integer indicating the maximum buffer size
   ("client_maxbuf") that the client can receive (set to 0 if no
   integrity or privacy layer is requested), and the remaining octets
   containing the UTF-8 [6] encoded authorization identity ("authzid")
   which may be empty.




Josefsson                 Expires May 21, 2006                 [Page 11]

Internet-Draft                 SASL GS2-*                  November 2005


   The client must validate the GSS_Wrap token it receive from the
   server.  If the resulting cleartext received from GSS_Unwrap is not 4
   octets long, the client fails the negotiation.  The client verifies
   that the server maximum buffer is 0 if the server doesn't advertise
   support for any security layer.

4.7.  Server side of authentication protocol exchange

   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, any chan_binding if requested by the application, 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.  If
   GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server send
   to the client the challenge, consisting of a four-octet network byte
   order integer encoding the length of the resulting output_token,
   concatenated with the actual token.  The server must pass the
   resulting challenge from the client to another call to
   GSS_Accept_sec_context, repeating 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 as
   described below.

   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
   examines the context to ensure that it provides a level of protection
   permitted by the server's security policy.  If the context is
   unacceptable, the server abort the authentication.  Otherwise, if the
   last call to GSS_Accept_sec_context returned an output_token, the
   server returns it to the client in a challenge (prefixed with the
   length integer) together with a GSS_Wrap token, unless the server
   already sent the GSS_Wrap token earlier.  If the
   GSS_Accept_sec_context did not return an output token, the server
   return an empty context (i.e., length=0) together with a GSS_Wrap
   token, unless the server already sent the GSS_Wrap token earlier.

   When the context has been established, or if the PROT_READY flag is
   set by the call to GSS_Accept_sec_context, the server may send, in
   addition to the length field and output_token (if any), a GSS_Wrap
   token.  The server passes data to GSS_Wrap with conf_flag set to
   FALSE, and responds with the generated output_message.




Josefsson                 Expires May 21, 2006                 [Page 12]

Internet-Draft                 SASL GS2-*                  November 2005


   If the server has not received a GSS_Wrap token from the client yet,
   the data will contain one octet with a bit-mask indicating the
   server's supported/preferred security layer ("server_qops"), then
   three octets encoding, in network byte order, an integer indicating
   the maximum message size ("server_maxbuf") that the server can
   receive (set to 0 if no integrity or privacy layer is requested).
   The server will later expect a GSS_Wrap token from the client.  The
   server pass this token to GSS_Unwrap and interprets the first octet
   of resulting cleartext as the selected security layer ("client_qop"),
   and the second through fourth octets as the network byte order
   maximum size output_message to send to the client ("client_maxbuf").
   The server will verify that the selected security layer is
   acceptable, it may be different from what indicated in "server_qops".

   If the server has received a GSS_Wrap token from the client earlier,
   the server passes that token to GSS_Unwrap and interprets the first
   octet of resulting cleartext as a bit-mask indicating the client's
   supported/preferred security layer ("client_qops"), and the second
   through fourth octets as the network byte order integer indicating
   the maximum size output_message to send to the client
   ("client_maxbuf").  The server then proceed to create the data used
   as input to GSS_Wrap.  The data will contain one octet indicating the
   selected security layer ("server_qop"), which should be one of those
   indicated in the bit-mask received from the client (but may be
   different if the server would abort authentication here and want to
   give the client a chance to use a different security method), three
   octets encoding, in network byte order, an integer indicating the
   maximum buffer size ("server_maxbuf") that the server can receive
   (set to 0 if no integrity or privacy layer is requested), and the
   remaining octets containing the UTF-8 [6] encoded authorization
   identity ("authzid") which may be empty.  The server must verify that
   the src_name identity is authorized to authenticate as the
   authorization identity.  After these verifications, the
   authentication process is complete.

   The server must validate the GSS_Wrap token it receive from the
   client.  If the resulting cleartext received from GSS_Unwrap is
   shorter than 4 octets, the server fails the negotiation.  The server
   verifies that the server maximum buffer is 0 if the server doesn't
   advertise support for any security layer.


5.  SPNEGO

   Use of The Simple and Protected GSS-API Negotiation Mechanism [10]
   (SPNEGO) underneath SASL introduces subtle interoperability problems
   and security considerations.  To address these, this section places
   additional requirements on implementations which support SPNEGO



Josefsson                 Expires May 21, 2006                 [Page 13]

Internet-Draft                 SASL GS2-*                  November 2005


   underneath SASL.

   A client which supports, for example, the Kerberos V5 GSSAPI
   mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL
   mechanism will not interoperate with a server which supports the
   Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL
   mechanism.  A client that only support Kerberos V5 underneath "GSS-
   SPNEGO" will not interoperate with a server that only support
   Kerberos V5 in the GS2 mechanism and the GS2 SPNEGO mechanism.

   Since SASL is capable of negotiating amongst GSSAPI mechanisms, the
   only reason for a server or client to support the "GSS-SPNEGO"
   mechanism is to allow a policy of only using mechanisms below a
   certain strength if those mechanism's negotiation is protected.  In
   such a case, a client or server would only want to negotiate those
   weaker mechanisms through SPNEGO.  In any case, there is no down-
   negotiation security consideration with using the strongest mechanism
   and set of options the implementation supports, so for
   interoperability that mechanism and set of options MUST be negotiable
   without using the "GSS-SPNEGO" or the GS2 SPNEGO mechanism.

   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 the "GSS-SPNEGO" or the GS2 SPNEGO
   mechanism, it may end up using mechanism Z when it should have used
   mechanism Y. For this reason, implementations MUST exclude from
   SPNEGO those GSSAPI mechanisms which are weaker than the strongest
   non-GSSAPI SASL mechanism advertised by the server.

   The situation is complicated by the fact that SPNEGO may be
   negotiated through both the "GSS-SPNEGO" mechanism and the GS2 SPNEGO
   mechanism.  Because all the functionality in the "GSSAPI" and "GSS-
   SPNEGO" mechanisms are available through the GS2 mechanism, and the
   GS2 family in addition also offer channel bindings and round-trip
   optimizations, it is expected that migration to the GS2 family will
   eventually happen.


6.  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 May 21, 2006                 [Page 14]

Internet-Draft                 SASL GS2-*                  November 2005


     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:
       The Kerberos V5 and SPNEGO mechanisms are also supported
       through the GSSAPI and GSS-SPNEGO mechanisms, respectively.


7.  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 [15] 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.
   3.  The SPNEGO mechanism can be used securely negotiate among GSS-API
       mechanisms.  This solution can only be used if all the SASL
       mechanisms are GSS-API mechanisms.

   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.

   SPNEGO [10] has protection against many of these down-negotiation
   attacks, SASL does not itself have such protection.  The section
   titled "SPNEGO" mentions considerations of choosing negotiation
   through SASL versus SPNEGO.



Josefsson                 Expires May 21, 2006                 [Page 15]

Internet-Draft                 SASL GS2-*                  November 2005


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


8.  Acknowledgements

   This document is a revision of RFC 2222 written by John G. Myers.  He
   also contributed significantly to this revision.  This version was
   derived from draft-ietf-sasl-gssapi-02 which was prepared by Alexey
   Melnikov.

   Contributions of many members of the SASL mailing list are gratefully
   acknowledged.


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


10.  References

10.1.  Normative References

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



Josefsson                 Expires May 21, 2006                 [Page 16]

Internet-Draft                 SASL GS2-*                  November 2005


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

   [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",
        RFC 3548, July 2003.

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

10.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]  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 May 21, 2006                 [Page 17]

Internet-Draft                 SASL GS2-*                  November 2005


Author's Address

   Simon Josefsson

   Email: simon@josefsson.org














































Josefsson                 Expires May 21, 2006                 [Page 18]

Internet-Draft                 SASL GS2-*                  November 2005


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 (2005).  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 May 21, 2006                 [Page 19]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/