draft-ietf-sasl-gs2-17.txt   draft-ietf-sasl-gs2-18.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Internet-Draft SJD AB Internet-Draft SJD AB
Intended status: Standards Track N. Williams Intended status: Standards Track N. Williams
Expires: March 13, 2010 Sun Microsystems Expires: May 13, 2010 Sun Microsystems
September 9, 2009 November 9, 2009
Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
draft-ietf-sasl-gs2-17 draft-ietf-sasl-gs2-18
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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 13, 2010. This Internet-Draft will expire on May 13, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document describes how to use a Generic Security Service described in the BSD License.
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. 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 4
3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 5 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 4
3.2. Computing mechanism names manually . . . . . . . . . . . . 6 3.2. Computing mechanism names manually . . . . . . . . . . . . 5
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 7 3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 6
4. SASL Authentication Exchange Message Format . . . . . . . . . 7 4. SASL Authentication Exchange Message Format . . . . . . . . . 6
5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Content of GSS-CHANNEL-BINDINGS structure . . . . . . . . 10 5.1. Content of GSS-CHANNEL-BINDINGS structure . . . . . . . . 10
5.2. Default Channel Binding . . . . . . . . . . . . . . . . . 10 5.2. Default Channel Binding . . . . . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Authentication Conditions . . . . . . . . . . . . . . . . . . 12 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 12
8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 13 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 13
9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 13 10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 13
10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 15 10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 15
11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 15 11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 15
11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 17 11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 17
12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 17 12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 17
13. Interoperability with the SASL GSSAPI mechanism . . . . . . . 17 13. Interoperability with the SASL GSSAPI mechanism . . . . . . . 17
13.1. The interoperability problem . . . . . . . . . . . . . . . 17 13.1. The interoperability problem . . . . . . . . . . . . . . . 17
skipping to change at page 8, line 26 skipping to change at page 8, line 26
o The [RFC2743] section 3.1 initial context token header MUST be o The [RFC2743] section 3.1 initial context token header MUST be
removed if present. If the header is not present, the client MUST removed if present. If the header is not present, the client MUST
send a "gs2-nonstd-flag" flag (see below). On the server side send a "gs2-nonstd-flag" flag (see below). On the server side
this header MUST be recomputed and restored prior to passing the this header MUST be recomputed and restored prior to passing the
token to GSS_Accept_sec_context, except when the "gs2-nonstd-flag" token to GSS_Accept_sec_context, except when the "gs2-nonstd-flag"
is sent. is sent.
o A GS2 header MUST be prefixed to the resulting initial context o A GS2 header MUST be prefixed to the resulting initial context
token. This header has the form "gs2-header" given below in ABNF token. This header has the form "gs2-header" given below in ABNF
[RFC5234]. [RFC5234].
The figure below describes the permissible attributes, their use, and
the format of their values. All attribute names are single US-ASCII
letters and are case-sensitive.
UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F
;; As UTF8-1 in RFC 3629 except ;; As UTF8-1 in RFC 3629 except
;; NUL, "=", and ",". ;; NUL, "=", and ",".
UTF8-2 = <as defined in RFC 3629 (STD 63)> UTF8-2 = <as defined in RFC 3629 (STD 63)>
UTF8-3 = <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-4 = <as defined in RFC 3629 (STD 63)>
UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4 UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4
saslname = 1*(UTF8-char-safe / "=2C" / "=3D") saslname = 1*(UTF8-char-safe / "=2C" / "=3D")
gs2-authzid = "a=" saslname gs2-authzid = "a=" saslname
;; GS2 has to transport an authzid since ;; GS2 has to transport an authzid since
;; the GSS-API has no equivalent ;; the GSS-API has no equivalent
gs2-nonstd-flag = "F" gs2-nonstd-flag = "F"
;; "F" means the mechanism is not a ;; "F" means the mechanism is not a
;; standard GSS-API mechanism in that the ;; standard GSS-API mechanism in that the
;; RFC2743 section 3.1 header was missing ;; RFC2743 section 3.1 header was missing
cb-name = 1*(ALPHA / DIGIT / "." / "-") cb-name = 1*(ALPHA / DIGIT / "." / "-")
;; See RFC 5056 section 7 ;; See RFC 5056 section 7
gs2-cb-flag = "p=" cb-name / "n" / "y" gs2-cb-flag = ("p=" cb-name) / "n" / "y"
;; GS2 channel binding (CB) flag ;; GS2 channel binding (CB) flag
;; "p" -> client supports and used CB ;; "p" -> client supports and used CB
;; "n" -> client does not support CB ;; "n" -> client does not support CB
;; "y" -> client supports CB, thinks the server ;; "y" -> client supports CB, thinks the server
;; does not ;; does not
gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] "," gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] ","
;; The GS2 header is gs2-header. ;; The GS2 header is gs2-header.
When the "gs2-nonstd-flag" flag is present, the client did not find/ When the "gs2-nonstd-flag" flag is present, the client did not find/
remove a [RFC2743] section 3.1 token header from the initial token remove a [RFC2743] section 3.1 token header from the initial token
skipping to change at page 13, line 28 skipping to change at page 14, line 10
GSS_Accept_sec_context) to requested authzid failed. GSS_Accept_sec_context) to requested authzid failed.
o If the client is not authorized to the requested authzid or an o If the client is not authorized to the requested authzid or an
authzid could not be derived from the client's initiator principal authzid could not be derived from the client's initiator principal
name. name.
8. GSS-API Parameters 8. GSS-API Parameters
GS2 does not use any GSS-API per-message tokens. Therefore the GS2 does not use any GSS-API per-message tokens. Therefore the
setting of req_flags related to per-message tokens is irrelevant. setting of req_flags related to per-message tokens is irrelevant.
The mutual_req_flag MUST be set. If channel binding is used then the
client MUST check that the corresponding ret_flag is set when the
context is fully establish, else authentication MUST fail.
Use or non-use of deleg_req_flag and anon_req_flag is an
implementation-specific detail. SASL and GS2 implementors are
encouraged to provide programming interfaces by which clients may
choose to delegate credentials and by which servers may receive them.
SASL and GS2 implementors are encouraged to provide programming
interfaces which provide a good mapping of GSS-API naming options.
9. Naming 9. Naming
There's no requirement that any particular GSS-API name-types be There's 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 protocol's profile, and "hostname" is the fully qualified host name
of the server. of the server.
skipping to change at page 21, line 25 skipping to change at page 22, line 25
17. Acknowledgements 17. 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 RFC2222. This document was derived from specified by RFC2222. This document was derived from
draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
significant contributions from John G. Myers, although the majority significant contributions from John G. Myers, although the majority
of this document has been rewritten by the current authors. of this document has been rewritten by the current authors.
Contributions of many members of the SASL mailing list are gratefully Contributions of many members of the SASL mailing list are gratefully
acknowledged. In particular, ideas and feedback from Sam Hartman, acknowledged. In particular, ideas and feedback from Pasi Eronen,
Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved the document Sam Hartman, Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved
and the protocol. the document and the protocol.
18. References 18. References
18.1. Normative References 18.1. Normative References
[FIPS.180-1.1995] [FIPS.180-1.1995]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-1, April 1995, Hash Standard", FIPS PUB 180-1, April 1995,
<http://www.itl.nist.gov/fipspubs/fip180-1.htm>. <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
skipping to change at page 23, line 20 skipping to change at page 24, line 20
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.
[I-D.ietf-sasl-scram] [I-D.ietf-sasl-scram]
Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams,
"Salted Challenge Response (SCRAM) SASL Mechanism", "Salted Challenge Response (SCRAM) SASL and GSS-API
draft-ietf-sasl-scram-05 (work in progress), August 2009. Mechanism", draft-ietf-sasl-scram-10 (work in progress),
October 2009.
[I-D.altman-tls-channel-bindings] [I-D.altman-tls-channel-bindings]
Altman, J., Williams, N., and L. Zhu, "Channel Bindings Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", draft-altman-tls-channel-bindings-06 (work in for TLS", draft-altman-tls-channel-bindings-07 (work in
progress), August 2009. progress), October 2009.
[mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle [mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
in Tunneled Authentication", in Tunneled Authentication",
WWW http://www.saunalahti.fi/~asokan/research/mitm.html. WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
Authors' Addresses Authors' Addresses
Simon Josefsson Simon Josefsson
SJD AB SJD AB
Hagagatan 24 Hagagatan 24
 End of changes. 15 change blocks. 
50 lines changed or deleted 71 lines changed or added

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