One document matched: draft-ietf-sasl-gs2-20.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1034 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml'>
<!ENTITY rfc1964 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1964.xml'>
<!ENTITY rfc2025 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2025.xml'>
<!ENTITY rfc2104 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2104.xml'>
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2222 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2222.xml'>
<!ENTITY rfc2743 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2743.xml'>
<!ENTITY rfc3629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
<!ENTITY rfc4033 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4033.xml'>
<!ENTITY rfc4121 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4121.xml'>
<!ENTITY rfc4178 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4178.xml'>
<!ENTITY rfc4422 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4422.xml'>
<!ENTITY rfc4648 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml'>
<!ENTITY rfc4752 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4752.xml'>
<!ENTITY rfc5056 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5056.xml'>
<!ENTITY rfc5234 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml'>
<!ENTITY rfc5246 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml'>
<!ENTITY rfc5554 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5554.xml'>
<!ENTITY rfc5587 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5587.xml'>
<!ENTITY fips180 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml2/reference.FIPS.180-1.1995.xml'>
<!ENTITY x690 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml2/reference.CCITT.X690.2002.xml'>
<!ENTITY SCRAM PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sasl-scram.xml'>
<!ENTITY TLSCB PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.altman-tls-channel-bindings.xml'>
]>
<?rfc compact="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<rfc category="std" ipr="pre5378Trust200902"
docName="draft-ietf-sasl-gs2-20">
<front>
<title abbrev="SASL GS2-*">
Using GSS-API Mechanisms in SASL:
The GS2 Mechanism Family
</title>
<author initials="S." surname="Josefsson" fullname="Simon Josefsson">
<organization>SJD AB</organization>
<address>
<postal>
<street>Hagagatan 24</street>
<city>Stockholm</city>
<code>113 47</code>
<country>SE</country>
</postal>
<email>simon@josefsson.org</email>
<uri>http://josefsson.org/</uri>
</address>
</author>
<author initials='N.' surname="Williams" fullname='Nicolas
Williams'>
<organization>Sun
Microsystems</organization>
<address>
<postal>
<street>5300
Riata
Trace
Ct</street>
<city>Austin</city>
<region>TX</region>
<code>78727</code>
<country>USA</country>
</postal>
<email>Nicolas.Williams@sun.com</email>
</address>
</author>
<date month="January" year="2010"/>
<abstract>
<t>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/GSSAPI" mechanism: it is more general, uses fewer
messages for the authentication phase in some cases, and
supports negotiable use of channel binding. Only
GSS-API mechanisms that support channel binding are
supported.</t>
</abstract>
</front>
<middle>
<section anchor="intro"
title="Introduction">
<t>Generic Security Service Application Program Interface
(GSS-API) <xref target="RFC2743"/> is a framework that
provides security services to applications using a
variety of authentication mechanisms. Simple
Authentication and Security Layer (SASL)
<xref target="RFC4422"/> is a framework to provide
authentication and security layers for connection
based protocols, also using a variety of mechanisms.
This document describes how to use a GSS-API mechanism
as though it were a SASL mechanism. This facility is
called GS2 -- a moniker that indicates that this is
the second GSS-API->SASL mechanism bridge. The
original GSS-API->SASL mechanism bridge was
specified by <xref target='RFC2222'/>, now
<xref target='RFC4752'/>; we shall sometimes refer to
the original bridge as GS1 in this document.</t>
<t>All GSS-API mechanisms are implicitly registered for
use within SASL by this specification. The SASL
mechanisms defined in this document are known as the
GS2 family of mechanisms.</t>
<t>The GS1 bridge failed to gain wide deployment for any
GSS-API mechanism other than "The Kerberos V5 GSS-API
mechanism" <xref target="RFC1964"/>
<xref target="RFC4121"/>, and has a number of problems
that led us to desire a new bridge. Specifically: a)
GS1 was not round-trip optimized, b) GS1 did not support
channel binding <xref target='RFC5056'/>. These
problems and the opportunity to create the next SASL
password-based mechanism,
<xref target='I-D.ietf-sasl-scram'>Salted Challenge
Response (SCRAM) SASL and GSS-API Mechanism</xref>, as
a GSS-API mechanism used by SASL applications via GS2,
provide the motivation for GS2.</t>
<t>In particular, the current consensus of the SASL
community appears to be that SASL "security layers"
(i.e., confidentiality and integrity protection of
application data after authentication) are too complex
and redundant because SASL applications tend to have an
option to run over a Transport Layer Security (TLS)
<xref target='RFC5246'/> channel. Use of SASL security
layers is best replaced with channel binding to a TLS
channel.</t>
<t>GS2 is designed to be as simple as possible. It adds
to GSS-API security context token exchanges only the
bare minimum to support SASL semantics and negotiation
of use of channel binding. Specifically, GS2 adds a
small header (a few bytes plus the length of the
client requested SASL authorization identity) to the
initial GSS-API context token and to the application
channel binding data. GS2 uses SASL mechanism
negotiation to implement channel binding negotiation.
All GS2 plaintext is protected via the use of GSS-API
channel binding. Additionally, to simplify the
implementation of GS2 mechanisms for implementors who
will not implement a GSS-API framework, we compress
the initial security context token header required by
<xref target='RFC2743'/> (see section 3.1).</t>
</section>
<section title="Conventions used in this document">
<t>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
<xref target="RFC2119" />.</t>
<t>The document uses many terms and function names defined
in <xref target="RFC2743" /> as updated by
<xref target="RFC5554" />.</t>
</section>
<section anchor="mechname"
title="Mechanism name">
<t>There are two SASL mechanism names for any GSS-API
mechanism used through this facility. One denotes that
the server supports channel binding. The other denotes
that it does not.</t>
<t>The SASL mechanism name for a GSS-API mechanism is that
which is provided by that mechanism when it was specified,
if one was specified. This name denotes that the server
does not support channel binding. Add the suffix "-PLUS"
and the resulting name denotes that the server does
support channel binding. SASL implementations can use the
GSS_Inquire_SASLname_for_mech call (see below) to query
for the SASL mechanism name of a GSS-API mechanism.</t>
<t>If the GSS_Inquire_SASLname_for_mech interface is not
used, the GS2 implementation needs some other mechanism to
map mechanism OIDs to SASL names internally. In this
case, the implementation can only support the mechanisms
for which it knows the SASL name. If the
GSS_Inquire_SASLname_for_mech call fails, and the GS2
implementation cannot map the OID to a SASL mechanism name
using some other means, it cannot use the particular
GSS-API mechanism since it does not know its SASL
mechanism name.</t>
<section title="Generating SASL mechanism names from GSS-API OIDs">
<t>For GSS-API mechanisms whose SASL names are not
defined together with the GSS-API mechanism or in
this document, the SASL mechanism name is
concatenation of the string "GS2-" and the <xref
target="RFC4648">Base32 encoding</xref> (with an
upper case alphabet) of the first 55 bits of the
binary <xref target="FIPS.180-1.1995">SHA-1
hash</xref> string computed over the <xref
target="CCITT.X690.2002">ASN.1 DER
encoding</xref>, 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. This name
denotes that the server does not support channel
binding. Add the suffix "-PLUS" and the resulting
name denotes that the server does support channel
binding.</t>
<t>A GS2 mechanism that has a non-OID-derived SASL
mechanism name is said to have a "user friendly SASL
mechanism name".</t>
</section>
<section title="Computing mechanism names manually">
<t>The hash-derived GS2 SASL mechanism name may be
computed manually. This is useful when the set of
supported GSS-API mechanisms is known in advance.
This eliminates 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 be concerned if the
mechanism is part of a mechanism family.</t>
</section>
<section title="Examples">
<t>The OID for the <xref target="RFC2025">SPKM-1
mechanism</xref> 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 7 octets to binary, drop
the last bit, and re-group them in groups of 5, and
convert them back to decimal, which results in these
computations:</t>
<figure>
<artwork>
hex:
1c f8 f4 2b 5a 9f 80
binary:
00011100 11111000 11110100 00101011 01011010
10011111 1000000
binary in groups of 5:
00011 10011 11100 01111 01000 01010 11010 11010
10011 11110 00000
decimal of each group:
3 19 28 15 8 10 26 26 19 30 0
base32 encoding:
D T 4 P I K 2 2 T 6 A
</artwork>
</figure>
<t>The last step translates each decimal value using
table 3 in <xref target="RFC4648">Base32</xref>.
Thus the SASL mechanism name for the SPKM-1 GSSAPI
mechanism is "GS2-DT4PIK22T6A".</t>
<t>The OID for the <xref target="RFC1964">Kerberos V5
GSS-API mechanism</xref> 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 7 octets to binary, drop the last bit,
and re-group them in groups of 5, and convert them
back to decimal, which results in these
computations:</t>
<figure>
<artwork>
hex:
82 d2 73 25 76 6b d6
binary:
10000010 11010010 01110011 00100101 01110110
01101011 1101011
binary in groups of 5:
10000 01011 01001 00111 00110 01001 01011 10110
01101 01111 01011
decimal of each group:
16 11 9 7 6 9 11 22 13 15 11
base32 encoding:
Q L J H G J L W N P L
</artwork>
</figure>
<t>The last step translates each decimal value using
table 3 in <xref target="RFC4648">Base32</xref>.
Thus the SASL mechanism name for the Kerberos V5
GSSAPI mechanism would be "GS2-QLJHGJLWNPL" and
(because this mechanism supports channel binding)
"GS2-QLJHGJLWNPL-PLUS". Instead, the next section
assigns the Kerberos V5 mechanism a non-hash-derived
mechanism name.</t>
</section>
<section anchor="grandfathered-names"
title="Grandfathered mechanism names">
<t>Some older GSS-API mechanisms were not specified with
a SASL GS2 mechanism name. Using a shorter name can
be useful nonetheless. We specify the names
"GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5
mechanism, to be used as if the original specification
documented it. See <xref target='iana' />.</t>
</section>
</section>
<section anchor="messages"
title="SASL Authentication Exchange Message Format">
<t>During the SASL authentication exchange for GS2, a number
of messages following the following format is sent between
the client and server. On success, this number is the
same as the number of context tokens that the GSS-API
mechanism would normally require in order to establish a
security context. On failures, the exchange can be
terminated early by any party.</t>
<t>When using a GS2 mechanism the SASL client is always a
GSS-API initiator and the SASL server is always a GSS-API
acceptor. The client calls GSS_Init_sec_context and the
server calls GSS_Accept_sec_context.</t>
<t>All the SASL authentication messages exchanged are
exactly the same as the security context tokens of the
GSS-API mechanism, except for the initial security context
token.</t>
<t>The client and server MAY send GSS-API error tokens
(tokens output by GSS_Init_sec_context() or
GSS_Accept_sec_context() when the major status code is
other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED). As
this indicates an error condition, after sending the
token, the sending side should fail the
authentication.</t>
<t>The initial security context token is modified as
follows:
<list style='symbols'>
<t>The initial context token header (see section 3.1 of
<xref target='RFC2743'/>) MUST be removed if present.
If the header is not present, the client MUST send a
"gs2-nonstd-flag" flag (see below). On the server
side this header MUST be recomputed and restored prior
to passing the token to GSS_Accept_sec_context, except
when the "gs2-nonstd-flag" is sent.</t>
<t>A GS2 header MUST be prefixed to the resulting
initial context token. This header has the form
"gs2-header" given below in ABNF
<xref target='RFC5234'/>.</t>
</list>
</t>
<t>The figure below describes the permissible attributes,
their use, and the format of their values. All attribute
names are single US-ASCII letters and are
case-sensitive.</t>
<figure>
<artwork type='abnf'>
UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F
;; As UTF8-1 in RFC 3629 except
;; NUL, "=", and ",".
UTF8-2 = <as defined in RFC 3629 (STD 63)>
UTF8-3 = <as defined in RFC 3629 (STD 63)>
UTF8-4 = <as defined in RFC 3629 (STD 63)>
UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4
saslname = 1*(UTF8-char-safe / "=2C" / "=3D")
gs2-authzid = "a=" saslname
;; GS2 has to transport an authzid since
;; the GSS-API has no equivalent
gs2-nonstd-flag = "F"
;; "F" means the mechanism is not a
;; standard GSS-API mechanism in that the
;; RFC2743 section 3.1 header was missing
cb-name = 1*(ALPHA / DIGIT / "." / "-")
;; See RFC 5056 section 7
gs2-cb-flag = ("p=" cb-name) / "n" / "y"
;; GS2 channel binding (CB) flag
;; "p" -> client supports and used CB
;; "n" -> client does not support CB
;; "y" -> client supports CB, thinks the server
;; does not
gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
;; The GS2 header is gs2-header.
</artwork>
</figure>
<t>When the "gs2-nonstd-flag" flag is present, the client
did not find/remove a token header
(<xref target='RFC2743'/> section 3.1) from the initial
token returned by GSS_Init_sec_context. This signals to
the server that it MUST NOT re-add the data that is
normally removed by the client.</t>
<t>The "gs2-cb-flag" signals the channel binding mode. One
of "p", "n", or "y" is used. A "p" means the client
supports and used a channel binding, and the name of the
channel binding type is indicated. A "n" means that the
client does not support channel binding. A "y" means the
client supports channel binding, but believes the server
does not support it, so it did not use a channel binding.
See the next section for more details.</t>
<t>The "gs2-authzid" holds the SASL authorization identity.
It is encoded using <xref target="RFC3629">UTF-8</xref>
with three exceptions:
<list style='symbols'>
<t>The NUL character is forbidden as required by section
3.4.1 of <xref target="RFC4422"/>.</t>
<t>The server MUST replace any "," (comma) in the string
with "=2C".</t>
<t>The server MUST replace any "=" (equals) in the
string with "=3D".</t>
</list>
Upon receipt of this value the server verifies its
correctness according to the used SASL protocol profile.
Failed verification results in a failed authentication
exchange.
</t>
</section>
<section anchor="cb"
title="Channel Bindings">
<t>GS2 supports channel binding to external secure channels,
such as TLS. Clients and servers may or may not support
channel binding, therefore the use of channel binding is
negotiable. GS2 does not provide security layers,
however, therefore it is imperative that GS2 provide
integrity protection for the negotiation of channel
binding.</t>
<t>Use of channel binding is negotiated as follows:
<list style='symbols'>
<t>Servers SHOULD advertise both non-PLUS and the
PLUS-variant of each GS2 mechanism name. If the
server cannot support channel binding, it MAY
advertise only the non-PLUS variant. If the server
would never succeed authentication of the non-PLUS
variant due to policy reasons, it MAY advertise only
the PLUS-variant.</t>
<t>If the client negotiates mechanisms then clients MUST
select the PLUS-variant if offered by the server.
Otherwise (the client does not negotiate mechanisms),
if the client has no prior knowledge about mechanisms
supported by the server and wasn't explicitly
configured to use a particular variant of the GS2
mechanism, then it MUST select only non-PLUS version
of the GS2 mechanism.</t>
<t>If the client does not support channel binding then
it MUST use a "n" gs2-cb-flag.</t>
<t>If the client supports channel binding and the server
does not appear to (i.e., the client did not see the
-PLUS name) then the client MUST either fail
authentication or it MUST chose the non-PLUS mechanism
name and use a "y" gs2-cb-flag.</t>
<t>If the client supports channel binding and the server
appears to support it (i.e., the client see the -PLUS
name), or if the client wishes to use channel binding
but the client does not negotiate mechanisms, then the
client MUST use a "p" gs2-cb-flag to indicate the
channel binding type it is using.</t>
<t>The client generate the chan_bindings input parameter
for GSS_Init_sec_context as described below.</t>
<t>Upon receipt of the initial authentication message
the server checks the gs2-cb-flag in the GS2 header
and constructs a chan_bindings parameter for
GSS_Accept_sec_context as described below. If the
client channel binding flag was "y" and the server did
advertise support for channel bindings then the server
MUST fail authentication. If the client channel
binding flag was "p" and the server does not support
the indicated channel binding type then the server
MUST fail authentication.</t>
</list>
</t>
<figure>
<artwork>
FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION
---- ----------------- ----------------- -----------
n no support N/A If server disallows
non-channel-bound
authentication, then
fail
y Yes, not required No Authentication may
succeed; CB not used
y Yes, not required Yes Authentication must fail
p Yes Yes Authentication may
succeed, with CB used
p Yes No Authentication will fail
N/A Yes, required No Client does not even try
</artwork>
</figure>
<t>For more discussions of channel bindings, and the syntax
of the channel binding data for various security
protocols, see <xref target="RFC5056"/>.</t>
<section anchor="cb-address"
title="Content of GSS-CHANNEL-BINDINGS structure">
<t>The calls to GSS_Init_sec_context and
GSS_Accept_sec_context take a chan_bindings parameter.
The value is a GSS-CHANNEL-BINDINGS structure
<xref target="RFC5554" />.</t>
<t>The initiator-address-type and acceptor-address-type
fields of the GSS-CHANNEL-BINDINGS structure MUST be set
to 0. The initiator-address and acceptor-address fields
MUST be the empty string.</t>
<t>The application-data field MUST be set to the
gs2-header concatenated with, when a gs2-cb-flag of "p"
is used, the application's channel binding data.</t>
</section>
<section anchor="default-cb"
title="Default Channel Binding">
<t>A default channel binding type agreement process for
all SASL application protocols that do not provide their
own channel binding type agreement is provided as
follows.</t>
<t>'tls-unique' is the default channel binding type for
any application that doesn't specify one.</t>
<t>Servers MUST implement the "tls-unique"
<xref target="tls-unique"/>
<xref target="I-D.altman-tls-channel-bindings"/> channel
binding type, if they implement any channel binding.
Clients SHOULD implement the "tls-unique" channel
binding type, if they implement any channel binding.
Clients and servers SHOULD choose the
highest-layer/innermost end-to-end TLS channel as the
channel to bind to.</t>
<t>Servers MUST choose the channel binding type indicated
by the client, or fail authentication if they don't
support it.</t>
</section>
</section>
<section anchor="examples"
title="Examples">
<figure>
<preamble>Example #1: a one round-trip GSS-API context
token exchange, no channel binding, optional
authzid given.</preamble>
<artwork>
C: Request authentication exchange
S: Empty Challenge
C: n,a=someuser,<initial context token with standard
header removed>
S: Send reply context token as is
C: Empty message
S: Outcome of authentication exchange
</artwork>
</figure>
<figure>
<preamble>Example #2: a one and one half round-trip
GSS-API context token exchange, no channel
binding.</preamble>
<artwork>
C: Request authentication exchange
S: Empty Challenge
C: n,,<initial context token with standard
header removed>
S: Send reply context token as is
C: Send reply context token as is
S: Outcome of authentication exchange
</artwork>
</figure>
<figure>
<preamble>Example #3: a two round-trip GSS-API context
token exchange, no channel binding, no standard
token header.</preamble>
<artwork>
C: Request authentication exchange
S: Empty Challenge
C: F,n,,<initial context token without
standard header>
S: Send reply context token as is
C: Send reply context token as is
S: Send reply context token as is
C: Empty message
S: Outcome of authentication exchange
</artwork>
</figure>
<figure>
<preamble>Example #4: using channel binding, optional
authzid given.</preamble>
<artwork>
C: Request authentication exchange
S: Empty Challenge
C: p=tls-unique,a=someuser,<initial context token with standard
header removed>
S: Send reply context token as is
...
</artwork>
</figure>
<figure>
<preamble>Example #5: using channel binding.</preamble>
<artwork>
C: Request authentication exchange
S: Empty Challenge
C: p=tls-unique,,<initial context token with standard
header removed>
S: Send reply context token as is
...
</artwork>
</figure>
<figure>
<preamble>Example #6: using non-standard channel
binding (requires out-of-band negotiation).</preamble>
<artwork>
C: Request authentication exchange
S: Empty Challenge
C: p=tls-server-end-point,,<initial context token with standard
header removed>
S: Send reply context token as is
...
</artwork>
</figure>
<figure>
<preamble>Example #7: client supports channel bindings
but server does not, optional authzid
given.</preamble>
<artwork>
C: Request authentication exchange
S: Empty Challenge
C: y,a=someuser,<initial
context token with standard header removed>
S: Send reply context token as is
...
</artwork>
</figure>
<t>GSS-API authentication is always initiated by the client. The
SASL framework allows either the client and server to initiate
authentication. In GS2 the server will send an initial empty
challenge (zero byte string) if it has not yet received a token
from the client. See section 3 of <xref target="RFC4422"/>.</t>
</section>
<section anchor="authcond"
title="Authentication Conditions">
<t>Authentication MUST NOT succeed if any one of the
following conditions are true:</t>
<t>
<list style="symbols">
<t>GSS_Init/Accept_sec_context return anything other
than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.</t>
<t>If the client's initial GS2 header does not match the
ABNF.</t>
<t>In particular, if the initial character of the client
message is anything except "F", "p", "n", or "y".</t>
<t>If the client's GS2 channel binding flag was "y" and
the server supports channel bindings.</t>
<t>If the client's GS2 channel binding flag was "p" and
the server does not support the indicated channel
binding.</t>
<t>If the client requires use of channel binding and the
server did not advertise support for channel
binding.</t>
<t>Authorization of client principal (i.e., src_name in
GSS_Accept_sec_context) to requested authzid
failed.</t>
<t>If the client is not authorized to the requested
authzid or an authzid could not be derived from the
client's initiator principal name.</t>
</list>
</t>
</section>
<section anchor="gssapiparams"
title="GSS-API Parameters">
<t>GS2 does not use any GSS-API per-message tokens.
Therefore the per-message token ret_flags from
GSS_Init_sec_context() and GSS_Accept_sec_context() are
irrelevant; implementations SHOULD NOT set the per-message
req_flags.</t>
<t>The mutual_req_flag MUST be set. If channel binding is
used then the client MUST check that the corresponding
ret_flag is set when the context is fully establish, else
authentication MUST fail.</t>
<t>Use or non-use of deleg_req_flag and anon_req_flag is an
implementation-specific detail. SASL and GS2 implementors
are encouraged to provide programming interfaces by which
clients may choose to delegate credentials and by which
servers may receive them. SASL and GS2 implementors are
encouraged to provide programming interfaces which provide
a good mapping of GSS-API naming options.</t>
</section>
<section anchor="naming"
title="Naming">
<t>There's no requirement that any particular GSS-API
name-types be used. However, typically SASL servers will
have host-based acceptor principal names (see
<xref target='RFC2743'/> section 4.1) and clients will
typically have username initiator principal names (see
<xref target='RFC2743'/> section 4.2). When a host-based
acceptor principal name is used ("service@hostname"),
"service" is the service name specified in the protocol's
profile, and "hostname" is the fully qualified host name
of the server.</t>
</section>
<section anchor="GSS_Inquire_SASLname_for_mech call"
title="GSS_Inquire_SASLname_for_mech call">
<t>We specify a new GSS-API utility function to allow SASL
implementations to more efficiently identify the GSS-API
mechanism that a particular SASL mechanism name refers
to.</t>
<figure>
<artwork>
Inputs:
o desired_mech OBJECT IDENTIFIER
Outputs:
o sasl_mech_name UTF-8 STRING -- SASL name for this
mechanism; caller must release with
GSS_Release_buffer()
o mech_name UTF-8 STRING -- name of this mechanism, possibly
localized; caller must release with GSS_Release_buffer()
o mech_description UTF-8 STRING -- possibly localized
description of this mechanism; caller must release with
GSS_Release_buffer()
Return major_status codes:
o GSS_S_COMPLETE indicates successful completion, and that
output parameters holds correct information.
o GSS_S_BAD_MECH indicates that a desired_mech was unsupported
by the GSS-API implementation.
The GSS_Inquire_SASLname_for_mech call is used to get the SASL
mechanism name for a GSS-API mechanism. It also returns a name
and description of the mechanism in user friendly form.
The output variable sasl_mech_name will hold the IANA registered
mechanism name for the GSS-API mechanism, or if none is
registered, a mechanism name computed from the OID as described
in section 3.1 of this document.
</artwork>
</figure>
<t><vspace blankLines="10000" /></t>
<section anchor="gss_inquire_saslname_for_mech"
title="gss_inquire_saslname_for_mech">
<t>The C binding for the GSS_Inquire_SASLname_for_mech
call is as follows.</t>
<figure>
<artwork>
OM_uint32 gss_inquire_saslname_for_mech(
OM_uint32 *minor_status,
const gss_OID desired_mech,
gss_buffer_t sasl_mech_name,
gss_buffer_t mech_name,
gss_buffer_t mech_description
);
Purpose:
Output the SASL mechanism name of a GSS-API mechanism.
It also returns a name and description of the mechanism in a
user friendly form.
Parameters:
minor_status Integer, modify
Mechanism specific status code.
Function value: GSS status code
GSS_S_COMPLETE Successful completion
GSS_S_BAD_MECH The desired_mech OID is unsupported
</artwork>
</figure>
</section>
</section>
<section anchor="GSS_Inquire_mech_for_SASLname call"
title="GSS_Inquire_mech_for_SASLname call">
<t>To allow SASL clients to more efficiently identify which
GSS-API mechanism a particular SASL mechanism name refers
to we specify a new GSS-API utility function for this
purpose.</t>
<figure>
<artwork>
Inputs:
o sasl_mech_name UTF-8 STRING -- SASL name of mechanism
Outputs:
o mech_type OBJECT IDENTIFIER -- must be explicit mechanism,
and not "default" specifier
Return major_status codes:
o GSS_S_COMPLETE indicates successful completion, and that output
parameters holds correct information.
o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism
had the indicated sasl_mech_name.
The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API
mechanism OID associated with a SASL mechanism name.
</artwork>
</figure>
<t><vspace blankLines="10000" /></t>
<section anchor="gss_inquire_mech_for_saslname"
title="gss_inquire_mech_for_saslname">
<t>The C binding for the GSS_Inquire_mech_for_SASLname
call is as follows.</t>
<figure>
<artwork>
OM_uint32 gss_inquire_mech_for_saslname(
OM_uint32 *minor_status,
const gss_buffer_t sasl_mech_name,
gss_OID *mech_type
);
Purpose:
Output GSS-API mechanism OID of mechanism associated with given
sasl_mech_name.
Parameters:
minor_status Integer, modify
Mechanism specific status code.
Function value: GSS status code
GSS_S_COMPLETE Successful completion
GSS_S_BAD_MECH The desired_mech OID is unsupported
</artwork>
</figure>
</section>
</section>
<section anchor="seclayers"
title="Security Layers">
<t>GS2 does not support SASL security layers. Applications
that need integrity or confidentiality protection can use
either channel binding to a secure external channel or
another SASL mechanism that does provide security
layers.</t>
</section>
<section anchor="gssapi"
title="Interoperability with the SASL GSSAPI mechanism">
<t>The <xref target="RFC1964">Kerberos V5 GSS-API</xref>
mechanism is currently used in SASL under the name
GSSAPI, see <xref target="RFC4752">GSSAPI
mechanism</xref>. The Kerberos V5 mechanism may also
be used with the GS2 family. This causes an
interoperability problem, which is discussed and
resolved below.</t>
<section title="The interoperability problem">
<t>The SASL "GSSAPI" mechanism is not wire-compatible
with the Kerberos V GSS-API mechanism used as a SASL
GS2 mechanism.</t>
<t>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
mechanism negotiation will fail.</t>
</section>
<section title="Resolving the problem">
<t>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.</t>
<t>Reasons for violating this recommendation may include
security considerations regarding the absent
features in the GS2 mechanism. The SASL "GSSAPI"
mechanism lacks support for channel bindings, which
means that using an external secure channel may not
be sufficient protection against active
attackers (see <xref target='RFC5056'/>, <xref target='mitm'/>).</t>
</section>
<section title="Additional Recommendations">
<t>If the application requires SASL security layers then
it MUST use the SASL "GSSAPI" mechanism
<xref target='RFC4752'/> instead of "GS2-KRB5" or
"GS2-KRB5-PLUS".</t>
<t>If the application can use channel binding to an
external channel then it is RECOMMENDED that it
select Kerberos V5 through the GS2 mechanism rather
than the "GSSAPI" mechanism.</t>
</section>
</section>
<section anchor="nego"
title="GSS-API Mechanisms that negotiate other mechanisms">
<t>A GSS-API mechanism that negotiates other mechanisms will
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.</t>
<section title="The interoperability problem">
<t>If a client implements GSS-API mechanism X, potentially
negotiated through a GSS-API mechanism Y, and the server
also implements GSS-API mechanism X negotiated through a
GSS-API mechanism Z, the authentication negotiation will
fail.</t>
</section>
<section title="Security problem">
<t>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 negotiates
other mechanisms (such as SPNEGO
<xref target="RFC4178"/>), 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 is disallowed under GS2.</t>
</section>
<section title="Resolving the problems">
<t>GSS-API mechanisms that negotiate other mechanisms MUST
NOT be used with the GS2 SASL mechanism. Specifically
SPNEGO <xref target="RFC4178"/> MUST NOT be used as a
GS2 mechanism. To make this easier for SASL
implementations we assign a symbolic SASL mechanism name
to the SPNEGO GSS-API mechanism: "SPNEGO". SASL client
implementations MUST NOT choose the SPNEGO mechanism
under any circumstances.</t>
<!-- [What about SASL apps that don't do mechanism
negotiation? Probably none exist. But if any did
then presumably it would OK to use the SPNEGO
mechanism, no? -Nico] -->
<t>The <xref target="RFC5587">GSS_C_MA_MECH_NEGO attribute
of GSS_Inquire_attrs_for_mech</xref> can be used to
identify such mechanisms.</t>
</section>
</section>
<section anchor="iana"
title="IANA Considerations">
<t>The IANA is advised to register a SASL mechanism family
as per <xref target="RFC4422"/> using the following
information.</t>
<figure>
<artwork>
Subject: Registration of SASL mechanism family 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.
</artwork>
</figure>
<t>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.</t>
<t>The IANA is further advised that GS2 SASL mechanism names
MUST NOT end in "-PLUS" except as a version of another
mechanism name simply suffixed with "-PLUS".</t>
<t>The SASL names for the Kerberos V5 GSS-API mechanism
<xref target='RFC4121'/> <xref target='RFC1964'/> used via
GS2 SHALL be "GS2-KRB5" and "GS2-KRB5-PLUS".</t>
<t>The SASL names for the SPNEGO GSS-API mechanism used via
GS2 SHALL be "SPNEGO" and "SPNEGO-PLUS". As described in
<xref target='nego'/> the SASL "SPNEGO" and "SPNEGO-PLUS"
MUST NOT be used. These names are provided as a
convenience for SASL library implementors.</t>
</section>
<section anchor="security"
title="Security Considerations">
<t>Security issues are also discussed throughout this
memo.</t>
<t>The security provided by a GS2 mechanism depends on the
security of the GSS-API mechanism. The GS2 mechanism
family depends on channel binding support, so GSS-API
mechanisms that do not support channel binding cannot be
successfully used as SASL mechanisms via the GS2
bridge.</t>
<t>Because GS2 does not support security layers it is
strongly RECOMMENDED that channel binding to a secure
external channel be used. Successful channel binding
eliminates the possibility of man-in-the-middle (MITM)
attacks, provided that the external channel and its
channel binding data are secure and provided that the
GSS-API mechanism used is secure. Authentication
failure because of channel binding failure may indicate
that an MITM attack was attempted, but note that a real
MITM attacker would likely attempt to close the
connection to the client or simulate network partition ,
thus MITM attack detection is heuristic.</t>
<t>Use of channel binding will also protect the SASL
mechanism negotiation -- if there is no MITM then the
external secure channel will have protected the SASL
mechanism negotiation.</t>
<t>The channel binding data MAY be sent (but the actual
GSS-API mechanism used) without confidentiality
protection and knowledge of it is assumed to provide
no advantage to an MITM (who can, in any case, compute
the channel binding data independently). If the
external channel does not provide confidentiality
protection and the GSS-API mechanism does not provide
confidentiality protection for the channel binding
data, then passive attackers (eavesdroppers) can
recover the channel binding data. See
<xref target='RFC5056'/>.</t>
<t>When constructing the input_name_string for
GSS_Import_name with the GSS_C_NT_HOSTBASED_SERVICE
name type, the client SHOULD NOT canonicalize the
server's fully qualified domain name using an insecure
or untrusted directory service, such as the <xref
target="RFC1034">Domain Name System</xref> without
<xref target="RFC4033">DNSSEC</xref>.</t>
<t>SHA-1 is used to derive SASL mechanism names, but no
traditional cryptographic properties are required -- the
required property is that the truncated output for
distinct inputs are different for practical input
values. GS2 does not use any other cryptographic
algorithm. Therefor GS2 is "algorithm agile", or, as
agile as the GSS-API mechanisms that are available for
use in SASL applications via GS2.</t>
<t>GS2 does not protect against downgrade attacks of
channel binding types. The complexities of negotiation
a channel binding type, and handling down-grade attacks
in that negotiation, was intentionally left out of scope
for this document.</t>
<t>The security considerations of SASL
<xref target='RFC4422'/>, the GSS-API
<xref target="RFC2743"/>, channel binding
<xref target="RFC5056"/>, any external channels (such as
TLS, <xref target="RFC5246"/>, channel binding types
(see the IANA channel binding type registry), and
GSS-API mechanisms (such as the Kerberos V5 mechanism
<xref target="RFC4121"/> <xref target="RFC1964"/>), also
apply.</t>
</section>
<section anchor="ack"
title="Acknowledgements">
<t>The history of GS2 can be traced to the "GSSAPI"
mechanism originally specified by RFC2222. 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
authors.</t>
<t>Contributions of many members of the SASL mailing list
are gratefully acknowledged. In particular, ideas and
feedback from Pasi Eronen, Sam Hartman, Jeffrey
Hutzelman, Alexey Melnikov, and Tom Yu improved the
document and the protocol. Other suggestions to the
documents were made by Spencer Dawkins, Ralph Droms,
Adrian Farrel, Robert Sparks, and Glen Zorn.</t>
</section>
</middle>
<back>
<references title="Normative References">
&fips180;
&rfc2119;
&rfc2743;
&rfc3629;
&rfc4422;
&rfc4648;
&rfc5056;
&rfc5234;
&rfc5554;
&x690;
<reference anchor="tls-unique">
<front>
<title>Registration of TLS unique channel binding
(generic)</title>
<author initials='L.' surname='Zhu' fullname='Larry Zhu'>
<organization abbrev='MSFT'>Microsoft</organization>
</author>
<date month='July' year='2008'/>
</front>
<seriesInfo name="IANA"
value="http://www.iana.org/assignments/channel-binding-types/tls-unique" />
</reference>
</references>
<references title="Informative References">
&rfc1034;
&rfc1964;
&rfc2025;
&rfc2222;
&rfc4033;
&rfc4121;
&rfc4178;
&rfc4752;
&rfc5246;
&rfc5587;
&SCRAM;
&TLSCB;
<reference anchor="mitm">
<front>
<title>Man-in-the-Middle in Tunneled Authentication</title>
<author initials="N." surname="Asokan" fullname="N. Asokan"/>
<author initials="V." surname="Niemi" fullname="V. Niemi"/>
<author initials="K." surname="Nyberg" fullname="K. Nyberg"/>
</front>
<seriesInfo name="WWW"
value="http://www.saunalahti.fi/~asokan/research/mitm.html" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 22:32:54 |