--- /dev/null
+
+
+
+Network Working Group S. Josefsson
+Internet-Draft SJD AB
+Intended status: Standards Track N. Williams
+Expires: September 24, 2009 Sun Microsystems
+ March 23, 2009
+
+
+ Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
+ draft-ietf-sasl-gs2-11
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79. This document may contain material
+ from IETF Documents or IETF Contributions published or made publicly
+ available before November 10, 2008. The person(s) controlling the
+ copyright in some of this material may not have granted the IETF
+ Trust the right to allow modifications of such material outside the
+ IETF Standards Process. Without obtaining an adequate license from
+ the person(s) controlling the copyright in such materials, this
+ document may not be modified outside the IETF Standards Process, and
+ derivative works of it may not be created outside the IETF Standards
+ Process, except to format it for publication as an RFC or to
+ translate it into languages other than English.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on September 24, 2009.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 1]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+Abstract
+
+ This document describes how to use a Generic Security Service
+ Application Program Interface (GSS-API) mechanism in the the Simple
+ Authentication and Security Layer (SASL) framework. This is done by
+ defining a new SASL mechanism family, called GS2. This mechanism
+ family offers a number of improvements over the previous "SASL/
+ 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.
+
+ See <http://josefsson.org/sasl-gs2-*/> for more information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 2]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions used in this document . . . . . . . . . . . . . . 5
+ 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 5
+ 3.2. Computing mechanism names manually . . . . . . . . . . . . 5
+ 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. SASL Authentication Exchange Message Format . . . . . . . . . 7
+ 4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 7
+ 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9
+ 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 11
+ 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 11
+ 9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 10. GSS_Mechanism_SASLname call . . . . . . . . . . . . . . . . . 11
+ 10.1. gss_mechanism_saslname . . . . . . . . . . . . . . . . . . 13
+ 11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 13
+ 11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 15
+ 12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 15
+ 13. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 16
+ 13.1. The interoperability problem . . . . . . . . . . . . . . . 16
+ 13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 16
+ 13.3. Additional Recommendations . . . . . . . . . . . . . . . . 16
+ 14. Mechanisms that negotiate other mechanisms . . . . . . . . . . 17
+ 14.1. The interoperability problem . . . . . . . . . . . . . . . 17
+ 14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 17
+ 14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 17
+ 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
+ 16. Security Considerations . . . . . . . . . . . . . . . . . . . 18
+ 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
+ 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+ 18.1. Normative References . . . . . . . . . . . . . . . . . . . 19
+ 18.2. Informative References . . . . . . . . . . . . . . . . . . 20
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 3]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+1. Introduction
+
+ Generic Security Service Application Program Interface (GSS-API)
+ [RFC2743] is a framework that provides security services to
+ applications using a variety of authentication "mechanisms". Simple
+ Authentication and Security Layer (SASL) [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 [RFC2222], now
+ [RFC4752]; we shall sometimes refer to the original bridge as "GS1"
+ in this document.
+
+ 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".
+
+ The GS1 bridge failed to gain wide deployment for any GSS-API
+ mechanism other than The "Kerberos V GSS-API mechanism" [RFC1964]
+ [RFC4121], and has a number of problems that lead us to desire a new
+ bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1
+ did not support channel binding [RFC5056]. These problems and the
+ opportunity to create the next SASL password-based mechanism, SCRAM
+ [I-D.newman-auth-scram], as a GSS-API mechanism used by SASL
+ applications via GS2, provide the motivation for GS2.
+
+ 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, since SASL applications tend to have an option to run over a
+ Transport Layer Security (TLS) [RFC5246] channel, redundant and best
+ replaced with channel binding.
+
+ 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 (2 bytes or 4 bytes plus the
+ length of the client requested SASL authorization ID (authzid)) to
+ the initial context token and to the application channel binding
+ data, and it 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 [RFC2743] (see section 3.1).
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 4]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+2. Conventions used in this document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+
+3. Mechanism name
+
+3.1. Generating SASL mechanism names from GSS-API OIDs
+
+ 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.
+
+ 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_Mechanism_Name call (see below) to
+ query for the SASL mechanism name of a GSS-API mechanism.
+
+ 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 Base32 encoding [RFC4648]
+ (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
+ encoding [CCITT.X690.2002], 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.
+
+3.2. Computing mechanism names 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
+ in advance. It also obliterate the need to implement Base32, SHA-1
+ and DER in the SASL mechanism. The computed mechanism name can be
+ used directly in the implementation, and the implementation need not
+ concern itself with that the mechanism is part of a mechanism family.
+
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 5]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+3.3. Examples
+
+ 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
+ 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:
+
+ 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
+
+ The last step translate each decimal value using table 3 in Base32
+ [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI
+ mechanism is "GS2-DT4PIK22T6A".
+
+ 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
+ 86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
+ 93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to
+ binary, and re-group them in groups of 5, and convert them back to
+ decimal, which results in these computations:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 6]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ 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
+
+ The last step translate each decimal value using table 3 in Base32
+ [RFC4648]. 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". But instead, we
+ assign the Kerberos V mechanism a non-hash-derived mechanism name:
+ "KerberosV-GS2" and "KerberosV-GS2-PLUS" (see Section 15).
+
+
+4. SASL Authentication Exchange Message Format
+
+4.1. SASL Messages
+
+ During the SASL authentication exchange for GS2, a number of messages
+ following the following format is sent between the client and server.
+ 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 (or to fail to do so).
+
+ Note that when using a GS2 mechanism the SASL client is always a GSS-
+ API initiator and the SASL server is always a GSS-API acceptor. Thus
+ the SASL client calls GSS_Init_sec_context() and the server calls
+ GSS_Accept_sec_context().
+
+ 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.
+
+ Also, the server SHOULD refrain from sending GSS-API error tokens
+ (tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
+ along with a major status code other than GSS_S_COMPLETE or
+ GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 7]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ The initial security context token is modified as follows:
+ o The [RFC2743] section 3.1 initial context token header MUST be
+ removed if present, and its presence is noted (see below). On the
+ server side this header MUST be recomputed and restored prior to
+ passing the token to GSS_Accept_sec_context().
+ o A GS2 header MUST be prefixed to the resulting initial context
+ token. This header has the form given below in ABNF [RFC5234].
+
+ 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 / 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-std-mech = "F"
+ ;; "F" means the mechanism is NOT is a
+ ;; standard GSS-API mechanism in that the
+ ;; RFC2743 section 3.1 header was missing
+ gs2-cb-flag = "n" / "y" / "p"
+ ;; GS2 channel binding (CB) flag
+ ;; "n" -> client does not support CB
+ ;; "y" -> client supports CB, thinks the server
+ ;; does not
+ ;; "p" -> client supports and used CB
+ gs2-header = [gs2-std-mech] gs2-cb-flag [gs2-authzid] ","
+ ;; The GS2 header is gs2-header.
+ ;; gs2-std-mech is present if the GSS-API
+ ;; mechanism's initial context token did not
+ ;; have the standard header defined in
+ ;; [RFC2743] section 3.1.
+
+ The GS2 header is also prepended to the application's channel binding
+ data. If the application did not provide channel binding data then
+ the GS2 header is used as though it were application-provided channel
+ binding data.
+
+ The "gs2-authzid" holds the SASL authorization identity. It is
+ encoded using UTF-8 [RFC3629] with three exceptions:
+ o The NUL characters is forbidden as required by section 3.4.1 of
+ [RFC4422].
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 8]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ o The server MUST replace any occurance of "," (comma) in the string
+ with "=2C".
+ o The server MUST replace any occurance of "=" (comma) in the string
+ with "=3D".
+
+ If a server sends a string that does not conform to this syntax, the
+ client MUST reject authentication.
+
+
+5. Channel Bindings
+
+ If the server supports channel binding then it must list both forms
+ of the SASL mechanism name for each GSS-API mechanism supported via
+ GS2 (i.e., GSS-API mechanisms that support channel binding).
+
+ If the client supports channel binding and the server does not (i.e.,
+ the server did not advertise the -PLUS names) then the client MUST
+ either fail authentication or it MUST set the channel binding flag in
+ the GS2 initial security context token to "y" and MUST NOT include
+ application channel binding data in the GSS-API channel binding input
+ to GSS_Init_sec_context().
+
+ If the client supports channel binding and the server also does then
+ the client MUST set the channel binding flag in the GS2 initial
+ security context token to "p" and MUST include application channel
+ binding data in the GSS-API channel binding input to
+ GSS_Init_sec_context().
+
+ If the client does not support channel binding then it MUST set the
+ channel binding flag in the GS2 initial security context token to "n"
+ and MUST NOT include application channel binding data in the GSS-API
+ channel binding input to GSS_Init_sec_context().
+
+ Upon receipt of the initial authentication message the server checks
+ the channel binding flag in the GS2 header and constructs a channel
+ binding data input for GSS_Accept_sec_context() accordingly. If the
+ client channel binding flag was "n" then the server MUST NOT include
+ application channel binding data in the GSS-API channel binding input
+ to GSS_Accept_sec_context(). If the client channel binding flag was
+ "y" and the server does support channel binding then the server MUST
+ fail authentication. If the client channel binding flag was "p" the
+ server MUST include application channel binding data in the GSS-API
+ channel binding input to GSS_Accept_sec_context().
+
+ For more discussions of channel bindings, and the syntax of the
+ channel binding data for various security protocols, see [RFC5056].
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 9]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+6. Examples
+
+ Example #1: a one round-trip GSS-API context token exchange, no
+ channel binding, optional authzid given.
+
+ C: Request authentication exchange
+ S: Empty Challenge
+ C: nauthzid=someuser, <initial context token with standard
+ header removed>
+ S: Send reply context token as is
+ C: Empty message
+ S: Outcome of authentication exchange
+
+ Example #2: a one and one half round-trip GSS-API context token
+ exchange.
+
+ C: Request authentication exchange
+ S: Empty Challenge
+ C: nauthzid=someuser, <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
+
+ Example #3: a two round-trip GSS-API context token exchange.
+
+ C: Request authentication exchange
+ S: Empty Challenge
+ C: nauthzid=someuser, <initial context token with standard
+ header removed>
+ 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
+
+ Example #4: using channel binding.
+
+ C: Request authentication exchange
+ S: Empty Challenge
+ C: yauthzid=someuser, <initial context token with standard
+ header removed>
+ S: Send reply context token as is
+ ...
+
+ 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
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 10]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ challenge (zero byte string) if it has not yet received a token from
+ the client. See section 3 of [RFC4422].
+
+
+7. Authentication Conditions
+
+ Authentication MUST NOT succeed if any one of the following
+ conditions are true:
+
+ o GSS_Init/Accept_sec_context() return anything other than
+ GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
+ o If the client's GS2 channel binding flag was "y" and the server
+ supports channel binding.
+ o If the client requires use of channel binding and the server did
+ not advertise support for channel binding.
+ o Authorization of client principal (i.e., src_name in
+ GSS_Accept_sec_context()) to requested authzid failed.
+ o If the client is not authorized to the requested authzid or an
+ authzid could not be derived from the client's initiator principal
+ name.
+
+
+8. GSS-API Parameters
+
+ GS2 does not use any GSS-API per-message tokens. Therefore the
+ setting of req_flags related to per-message tokens is irrelevant.
+
+
+9. Naming
+
+ 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 [RFC2743] section 4.1) and clients will
+ typically have username initiator principal names (see [RFC2743]
+ section 4.2).
+
+
+10. GSS_Mechanism_SASLname call
+
+ To allow SASL implementations to query for the SASL mechanism name of
+ a GSS-API mechanism, we specify a new GSS-API function for this
+ purpose.
+
+
+
+
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 11]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ Inputs:
+
+ o desired_mech OBJECT IDENTIFIER
+
+ Outputs:
+
+ o sasl_mech_name OCTET STRING -- SASL name for this mechanism
+ (really, ASCII)
+
+ o mech_name UTF-8 STRING -- name of this mechanism, possibly
+ localized
+
+ o mech_description UTF-8 STRING -- possibly localized
+ description of this mechanism.
+
+ 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 disred_mech was unsupported by
+ the GSS-API implementation.
+
+ The GSS_Mechanism_SASLname 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 a human readable form.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 12]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+10.1. gss_mechanism_saslname
+
+ The C binding for the GSS_Mechanism_SASLname call is as follows.
+
+ OM_uint32 gss_mechanism_saslname(
+ 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. Also output
+ a name and description of the mechanism in a human readable 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
+
+
+11. GSS_Inquire_mech_for_SASLname call
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 13]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ Inputs:
+
+ o sasl_mech_name OCTET STRING -- SASL name of mechanism
+ (really, ASCII)
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 14]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+11.1. gss_inquire_mech_for_saslname
+
+ The C binding for the GSS_Inquire_mech_for_SASLname call is as
+ follows.
+
+ 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
+
+
+12. Security Layers
+
+ GS2 does not currently support SASL security layers. Applications
+ that need integrity protection or confidentiality and integrity
+ protection MUST use either channel binding to a secure external
+ channel or a SASL mechanism that does provide security layers.
+
+ NOTE WELL: the GS2 client's first authentication message MUST always
+ start with "F", "n", "y" or "p", otherwise the server MUST fail
+ authentication. This will allow us to add support for security
+ layers in the future if it were to become necessary. Note that
+ adding security layer support to GS2 must not break existing SASL/GS2
+ applications, which can be accomplished by making security layers
+ optional.
+
+ [A sketch of how to add sec layer support... Add a way for the
+ client to: a) make an offer of sec layers and max buffer, b) make an
+ opportunistic selection of sec layer and buffer size, both in the
+ first client authentication message, and starting with a character
+ other than "F", "n", "y" or "p". The server could accept the
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 15]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ opportunistic proposal (reply token prefixed with a byte indicating
+ acceptance) or reject it along with an indication of the server's
+ acceptable sec layers and max buffer size. In the latter case the
+ GSS-API security context token exchange must be abandoned and
+ recommenced, although this would be a detail of the GS2 bridge not
+ exposed to the SASL application. The negotiation would be protected
+ via GSS channel binding, as with the rest of GS2.]
+
+
+13. Interoperability with the SASL "GSSAPI" mechanism
+
+ The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL
+ under the name "GSSAPI", see GSSAPI mechanism [RFC4752]. The
+ Kerberos V5 mechanism may also be used with the GS2 family. This
+ causes an interopability problem, which is discussed and resolved
+ below.
+
+13.1. The interoperability problem
+
+ The SASL "GSSAPI" mechanism is not wire-compatible with the Kerberos
+ V GSS-API mechanism used as a SASL GS2 mechanism.
+
+ 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.
+
+13.2. Resolving the problem
+
+ If the Kerberos V5 mechanism is supported under GS2 in a server, the
+ server SHOULD also support Kerberos V5 through the "GSSAPI"
+ mechanism, to avoid interoperability problems with older clients.
+
+ Reasons for violating this recommendation may include security
+ considerations regarding the absent features in the GS2 mechanism.
+ The 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 [RFC5056], [mitm]).
+
+13.3. Additional Recommendations
+
+ If the application requires security layers then it MUST prefer the
+ SASL "GSSAPI" mechanism over "KerberosV-GS2".
+
+ 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.
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 16]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+14. Mechanisms that negotiate other mechanisms
+
+ A GSS-API mechanism that negotiate other mechanisms interact badly
+ with the SASL mechanism negotiation. There are two problems. The
+ first is an interoperability problem and the second is a security
+ concern. The problems are described and resolved below.
+
+14.1. The interoperability problem
+
+ If a client implement GSS-API mechanism X, potentially negotiated
+ through a GSS-API mechanism Y, and the server also implement GSS-API
+ mechanism X negotiated through a GSS-API mechanism Z, the
+ authentication negotiation will fail.
+
+14.2. Security problem
+
+ If a client's policy is to first prefer GSSAPI mechanism X, then non-
+ GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
+ mechanisms Y and Z but not X, then if the client attempts to
+ negotiate mechanism X by using a GSS-API mechanism that negotiate
+ other mechanisms (such as SPNEGO), it may end up using mechanism Z
+ when it ideally should have used mechanism Y. For this reason, the
+ use of GSS-API mechanisms that negotiate other mechanisms are
+ disallowed under GS2.
+
+14.3. Resolving the problems
+
+ GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
+ with the GS2 SASL mechanism. Specifically SPNEGO [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. [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]
+
+ The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech()
+ [I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such
+ mechanisms.
+
+
+15. IANA Considerations
+
+ The SASL names for the Kerberos V GSS-API mechanism [RFC4121]
+ [RFC1964] used via GS2 SHALL be "KerberosV-GS2" and "KerberosV-GS2-
+ PLUS".
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 17]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ 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" MUST NOT be used. These names are
+ provided as a convienience for SASL library implementors.
+
+ 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.
+
+ The IANA is further advised that SASL mechanisms MUST NOT end in
+ "-PLUS" except as a version of another mechanism name simply suffixed
+ with "-PLUS".
+
+ Subject: Registration of SASL mechanism GS2-*
+ SASL mechanism prefix: GS2-
+ Security considerations: RFC [THIS-DOC]
+ Published specification: RFC [THIS-DOC]
+ Person & email address to contact for further information:
+ Simon Josefsson <simon@josefsson.org>
+ Intended usage: COMMON
+ Owner/Change controller: iesg@ietf.org
+ Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
+
+
+16. Security Considerations
+
+ Security issues are also discussed throughout this memo.
+
+ 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.
+
+ 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.
+
+ Use of channel binding will also protect the SASL mechanism
+ negotiation -- if there is no MITM then the external secure channel
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 18]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ will have protected the SASL mechanism negotiation.
+
+ The channel binding data MAY be sent (byt 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 [RFC5056].
+
+ 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 Domain Name
+ System [RFC1034] without DNSSEC [RFC4033].
+
+ GS2 does not directly use any cryptographic algorithms, therefore it
+ is automatically "algorithm agile", or, as agile as the GSS-API
+ mechanisms that are available for use in SASL apoplications via GS2.
+
+ The security considerations of SASL [RFC4422], the GSS-API [RFC2743],
+ channel binding [RFC5056], any external channels (such as TLS,
+ [RFC5246], channel binding types (see the IANA channel binding type
+ registry), and GSS-API mechanisms (such as the Kerberos V mechanism
+ [RFC4121] [RFC1964]), may also apply.
+
+
+17. Acknowledgements
+
+ 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.
+
+ Contributions of many members of the SASL mailing list are gratefully
+ acknowledged. In particular, ideas and feedback from Sam Hartman,
+ Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved the document
+ and the protocol.
+
+
+18. References
+
+18.1. Normative References
+
+ [FIPS.180-1.1995]
+ National Institute of Standards and Technology, "Secure
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 19]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ Hash Standard", FIPS PUB 180-1, April 1995,
+ <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2743] Linn, J., "Generic Security Service Application Program
+ Interface Version 2, Update 1", RFC 2743, January 2000.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
+ Security Layer (SASL)", RFC 4422, June 2006.
+
+ [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
+ Encodings", RFC 4648, October 2006.
+
+ [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
+ Channels", RFC 5056, November 2007.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+ [CCITT.X690.2002]
+ International International Telephone and Telegraph
+ Consultative Committee, "ASN.1 encoding rules:
+ Specification of basic encoding Rules (BER), Canonical
+ encoding rules (CER) and Distinguished encoding rules
+ (DER)", CCITT Recommendation X.690, July 2002.
+
+18.2. Informative References
+
+ [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
+ STD 13, RFC 1034, November 1987.
+
+ [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
+ RFC 1964, June 1996.
+
+ [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
+ (SPKM)", RFC 2025, October 1996.
+
+ [RFC2222] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
+ Rose, "DNS Security Introduction and Requirements",
+ RFC 4033, March 2005.
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 20]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+ Version 5 Generic Security Service Application Program
+ Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+ July 2005.
+
+ [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
+ Simple and Protected Generic Security Service Application
+ Program Interface (GSS-API) Negotiation Mechanism",
+ RFC 4178, October 2005.
+
+ [RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
+ Authentication and Security Layer (SASL) Mechanism",
+ RFC 4752, November 2006.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+ [I-D.newman-auth-scram]
+ Menon-Sen, A., Melnikov, A., and C. Newman, "Salted
+ Challenge Response (SCRAM) SASL Mechanism",
+ draft-newman-auth-scram-10 (work in progress),
+ February 2009.
+
+ [I-D.ietf-kitten-extended-mech-inquiry]
+ Williams, N., "Extended Generic Security Service Mechanism
+ Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-04
+ (work in progress), March 2008.
+
+ [mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
+ in Tunneled Authentication",
+ WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
+
+
+Authors' Addresses
+
+ Simon Josefsson
+ SJD AB
+ Hagagatan 24
+ Stockholm 113 47
+ SE
+
+ Email: simon@josefsson.org
+ URI: http://josefsson.org/
+
+
+
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 21]
+\f
+Internet-Draft SASL GS2-* March 2009
+
+
+ Nicolas Williams
+ Sun Microsystems
+ 5300 Riata Trace Ct
+ Austin, TX 78727
+ USA
+
+ Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson & Williams Expires September 24, 2009 [Page 22]
+\f
--- /dev/null
+
+
+
+NETWORK WORKING GROUP A. Menon-Sen
+Internet-Draft Oryx Mail Systems GmbH
+Intended status: Standards Track A. Melnikov
+Expires: September 24, 2009 Isode Ltd
+ C. Newman
+ N. Williams
+ Sun Microsystems
+ March 23, 2009
+
+
+ Salted Challenge Response (SCRAM) SASL Mechanism
+ draft-newman-auth-scram-11.txt
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on September 24, 2009.
+
+Copyright Notice
+
+ Copyright (c) 2009 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 1]
+\f
+Internet-Draft SCRAM March 2009
+
+
+Abstract
+
+ The secure authentication mechanism most widely deployed and used by
+ Internet application protocols is the transmission of clear-text
+ passwords over a channel protected by Transport Layer Security (TLS).
+ There are some significant security concerns with that mechanism,
+ which could be addressed by the use of a challenge response
+ authentication mechanism protected by TLS. Unfortunately, the
+ challenge response mechanisms presently on the standards track all
+ fail to meet requirements necessary for widespread deployment, and
+ have had success only in limited use.
+
+ This specification describes a family of authentication mechanisms
+ called the Salted Challenge Response Authentication Mechanism
+ (SCRAM), which addresses the security concerns and meets the
+ deployability requirements. When used in combination with TLS or an
+ equivalent security layer, a mechanism from this family could improve
+ the status-quo for application protocol authentication and provide a
+ suitable choice for a mandatory-to-implement mechanism for future
+ application protocol standards.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 2]
+\f
+Internet-Draft SCRAM March 2009
+
+
+Table of Contents
+
+ 1. Conventions Used in This Document . . . . . . . . . . 4
+ 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 4
+ 1.2. Notation . . . . . . . . . . . . . . . . . . . . . . . 5
+ 2. Introduction . . . . . . . . . . . . . . . . . . . . . 7
+ 3. SCRAM Algorithm Overview . . . . . . . . . . . . . . . 9
+ 4. SCRAM Mechanism Names . . . . . . . . . . . . . . . . 10
+ 5. SCRAM Authentication Exchange . . . . . . . . . . . . 11
+ 5.1. SCRAM Attributes . . . . . . . . . . . . . . . . . . . 12
+ 6. Channel Binding . . . . . . . . . . . . . . . . . . . 15
+ 6.1. Channel Binding to TLS Channels . . . . . . . . . . . 16
+ 7. Formal Syntax . . . . . . . . . . . . . . . . . . . . 17
+ 8. SCRAM as a GSS-API Mechanism . . . . . . . . . . . . . 20
+ 8.1. GSS-API Principal Name Types for SCRAM . . . . . . . . 20
+ 8.2. GSS-API Per-Message Tokens for SCRAM . . . . . . . . . 20
+ 8.3. GSS_Pseudo_random() for SCRAM . . . . . . . . . . . . 21
+ 9. Security Considerations . . . . . . . . . . . . . . . 22
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . 24
+ 11. Acknowledgements . . . . . . . . . . . . . . . . . . . 25
+ Appendix A. Other Authentication Mechanisms . . . . . . . . . . . 26
+ Appendix B. Design Motivations . . . . . . . . . . . . . . . . . . 27
+ Appendix C. SCRAM Examples and Internet-Draft Change History . . . 28
+ 12. References . . . . . . . . . . . . . . . . . . . . . . 31
+ 12.1. Normative References . . . . . . . . . . . . . . . . . 31
+ 12.2. Normative References for GSS-API implementors . . . . 31
+ 12.3. Informative References . . . . . . . . . . . . . . . . 32
+ Authors' Addresses . . . . . . . . . . . . . . . . . . 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 3]
+\f
+Internet-Draft SCRAM March 2009
+
+
+1. Conventions Used in This Document
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ Formal syntax is defined by [RFC5234] including the core rules
+ defined in Appendix B of [RFC5234].
+
+ Example lines prefaced by "C:" are sent by the client and ones
+ prefaced by "S:" by the server. If a single "C:" or "S:" label
+ applies to multiple lines, then the line breaks between those lines
+ are for editorial clarity only, and are not part of the actual
+ protocol exchange.
+
+1.1. Terminology
+
+ This document uses several terms defined in [RFC4949] ("Internet
+ Security Glossary") including the following: authentication,
+ authentication exchange, authentication information, brute force,
+ challenge-response, cryptographic hash function, dictionary attack,
+ eavesdropping, hash result, keyed hash, man-in-the-middle, nonce,
+ one-way encryption function, password, replay attack and salt.
+ Readers not familiar with these terms should use that glossary as a
+ reference.
+
+ Some clarifications and additional definitions follow:
+
+ o Authentication information: Information used to verify an identity
+ claimed by a SCRAM client. The authentication information for a
+ SCRAM identity consists of salt, iteration count, the "StoredKey"
+ and "ServerKey" (as defined in the algorithm overview) for each
+ supported cryptographic hash function.
+
+ o Authentication database: The database used to look up the
+ authentication information associated with a particular identity.
+ For application protocols, LDAPv3 (see [RFC4510]) is frequently
+ used as the authentication database. For network-level protocols
+ such as PPP or 802.11x, the use of RADIUS is more common.
+
+ o Base64: An encoding mechanism defined in [RFC4648] which converts
+ an octet string input to a textual output string which can be
+ easily displayed to a human. The use of base64 in SCRAM is
+ restricted to the canonical form with no whitespace.
+
+ o Octet: An 8-bit byte.
+
+ o Octet string: A sequence of 8-bit bytes.
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 4]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ o Salt: A random octet string that is combined with a password
+ before applying a one-way encryption function. This value is used
+ to protect passwords that are stored in an authentication
+ database.
+
+1.2. Notation
+
+ The pseudocode description of the algorithm uses the following
+ notations:
+
+ o ":=": The variable on the left hand side represents the octet
+ string resulting from the expression on the right hand side.
+
+ o "+": Octet string concatenation.
+
+ o "[ ]": A portion of an expression enclosed in "[" and "]" may not
+ be included in the result under some circumstances. See the
+ associated text for a description of those circumstances.
+
+ o HMAC(key, str): Apply the HMAC keyed hash algorithm (defined in
+ [RFC2104]) using the octet string represented by "key" as the key
+ and the octet string "str" as the input string. The size of the
+ result is the hash result size for the hash function in use. For
+ example, it is 20 octets for SHA-1 (see [RFC3174]).
+
+ o H(str): Apply the cryptographic hash function to the octet string
+ "str", producing an octet string as a result. The size of the
+ result depends on the hash result size for the hash function in
+ use.
+
+ o XOR: Apply the exclusive-or operation to combine the octet string
+ on the left of this operator with the octet string on the right of
+ this operator. The length of the output and each of the two
+ inputs will be the same for this use.
+
+ o Hi(str, salt):
+
+
+
+ U0 := HMAC(str, salt + INT(1))
+ U1 := HMAC(str, U0)
+ U2 := HMAC(str, U1)
+ ...
+ Ui-1 := HMAC(str, Ui-2)
+ Ui := HMAC(str, Ui-1)
+
+ Hi := U0 XOR U1 XOR U2 XOR ... XOR Ui
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 5]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ where "i" is the iteration count, "+" is the string concatenation
+ operator and INT(g) is a four-octet encoding of the integer g,
+ most significant octet first.
+
+ o This is, essentially, PBKDF2 [RFC2898] with HMAC() as the PRF and
+ with dkLen == output length of HMAC() == output length of H().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 6]
+\f
+Internet-Draft SCRAM March 2009
+
+
+2. Introduction
+
+ This specification describes a family of authentication mechanisms
+ called the Salted Challenge Response Authentication Mechanism (SCRAM)
+ which addresses the requirements necessary to deploy a challenge-
+ response mechanism more widely than past attempts. When used in
+ combination with Transport Layer Security (TLS, see [RFC5246]) or an
+ equivalent security layer, a mechanism from this family could improve
+ the status-quo for application protocol authentication and provide a
+ suitable choice for a mandatory-to-implement mechanism for future
+ application protocol standards.
+
+ For simplicity, this family of mechanism does not presently include
+ negotiation of a security layer. It is intended to be used with an
+ external security layer such as that provided by TLS or SSH, with
+ optional channel binding [RFC5056] to the external security layer.
+
+ SCRAM is specified herein as a pure Simple Authentication and
+ Security Layer (SASL) [RFC4422] mechanism, but it conforms to the new
+ bridge between SASL and the Generic Security Services Application
+ Programming Interface (GSS-API) called "GS2" [ref-needed]. This
+ means that SCRAM is actually both, a GSS-API and SASL mechanism.
+
+ SCRAM provides the following protocol features:
+
+ o The authentication information stored in the authentication
+ database is not sufficient by itself to impersonate the client.
+ The information is salted to prevent a pre-stored dictionary
+ attack if the database is stolen.
+
+ o The server does not gain the ability to impersonate the client to
+ other servers (with an exception for server-authorized proxies).
+
+ o The mechanism permits the use of a server-authorized proxy without
+ requiring that proxy to have super-user rights with the back-end
+ server.
+
+ o A standard attribute is defined to enable storage of the
+ authentication information in LDAPv3 (see [RFC4510]).
+
+ o Mutual authentication is supported, but only the client is named
+ (i.e., the server has no name).
+
+ For an in-depth discussion of why other challenge response mechanisms
+ are not considered sufficient, see appendix A. For more information
+ about the motivations behind the design of this mechanism, see
+ appendix B.
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 7]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ Comments regarding this draft may be sent either to the
+ ietf-sasl@imc.org mailing list or to the authors.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 8]
+\f
+Internet-Draft SCRAM March 2009
+
+
+3. SCRAM Algorithm Overview
+
+ Note that this section omits some details, such as client and server
+ nonces. See Section 5 for more details.
+
+ To begin with, the client is in possession of a username and
+ password. It sends the username to the server, which retrieves the
+ corresponding authentication information, i.e. a salt, StoredKey,
+ ServerKey and the iteration count i. (Note that a server
+ implementation may chose to use the same iteration count for all
+ account.) The server sends the salt and the iteration count to the
+ client, which then computes the following values and sends a
+ ClientProof to the server:
+
+
+ SaltedPassword := Hi(password, salt)
+ ClientKey := H(SaltedPassword)
+ StoredKey := H(ClientKey)
+ AuthMessage := client-first-message + "," +
+ server-first-message + "," +
+ client-final-message-without-proof
+ ClientSignature := HMAC(StoredKey, AuthMessage)
+ ClientProof := ClientKey XOR ClientSignature
+ ServerKey := HMAC(SaltedPassword, salt)
+ ServerSignature := HMAC(ServerKey, AuthMessage)
+
+
+ The server authenticates the client by computing the ClientSignature,
+ exclusive-ORing that with the ClientProof to recover the ClientKey
+ and verifying the correctness of the ClientKey by applying the hash
+ function and comparing the result to the StoredKey. If the ClientKey
+ is correct, this proves that the client has access to the user's
+ password.
+
+ Similarly, the client authenticates the server by computing the
+ ServerSignature and comparing it to the value sent by the server. If
+ the two are equal, it proves that the server had access to the user's
+ ServerKey.
+
+ The AuthMessage is computed by concatenating messages from the
+ authentication exchange. The format of these messages is defined in
+ Section 7.
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 9]
+\f
+Internet-Draft SCRAM March 2009
+
+
+4. SCRAM Mechanism Names
+
+ A SCRAM mechanism name is a string "SCRAM-HMAC-" followed by the
+ uppercased name of the underlying hashed function taken from the IANA
+ "Hash Function Textual Names" registry (see http://www.iana.org),
+ optionally followed by the suffix "-PLUS" (see below)..
+
+ For interoperability, all SCRAM clients and servers MUST implement
+ the SCRAM-HMAC-SHA-1 authentication mechanism, i.e. an authentication
+ mechanism from the SCRAM family that uses the SHA-1 hash function as
+ defined in [RFC3174].
+
+ The "-PLUS" suffix is used only when the server supports channel
+ binding to the external channel. In this case the server will
+ advertise both, SCRAM-HMAC-SHA-1 and SCRAM-HMAC-SHA-1-PLUS, otherwise
+ the server will advertise only SCRAM-HMAC-SHA-1. The "-PLUS" exists
+ to allow negotiation of the use of channel binding. See Section 6.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 10]
+\f
+Internet-Draft SCRAM March 2009
+
+
+5. SCRAM Authentication Exchange
+
+ SCRAM is a text protocol where the client and server exchange
+ messages containing one or more attribute-value pairs separated by
+ commas. Each attribute has a one-letter name. The messages and
+ their attributes are described in Section 5.1, and defined in
+ Section 7.
+
+ This is a simple example of a SCRAM-HMAC-SHA-1 authentication
+ exchange:
+
+
+ C: n,n=Chris Newman,r=ClientNonce
+ S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
+ C: r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
+ S: v=WxPv/siO5l+qxN4
+
+
+ With channel-binding data sent by the client this might look like
+ this:
+
+
+ C: p,n=Chris Newman,r=ClientNonce
+ S: r=ClientNonceServerNonce,s=PxR/wv+epq,i=128
+ C: c=0123456789ABCDEF,r=ClientNonceServerNonce,p=WxPv/siO5l+qxN4
+ S: v=WxPv/siO5l+qxN4
+
+
+ <<Note that the channel-bind data above, as well as all hashes are
+ fake>>
+
+ First, the client sends a message containing:
+
+ o a GS2 header consisting of a flag indicating whether channel
+ binding is supported-but-not-used, not supported, or used, and the
+ SASL authzid (optional);
+
+ o SCRAM username and client nonce attributes.
+
+ Note that the client's first message will always start with "n", "y"
+ or "p", otherwise the message is invalid and authentication MUST
+ fail. This is important, as it allows for GS2 extensibility (e.g.,
+ to add support for security layers).
+
+ In response, the server sends the user's iteration count i, the
+ user's salt, and appends its own nonce to the client-specified one.
+ The client then responds with the same nonce and a ClientProof
+ computed using the selected hash function as explained earlier. In
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 11]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ this step the client can also include an optional authorization
+ identity. The server verifies the nonce and the proof, verifies that
+ the authorization identity (if supplied by the client in the second
+ message) is authorized to act as the authentication identity, and,
+ finally, it responds with a ServerSignature, concluding the
+ authentication exchange. The client then authenticates the server by
+ computing the ServerSignature and comparing it to the value sent by
+ the server. If the two are different, the client MUST consider the
+ authentication exchange to be unsuccessful and it might have to drop
+ the connection.
+
+5.1. SCRAM Attributes
+
+ This section describes the permissible attributes, their use, and the
+ format of their values. All attribute names are single US-ASCII
+ letters and are case-sensitive.
+
+ o a: This is an optional attribute, and is part of the GS2 [ref-
+ needed] bridge between the GSS-API and SASL. This attribute
+ specifies an authorization identity. A client may include it in
+ its second message to the server if it wants to authenticate as
+ one user, but subsequently act as a different user. This is
+ typically used by an administrator to perform some management task
+ on behalf of another user, or by a proxy in some situations.
+
+ Upon the receipt of this value the server verifies its
+ correctness according to the used SASL protocol profile.
+ Failed verification results in failed authentication exchange.
+
+ If this attribute is omitted (as it normally would be), or
+ specified with an empty value, the authorization identity is
+ assumed to be derived from the username specified with the
+ (required) "n" attribute.
+
+ The server always authenticates the user specified by the "n"
+ attribute. If the "a" attribute specifies a different user,
+ the server associates that identity with the connection after
+ successful authentication and authorization checks.
+
+ The syntax of this field is the same as that of the "n" field
+ with respect to quoting of '=' and ','.
+
+ o n: This attribute specifies the name of the user whose password is
+ used for authentication. A client must include it in its first
+ message to the server. If the "a" attribute is not specified
+ (which would normally be the case), this username is also the
+ identity which will be associated with the connection subsequent
+ to authentication and authorization.
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 12]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ Before sending the username to the server, the client MUST
+ prepare the username using the "SASLPrep" profile [RFC4013] of
+ the "stringprep" algorithm [RFC3454]. If the preparation of
+ the username fails or results in an empty string, the client
+ SHOULD abort the authentication exchange (*).
+
+ (*) An interactive client can request a repeated entry of the
+ username value.
+
+ Upon receipt of the username by the server, the server SHOULD
+ prepare it using the "SASLPrep" profile [RFC4013] of the
+ "stringprep" algorithm [RFC3454]. If the preparation of the
+ username fails or results in an empty string, the server SHOULD
+ abort the authentication exchange.
+
+ The characters ',' or '=' in usernames are sent as '=2C' and
+ '=3D' respectively. If the server receives a username which
+ contains '=' not followed by either '2C' or '3D', then the
+ server MUST fail the authentication.
+
+ o m: This attribute is reserved for future extensibility. In this
+ version of SCRAM, its presence in a client or a server message
+ MUST cause authentication failure when the attribute is parsed by
+ the other end.
+
+ o r: This attribute specifies a sequence of random printable
+ characters excluding ',' which forms the nonce used as input to
+ the hash function. No quoting is applied to this string (<<unless
+ the binding of SCRAM to a particular protocol states otherwise>>).
+ As described earlier, the client supplies an initial value in its
+ first message, and the server augments that value with its own
+ nonce in its first response. It is important that this be value
+ different for each authentication. The client MUST verify that
+ the initial part of the nonce used in subsequent messages is the
+ same as the nonce it initially specified. The server MUST verify
+ that the nonce sent by the client in the second message is the
+ same as the one sent by the server in its first message.
+
+ o c: This REQUIRED attribute specifies base64-encoded of a header
+ and the channel-binding data. It is sent by the client in its
+ second authentication message. The header consist of:
+
+ * the GS2 header from the client's first message (recall: a
+ channel binding flag and an optional authzid);
+
+ * followed by the external channel's channel binding type prefix
+ (see [RFC5056], if and only if the client is using channel
+ binding;
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 13]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ * followed by the external channel's channel binding data, if and
+ only if the client is using channel binding.
+
+ o s: This attribute specifies the base64-encoded salt used by the
+ server for this user. It is sent by the server in its first
+ message to the client.
+
+ o i: This attribute specifies an iteration count for the selected
+ hash function and user, and must be sent by the server along with
+ the user's salt.
+
+ For SCRAM-HMAC-SHA-1 SASL mechanism servers SHOULD announce a
+ hash iteration-count of at least 128.
+
+ o p: This attribute specifies a base64-encoded ClientProof. The
+ client computes this value as described in the overview and sends
+ it to the server.
+
+ o v: This attribute specifies a base64-encoded ServerSignature. It
+ is sent by the server in its final message, and is used by the
+ client to verify that the server has access to the user's
+ authentication information. This value is computed as explained
+ in the overview.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 14]
+\f
+Internet-Draft SCRAM March 2009
+
+
+6. Channel Binding
+
+ SCRAM 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. SCRAM does not
+ provide security layers, however, therefore it is imperative that
+ SCRAM provide integrity protection for the negotiation of channel
+ binding.
+
+ Use of channel binding is negotiated as follows:
+
+ o The server advertises support for channel binding by advertising
+ both, SCRAM-HMAC-<hash-function> and SCRAM-HMAC-<hash-function>-
+ PLUS.
+
+ o If the client negotiates mechanisms then client MUST select SCRAM-
+ HMAC-<hash-function>-PLUS if offered by the server. Otherwise, if
+ the client does not negotiate mechanisms then it MUST select only
+ SCRAM-HMAC-<hash-function> (not suffixed with "-PLUS").
+
+ o If the client and server both support channel binding, or if the
+ client wishes to use channel binding but the client does not
+ negotiate mechanisms, the client MUST set the GS2 channel binding
+ flag to "p" and MUST include channel binding data for the external
+ channel in the computation of the "c=" attribute (see
+ Section 5.1).
+
+ o If the client supports channel binding but the server does not
+ then the client MUST set the GS2 channel binding flag to "y" and
+ MUST NOT include channel binding data for the external channel in
+ the computation of the "c=" attribute (see Section 5.1).
+
+ o If the client does not support channel binding then the client
+ MUST set the GS2 channel binding flag to "n" and MUST NOT include
+ channel binding data for the external channel in the computation
+ of the "c=" attribute (see Section 5.1).
+
+ o If the server receives a client first message with the GS2 channel
+ binding flag set to "y" and the server supports channel binding
+ the server MUST fail authentication. This is because if the
+ client sets the GS2 channel binding flag set to "y" then the
+ client must have believed that the server did not support channel
+ binding -- if the server did in fact support channel binding then
+ this is an indication that there has been a downgrade attack
+ (e.g., an attacker changed the server's mechanism list to exclude
+ the -PLUS suffixed SCRAM mechanism name(s)).
+
+ The server MUST always validate the client's "c=" field. The server
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 15]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ does this by constructing the value of the "c=" attribute and then
+ checking that it matches the client's c= attribute value.
+
+6.1. Channel Binding to TLS Channels
+
+ If an external TLS channel is to be bound into the SCRAM
+ authentication, and if the channel was established using a server
+ certificate to authenticate the server, then the SCRAM client and
+ server MUST use the 'tls-server-end-point' channel binding type. See
+ the IANA Channel Binding Types registry.
+
+ If an external TLS channel is to be bound into the SCRAM
+ authentication, and if the channel was established without the use of
+ any server certificate to authenticate the server, then the SCRAM
+ client and server MUST use the 'tls-unique' channel binding type.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 16]
+\f
+Internet-Draft SCRAM March 2009
+
+
+7. Formal Syntax
+
+ The following syntax specification uses the Augmented Backus-Naur
+ Form (ABNF) notation as specified in [RFC5234]. "UTF8-2", "UTF8-3"
+ and "UTF8-4" non-terminal are defined in [RFC3629].
+
+
+ ALPHA = <as defined in RFC 5234 appendix B.1>
+ DIGIT = <as defined in RFC 5234 appendix B.1>
+ 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)>
+
+ generic-message = attr-val *("," attr-val)
+ ;; Generic syntax of any server challenge
+ ;; or client response
+
+ attr-val = ALPHA "=" value
+
+ value = *value-char
+
+ value-safe-char = %x01-2B / %x2D-3C / %x3E-7F /
+ UTF8-2 / UTF8-3 / UTF8-4
+ ;; UTF8-char except NUL, "=", and ",".
+
+ value-char = value-safe-char / "="
+
+ base64-char = ALPHA / DIGIT / "/" / "+"
+
+ base64-4 = 4base64-char
+
+ base64-3 = 3base64-char "="
+
+ base64-2 = 2base64-char "=="
+
+ base64 = *base64-4 [base64-3 / base64-2]
+
+ posit-number = %x31-39 *DIGIT
+ ;; A positive number
+
+ saslname = 1*(value-safe-char / "=2C" / "=3D")
+ ;; Conforms to <value>
+
+ authzid = "a=" saslname
+ ;; Protocol specific.
+
+ gs2-cbind-flag = "n" / "y" / "p"
+ ;; "n" -> client doesn't support channel binding
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 17]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ ;; "y" -> client does support channel binding
+ ;; but thinks the server does not.
+ ;; "p" -> client requires channel binding
+ gs2-header = gs2-cbind-flag [ authzid ] ","
+ ;; GS2 header for SCRAM
+ ;; (the actual GS2 header includes an optional
+ ;; flag to indicate that the GSS mechanism is not
+ ;; "standard" but since SCRAM is "standard" we
+ ;; don't include that flag).
+
+ username = "n=" saslname
+ ;; Usernames are prepared using SASLPrep.
+
+ reserved-mext = "m=" 1*(value-char)
+ ;; Reserved for signalling mandatory extensions.
+ ;; The exact syntax will be defined in
+ ;; the future.
+
+ ;;cbind-type = value
+ ;;cbind-input = gs2-header [ value ":" cbind-data ]
+ channel-binding = "c=" base64
+ ;; base64 encoding of cbind-input
+
+ proof = "p=" base64
+
+ nonce = "r=" c-nonce [s-nonce]
+ ;; Second part provided by server.
+
+ c-nonce = value
+
+ s-nonce = value
+
+ salt = "s=" base64
+
+ verifier = "v=" base64
+ ;; base-64 encoded ServerSignature.
+
+ iteration-count = "i=" posit-number
+ ;; A positive number
+
+ client-first-message =
+ gs2-header [reserved-mext ","]
+ username "," nonce ["," extensions]
+
+ server-first-message =
+ [reserved-mext ","] nonce "," salt ","
+ iteration-count ["," extensions]
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 18]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ client-final-message-without-proof =
+ [channel-binding ","] nonce [","
+ extensions]
+
+ client-final-message =
+ client-final-message-without-proof "," proof
+
+ gss-server-error = "e=" value
+ server-final-message = gss-server-error /
+ verifier ["," extensions]
+ ;; The error message is only for the GSS-API
+ ;; form of SCRAM, and it is OPTIONAL to
+ ;; implement it.
+
+ extensions = attr-val *("," attr-val)
+ ;; All extensions are optional,
+ ;; i.e. unrecognized attributes
+ ;; not defined in this document
+ ;; MUST be ignored.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 19]
+\f
+Internet-Draft SCRAM March 2009
+
+
+8. SCRAM as a GSS-API Mechanism
+
+ This section and its sub-sections and all normative references of it
+ not referenced elsewhere in this document are INFORMATIONAL for SASL
+ implementors, but they are NORMATIVE for GSS-API implementors.
+
+ SCRAM is actually also GSS-API mechanism. The messages are the same,
+ but a) the GS2 header on the client's first message and channel
+ binding data is excluded when SCRAM is used as a GSS-API mechanism,
+ and b) the RFC2743 section 3.1 initial context token header is
+ prefixed to the client's first authentication message (context
+ token).
+
+ The GSS-API mechanism OID for SCRAM is <TBD> (see Section 10).
+
+8.1. GSS-API Principal Name Types for SCRAM
+
+ SCRAM does not name acceptors. Therefore only GSS_C_NO_NAME and
+ names of type GSS_C_NT_ANONYMOUS shall be allowed as the target name
+ input of GSS_Init_sec_context() when using a SCRAM mechanism.
+
+ SCRAM supports only a single name type for initiators:
+ GSS_C_NT_USER_NAME. GSS_C_NT_USER_NAME is the default name type for
+ SCRAM.
+
+ There is no name canonicalization procedure for SCRAM beyond applying
+ SASLprep as described in Section 5.1.
+
+ The query, display and exported name syntax for SCRAM principal names
+ is the same: there is no syntax -- SCRAM principal names are free-
+ form. (The exported name token does, of course, conform to [RFC2743]
+ section 3.2, but the "NAME" part of the token is just a SCRAM user
+ name.)
+
+8.2. GSS-API Per-Message Tokens for SCRAM
+
+ The per-message tokens for SCRAM as a GSS-API mechanism SHALL BE the
+ same as those for the Kerberos V GSS-API mechanism [RFC4121], using
+ the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].
+
+ The 128-bit session key SHALL be derived by using the least
+ significant (right-most) 128 bits of HMAC(StoredKey, "GSS-API session
+ key" || ClientKey || AuthMessage).
+
+ SCRAM does support PROT_READY, and is PROT_READY on the initiator
+ side first upon receipt of the server's reply to the initial security
+ context token.
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 20]
+\f
+Internet-Draft SCRAM March 2009
+
+
+8.3. GSS_Pseudo_random() for SCRAM
+
+ The GSS_Pseudo_random() [RFC4401] for SCRAM SHALL be the same as for
+ the Kerberos V GSS-API mechanism [RFC4402]. There is no acceptor-
+ asserted sub-session key for SCRAM, thus GSS_C_PRF_KEY_FULL and
+ GSS_C_PRF_KEY_PARTIAL are equivalent for SCRAM's GSS_Pseudo_random().
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 21]
+\f
+Internet-Draft SCRAM March 2009
+
+
+9. Security Considerations
+
+ If the authentication exchange is performed without a strong security
+ layer, then a passive eavesdropper can gain sufficient information to
+ mount an offline dictionary or brute-force attack which can be used
+ to recover the user's password. The amount of time necessary for
+ this attack depends on the cryptographic hash function selected, the
+ strength of the password and the iteration count supplied by the
+ server. An external security layer with strong encryption will
+ prevent this attack.
+
+ If the external security layer used to protect the SCRAM exchange
+ uses an anonymous key exchange, then the SCRAM channel binding
+ mechanism can be used to detect a man-in-the-middle attack on the
+ security layer and cause the authentication to fail as a result.
+ However, the man-in-the-middle attacker will have gained sufficient
+ information to mount an offline dictionary or brute-force attack.
+ For this reason, SCRAM includes the ability to increase the iteration
+ count over time.
+
+ If the authentication information is stolen from the authentication
+ database, then an offline dictionary or brute-force attack can be
+ used to recover the user's password. The use of salt mitigates this
+ attack somewhat by requiring a separate attack on each password.
+ Authentication mechanisms which protect against this attack are
+ available (e.g., the EKE class of mechanisms), but the patent
+ situation is presently unclear.
+
+ If an attacker obtains the authentication information from the
+ authentication repository and either eavesdrops on one authentication
+ exchange or impersonates a server, the attacker gains the ability to
+ impersonate that user to all servers providing SCRAM access using the
+ same hash function, password, iteration count and salt. For this
+ reason, it is important to use randomly-generated salt values.
+
+ SCRAM does not negotiate a hash function to use. Hash function
+ negotiation is left to the SASL mechanism negotiation. It is
+ important that clients be able to sort a locally available list of
+ mechanisms by preference so that the client may pick the most
+ preferred of a server's advertised mechanism list. This preference
+ order is not specified here as it is a local matter. The preference
+ order should include objective and subjective notions of mechanism
+ cryptographic strength (e.g., SCRAM with a successor to SHA-1 may be
+ preferred over SCRAM with SHA-1).
+
+ Note that to protect the SASL mechanism negotiation applications
+ normally must list the server mechs twice: once before and once after
+ authentication, the latter using security layers. Since SCRAM does
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 22]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ not provide security layers the only ways to protect the mechanism
+ negotiation are: a) use channel binding to an external channel, or b)
+ use an external channel that authenticates a user-provided server
+ name.
+
+ A hostile server can perform a computational denial-of-service attack
+ on clients by sending a big iteration count value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 23]
+\f
+Internet-Draft SCRAM March 2009
+
+
+10. IANA Considerations
+
+ IANA is requested to add the following entries to the SASL Mechanism
+ registry established by [RFC4422]:
+
+
+ To: iana@iana.org
+ Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1
+
+ SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1
+ Security considerations: Section 7 of [RFCXXXX]
+ Published specification (optional, recommended): [RFCXXXX]
+ Person & email address to contact for further information:
+ IETF SASL WG <ietf-sasl@imc.org>
+ Intended usage: COMMON
+ Owner/Change controller: IESG <iesg@ietf.org>
+ Note:
+
+ To: iana@iana.org
+ Subject: Registration of a new SASL mechanism SCRAM-HMAC-SHA-1-PLUS
+
+ SASL mechanism name (or prefix for the family): SCRAM-HMAC-SHA-1-PLUS
+ Security considerations: Section 7 of [RFCXXXX]
+ Published specification (optional, recommended): [RFCXXXX]
+ Person & email address to contact for further information:
+ IETF SASL WG <ietf-sasl@imc.org>
+ Intended usage: COMMON
+ Owner/Change controller: IESG <iesg@ietf.org>
+ Note:
+
+
+ Note that even though this document defines a family of SCRAM-HMAC
+ mechanisms, it doesn't register a family of SCRAM-HMAC mechanisms in
+ the SASL Mechanisms registry. IANA is requested to prevent future
+ registrations of SASL mechanisms starting with SCRAM-HMAC- without
+ consulting the SASL mailing list <ietf-sasl@imc.org> first.
+
+ Note to future SCRAM-HMAC mechanism designers: each new SCRAM-HMAC
+ SASL mechanism MUST be explicitly registered with IANA and MUST
+ comply with SCRAM-HMAC mechanism naming convention defined in
+ Section 4 of this document.
+
+ We hereby request that IANA assign a GSS-API mechanism OID for SCRAM.
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 24]
+\f
+Internet-Draft SCRAM March 2009
+
+
+11. Acknowledgements
+
+ The authors would like to thank Dave Cridland for his contributions
+ to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 25]
+\f
+Internet-Draft SCRAM March 2009
+
+
+Appendix A. Other Authentication Mechanisms
+
+ The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has
+ proved to be too complex to implement and test, and thus has poor
+ interoperability. The security layer is often not implemented, and
+ almost never used; everyone uses TLS instead. For a more complete
+ list of problems with DIGEST-MD5 which lead to the creation of SCRAM
+ see [I-D.ietf-sasl-digest-to-historic].
+
+ The CRAM-MD5 SASL mechanism, while widely deployed has also some
+ problems, in particular it is missing some modern SASL features such
+ as support for internationalized usernames and passwords, support for
+ passing of authorization identity, support for channel bindings. It
+ also doesn't support server authentication. For a more complete list
+ of problems with CRAM-MD5 see [I-D.ietf-sasl-crammd5-to-historic].
+
+ The PLAIN [RFC4616] SASL mechanism allows a malicious server or
+ eavesdropper to impersonate the authenticating user to any other
+ server for which the user has the same password. It also sends the
+ password in the clear over the network, unless TLS is used. Server
+ authentication is not supported.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 26]
+\f
+Internet-Draft SCRAM March 2009
+
+
+Appendix B. Design Motivations
+
+ The DIGEST-MD5 [I-D.ietf-sasl-digest-to-historic] mechanism has
+ proved to be too complex to implement and test, and thus has poor
+ interoperability. The security layer is often not implemented, and
+ almost never used; everyone uses TLS instead. For a more complete
+ list of problems with DIGEST-MD5 which lead to the creation of SCRAM
+ see [I-D.ietf-sasl-digest-to-historic].
+
+ The CRAM-MD5 SASL mechanism, while widely deployed has also some
+ problems, in particular it is missing some modern SASL features such
+ as support for internationalized usernames and passwords, support for
+ passing of authorization identity, support for channel bindings. It
+ also doesn't support server authentication. For a more complete list
+ of problems with CRAM-MD5 see [I-D.ietf-sasl-crammd5-to-historic].
+
+ The PLAIN [RFC4616] SASL mechanism allows a malicious server or
+ eavesdropper to impersonate the authenticating user to any other
+ server for which the user has the same password. It also sends the
+ password in the clear over the network, unless TLS is used. Server
+ authentication is not supported.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 27]
+\f
+Internet-Draft SCRAM March 2009
+
+
+Appendix C. SCRAM Examples and Internet-Draft Change History
+
+ <<To be written.>>
+
+ (RFC Editor: Please delete everything after this point)
+
+ Open Issues
+
+ o The appendices need to be written.
+
+ o Should the server send a base64-encoded ServerSignature for the
+ value of the "v" attribute, or should it compute a ServerProof the
+ way the client computes a ClientProof?
+
+ Changes since -10
+
+ o Converted the source for this I-D to XML.
+
+ o Added text to make SCRAM compliant with the new GS2 design.
+
+ o Added text on channel binding negotiation.
+
+ o Added text on channel binding, including a reference to RFC5056.
+
+ o Added text on SCRAM as a GSS-API mechanism. This noted as not
+ relevant to SASL-only implementors -- the normative references for
+ SCRAM as a GSS-API mechanism are segregated as well.
+
+ Changes since -07
+
+ o Updated References.
+
+ o Clarified purpose of the m= attribute.
+
+ o Fixed a problem with authentication/authorization identity's ABNF
+ not allowing for some characters.
+
+ o Updated ABNF for nonce to show client-generated and server-
+ generated parts.
+
+ o Only register SCRAM-HMAC-SHA-1 with IANA and require explicit
+ registrations of all other SCRAM-HMAC- mechanisms.
+
+ Changes since -06
+
+ o Removed hash negotiation from SCRAM and turned it into a family of
+ SASL mechanisms.
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 28]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ o Start using "Hash Function Textual Names" IANA registry for SCRAM
+ mechanism naming.
+
+ o Fixed definition of Hi(str, salt) to be consistent with [RFC2898].
+
+ o Clarified extensibility of SCRAM: added m= attribute (for future
+ mandatory extensions) and specified that all unrecognized
+ attributes must be ignored.
+
+ Changes since -05
+
+ o Changed the mandatory to implement hash algorithm to SHA-1 (as per
+ WG consensus).
+
+ o Added text about use of SASLPrep for username canonicalization/
+ validation.
+
+ o Clarified that authorization identity is canonicalized/verified
+ according to SASL protocol profile.
+
+ o Clarified that iteration count is per-user.
+
+ o Clarified how clients select the authentication function.
+
+ o Added IANA registration for the new mechanism.
+
+ o Added missing normative references (UTF-8, SASLPrep).
+
+ o Various editorial changes based on comments from Hallvard B
+ Furuseth, Nico William and Simon Josefsson.
+
+ Changes since -04
+
+ o Update Base64 and Security Glossary references.
+
+ o Add Formal Syntax section.
+
+ o Don't bother with "v=".
+
+ o Make MD5 mandatory to implement. Suggest i=128.
+
+ Changes since -03
+
+ o Seven years have passed, in which it became clear that DIGEST-MD5
+ suffered from unacceptably bad interoperability, so SCRAM-MD5 is
+ now back from the dead.
+
+ o Be hash agnostic, so MD5 can be replaced more easily.
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 29]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ o General simplification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 30]
+\f
+Internet-Draft SCRAM March 2009
+
+
+12. References
+
+12.1. Normative References
+
+ [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+ Hashing for Message Authentication", RFC 2104,
+ February 1997.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
+ (SHA1)", RFC 3174, September 2001.
+
+ [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
+ Internationalized Strings ("stringprep")", RFC 3454,
+ December 2002.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
+ and Passwords", RFC 4013, February 2005.
+
+ [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and
+ Security Layer (SASL)", RFC 4422, June 2006.
+
+ [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
+ Encodings", RFC 4648, October 2006.
+
+ [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
+ Channels", RFC 5056, November 2007.
+
+ [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+12.2. Normative References for GSS-API implementors
+
+ [RFC2743] Linn, J., "Generic Security Service Application Program
+ Interface Version 2, Update 1", RFC 2743, January 2000.
+
+ [RFC3962] Raeburn, K., "Advanced Encryption Standard (AES)
+ Encryption for Kerberos 5", RFC 3962, February 2005.
+
+ [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
+ Version 5 Generic Security Service Application Program
+ Interface (GSS-API) Mechanism: Version 2", RFC 4121,
+ July 2005.
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 31]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
+ Extension for the Generic Security Service Application
+ Program Interface (GSS-API)", RFC 4401, February 2006.
+
+ [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
+ Kerberos V Generic Security Service Application Program
+ Interface (GSS-API) Mechanism", RFC 4402, February 2006.
+
+12.3. Informative References
+
+ [I-D.ietf-sasl-crammd5-to-historic]
+ Zeilenga, K., "CRAM-MD5 to Historic",
+ draft-ietf-sasl-crammd5-to-historic-00 (work in progress),
+ November 2008.
+
+ [I-D.ietf-sasl-digest-to-historic]
+ Melnikov, A., "Moving DIGEST-MD5 to Historic",
+ draft-ietf-sasl-digest-to-historic-00 (work in progress),
+ July 2008.
+
+ [I-D.ietf-sasl-rfc2831bis]
+ Melnikov, A., "Using Digest Authentication as a SASL
+ Mechanism", draft-ietf-sasl-rfc2831bis-12 (work in
+ progress), March 2007.
+
+ [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP
+ AUTHorize Extension for Simple Challenge/Response",
+ RFC 2195, September 1997.
+
+ [RFC2202] Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and HMAC-
+ SHA-1", RFC 2202, September 1997.
+
+ [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography
+ Specification Version 2.0", RFC 2898, September 2000.
+
+ [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+ Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+ [RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP): Technical Specification Road Map", RFC 4510,
+ June 2006.
+
+ [RFC4616] Zeilenga, K., "The PLAIN Simple Authentication and
+ Security Layer (SASL) Mechanism", RFC 4616, August 2006.
+
+ [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
+ RFC 4949, August 2007.
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 32]
+\f
+Internet-Draft SCRAM March 2009
+
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
+ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 33]
+\f
+Internet-Draft SCRAM March 2009
+
+
+Authors' Addresses
+
+ Abhijit Menon-Sen
+ Oryx Mail Systems GmbH
+
+ Email: ams@oryx.com
+
+
+ Alexey Melnikov
+ Isode Ltd
+
+ Email: Alexey.Melnikov@isode.com
+
+
+ Chris Newman
+ Sun Microsystems
+ 1050 Lakes Drive
+ West Covina, CA 91790
+ USA
+
+ Email: chris.newman@sun.com
+
+
+ Nicolas Williams
+ Sun Microsystems
+ 5300 Riata Trace Ct
+ Austin, TX 78727
+ USA
+
+ Email: Nicolas.Williams@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Menon-Sen, et al. Expires September 24, 2009 [Page 34]
+\f
git.samba.org / metze / heimdal / wip.git / commitdiff