draft-ietf-sasl-gs2-15.txt   draft-ietf-sasl-gs2-16.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: February 1, 2010 Sun Microsystems Expires: February 5, 2010 Sun Microsystems
July 31, 2009 August 4, 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-15 draft-ietf-sasl-gs2-16
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. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 February 1, 2010. This Internet-Draft will expire on February 5, 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 10, line 44 skipping to change at page 10, line 44
The application-data field MUST be set to the gs2-header concatenated The application-data field MUST be set to the gs2-header concatenated
with, when a gs2-cb-flag of "p" is used, the application's channel with, when a gs2-cb-flag of "p" is used, the application's channel
binding data. binding data.
5.2. Default Channel Binding 5.2. Default Channel Binding
A default channel binding type agreement process for all SASL A default channel binding type agreement process for all SASL
application protocols that do not provide their own channel binding application protocols that do not provide their own channel binding
type agreement is provided as follows. type agreement is provided as follows.
Clients and servers MUST implement the "tls-unique" [tls-unique] 'tls-unique' is the default channel binding type for any application
[I-D.altman-tls-channel-bindings] channel binding type. Clients and that doesn't specify one.
servers SHOULD choose the highest-layer/innermost end-to-end TLS
channel as the channel to bind to.
Clients SHOULD choose the tls-unique channel binding type. Servers MUST implement the "tls-unique" [tls-unique]
Conversely, clients MAY choose a different channel binding type based [I-D.altman-tls-channel-bindings] channel binding type, if they
on user input, configuration, or a future, as-yet undefined channel implement any channel binding. Clients SHOULD implement the "tls-
binding type negotiation protocol. Servers MUST choose the channel unique" channel binding type, if they implement any channel binding.
binding type indicated by the client, if they support it. Clients and servers SHOULD choose the highest-layer/innermost end-to-
end TLS channel as the channel to bind to.
Servers MUST choose the channel binding type indicated by the client,
or fail authentication if they don't support it.
6. Examples 6. Examples
Example #1: a one round-trip GSS-API context token exchange, no Example #1: a one round-trip GSS-API context token exchange, no
channel binding, optional authzid given. channel binding, optional authzid given.
C: Request authentication exchange C: Request authentication exchange
S: Empty Challenge S: Empty Challenge
C: n,a=someuser,<initial context token with standard C: n,a=someuser,<initial context token with standard
header removed> header removed>
skipping to change at page 19, line 17 skipping to change at page 19, line 17
14.3. Resolving the problems 14.3. Resolving the problems
GSS-API mechanisms that negotiate other mechanisms MUST NOT be used GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT
be used as a GS2 mechanism. To make this easier for SASL be used as a GS2 mechanism. To make this easier for SASL
implementations we assign a symbolic SASL mechanism name to the implementations we assign a symbolic SASL mechanism name to the
SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST
NOT choose the SPNEGO mechanism under any circumstances. NOT choose the SPNEGO mechanism under any circumstances.
The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech
[I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such [RFC5587] can be used to identify such mechanisms.
mechanisms.
15. IANA Considerations 15. IANA Considerations
The IANA is advised that SASL mechanism names starting with "GS2-" The IANA is advised that SASL mechanism names starting with "GS2-"
are reserved for SASL mechanisms which conform to this document. The are reserved for SASL mechanisms which conform to this document. The
IANA is directed to place a statement to that effect in the sasl- IANA is directed to place a statement to that effect in the sasl-
mechanisms registry. mechanisms registry.
The IANA is further advised that GS2 SASL mechanism names MUST NOT The IANA is further advised that GS2 SASL mechanism names MUST NOT
end in "-PLUS" except as a version of another mechanism name simply end in "-PLUS" except as a version of another mechanism name simply
skipping to change at page 23, line 15 skipping to change at page 23, line 15
Program Interface (GSS-API) Negotiation Mechanism", Program Interface (GSS-API) Negotiation Mechanism",
RFC 4178, October 2005. RFC 4178, October 2005.
[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple [RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
Authentication and Security Layer (SASL) Mechanism", Authentication and Security Layer (SASL) Mechanism",
RFC 4752, November 2006. RFC 4752, November 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5587] Williams, N., "Extended Generic Security Service Mechanism
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 Mechanism",
draft-ietf-sasl-scram-02 (work in progress), July 2009. draft-ietf-sasl-scram-04 (work in progress), July 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-05 (work in for TLS", draft-altman-tls-channel-bindings-05 (work in
progress), June 2009. progress), June 2009.
[I-D.ietf-kitten-extended-mech-inquiry]
Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-06
(work in progress), April 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
Stockholm 113 47 Stockholm 113 47
 End of changes. 9 change blocks. 
21 lines changed or deleted 20 lines changed or added

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