[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                                            March 29, 2007
Intended status: Standards Track
Expires: September 30, 2007


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

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 September 30, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).














Josefsson              Expires September 30, 2007               [Page 1]

Internet-Draft                 SASL GS2-*                     March 2007


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.  This is done by
   defining a new SASL mechanism family, called GS2.  This mechanism
   family offers a number of improvements over the previous SASL/GSS-API
   mechanism: it is more general, uses fewer messages for the
   authentication phase in some cases, and supports a SASL-specific
   notion of channel binding.

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







































Josefsson              Expires September 30, 2007               [Page 2]

Internet-Draft                 SASL GS2-*                     March 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
   3.  Mechanism name . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Generating SASL mechanism names from GSS-API OIDs  . . . .  6
     3.2.  Computing mechanism names manually . . . . . . . . . . . .  6
     3.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  SASL Authentication Exchange Message Format  . . . . . . . . .  8
     4.1.  SASL Messages  . . . . . . . . . . . . . . . . . . . . . .  8
     4.2.  Context Token Field  . . . . . . . . . . . . . . . . . . .  9
       4.2.1.  Client side  . . . . . . . . . . . . . . . . . . . . .  9
       4.2.2.  Server side  . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 11
       4.3.1.  The GS2_Wrap function  . . . . . . . . . . . . . . . . 12
       4.3.2.  Client first GS2_Wrap input  . . . . . . . . . . . . . 12
       4.3.3.  Server last GS2_Wrap input . . . . . . . . . . . . . . 13
       4.3.4.  Server first GS2_Wrap input  . . . . . . . . . . . . . 13
       4.3.5.  Client last GS2_Wrap input . . . . . . . . . . . . . . 14
   5.  Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 15
   6.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Authentication Conditions  . . . . . . . . . . . . . . . . . . 20
   8.  GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 21
   9.  Security Layer Bits  . . . . . . . . . . . . . . . . . . . . . 22
     9.1.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . 22
   10. Non-integrity capable GSS-API mechanisms . . . . . . . . . . . 24
   11. Interoperability with the SASL "GSSAPI" mechanism  . . . . . . 25
     11.1. The interoperability problem . . . . . . . . . . . . . . . 25
     11.2. Resolving the problem  . . . . . . . . . . . . . . . . . . 25
     11.3. Additional recommendations . . . . . . . . . . . . . . . . 25
   12. Mechanisms that negotiate other mechanisms . . . . . . . . . . 26
     12.1. The interoperability problem . . . . . . . . . . . . . . . 26
     12.2. Security problem . . . . . . . . . . . . . . . . . . . . . 26
     12.3. Resolving the problems . . . . . . . . . . . . . . . . . . 26
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   14. Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
   16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     16.1. Normative References . . . . . . . . . . . . . . . . . . . 31
     16.2. Informative References . . . . . . . . . . . . . . . . . . 31
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33
   Intellectual Property and Copyright Statements . . . . . . . . . . 34









Josefsson              Expires September 30, 2007               [Page 3]

Internet-Draft                 SASL GS2-*                     March 2007


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" [10] is also supported in SASL
   through "SASL GSSAPI mechanisms" [12].  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 [11]), see the section
   "Mechanisms that negotiate other mechanisms" below.

   There are interoperability and security concerns with GSSAPI
   mechanism that do not provide integrity, see the section "Non-
   integrity capable GSS-API 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.













Josefsson              Expires September 30, 2007               [Page 4]

Internet-Draft                 SASL GS2-*                     March 2007


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














































Josefsson              Expires September 30, 2007               [Page 5]

Internet-Draft                 SASL GS2-*                     March 2007


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 [6] (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], including the tag and
   length octets, 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.  Examples

   The OID for the SPKM-1 mechanism [13] is 1.3.6.1.5.5.1.1.  The ASN.1
   DER encoding of the OID, including the tag and length, is (in hex) 06
   07 2b 06 01 05 05 01 01.  The SHA-1 hash of the ASN.1 DER encoding is
   (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad.
   Convert the first ten octets to binary, and re-group them in groups
   of 5, and convert them back to decimal, which results in these
   computations:

   hex:
   1c f8 f4 2b 5a 9f 80 fa e9 f8

   binary:
   00011100 11111000 11110100 00101011 01011010
   10011111 10000000 11111010 11101001 11111000

   binary in groups of 5:
   00011 10011 11100 01111 01000 01010 11010 11010
   10011 11110 00000 01111 10101 11010 01111 11000

   decimal of each group:
   3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24

   base32 encoding:



Josefsson              Expires September 30, 2007               [Page 6]

Internet-Draft                 SASL GS2-*                     March 2007


   D T 4 P I K 2 2 T 6 A P V 2 P Y

   The last step translate each decimal value using table 3 in Base32
   [6].  Thus the SASL mechanism name for the SPKM-1 GSSAPI mechanism is
   "GS2-DT4PIK22T6APV2PY".

   The OID for the Kerberos V5 GSS-API mechanism [10] is
   1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
   86 F7 12 01 02 02.  The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
   93 25 51 6a fc ff 04 b0 43 60.  Convert the first ten octets to
   binary, and re-group them in groups of 5, and convert them back to
   decimal, which results in these computations:

   hex:
   82 d2 73 25 76 6b d6 c8 45 aa

   binary:
   10000010 11010010 01110011 00100101 01110110
   01101011 11010110 11001000 01000101 10101010

   binary in groups of 5:
   10000 01011 01001 00111 00110 01001 01011 10110
   01101 01111 01011 01100 10000 10001 01101 01010

   decimal of each group:
   16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10

   base32 encoding:
   Q L J H G J L W N P L M Q R N K

   The last step translate each decimal value using table 3 in Base32
   [6].  Thus the SASL mechanism name for the Kerberos V5 GSSAPI
   mechanism is "GS2-QLJHGJLWNPLMQRNK".


















Josefsson              Expires September 30, 2007               [Page 7]

Internet-Draft                 SASL GS2-*                     March 2007


4.  SASL Authentication Exchange Message Format

4.1.  SASL Messages

   During the SASL authentication exchange for GS2, a number of messages
   following the following format is sent between the client and server.

                           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                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Wrap token length                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               /
      /                        [Context token]                        /
      /                                           --------------------/
      /                     ---------------------/                    /
      /--------------------/                                          /
      /                          [Wrap token]                         /
      /                                                               /
      /                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The "Context length" and "Wrap token length" fields each contain a 4
   octet (32 bit) integer encoded in network byte order, that indicate
   the length of the "Context token" and "Wrap token" fields,
   respectively.  A length of 0 means that a particular field is not
   present.

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

   The "Wrap token" field, if present, contain the output generated by
   the GS2_Wrap function.

   The fields need not be aligned to 32-bit a boundary.  There is no
   padding between fields.

   Messages shorter than or equal to 8 octets are invalid.  From that it
   follows that at least one of the "Context token length" and the "Wrap
   token length" integers MUST be non-zero in a particular message.  If
   the sum of the length integers is longer than the entire message
   size, minus 8 octets for the length fields, the message is invalid.

   During any successful authentication exchange, the client and server
   will each send exactly one (non-empty) "Wrap token".



Josefsson              Expires September 30, 2007               [Page 8]

Internet-Draft                 SASL GS2-*                     March 2007


   Conforming implementations MUST NOT send additional data after the
   above message syntax, and MUST ignore additional data.  To
   illustrate, implementations MUST NOT assume that the last "Wrap token
   length" octets of the packet correspond to the "Wrap token", because
   that would be incorrect if the packet contained additional data not
   described by this document.

4.2.  Context Token Field

   The format of the "Context token" field inside the SASL token is
   defined by each GSS-API mechanism, and the data is computed by (for
   the client) GSS_Init_sec_context and (for the server)
   GSS_Accept_sec_context.

4.2.1.  Client side

   The client calls GSS_Init_sec_context, passing in
   input_context_handle of GSS_C_NO_CONTEXT (initially), mech_type of
   the GSSAPI mechanism for which this SASL mechanism is registered, the
   chan_binding is set to NULL, 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.

   (*) - Clients MAY use name types other than
   GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but
   only when they have a priori knowledge that the servers support
   alternate name types.  Otherwise clients MUST use
   GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names.

   When calling the GSS_Init_sec_context the client SHOULD pass the
   integ_req_flag of TRUE, but MAY set it to FALSE (see section 10
   below).  If the client intends to request a security layer, it MUST
   also supply to the GSS_Init_sec_context a mutual_req_flag of TRUE,
   and a sequence_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 responds with any resulting output_token.

   If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the
   client expect the server to issue a token in a subsequent challenge
   or as additional information to the outcome of the authentication.
   The client pass the context token to another call to
   GSS_Init_sec_context, repeating the procedure, until GSS_S_COMPLETE
   is returned or authentication is aborted.



Josefsson              Expires September 30, 2007               [Page 9]

Internet-Draft                 SASL GS2-*                     March 2007


   If the server sent a (non-empty) "Wrap token", the context token is
   processed before processing the other tokens.  This is required
   because GSS_Unwrap may need the context to be in the state it is
   after the "Context token" in the message has been processed.

   When GSS_Init_sec_context returns GSS_S_COMPLETE, the client MUST
   examine the context to ensure that it provides a level of protection
   permitted by the client's security policy.

4.2.2.  Server side

   The server passes the first context token to GSS_Accept_sec_context
   as input_token, setting input_context_handle to GSS_C_NO_CONTEXT
   (initially), the chan_binding set to NULL, and a suitable
   acceptor_cred_handle (see below).

   Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
   or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
   GSS-API mechanism for which this SASL mechanism is registered (*).
   Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle.
   Servers MAY use a credential obtained by calling GSS_Acquire_cred or
   GSS_Add_cred for the server's principal name(s) (**) and the GSS-API
   mechanism for which this SASL mechanism is registered.

   (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
   GSS-API mechanism as an input parameter.  The OID set can be created
   by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member.  It can
   be freed by calling the GSS_Release_oid_set.

   (**) - Use of server's principal names having
   GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
   where "service" is the service name specified in the protocol's
   profile, and "hostname" is the fully qualified host name of the
   server, is RECOMMENDED.  The server name can be generated by calling
   GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE
   and input_name_string of "service@hostname".

   The server then responds with any resulting output_token.

   The server pass any resulting challenge from the client to another
   call to GSS_Accept_sec_context, repeating the procedure, until
   GSS_S_COMPLETE is returned or authentication is aborted.

   If the client sent a (non-empty) "Wrap token", the context token is
   processed first.

   Upon successful establishment of the security context (i.e.
   GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD



Josefsson              Expires September 30, 2007              [Page 10]

Internet-Draft                 SASL GS2-*                     March 2007


   verify that the negotiated GSS-API mechanism is indeed the registered
   one.  This is done by examining the value of the mech_type parameter
   returned from the GSS_Accept_sec_context call.  If the value differ,
   the SASL authentication MUST be aborted.

   Upon successful establishment of the security context and if the
   server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor
   credential handle, the server SHOULD also check using the
   GSS_Inquire_context that the target_name used by the client matches:

   - the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
   where "service" is the service name specified in the application
   protocol's profile, and "hostname" is the fully qualified host name
   of the server.

   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server MUST
   examine the context to ensure that it provides a level of protection
   permitted by the server's security policy.

4.3.  Wrap Token Field

   The Wrap token field MUST NOT be sent or received before the
   PROT_READY flag is 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 Wrap token field
   does not have to be present directly when the PROT_READY flag is set.
   During any exchange, exactly one Wrap token field is sent in each
   direction.  The GS2_Wrap function is defined below, and its inputs
   MUST follow the format described below.  If not exactly one 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, or for GSS-API mechanism that do not provide per-message
   protection.  This may result in a SASL token consisting of a context
   token length of 0 and a Wrap token.

   The entity that sends the first Wrap token will have to specify a
   bitmap of supported and preferred quality of protection schemes.  The
   entity that replies to the Wrap tokens will pick a scheme, based on
   the bitmask and local policy.  The quality of protection values are
   defined in section 9.

   Two pairs of input formats to the GS2_Wrap function are defined.  The
   first pair is used when the client sends the Wrap token first and the
   server responds.  The other pair is used when the server sends the



Josefsson              Expires September 30, 2007              [Page 11]

Internet-Draft                 SASL GS2-*                     March 2007


   Wrap token first and the client responds.

   The inputs below are passed to GS2_Wrap, and the output is used as
   the Wrap token value.

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

4.3.1.  The GS2_Wrap function

   The GS2_Wrap function have two implementations, and which one is used
   depends on whether the negotiated GSS-API context supports per-
   message protection.  When a context is successfully negotiated (i.e.,
   when GSS_S_COMPLETE is returned from, for clients,
   GSS_Init_sec_context, or, for servers, GSS_Accept_sec_context) and
   the output variable integ_avail is FALSE, then GSS_Wrap cannot be
   used and instead we define GS2_Wrap to be the identity function.
   When integ_avail is negotiated TRUE, the GS2_Wrap is identical to
   calling the GSS_Wrap function with conf_flag set to FALSE and using
   the generated output_message as the output data.

4.3.2.  Client first GS2_Wrap input

   The input to GS2_Wrap when the client sends a Wrap token field 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  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 quality of protection values are defined
   in section 9.

   The "client_maxbuf" field indicate the maximum protected buffer size
   the client can receive in network byte order.  It MUST be 0 if the
   client doesn't advertise support for any security layer, the server
   MUST verify this.  Small values can make it impossible for the server
   to send any protected message to the client, due to the overhead



Josefsson              Expires September 30, 2007              [Page 12]

Internet-Draft                 SASL GS2-*                     March 2007


   added by GSS_Wrap, and the server MAY reject the authentication if it
   detects this situation.

   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 quality of protection values are defined in section 9.

   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 [5].  The authorization
   identity is not terminated with the NUL (U+0000) character.  Servers
   MUST validate that the authorization identity is valid UTF-8.

4.3.3.  Server last GS2_Wrap input

   The input to GS2_Wrap when the server sends a Wrap token field, after
   receiving the Wrap token in the previous section from the client, 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
   protection.  The quality of protection values are defined in section
   9.

   The "server_maxbuf" field indicate the maximum protected data buffer
   size the server can receive in network byte order.  It MUST be 0 if
   the server doesn't advertise support for any security layer, the
   client MUST verify this.  Small values can make it impossible for the
   client to send any protected message to the server, due to the
   overhead added by GSS_Wrap, and the client MAY reject the
   authentication if it detects this situation.

4.3.4.  Server first GS2_Wrap input

   The input to GS2_Wrap when the server sends the Wrap token first is
   as follows.



Josefsson              Expires September 30, 2007              [Page 13]

Internet-Draft                 SASL GS2-*                     March 2007


                           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                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |[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 quality of protection
   values are defined in section 9.

   The "server_maxbuf" is the same as above.

   The optional field "server_cbqops" indicate the server's preferred
   quality of protection if channel binding negotiation succeeds.  The
   quality of protection values are defined in section 9.

   The optional field "channel_binding_data" contain the actual channel
   binding data.

4.3.5.  Client last GS2_Wrap input

   The input to GS2_Wrap when the clients sends a Wrap token field,
   after receiving the Wrap token in the previous section from the
   server, 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  client_qop   |               client_maxbuf                   |
      /             [authzid]                                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The "client_qop" field is the selected quality of protection.  The
   quality of protection values are defined in section 9.

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












Josefsson              Expires September 30, 2007              [Page 14]

Internet-Draft                 SASL GS2-*                     March 2007


5.  Channel Bindings

   The GS2 mechanism provide its own channel binding mechanism, instead
   of using the "chan_binding" parameter in the GSS-API context
   functions.  The reason for this is that the GS2 mechanism 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 do not match.

   Client and servers MUST set the "chan_binding" parameter in the calls
   to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to
   NULL.

   Implementations SHOULD set the "client_cbqops" and "server_cbqops" to
   no security layer and instead depend on the session security afforded
   by the bound-in channel.

   Use of no SASL security layers in combination with channel binding
   should provide better performance than using SASL security layers
   over secure channels, and better security characteristics than using
   no SASL security layers over secure channels without channel binding.

   For more discussions of channel bindings, and the syntax of the
   channel binding data for various security protocols, see [8].  For
   easy reference, the channel binding format used for The Transport
   Layer Security (TLS) Protocol [14] is specified in [16].

























Josefsson              Expires September 30, 2007              [Page 15]

Internet-Draft                 SASL GS2-*                     March 2007


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 informal pseudo-language is used to describe the packets sent
   below.  GS2_Wrap refer to the operation of calling GS2_Wrap on the
   indicated fields, formatted in the structures described earlier.
   GSS_Init_sec_context and GSS_Accept_sec_context refer to the context
   token generated by calling the respective function.  The GS2 SASL
   Message is denoted as [Context_token, Wrap_token], and the length
   fields are not mentioned.

   An authentication exchange using GS2 may look like:

         C: Request authentication exchange
         S: Send ["", ""] token
         C: Send [GSS_Init_sec_context, ""] token
         ...
         S: After PROT_READY is set,
            send [GSS_Accept_sec_context,
                  GS2_Wrap(server_qops | server_maxbuf]
         ...
         C: After PROT_READY is set,
            send [GSS_Init_sec_context,
                  GS2_Wrap (client_qop | client_maxbuf | authzid)]
         S: Send [GSS_Accept_sec_context, ""] token
         C: Send [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 does not support additional information to
   be sent together with the authentication request.

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









Josefsson              Expires September 30, 2007              [Page 16]

Internet-Draft                 SASL GS2-*                     March 2007


         C: Request authentication exchange
         S: Send ["", ""] token
         C: Send [GSS_Init_sec_context, ""] token
         ...
         C: After PROT_READY is set,
            send [GSS_Init_sec_context,
                  GS2_Wrap(client_qops | client_maxbuf |
                           channel_binding_length=0 | authzid)]
         ...
         S: After PROT_READY is set,
            send [GSS_Accept_sec_context,
                  GS2_Wrap (server_qop | server_maxbuf)]
         C: Send [GSS_Init_sec_context, ""] token
         S: Send [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:

         C: Request authentication exchange and
            send [GSS_Init_sec_context, ""] token
         S: Send [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 [GSS_Init_sec_context, ""] token
         S: Send [GSS_Accept_sec_context, ""] token
         ...
         C: Send [GSS_Init_sec_context, ""] token
         S: Indicate successful authentication and
            send [GSS_Accept_sec_context, ""] token
            as additional information.

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








Josefsson              Expires September 30, 2007              [Page 17]

Internet-Draft                 SASL GS2-*                     March 2007


         C: Request authentication exchange
         ...
         S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs
            a token, send ["", GS2_Wrap(server_qops | server_maxbuf)]
         C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not
            output a token, send
            ["", GS2_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 ["", GS2_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 ["", GS2_Wrap(server_qop | server_maxbuf |
                                            channel_binding_length=0)]
      S: Outcome of authentication exchange

   Adding channel bindings to the last examples, gives the following
   complex situation.  Here the client request confidentiality for the
   application data if channel binding fails but no SASL security layer
   if channel binding negotiation succeeds:

         C: Request authentication exchange
         ...
         C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a
            token, send [GSS_Init_sec_context,
                    GS2_Wrap(client_qops=0x04 | client_maxbuf |
                             channel_binding_length=n |
                             client_cbqops=0x01 | channel_binding_data |
                             authzid)]
         S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not
            output a token, send ["",
                                  GS2_Wrap(server_qop | server_maxbuf |
                                           channel_binding_length=0)]
         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.





Josefsson              Expires September 30, 2007              [Page 18]

Internet-Draft                 SASL GS2-*                     March 2007


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

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








































Josefsson              Expires September 30, 2007              [Page 19]

Internet-Draft                 SASL GS2-*                     March 2007


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

























Josefsson              Expires September 30, 2007              [Page 20]

Internet-Draft                 SASL GS2-*                     March 2007


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 September 30, 2007              [Page 21]

Internet-Draft                 SASL GS2-*                     March 2007


9.  Security Layer Bits

   The fields "client_qops", "server_qops", "client_cbqops", and
   "server_cbqops" are bit-fields that encode a set of requested quality
   of protection.  The fields "client_qop" and "server_qop" encode a
   single quality of protection value.

   The "client_qop" and "server_qop" will contains the chosen security
   layer.

   Note that "client_qop" and "server_qop" MAY indicate a quality of
   protection that was not offered by the server and client,
   respectively.  This SHOULD only be used when the server or client
   (respectively) would otherwise fail the entire authentication
   exchange.  The server/client that receives a "client_qop"/
   "server_qop" MUST verify that it corresponds to an acceptable
   security level.

   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.

   When decoding any received data with GSS_Unwrap the major_status
   other than the GSS_S_COMPLETE MUST be treated as a fatal error.

   For integrity and confidentiality protection, GS2 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.

9.1.  Examples

   When no security layer is negotiated the octet will encode an integer
   1 as follows.

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |0|0|0|0|0|0|0|1|
      +-+-+-+-+-+-+-+-+

   When integrity is negotiated the octet will encode an integer 2 as



Josefsson              Expires September 30, 2007              [Page 22]

Internet-Draft                 SASL GS2-*                     March 2007


   follows.

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |0|0|0|0|0|0|1|0|
      +-+-+-+-+-+-+-+-+

   When confidentiality is negotiated the octet will encode an integer 4
   as follows.

       0 1 2 3 4 5 6 7
      +-+-+-+-+-+-+-+-+
      |0|0|0|0|0|1|0|0|
      +-+-+-+-+-+-+-+-+





































Josefsson              Expires September 30, 2007              [Page 23]

Internet-Draft                 SASL GS2-*                     March 2007


10.  Non-integrity capable GSS-API mechanisms

   Mechanisms that do not support integrity can be used with GS2, but
   some security features cannot be provided, in particular including
   channel bindings, security layers, and integrity protection of the
   authorization identity.

   Channel bindings and security layers MUST NOT be negotiated when the
   GSS-API mechanism do not support integrity.  It should also be
   understood that the authorization identity is not integrity
   protected.

   Whether a mechanism supports integrity or not, for the purpose of
   GS2, is decided by whether the integ_avail output variable from
   GSS_Init_sec_context (for clients) and GSS_Accept_sec_context (for
   servers).  If integ_avail is FALSE, integrity is not supported.

   There is a potential interoperability problem if a client call
   GSS_Init_sec_context with integ_req_flag of TRUE and the context
   negotiation fails because the mechanism (due to design, the
   capability of the credentials, or policy) cannot provide per-message
   protection.  Calling GSS_Init_sec_context with a FALSE integ_req_flag
   instead is not optimal, since a mechanism may then negotiate less
   security than it would have otherwise done.

   It is RECOMMENDED that implementations only ever call
   GSS_Init_sec_context with a integ_req_flag of FALSE when it knows
   that the particular GSS-API mechanism will not be able to negotiate
   per-message protection services.

   Implementations MAY have a policy to disallow non-integrity capable
   mechanisms, and always call GSS_Init_sec_context with the
   integ_req_flag set to TRUE.


















Josefsson              Expires September 30, 2007              [Page 24]

Internet-Draft                 SASL GS2-*                     March 2007


11.  Interoperability with the SASL "GSSAPI" mechanism

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

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

11.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 [18].

11.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 September 30, 2007              [Page 25]

Internet-Draft                 SASL GS2-*                     March 2007


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

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

12.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 ideally should have used mechanism Y. For this reason, the
   use of GSS-API mechanisms that negotiate other mechanisms are
   disallowed under GS2.

12.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 [11] under GS2.

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


















Josefsson              Expires September 30, 2007              [Page 26]

Internet-Draft                 SASL GS2-*                     March 2007


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

     Subject: Registration of SASL mechanism GS2-*
     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.



































Josefsson              Expires September 30, 2007              [Page 27]

Internet-Draft                 SASL GS2-*                     March 2007


14.  Security Considerations

   The security provided by GS2 depends on the security provided by the
   GSS-API mechanism.  If the mechanism do not provide integrity
   protection, the authorization identity can be replaced by a man in
   the middle, and channel bindings and security layers cannot be
   negotiated.  Therefor, it is generally recommended against using any
   GSS-API mechanism widely on the Internet that do not support
   integrity.

   Because the negotiation of a particular 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.  This is a generic design critera for the GSS-API
   mechanisms used under GS2.

   When a server or client supports multiple GSS-API 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 [14].  To
       protect against certain tunnel attacks [18], the GSS-API
       mechanism need to support integrity to provide support for
       channel bindings.

   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.  This solution, however, is not guaranteed
       to lead to the most secure mechanism supported by both parties,
       and is therefor only recommended as an additional precaution.

   3.  Specify how to use the SPNEGO mechanism in SASL.

   The channel binding is sent without privacy protection and knowledge
   of it is assumed to provide no advantage to an attacker.  This is a
   property that has to be considered when specifying channel bindings
   for a security protocol that will be used with GS2.

   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, such as the Domain Name



Josefsson              Expires September 30, 2007              [Page 28]

Internet-Draft                 SASL GS2-*                     March 2007


   System [9] without DNSSEC [15].

   The GS2 protocol hard code the SHA-1 algorithm for computing the
   mechanism names.  It is not possible to negotiate another hash
   algorithm.  However, no traditional cryptographic hash properties
   (such as collision resistance or pre-image resistance) are required
   nor assumed.  The required and assumed property is that it is
   statistically unlikely that two different DER-encoded OID's share the
   same first 10 octets of the SHA-1 value.  It is possible to
   practically confirm that the SHA-1 algorithm has the necessary
   property, by testing many different inputs.

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

































Josefsson              Expires September 30, 2007              [Page 29]

Internet-Draft                 SASL GS2-*                     March 2007


15.  Acknowledgements

   The history of GS2 can be traced to the GSSAPI mechanism described in
   RFC 2222.  The GSSAPI mechanism had some drawbacks, which created a
   need for an improved version.  This document was derived from
   draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
   significant contributions from John G. Myers, although the majority
   of this document has been rewritten by the current author.

   Contributions of many members of the SASL mailing list are gratefully
   acknowledged.  In particular, ideas and feedback from Sam Hartman,
   Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu
   improved the document and the protocol.






































Josefsson              Expires September 30, 2007              [Page 30]

Internet-Draft                 SASL GS2-*                     March 2007


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]   Melnikov, A. and K. Zeilenga, "Simple Authentication and
         Security Layer (SASL)", RFC 4422, June 2006.

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

   [4]   National Institute of Standards and Technology, "Secure Hash
         Standard", FIPS PUB 180-1, April 1995,
         <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.

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

   [6]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
         RFC 4648, October 2006.

   [7]   International Telecommunications Union, "Information Technology
         - ASN.1 encoding rules: Specification of Basic Encoding Rules
         (BER), Canonical Encoding Rules (CER) and Distinguished
         Encoding Rules (DER)", ITU-T Recommendation X.690, 1994.

   [8]   Williams, N., "On the Use of Channel Bindings to Secure
         Channels", draft-williams-on-channel-binding-00 (work in
         progress), August 2006.

16.2.  Informative References

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

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

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

   [12]  Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication
         and Security Layer (SASL) Mechanism", RFC 4752, November 2006.




Josefsson              Expires September 30, 2007              [Page 31]

Internet-Draft                 SASL GS2-*                     March 2007


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

   [14]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
         Protocol Version 1.1", RFC 4346, April 2006.

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

   [16]  Altman, J. and N. Williams, "On the Use of Channel Bindings to
         Secure Channels", draft-altman-tls-channel-bindings-01 (work in
         progress), December 2006.

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

   [18]  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 September 30, 2007              [Page 32]

Internet-Draft                 SASL GS2-*                     March 2007


Author's Address

   Simon Josefsson

   Email: simon@josefsson.org














































Josefsson              Expires September 30, 2007              [Page 33]

Internet-Draft                 SASL GS2-*                     March 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).





Josefsson              Expires September 30, 2007              [Page 34]


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