draft-ietf-sasl-gs2-18.txt   draft-ietf-sasl-gs2-19.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Internet-Draft SJD AB Internet-Draft SJD AB
Intended status: Standards Track N. Williams Intended status: Standards Track N. Williams
Expires: May 13, 2010 Sun Microsystems Expires: July 12, 2010 Sun Microsystems
November 9, 2009 January 8, 2010
Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
draft-ietf-sasl-gs2-18 draft-ietf-sasl-gs2-19
Abstract Abstract
This document describes how to use a Generic Security Service This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework. This is done by Authentication and Security Layer (SASL) framework. This is done by
defining a new SASL mechanism family, called GS2. This mechanism defining a new SASL mechanism family, called GS2. This mechanism
family offers a number of improvements over the previous "SASL/ family offers a number of improvements over the previous "SASL/
GSSAPI" mechanism: it is more general, uses fewer messages for the GSSAPI" mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports negotiable use of authentication phase in some cases, and supports negotiable use of
channel binding. Only GSS-API mechanisms that support channel channel binding. Only GSS-API mechanisms that support channel
binding are supported. binding are supported.
See <http://josefsson.org/sasl-gs2-*/> for more information.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 47 skipping to change at page 1, line 45
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 13, 2010. This Internet-Draft will expire on July 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 18 skipping to change at page 3, line 18
2. Conventions used in this document . . . . . . . . . . . . . . 4 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 4 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 4
3.2. Computing mechanism names manually . . . . . . . . . . . . 5 3.2. Computing mechanism names manually . . . . . . . . . . . . 5
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 6 3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 6
4. SASL Authentication Exchange Message Format . . . . . . . . . 6 4. SASL Authentication Exchange Message Format . . . . . . . . . 6
5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Content of GSS-CHANNEL-BINDINGS structure . . . . . . . . 10 5.1. Content of GSS-CHANNEL-BINDINGS structure . . . . . . . . 10
5.2. Default Channel Binding . . . . . . . . . . . . . . . . . 10 5.2. Default Channel Binding . . . . . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Authentication Conditions . . . . . . . . . . . . . . . . . . 12 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 12
8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 13 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 13
9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 13 10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 14
10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 15 10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 15
11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 15 11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 15
11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 17 11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 17
12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 17 12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 17
13. Interoperability with the SASL GSSAPI mechanism . . . . . . . 17 13. Interoperability with the SASL GSSAPI mechanism . . . . . . . 17
13.1. The interoperability problem . . . . . . . . . . . . . . . 17 13.1. The interoperability problem . . . . . . . . . . . . . . . 17
13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 18 13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 18
13.3. Additional Recommendations . . . . . . . . . . . . . . . . 18 13.3. Additional Recommendations . . . . . . . . . . . . . . . . 18
14. GSS-API Mechanisms that negotiate other mechanisms . . . . . . 18 14. GSS-API Mechanisms that negotiate other mechanisms . . . . . . 18
14.1. The interoperability problem . . . . . . . . . . . . . . . 18 14.1. The interoperability problem . . . . . . . . . . . . . . . 18
skipping to change at page 4, line 25 skipping to change at page 4, line 25
that this is the second GSS-API->SASL mechanism bridge. The original that this is the second GSS-API->SASL mechanism bridge. The original
GSS-API->SASL mechanism bridge was specified by [RFC2222], now GSS-API->SASL mechanism bridge was specified by [RFC2222], now
[RFC4752]; we shall sometimes refer to the original bridge as GS1 in [RFC4752]; we shall sometimes refer to the original bridge as GS1 in
this document. this document.
All GSS-API mechanisms are implicitly registered for use within SASL All GSS-API mechanisms are implicitly registered for use within SASL
by this specification. The SASL mechanisms defined in this document by this specification. The SASL mechanisms defined in this document
are known as the GS2 family of mechanisms. are known as the GS2 family of mechanisms.
The GS1 bridge failed to gain wide deployment for any GSS-API The GS1 bridge failed to gain wide deployment for any GSS-API
mechanism other than The "Kerberos V5 GSS-API mechanism" [RFC1964] mechanism other than "The Kerberos V5 GSS-API mechanism" [RFC1964]
[RFC4121], and has a number of problems that lead us to desire a new [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 bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1
did not support channel binding [RFC5056]. These problems and the did not support channel binding [RFC5056]. These problems and the
opportunity to create the next SASL password-based mechanism, SCRAM opportunity to create the next SASL password-based mechanism, Salted
Challenge Response (SCRAM) SASL and GSS-API Mechanism
[I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL [I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL
applications via GS2, provide the motivation for GS2. applications via GS2, provide the motivation for GS2.
In particular, the current consensus of the SASL community appears to In particular, the current consensus of the SASL community appears to
be that SASL "security layers" (i.e., confidentiality and integrity be that SASL "security layers" (i.e., confidentiality and integrity
protection of application data after authentication) are too complex protection of application data after authentication) are too complex
and, since SASL applications tend to have an option to run over a and redundant because SASL applications tend to have an option to run
Transport Layer Security (TLS) [RFC5246] channel, redundant and best over a Transport Layer Security (TLS) [RFC5246] channel. Use of SASL
replaced with channel binding. security layers is best replaced with channel binding to a TLS
channel.
GS2 is designed to be as simple as possible. It adds to GSS-API GS2 is designed to be as simple as possible. It adds to GSS-API
security context token exchanges only the bare minimum to support security context token exchanges only the bare minimum to support
SASL semantics and negotiation of use of channel binding. SASL semantics and negotiation of use of channel binding.
Specifically, GS2 adds a small header (a few bytes plus the length of Specifically, GS2 adds a small header (a few bytes plus the length of
the client requested SASL authorization identity) to the initial GSS- the client requested SASL authorization identity) to the initial GSS-
API context token and to the application channel binding data. GS2 API context token and to the application channel binding data. GS2
uses SASL mechanism negotiation to implement channel binding uses SASL mechanism negotiation to implement channel binding
negotiation. All GS2 plaintext is protected via the use of GSS-API negotiation. All GS2 plaintext is protected via the use of GSS-API
channel binding. Additionally, to simplify the implementation of GS2 channel binding. Additionally, to simplify the implementation of GS2
skipping to change at page 5, line 29 skipping to change at page 5, line 30
The SASL mechanism name for a GSS-API mechanism is that which is The SASL mechanism name for a GSS-API mechanism is that which is
provided by that mechanism when it was specified, if one was provided by that mechanism when it was specified, if one was
specified. This name denotes that the server does not support specified. This name denotes that the server does not support
channel binding. Add the suffix "-PLUS" and the resulting name channel binding. Add the suffix "-PLUS" and the resulting name
denotes that the server does support channel binding. SASL denotes that the server does support channel binding. SASL
implementations can use the GSS_Inquire_SASLname_for_mech call (see implementations can use the GSS_Inquire_SASLname_for_mech call (see
below) to query for the SASL mechanism name of a GSS-API mechanism. below) to query for the SASL mechanism name of a GSS-API mechanism.
If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2
implementation need some other mechanism to map mechanism OIDs to implementation needs some other mechanism to map mechanism OIDs to
SASL name internally. In this case, the implementation can only SASL names internally. In this case, the implementation can only
support the mechanisms for which it knows the SASL name. If the support the mechanisms for which it knows the SASL name. If the
GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation
cannot map the OID to a SASL mechanism name using some other means, 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 it cannot use the particular GSS-API mechanism since it does not know
its SASL mechanism name. its SASL mechanism name.
3.1. Generating SASL mechanism names from GSS-API OIDs 3.1. Generating SASL mechanism names from GSS-API OIDs
For GSS-API mechanisms whose SASL names are not defined together with 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 the GSS-API mechanism or in this document, the SASL mechanism name is
concatenation of the string "GS2-" and the Base32 encoding [RFC4648] concatenation of the string "GS2-" and the Base32 encoding [RFC4648]
(with an upper case alphabet) of the first 55 bits of the binary (with an upper case alphabet) of the first 55 bits of the binary
SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER
encoding [CCITT.X690.2002], including the tag and length octets, of encoding [CCITT.X690.2002], including the tag and length octets, of
the GSS-API mechanism's Object Identifier. The Base32 rules on the GSS-API mechanism's Object Identifier. The Base32 rules on
padding characters and characters outside of the base32 alphabet are padding characters and characters outside of the Base32 alphabet are
not relevant to this use of Base32. If any padding or non-alphabet not relevant to this use of Base32. If any padding or non-alphabet
characters are encountered, the name is not a GS2 family mechanism characters are encountered, the name is not a GS2 family mechanism
name. This name denotes that the server does not support channel name. This name denotes that the server does not support channel
binding. Add the suffix "-PLUS" and the resulting name denotes that binding. Add the suffix "-PLUS" and the resulting name denotes that
the server does support channel binding. the server does support channel binding.
A GS2 mechanism that has a non-OID-derived SASL mechanism name is A GS2 mechanism that has a non-OID-derived SASL mechanism name is
said to have a "user friendly SASL mechanism name". said to have a "user friendly SASL mechanism name".
3.2. Computing mechanism names manually 3.2. Computing mechanism names manually
The hash-derived GS2 SASL mechanism name may be computed manually. The hash-derived GS2 SASL mechanism name may be computed manually.
This is useful when the set of supported GSS-API mechanisms is known This is useful when the set of supported GSS-API mechanisms is known
in advance. This obliterate the need to implement Base32, SHA-1 and in advance. This eliminates the need to implement Base32, SHA-1 and
DER in the SASL mechanism. The computed mechanism name can be used DER in the SASL mechanism. The computed mechanism name can be used
directly in the implementation, and the implementation need not directly in the implementation, and the implementation need not be
concern itself with that the mechanism is part of a mechanism family. concerned if the mechanism is part of a mechanism family.
3.3. Examples 3.3. Examples
The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The
ASN.1 DER encoding of the OID, including the tag and length, is (in 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 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 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 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 bit, and re-group them in groups of 5, and convert them back to
decimal, which results in these computations: decimal, which results in these computations:
skipping to change at page 6, line 44 skipping to change at page 6, line 47
binary in groups of 5: binary in groups of 5:
00011 10011 11100 01111 01000 01010 11010 11010 00011 10011 11100 01111 01000 01010 11010 11010
10011 11110 00000 10011 11110 00000
decimal of each group: decimal of each group:
3 19 28 15 8 10 26 26 19 30 0 3 19 28 15 8 10 26 26 19 30 0
base32 encoding: base32 encoding:
D T 4 P I K 2 2 T 6 A D T 4 P I K 2 2 T 6 A
The last step translate each decimal value using table 3 in Base32 The last step translates each decimal value using table 3 in Base32
[RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI
mechanism is "GS2-DT4PIK22T6A". mechanism is "GS2-DT4PIK22T6A".
The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48 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 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 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 the last bit, and re-group them in groups of 5, and convert them back
to decimal, which results in these computations: to decimal, which results in these computations:
skipping to change at page 7, line 23 skipping to change at page 7, line 27
binary in groups of 5: binary in groups of 5:
10000 01011 01001 00111 00110 01001 01011 10110 10000 01011 01001 00111 00110 01001 01011 10110
01101 01111 01011 01101 01111 01011
decimal of each group: decimal of each group:
16 11 9 7 6 9 11 22 13 15 11 16 11 9 7 6 9 11 22 13 15 11
base32 encoding: base32 encoding:
Q L J H G J L W N P L Q L J H G J L W N P L
The last step translate each decimal value using table 3 in Base32 The last step translates each decimal value using table 3 in Base32
[RFC4648]. Thus the SASL mechanism name for the Kerberos V5 GSSAPI [RFC4648]. Thus the SASL mechanism name for the Kerberos V5 GSSAPI
mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism
supports channel binding) "GS2-QLJHGJLWNPL-PLUS". Instead, the next supports channel binding) "GS2-QLJHGJLWNPL-PLUS". Instead, the next
section assigns the Kerberos V5 mechanism a non-hash-derived section assigns the Kerberos V5 mechanism a non-hash-derived
mechanism name. mechanism name.
3.4. Grandfathered mechanism names 3.4. Grandfathered mechanism names
Some older GSS-API mechanisms were not specified with a SASL GS2 Some older GSS-API mechanisms were not specified with a SASL GS2
mechanism name. Using a shorter name can be useful nonetheless. We mechanism name. Using a shorter name can be useful nonetheless. We
skipping to change at page 8, line 12 skipping to change at page 8, line 17
client calls GSS_Init_sec_context and the server calls client calls GSS_Init_sec_context and the server calls
GSS_Accept_sec_context. GSS_Accept_sec_context.
All the SASL authentication messages exchanged are exactly the same All the SASL authentication messages exchanged are exactly the same
as the security context tokens of the GSS-API mechanism, except for as the security context tokens of the GSS-API mechanism, except for
the initial security context token. the initial security context token.
The client and server MAY send GSS-API error tokens (tokens output by 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 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). status code is other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED).
As this indicate an error condition, after sending the token, the As this indicates an error condition, after sending the token, the
sending side should fail the authentication. sending side should fail the authentication.
The initial security context token is modified as follows: The initial security context token is modified as follows:
o The [RFC2743] section 3.1 initial context token header MUST be o The initial context token header (see section 3.1 of [RFC2743])
removed if present. If the header is not present, the client MUST MUST be removed if present. If the header is not present, the
send a "gs2-nonstd-flag" flag (see below). On the server side client MUST send a "gs2-nonstd-flag" flag (see below). On the
this header MUST be recomputed and restored prior to passing the server side this header MUST be recomputed and restored prior to
token to GSS_Accept_sec_context, except when the "gs2-nonstd-flag" passing the token to GSS_Accept_sec_context, except when the "gs2-
is sent. nonstd-flag" is sent.
o A GS2 header MUST be prefixed to the resulting initial context o A GS2 header MUST be prefixed to the resulting initial context
token. This header has the form "gs2-header" given below in ABNF token. This header has the form "gs2-header" given below in ABNF
[RFC5234]. [RFC5234].
The figure below describes the permissible attributes, their use, and The figure below describes the permissible attributes, their use, and
the format of their values. All attribute names are single US-ASCII the format of their values. All attribute names are single US-ASCII
letters and are case-sensitive. letters and are case-sensitive.
UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F
;; As UTF8-1 in RFC 3629 except ;; As UTF8-1 in RFC 3629 except
skipping to change at page 9, line 33 skipping to change at page 9, line 33
gs2-cb-flag = ("p=" cb-name) / "n" / "y" gs2-cb-flag = ("p=" cb-name) / "n" / "y"
;; GS2 channel binding (CB) flag ;; GS2 channel binding (CB) flag
;; "p" -> client supports and used CB ;; "p" -> client supports and used CB
;; "n" -> client does not support CB ;; "n" -> client does not support CB
;; "y" -> client supports CB, thinks the server ;; "y" -> client supports CB, thinks the server
;; does not ;; does not
gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] "," gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
;; The GS2 header is gs2-header. ;; The GS2 header is gs2-header.
When the "gs2-nonstd-flag" flag is present, the client did not find/ When the "gs2-nonstd-flag" flag is present, the client did not find/
remove a [RFC2743] section 3.1 token header from the initial token remove a token header ([RFC2743] section 3.1) from the initial token
returned by GSS_Init_sec_context. This signals to the server that it 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. MUST NOT re-add the data that is normally removed by the client.
The "gs2-cb-flag" signals the channel binding mode. One of "p", "n", 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 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 binding, and the name of the channel binding type is indicated. A
"n" means that the client does not support channel binding. A "y" "n" means that the client does not support channel binding. A "y"
means the client supports channel binding, but believes the server means the client supports channel binding, but believes the server
does not support it, so it did not use a channel binding. See the does not support it, so it did not use a channel binding. See the
next section for more details. next section for more details.
The "gs2-authzid" holds the SASL authorization identity. It is The "gs2-authzid" holds the SASL authorization identity. It is
encoded using UTF-8 [RFC3629] with three exceptions: encoded using UTF-8 [RFC3629] with three exceptions:
o The NUL characters is forbidden as required by section 3.4.1 of o The NUL character is forbidden as required by section 3.4.1 of
[RFC4422]. [RFC4422].
o The server MUST replace any "," (comma) in the string with "=2C". o The server MUST replace any "," (comma) in the string with "=2C".
o The server MUST replace any "=" (equals) in the string with "=3D". o The server MUST replace any "=" (equals) in the string with "=3D".
Upon the receipt of this value the server verifies its correctness Upon receipt of this value the server verifies its correctness
according to the used SASL protocol profile. Failed verification according to the used SASL protocol profile. Failed verification
results in failed authentication exchange. results in a failed authentication exchange.
5. Channel Bindings 5. Channel Bindings
GS2 supports channel binding to external secure channels, such as GS2 supports channel binding to external secure channels, such as
TLS. Clients and servers may or may not support channel binding, TLS. Clients and servers may or may not support channel binding,
therefore the use of channel binding is negotiable. GS2 does not therefore the use of channel binding is negotiable. GS2 does not
provide security layers, however, therefore it is imperative that GS2 provide security layers, however, therefore it is imperative that GS2
provide integrity protection for the negotiation of channel binding. provide integrity protection for the negotiation of channel binding.
Use of channel binding is negotiated as follows: Use of channel binding is negotiated as follows:
skipping to change at page 10, line 48 skipping to change at page 11, line 5
GSS_Init_sec_context as described below. GSS_Init_sec_context as described below.
o Upon receipt of the initial authentication message the server o Upon receipt of the initial authentication message the server
checks the gs2-cb-flag in the GS2 header and constructs a checks the gs2-cb-flag in the GS2 header and constructs a
chan_bindings parameter for GSS_Accept_sec_context as described chan_bindings parameter for GSS_Accept_sec_context as described
below. If the client channel binding flag was "y" and the server below. If the client channel binding flag was "y" and the server
did advertise support for channel bindings then the server MUST did advertise support for channel bindings then the server MUST
fail authentication. If the client channel binding flag was "p" fail authentication. If the client channel binding flag was "p"
and the server does not support the indicated channel binding type and the server does not support the indicated channel binding type
then the server MUST fail authentication. then the server MUST fail authentication.
FLAG SERVER CB SUPPORT DISPOSITION
---- ----------------- -----------
n Irrelevant If server disallows non-channel-
bound authentication, then fail
y CB not supported Authentication may succeed
y CB supported Authentication must fail
p CB supported Authentication may succeed, with
CB used
p CB not supported Authentication will fail
<none> CB not supported Client does not even try because
it insists on CB
For more discussions of channel bindings, and the syntax of the For more discussions of channel bindings, and the syntax of the
channel binding data for various security protocols, see [RFC5056]. channel binding data for various security protocols, see [RFC5056].
5.1. Content of GSS-CHANNEL-BINDINGS structure 5.1. Content of GSS-CHANNEL-BINDINGS structure
The calls to GSS_Init_sec_context and GSS_Accept_sec_context takes a The calls to GSS_Init_sec_context and GSS_Accept_sec_context take a
chan_bindings parameter. The value is a GSS-CHANNEL-BINDINGS chan_bindings parameter. The value is a GSS-CHANNEL-BINDINGS
structure [RFC5554]. structure [RFC5554].
The initiator-address-type and acceptor-address-type fields of the The initiator-address-type and acceptor-address-type fields of the
GSS-CHANNEL-BINDINGS structure MUST be set to 0. The initiator- GSS-CHANNEL-BINDINGS structure MUST be set to 0. The initiator-
address and acceptor-address fields MUST be the empty string. address and acceptor-address fields MUST be the empty string.
The application-data field MUST be set to the gs2-header concatenated 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 with, when a gs2-cb-flag of "p" is used, the application's channel
binding data. binding data.
skipping to change at page 14, line 7 skipping to change at page 14, line 25
o If the client requires use of channel binding and the server did o If the client requires use of channel binding and the server did
not advertise support for channel binding. not advertise support for channel binding.
o Authorization of client principal (i.e., src_name in o Authorization of client principal (i.e., src_name in
GSS_Accept_sec_context) to requested authzid failed. GSS_Accept_sec_context) to requested authzid failed.
o If the client is not authorized to the requested authzid or an o If the client is not authorized to the requested authzid or an
authzid could not be derived from the client's initiator principal authzid could not be derived from the client's initiator principal
name. name.
8. GSS-API Parameters 8. GSS-API Parameters
GS2 does not use any GSS-API per-message tokens. Therefore the GS2 does not use any GSS-API per-message tokens. Therefore the per-
setting of req_flags related to per-message tokens is irrelevant. 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.
The mutual_req_flag MUST be set. If channel binding is used then the 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 client MUST check that the corresponding ret_flag is set when the
context is fully establish, else authentication MUST fail. context is fully establish, else authentication MUST fail.
Use or non-use of deleg_req_flag and anon_req_flag is an Use or non-use of deleg_req_flag and anon_req_flag is an
implementation-specific detail. SASL and GS2 implementors are implementation-specific detail. SASL and GS2 implementors are
encouraged to provide programming interfaces by which clients may encouraged to provide programming interfaces by which clients may
choose to delegate credentials and by which servers may receive them. choose to delegate credentials and by which servers may receive them.
SASL and GS2 implementors are encouraged to provide programming SASL and GS2 implementors are encouraged to provide programming
skipping to change at page 14, line 34 skipping to change at page 15, line 8
used. However, typically SASL servers will have host-based acceptor used. However, typically SASL servers will have host-based acceptor
principal names (see [RFC2743] section 4.1) and clients will principal names (see [RFC2743] section 4.1) and clients will
typically have username initiator principal names (see [RFC2743] typically have username initiator principal names (see [RFC2743]
section 4.2). When a host-based acceptor principal name is used section 4.2). When a host-based acceptor principal name is used
("service@hostname"), "service" is the service name specified in the ("service@hostname"), "service" is the service name specified in the
protocol's profile, and "hostname" is the fully qualified host name protocol's profile, and "hostname" is the fully qualified host name
of the server. of the server.
10. GSS_Inquire_SASLname_for_mech call 10. GSS_Inquire_SASLname_for_mech call
To allow SASL implementations to query for the SASL mechanism name of We specify a new GSS-API utility function to allow SASL
a GSS-API mechanism, we specify a new GSS-API function for this implementations to more efficiently identify the GSS-API mechanism
purpose. that a particular SASL mechanism name refers to.
Inputs: Inputs:
o desired_mech OBJECT IDENTIFIER o desired_mech OBJECT IDENTIFIER
Outputs: Outputs:
o sasl_mech_name UTF-8 STRING -- SASL name for this o sasl_mech_name UTF-8 STRING -- SASL name for this
mechanism; caller must release with mechanism; caller must release with
GSS_Release_buffer() GSS_Release_buffer()
skipping to change at page 16, line 15 skipping to change at page 16, line 15
10.1. gss_inquire_saslname_for_mech 10.1. gss_inquire_saslname_for_mech
The C binding for the GSS_Inquire_SASLname_for_mech call is as The C binding for the GSS_Inquire_SASLname_for_mech call is as
follows. follows.
OM_uint32 gss_inquire_saslname_for_mech( OM_uint32 gss_inquire_saslname_for_mech(
OM_uint32 *minor_status, OM_uint32 *minor_status,
const gss_OID desired_mech, const gss_OID desired_mech,
gss_buffer_t sasl_mech_name, gss_buffer_t sasl_mech_name,
gss_buffer_t mech_name, gss_buffer_t mech_name,
gss_buffer_t mech_description, gss_buffer_t mech_description
); );
Purpose: Purpose:
Output the SASL mechanism name of a GSS-API mechanism. Output the SASL mechanism name of a GSS-API mechanism.
It also returns a name and description of the mechanism in a It also returns a name and description of the mechanism in a
user friendly form. user friendly form.
Parameters: Parameters:
skipping to change at page 19, line 23 skipping to change at page 19, line 23
mechanism, to avoid interoperability problems with older clients. mechanism, to avoid interoperability problems with older clients.
Reasons for violating this recommendation may include security Reasons for violating this recommendation may include security
considerations regarding the absent features in the GS2 mechanism. considerations regarding the absent features in the GS2 mechanism.
The SASL "GSSAPI" mechanism lacks support for channel bindings, which The SASL "GSSAPI" mechanism lacks support for channel bindings, which
means that using an external secure channel may not be sufficient means that using an external secure channel may not be sufficient
protection against active attackers (see [RFC5056], [mitm]). protection against active attackers (see [RFC5056], [mitm]).
13.3. Additional Recommendations 13.3. Additional Recommendations
If the application requires security layers then it MUST prefer the If the application requires SASL security layers then it MUST use the
SASL "GSSAPI" mechanism over "GS2-KRB5" or "GS2-KRB5-PLUS". SASL "GSSAPI" mechanism [RFC4752] instead of "GS2-KRB5" or "GS2-KRB5-
PLUS".
If the application can use channel binding to an external channel If the application can use channel binding to an external channel
then it is RECOMMENDED that it select Kerberos V5 through the GS2 then it is RECOMMENDED that it select Kerberos V5 through the GS2
mechanism rather than the "GSSAPI" mechanism. mechanism rather than the "GSSAPI" mechanism.
14. GSS-API Mechanisms that negotiate other mechanisms 14. GSS-API Mechanisms that negotiate other mechanisms
A GSS-API mechanism that negotiate other mechanisms interact badly A GSS-API mechanism that negotiates other mechanisms will interact
with the SASL mechanism negotiation. There are two problems. The badly with the SASL mechanism negotiation. There are two problems.
first is an interoperability problem and the second is a security The first is an interoperability problem and the second is a security
concern. The problems are described and resolved below. concern. The problems are described and resolved below.
14.1. The interoperability problem 14.1. The interoperability problem
If a client implement GSS-API mechanism X, potentially negotiated If a client implements GSS-API mechanism X, potentially negotiated
through a GSS-API mechanism Y, and the server also implement GSS-API through a GSS-API mechanism Y, and the server also implements GSS-API
mechanism X negotiated through a GSS-API mechanism Z, the mechanism X negotiated through a GSS-API mechanism Z, the
authentication negotiation will fail. authentication negotiation will fail.
14.2. Security problem 14.2. Security problem
If a client's policy is to first prefer GSSAPI mechanism X, then non- 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 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 mechanisms Y and Z but not X, then if the client attempts to
negotiate mechanism X by using a GSS-API mechanism that negotiate negotiate mechanism X by using a GSS-API mechanism that negotiates
other mechanisms (such as SPNEGO), it may end up using mechanism Z other mechanisms (such as SPNEGO [RFC4178]), it may end up using
when it ideally should have used mechanism Y. For this reason, the mechanism Z when it ideally should have used mechanism Y. For this
use of GSS-API mechanisms that negotiate other mechanisms are reason, the use of GSS-API mechanisms that negotiate other mechanisms
disallowed under GS2. is disallowed under GS2.
14.3. Resolving the problems 14.3. Resolving the problems
GSS-API mechanisms that negotiate other mechanisms MUST NOT be used GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT
be used as a GS2 mechanism. To make this easier for SASL be used as a GS2 mechanism. To make this easier for SASL
implementations we assign a symbolic SASL mechanism name to the implementations we assign a symbolic SASL mechanism name to the
SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST
NOT choose the SPNEGO mechanism under any circumstances. NOT choose the SPNEGO mechanism under any circumstances.
skipping to change at page 21, line 45 skipping to change at page 21, line 45
GSS-API mechanism does not provide confidentiality protection for the GSS-API mechanism does not provide confidentiality protection for the
channel binding data, then passive attackers (eavesdroppers) can channel binding data, then passive attackers (eavesdroppers) can
recover the channel binding data. See [RFC5056]. recover the channel binding data. See [RFC5056].
When constructing the input_name_string for GSS_Import_name with the When constructing the input_name_string for GSS_Import_name with the
GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT
canonicalize the server's fully qualified domain name using an canonicalize the server's fully qualified domain name using an
insecure or untrusted directory service, such as the Domain Name insecure or untrusted directory service, such as the Domain Name
System [RFC1034] without DNSSEC [RFC4033]. System [RFC1034] without DNSSEC [RFC4033].
GS2 does not directly use any cryptographic algorithms, therefore it SHA-1 is used to derive SASL mechanism names, but no traditional
is automatically "algorithm agile", or, as agile as the GSS-API cryptographic properties are required -- the required property is
mechanisms that are available for use in SASL applications via GS2. that the truncated output for distinct inputs are different for
The exception is the use of SHA-1 for deriving SASL mechanism names, practical input values. GS2 does not use any other cryptographic
but no cryptographic properties are required. The required property algorithm. Therefor GS2 is "algorithm agile", or, as agile as the
is that the truncated output for distinct inputs are different for GSS-API mechanisms that are available for use in SASL applications
practical input values. via GS2.
GS2 does not protect against downgrade attacks of channel binding GS2 does not protect against downgrade attacks of channel binding
types. The complexities of negotiation a channel binding type, and types. The complexities of negotiation a channel binding type, and
handling down-grade attacks in that negotiation, was intentionally handling down-grade attacks in that negotiation, was intentionally
left out of scope for this document. left out of scope for this document.
The security considerations of SASL [RFC4422], the GSS-API [RFC2743], The security considerations of SASL [RFC4422], the GSS-API [RFC2743],
channel binding [RFC5056], any external channels (such as TLS, channel binding [RFC5056], any external channels (such as TLS,
[RFC5246], channel binding types (see the IANA channel binding type [RFC5246], channel binding types (see the IANA channel binding type
registry), and GSS-API mechanisms (such as the Kerberos V5 mechanism registry), and GSS-API mechanisms (such as the Kerberos V5 mechanism
skipping to change at page 22, line 27 skipping to change at page 22, line 27
The history of GS2 can be traced to the "GSSAPI" mechanism originally The history of GS2 can be traced to the "GSSAPI" mechanism originally
specified by RFC2222. This document was derived from specified by RFC2222. This document was derived from
draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
significant contributions from John G. Myers, although the majority significant contributions from John G. Myers, although the majority
of this document has been rewritten by the current authors. of this document has been rewritten by the current authors.
Contributions of many members of the SASL mailing list are gratefully Contributions of many members of the SASL mailing list are gratefully
acknowledged. In particular, ideas and feedback from Pasi Eronen, acknowledged. In particular, ideas and feedback from Pasi Eronen,
Sam Hartman, Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved Sam Hartman, Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved
the document and the protocol. the document and the protocol. Other suggestions to the documents
were made by Spencer Dawkins, Ralph Droms, Adrian Farrel, Robert
Sparks, and Glen Zorn.
18. References 18. References
18.1. Normative References 18.1. Normative References
[FIPS.180-1.1995] [FIPS.180-1.1995]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1, April 1995, Hash Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>. <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
skipping to change at page 23, line 26 skipping to change at page 23, line 28
[CCITT.X690.2002] [CCITT.X690.2002]
International International Telephone and Telegraph International International Telephone and Telegraph
Consultative Committee, "ASN.1 encoding rules: Consultative Committee, "ASN.1 encoding rules:
Specification of basic encoding Rules (BER), Canonical Specification of basic encoding Rules (BER), Canonical
encoding rules (CER) and Distinguished encoding rules encoding rules (CER) and Distinguished encoding rules
(DER)", CCITT Recommendation X.690, July 2002. (DER)", CCITT Recommendation X.690, July 2002.
[tls-unique] [tls-unique]
Zhu, L., "Registration of TLS unique channel binding Zhu, L., "Registration of TLS unique channel binding
(generic)", July 2008. (generic)", IANA http://www.iana.org/assignments/
channel-binding-types/tls-unique, July 2008.
18.2. Informative References 18.2. Informative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996. RFC 1964, June 1996.
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
 End of changes. 34 change blocks. 
62 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/