rfc5801.txt   draft-josefsson-kitten-gs2bis.txt 
Internet Engineering Task Force (IETF) S. Josefsson Network Working Group S. Josefsson
Request for Comments: 5801 SJD AB Internet-Draft SJD AB
Category: Standards Track N. Williams Intended status: Standards Track March 3, 2014
ISSN: 2070-1721 Oracle Expires: September 4, 2014
July 2010
Using Generic Security Service Application Program Interface (GSS-API) Using Generic Security Service Application Program Interface (GSS-API)
Mechanisms in Simple Authentication and Security Layer (SASL): Mechanisms in Simple Authentication and Security Layer (SASL): The GS2
The GS2 Mechanism Family Mechanism Family
draft-josefsson-kitten-gs2bis-00
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 Simple Application Program Interface (GSS-API) mechanism in 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. This is an update of RFC 5801 that relaxes the
binding and mutual authentication are supported. requirement for channel binding support and mutual authentication in
the underlying GSS-API mechanism.
Status of This Memo Status of this Memo
This is an Internet Standards Track document. This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is a product of the Internet Engineering Task Force Internet-Drafts are working documents of the Internet Engineering
(IETF). It represents the consensus of the IETF community. It has Task Force (IETF). Note that other groups may also distribute
received public review and has been approved for publication by the working documents as Internet-Drafts. The list of current Internet-
Internet Engineering Steering Group (IESG). Further information on Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, Internet-Drafts are draft documents valid for a maximum of six months
and how to provide feedback on it may be obtained at and may be updated, replaced, or obsoleted by other documents at any
http://www.rfc-editor.org/info/rfc5801. time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2014 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 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction ....................................................4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document ...............................5 2. Conventions Used in This Document . . . . . . . . . . . . . . 5
3. Mechanism Name ..................................................5 3. Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Generating SASL Mechanism Names from GSS-API OIDs ..........5 3.1. Generating SASL Mechanism Names from GSS-API OIDs . . . . 5
3.2. Computing Mechanism Names Manually .........................6 3.2. Computing Mechanism Names Manually . . . . . . . . . . . . 6
3.3. Examples ...................................................6 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Grandfathered Mechanism Names ..............................7 3.4. Grandfathered Mechanism Names . . . . . . . . . . . . . . 8
4. SASL Authentication Exchange Message Format .....................8 4. SASL Authentication Exchange Message Format . . . . . . . . . 8
5. Channel Bindings ...............................................10 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Content of GSS-CHANNEL-BINDINGS Structure .................11 5.1. Content of GSS-CHANNEL-BINDINGS Structure . . . . . . . . 11
5.2. Default Channel Binding ...................................12 5.2. Default Channel Binding . . . . . . . . . . . . . . . . . 11
6. Examples .......................................................12 6. When the mechanism does not support channel binding and/or
7. Authentication Conditions ......................................14 mutual authentication . . . . . . . . . . . . . . . . . . . . 12
8. GSS-API Parameters .............................................15 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Naming .........................................................15 8. Authentication Conditions . . . . . . . . . . . . . . . . . . 15
10. GSS_Inquire_SASLname_for_mech Call ............................15 9. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 15
10.1. gss_inquire_saslname_for_mech ............................16 10. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. GSS_Inquire_mech_for_SASLname Call ............................18 11. GSS_Inquire_SASLname_for_mech Call . . . . . . . . . . . . . . 16
11.1. gss_inquire_mech_for_saslname ............................19 11.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 18
12. Security Layers ...............................................20 12. GSS_Inquire_mech_for_SASLname Call . . . . . . . . . . . . . . 20
13. Interoperability with the SASL GSSAPI Mechanism ...............20 12.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 21
13.1. The Interoperability Problem .............................20 13. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 21
13.2. Resolving the Problem ....................................20 14. Interoperability with the SASL GSSAPI Mechanism . . . . . . . 22
13.3. Additional Recommendations ...............................20 14.1. The Interoperability Problem . . . . . . . . . . . . . . . 22
14. GSS-API Mechanisms That Negotiate Other Mechanisms ............21 14.2. Resolving the Problem . . . . . . . . . . . . . . . . . . 22
14.1. The Interoperability Problem .............................21 14.3. Additional Recommendations . . . . . . . . . . . . . . . . 22
14.2. Security Problem .........................................21 15. GSS-API Mechanisms That Negotiate Other Mechanisms . . . . . . 22
14.3. Resolving the Problems ...................................21 15.1. The Interoperability Problem . . . . . . . . . . . . . . . 23
15. IANA Considerations ...........................................22 15.2. Security Problem . . . . . . . . . . . . . . . . . . . . . 23
16. Security Considerations .......................................22 15.3. Resolving the Problems . . . . . . . . . . . . . . . . . . 23
17. Acknowledgements ..............................................24 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
18. References ....................................................24 17. Security Considerations . . . . . . . . . . . . . . . . . . . 24
18.1. Normative References .....................................24 18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
18.2. Informative References ...................................25 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
19.1. Normative References . . . . . . . . . . . . . . . . . . . 26
19.2. Informative References . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Generic Security Service Application Program Interface (GSS-API) Generic Security Service Application Program Interface (GSS-API)
[RFC2743] is a framework that provides security services to [RFC2743] is a framework that provides security services to
applications using a variety of authentication mechanisms. Simple applications using a variety of authentication mechanisms. Simple
Authentication and Security Layer (SASL) [RFC4422] is a framework to Authentication and Security Layer (SASL) [RFC4422] is a framework to
provide authentication and security layers for connection-based provide authentication and security layers for connection-based
protocols, also using a variety of mechanisms. This document protocols, also using a variety of mechanisms. This document
describes how to use a GSS-API mechanism as though it were a SASL describes how to use a GSS-API mechanism as though it were a SASL
skipping to change at page 7, line 48 skipping to change at page 8, line 14
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
specify the names "GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5 specify the names "GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5
mechanism, to be used as if the original specification documented it, mechanism, to be used as if the original specification documented it,
see Section 15. see Section 16.
4. SASL Authentication Exchange Message Format 4. SASL Authentication Exchange Message Format
During the SASL authentication exchange for GS2, a number of messages During the SASL authentication exchange for GS2, a number of messages
following the following format are sent between the client and following the following format are sent between the client and
server. On success, this number is the same as the number of context 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 tokens that the GSS-API mechanism would normally require in order to
establish a security context. On failures, the exchange can be establish a security context. On failures, the exchange can be
terminated early by any party. terminated early by any party.
skipping to change at page 12, line 24 skipping to change at page 12, line 16
Servers MUST implement the "tls-unique" [RFC5929] channel binding Servers MUST implement the "tls-unique" [RFC5929] channel binding
type, if they implement any channel binding. Clients SHOULD type, if they implement any channel binding. Clients SHOULD
implement the "tls-unique" channel binding type, if they implement implement the "tls-unique" channel binding type, if they implement
any channel binding. Clients and servers SHOULD choose the highest- any channel binding. Clients and servers SHOULD choose the highest-
layer/innermost end-to-end TLS channel as the channel to which to layer/innermost end-to-end TLS channel as the channel to which to
bind. bind.
Servers MUST choose the channel binding type indicated by the client, Servers MUST choose the channel binding type indicated by the client,
or fail authentication if they don't support it. or fail authentication if they don't support it.
6. Examples 6. When the mechanism does not support channel binding and/or mutual
authentication
Some authentication mechanisms does not offer mutual authentication
or is unable to provide channel bindings. This is unfortunate, and
usually suggests that the authentication mechanism offers limited
authentication functionality. However there are situations when the
lack of this functionality can be mitigated with other protection
mechanisms, leading to acceptable overall security. Being able to
define and use an authentication mechanism as a GSS-API mechanism and
then use that GSS-API mechanism in the SASL environment using GS2 has
advantages; for example, being able to re-use existing generic GS2
implementations. Further, being able to express all mechanisms that
can be expressed as a GSS-API mechanisms as a SASL mechanism (and
vice versa) provides design elegance and framework replacability.
Therefor, this document relaxes the requirement that the GSS-API
mechanism support channel bindings and/or mutual authentication.
Implementing and deploying applications that supports those mechanism
require some consideration, and this section discuss the relevant
areas.
For the discussion it helps to understand what happens with the GS2
bridge when a GSS-API mechanism does not offer channel bindings or
mutual authentication. When channel bindings is not supported by the
underlying mechanism, GS2 cannot protect its data (essentially: the
channel binding flag and the SASL authorization identity). This
means that the security of the channel binding mode breaks down and
that the other side cannot trust the SASL authorization identity.
When mutual authentication is not happening, the client cannot know
that it sends its data to the intended server.
It is acceptable to use these mechanisms with GS2 in some situations.
For example, if the client uses TLS against a server, and the client
verify the server's certificate properly so that server
authentication has occured, then authenticating the client to the
server using a "weak" GSS-API mechanism will technically work. The
security properties will not be as good as they would have been if
the underlying mechanism supported channel binding or mutual
authentication, however they become as good as possible.
This document relaxes the requirements on GSS-API mechanism so that
all GSS-API mechanism can be expressed in GS2. For these mechanisms,
the "gs2-cb-flag" value MUST always be "n", and the PLUS-variant of
the GS2 mechanism name MUST NOT be advertised or negotiated.
The SAML SASL bridge [RFC6595] and the SAML OpenID bridge [RFC6616]
are two examples of documents that describe such bridges. These
documents did not meet the requirements of the original GS2 bridge,
but with the update in this document they are conformant. Note that
both documents had discussions describing this aspect and sufficient
requirements for safe implementation and deployment.
7. Examples
Example #1: a one round-trip GSS-API context token exchange, no Example #1: a one round-trip GSS-API context token exchange, no
channel binding, optional authzid given. channel binding, optional authzid given.
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
C: n,a=someuser,<initial context token with standard C: n,a=someuser,<initial context token with standard
header removed> header removed>
S: Send reply context token as is S: Send reply context token as is
C: Empty message C: Empty message
skipping to change at page 14, line 21 skipping to change at page 15, line 21
context token with standard header removed> context token with standard header removed>
S: Send reply context token as is S: Send reply context token as is
... ...
GSS-API authentication is always initiated by the client. The SASL GSS-API authentication is always initiated by the client. The SASL
framework allows either the client or the server to initiate framework allows either the client or the server to initiate
authentication. In GS2, the server will send an initial empty authentication. In GS2, the server will send an initial empty
challenge (zero-byte string) if it has not yet received a token from challenge (zero-byte string) if it has not yet received a token from
the client. See Section 3 of [RFC4422]. the client. See Section 3 of [RFC4422].
7. Authentication Conditions 8. Authentication Conditions
Authentication MUST NOT succeed if any one of the following Authentication MUST NOT succeed if any one of the following
conditions are true: conditions are true:
o If GSS_Init/Accept_sec_context returns anything other than o If GSS_Init/Accept_sec_context returns anything other than
GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE. GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
o If the client's initial GS2 header does not match the ABNF. o If the client's initial GS2 header does not match the ABNF.
o In particular, if the initial character of the client message is o In particular, if the initial character of the client message is
anything except "F", "p", "n", or "y". anything except "F", "p", "n", or "y".
o If the client's GS2 channel binding flag was "y" and the server o If the client's GS2 channel binding flag was "y" and the server
supports channel bindings. supports channel bindings.
o If the client's GS2 channel binding flag was "p" and the server o If the client's GS2 channel binding flag was "p" and the server
does not support the indicated channel binding. does not support the indicated channel binding.
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 If authorization of client principal (i.e., src_name in o If 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 9. GSS-API Parameters
GS2 does not use any GSS-API per-message tokens. Therefore, the per- GS2 does not use any GSS-API per-message tokens. Therefore, the per-
message token ret_flags from GSS_Init_sec_context() and message token ret_flags from GSS_Init_sec_context() and
GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT
set the per-message req_flags. set the per-message req_flags.
The mutual_req_flag MUST be set. Clients MUST check that the The mutual_req_flag MUST be set. Clients MUST check that the
corresponding ret_flag is set when the context is fully established, corresponding ret_flag is set when the context is fully established,
else authentication MUST fail. 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
interfaces that provide a good mapping of GSS-API naming options. interfaces that provide a good mapping of GSS-API naming options.
9. Naming 10. Naming
There is no requirement that any particular GSS-API name-types be There is no requirement that any particular GSS-API name-types be
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 of protocol's profile and "hostname" is the fully qualified host name of
the server. the server.
10. GSS_Inquire_SASLname_for_mech Call 11. GSS_Inquire_SASLname_for_mech Call
We specify a new GSS-API utility function to allow SASL We specify a new GSS-API utility function to allow SASL
implementations to more efficiently identify the GSS-API mechanism to implementations to more efficiently identify the GSS-API mechanism to
which a particular SASL mechanism name refers. which a particular SASL mechanism name refers.
Inputs: Inputs:
o desired_mech OBJECT IDENTIFIER o desired_mech OBJECT IDENTIFIER
Outputs: Outputs:
skipping to change at page 16, line 32 skipping to change at page 18, line 5
The GSS_Inquire_SASLname_for_mech call is used to get the SASL 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 mechanism name for a GSS-API mechanism. It also returns a name
and description of the mechanism in user-friendly form. and description of the mechanism in user-friendly form.
The output variable sasl_mech_name will hold the IANA registered The output variable sasl_mech_name will hold the IANA registered
mechanism name for the GSS-API mechanism, or if none is mechanism name for the GSS-API mechanism, or if none is
registered, a mechanism name computed from the OID as described registered, a mechanism name computed from the OID as described
in Section 3.1 of this document. in Section 3.1 of this document.
10.1. gss_inquire_saslname_for_mech 11.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.
As mentioned in [RFC2744], routines may return GSS_S_FAILURE, As mentioned in [RFC2744], routines may return GSS_S_FAILURE,
indicating an implementation-specific or mechanism-specific error indicating an implementation-specific or mechanism-specific error
condition, further details of which are reported via the minor_status condition, further details of which are reported via the minor_status
parameter. parameter.
OM_uint32 gss_inquire_saslname_for_mech( OM_uint32 gss_inquire_saslname_for_mech(
skipping to change at page 18, line 5 skipping to change at page 20, line 5
The application must free storage associated The application must free storage associated
with this name after use with a call to with this name after use with a call to
gss_release_buffer(). gss_release_buffer().
Function value: GSS status code: Function value: GSS status code:
GSS_S_COMPLETE Successful completion. GSS_S_COMPLETE Successful completion.
GSS_S_BAD_MECH The desired_mech OID is unsupported. GSS_S_BAD_MECH The desired_mech OID is unsupported.
11. GSS_Inquire_mech_for_SASLname Call 12. GSS_Inquire_mech_for_SASLname Call
To allow SASL clients to more efficiently identify to which GSS-API To allow SASL clients to more efficiently identify to which GSS-API
mechanism a particular SASL mechanism name refers, we specify a new mechanism a particular SASL mechanism name refers, we specify a new
GSS-API utility function for this purpose. GSS-API utility function for this purpose.
Inputs: Inputs:
o sasl_mech_name UTF-8 STRING -- SASL name of mechanism. o sasl_mech_name UTF-8 STRING -- SASL name of mechanism.
Outputs: Outputs:
skipping to change at page 19, line 5 skipping to change at page 21, line 5
o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism
had the indicated sasl_mech_name. had the indicated sasl_mech_name.
o GSS_S_FAILURE indicates that the operation failed for reasons o GSS_S_FAILURE indicates that the operation failed for reasons
unspecified at the GSS-API level. unspecified at the GSS-API level.
The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API
mechanism OID associated with a SASL mechanism name. mechanism OID associated with a SASL mechanism name.
11.1. gss_inquire_mech_for_saslname 12.1. gss_inquire_mech_for_saslname
The C binding for the GSS_Inquire_mech_for_SASLname call is as The C binding for the GSS_Inquire_mech_for_SASLname call is as
follows. follows.
As mentioned in [RFC2744], routines may return GSS_S_FAILURE, As mentioned in [RFC2744], routines may return GSS_S_FAILURE,
indicating an implementation-specific or mechanism-specific error indicating an implementation-specific or mechanism-specific error
condition, further details of which are reported via the minor_status condition, further details of which are reported via the minor_status
parameter. parameter.
OM_uint32 gss_inquire_mech_for_saslname( OM_uint32 gss_inquire_mech_for_saslname(
skipping to change at page 20, line 5 skipping to change at page 21, line 48
In particular, the application should not attempt In particular, the application should not attempt
to free it. Specify NULL if not required. to free it. Specify NULL if not required.
Function value: GSS status code: Function value: GSS status code:
GSS_S_COMPLETE Successful completion. GSS_S_COMPLETE Successful completion.
GSS_S_BAD_MECH There is no GSS-API mechanism known GSS_S_BAD_MECH There is no GSS-API mechanism known
as sasl_mech_name. as sasl_mech_name.
12. Security Layers 13. Security Layers
GS2 does not support SASL security layers. Applications that need GS2 does not support SASL security layers. Applications that need
integrity or confidentiality protection can use either channel integrity or confidentiality protection can use either channel
binding to a secure external channel or another SASL mechanism that binding to a secure external channel or another SASL mechanism that
does provide security layers. does provide security layers.
13. Interoperability with the SASL GSSAPI Mechanism 14. Interoperability with the SASL GSSAPI Mechanism
The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL
under the name GSSAPI, see [RFC4752]. The Kerberos V5 mechanism may under the name GSSAPI, see [RFC4752]. The Kerberos V5 mechanism may
also be used with the GS2 family. This causes an interoperability also be used with the GS2 family. This causes an interoperability
problem, which is discussed and resolved below. problem, which is discussed and resolved below.
13.1. The Interoperability Problem 14.1. The Interoperability Problem
The SASL "GSSAPI" mechanism is not wire compatible with the Kerberos The SASL "GSSAPI" mechanism is not wire compatible with the Kerberos
V GSS-API mechanism used as a SASL GS2 mechanism. V GSS-API mechanism used as a SASL GS2 mechanism.
If a client (or server) only support Kerberos V5 under the "GSSAPI" If a client (or server) only support Kerberos V5 under the "GSSAPI"
name, and the server (or client) only support Kerberos V5 under the name, and the server (or client) only support Kerberos V5 under the
GS2 family, the mechanism negotiation will fail. GS2 family, the mechanism negotiation will fail.
13.2. Resolving the Problem 14.2. Resolving the Problem
If the Kerberos V5 mechanism is supported under GS2 in a server, the If the Kerberos V5 mechanism is supported under GS2 in a server, the
server SHOULD also support Kerberos V5 through the "GSSAPI" server SHOULD also support Kerberos V5 through the "GSSAPI"
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] and [MITM]). protection against active attackers (see [RFC5056] and [MITM]).
13.3. Additional Recommendations 14.3. Additional Recommendations
If the application requires SASL security layers, then it MUST use If the application requires SASL security layers, then it MUST use
the SASL "GSSAPI" mechanism [RFC4752] instead of "GS2-KRB5" or "GS2- the SASL "GSSAPI" mechanism [RFC4752] instead of "GS2-KRB5" or "GS2-
KRB5-PLUS". 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 15. GSS-API Mechanisms That Negotiate Other Mechanisms
A GSS-API mechanism that negotiates other mechanisms will interact A GSS-API mechanism that negotiates other mechanisms will interact
badly with the SASL mechanism negotiation. There are two problems. badly with the SASL mechanism negotiation. There are two problems.
The 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 15.1. The Interoperability Problem
If a client implements 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 implements 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 15.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 negotiates negotiate mechanism X by using a GSS-API mechanism that negotiates
other mechanisms (such as Simple and Protected GSS-API Negotiation other mechanisms (such as Simple and Protected GSS-API Negotiation
(SPNEGO) [RFC4178]), it may end up using mechanism Z when it ideally (SPNEGO) [RFC4178]), it may end up using mechanism Z when it ideally
should have used mechanism Y. For this reason, the use of GSS-API should have used mechanism Y. For this reason, the use of GSS-API
mechanisms that negotiate other mechanisms is disallowed under GS2. mechanisms that negotiate other mechanisms is disallowed under GS2.
14.3. Resolving the Problems 15.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.
The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech
[RFC5587] can be used to identify such mechanisms. [RFC5587] can be used to identify such mechanisms.
15. IANA Considerations 16. IANA Considerations
The IANA has registered a SASL mechanism family as per [RFC4422] The IANA has registered a SASL mechanism family as per [RFC4422]
using the following information. using the following information.
Subject: Registration of SASL mechanism family GS2-* Subject: Registration of SASL mechanism family GS2-*
SASL mechanism prefix: GS2- SASL mechanism prefix: GS2-
Security considerations: RFC 5801 Security considerations: RFC 5801
Published specification: RFC 5801 Published specification: RFC 5801
Person & email address to contact for further information: Person & email address to contact for further information:
Simon Josefsson <simon@josefsson.org> Simon Josefsson <simon@josefsson.org>
skipping to change at page 22, line 33 skipping to change at page 24, line 18
registry. registry.
The IANA is further advised that GS2 SASL mechanism names MUST NOT The IANA is further advised that GS2 SASL mechanism names MUST NOT
end in "-PLUS" except as a version of another mechanism name simply end in "-PLUS" except as a version of another mechanism name simply
suffixed with "-PLUS". suffixed with "-PLUS".
The SASL names for the Kerberos V5 GSS-API mechanism [RFC4121] The SASL names for the Kerberos V5 GSS-API mechanism [RFC4121]
[RFC1964] used via GS2 SHALL be "GS2-KRB5" and "GS2-KRB5-PLUS". [RFC1964] used via GS2 SHALL be "GS2-KRB5" and "GS2-KRB5-PLUS".
The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be
"SPNEGO" and "SPNEGO-PLUS". As described in Section 14, the SASL "SPNEGO" and "SPNEGO-PLUS". As described in Section 15, the SASL
"SPNEGO" and "SPNEGO-PLUS" MUST NOT be used. These names are "SPNEGO" and "SPNEGO-PLUS" MUST NOT be used. These names are
provided as a convenience for SASL library implementors. provided as a convenience for SASL library implementors.
16. Security Considerations 17. Security Considerations
Security issues are also discussed throughout this memo. Security issues are also discussed throughout this memo.
The security provided by a GS2 mechanism depends on the security of The security provided by a GS2 mechanism depends on the security of
the GSS-API mechanism. The GS2 mechanism family depends on channel the GSS-API mechanism. The GS2 mechanism family depends on channel
binding support, so GSS-API mechanisms that do not support channel binding support, so GSS-API mechanisms that do not support channel
binding cannot be successfully used as SASL mechanisms via the GS2 binding cannot be successfully used as SASL mechanisms via the GS2
bridge. bridge.
Because GS2 does not support security layers, it is strongly Because GS2 does not support security layers, it is strongly
skipping to change at page 24, line 5 skipping to change at page 25, line 32
GS2 does not protect against downgrade attacks of channel binding GS2 does not protect against downgrade attacks of channel binding
types. Negotiation of channel binding type was intentionally left types. Negotiation of channel binding type was intentionally left
out of scope for this document. 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
[RFC4121] [RFC1964]), also apply. [RFC4121] [RFC1964]), also apply.
17. Acknowledgements 18. Acknowledgements
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 RFC 2222. This document was derived from [SASL-GSSAPI], specified by RFC 2222. This document was derived from
which was prepared by Alexey Melnikov with significant contributions draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
from John G. Myers, although the majority of this document has been significant contributions from John G. Myers, although the majority
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. Other suggestions to the documents the document and the protocol. Other suggestions to the documents
were made by Spencer Dawkins, Ralph Droms, Adrian Farrel, Robert were made by Spencer Dawkins, Ralph Droms, Adrian Farrel, Robert
Sparks, and Glen Zorn. Sparks, and Glen Zorn.
18. References 19. References
19.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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
skipping to change at page 25, line 20 skipping to change at page 26, line 47
[CCITT.X690.2002] [CCITT.X690.2002]
International Telephone and Telegraph Consultative International Telephone and Telegraph Consultative
Committee, "ASN.1 encoding rules: Specification of basic Committee, "ASN.1 encoding rules: Specification of basic
encoding Rules (BER), Canonical encoding rules (CER) and encoding Rules (BER), Canonical encoding rules (CER) and
Distinguished encoding rules (DER)", CCITT Recommendation Distinguished encoding rules (DER)", CCITT Recommendation
X.690, July 2002. X.690, July 2002.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010. for TLS", RFC 5929, July 2010.
18.2. Informative References 19.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
(SPKM)", RFC 2025, October 1996. (SPKM)", RFC 2025, October 1996.
skipping to change at page 26, line 15 skipping to change at page 27, line 41
[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple [RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
Authentication and Security Layer (SASL) Mechanism", Authentication and Security Layer (SASL) Mechanism",
RFC 4752, November 2006. RFC 4752, November 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5587] Williams, N., "Extended Generic Security Service Mechanism [RFC5587] Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", RFC 5587, July 2009. Inquiry APIs", RFC 5587, July 2009.
[RFC5802] Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, [RFC5802] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism "Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle [RFC6595] Wierenga, K., Lear, E., and S. Josefsson, "A Simple
in Tunnelled Authentication", in 11th Security Authentication and Security Layer (SASL) and GSS-API
Protocols Workshop, 2002. Mechanism for the Security Assertion Markup Language
(SAML)", RFC 6595, April 2012.
[SASL-GSSAPI] [RFC6616] Lear, E., Tschofenig, H., Mauldin, H., and S. Josefsson,
Melnikov, A., "The Kerberos V5 ("GSSAPI") SASL mechanism", "A Simple Authentication and Security Layer (SASL) and
Work in Progress, March 2005. Generic Security Service Application Program Interface
(GSS-API) Mechanism for OpenID", RFC 6616, May 2012.
Authors' Addresses [MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunnelled Authentication",
WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
Author's Address
Simon Josefsson Simon Josefsson
SJD AB SJD AB
Hagagatan 24 Hagagatan 24
Stockholm 113 47 Stockholm 113 47
SE SE
EMail: simon@josefsson.org Email: simon@josefsson.org
URI: http://josefsson.org/ URI: http://josefsson.org/
Nicolas Williams
Oracle
5300 Riata Trace Ct
Austin, TX 78727
USA
EMail: Nicolas.Williams@oracle.com
 End of changes. 48 change blocks. 
101 lines changed or deleted 158 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/