draft-ietf-sasl-gs2-12.txt   draft-ietf-sasl-gs2-13.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: October 20, 2009 Sun Microsystems Expires: November 27, 2009 Sun Microsystems
April 18, 2009 May 26, 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-12 draft-ietf-sasl-gs2-13
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 October 20, 2009. This Internet-Draft will expire on November 27, 2009.
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 3, line 17 skipping to change at page 3, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 5 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 5
3.2. Computing mechanism names manually . . . . . . . . . . . . 6 3.2. Computing mechanism names manually . . . . . . . . . . . . 6
3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 7 3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 7
4. SASL Authentication Exchange Message Format . . . . . . . . . 7 4. SASL Authentication Exchange Message Format . . . . . . . . . 7
4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 7 4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 7
5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Channel Binding to TLS Channels . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Authentication Conditions . . . . . . . . . . . . . . . . . . 11 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 11
8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 12 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 12
9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 12 10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 12
10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 13 10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 14
11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 13 11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 14
11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 15 11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 16
12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 15 12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 16
13. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 16 13. Interoperability with the SASL GSSAPI mechanism . . . . . . . 17
13.1. The interoperability problem . . . . . . . . . . . . . . . 16 13.1. The interoperability problem . . . . . . . . . . . . . . . 17
13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 16 13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 17
13.3. Additional Recommendations . . . . . . . . . . . . . . . . 16 13.3. Additional Recommendations . . . . . . . . . . . . . . . . 17
14. Mechanisms that negotiate other mechanisms . . . . . . . . . . 17 14. GSS-API Mechanisms that negotiate other mechanisms . . . . . . 18
14.1. The interoperability problem . . . . . . . . . . . . . . . 17 14.1. The interoperability problem . . . . . . . . . . . . . . . 18
14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 17 14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 18
14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 17 14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 18
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
16. Security Considerations . . . . . . . . . . . . . . . . . . . 18 16. Security Considerations . . . . . . . . . . . . . . . . . . . 19
17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
18.1. Normative References . . . . . . . . . . . . . . . . . . . 19 18.1. Normative References . . . . . . . . . . . . . . . . . . . 20
18.2. Informative References . . . . . . . . . . . . . . . . . . 20 18.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Generic Security Service Application Program Interface (GSS-API) Generic Security Service Application Program Interface (GSS-API)
[RFC2743] is a framework that provides security services to [RFC2743] is a framework that provides security services to
applications using a variety of authentication "mechanisms". Simple applications using a variety of authentication "mechanisms". Simple
Authentication and Security Layer (SASL) [RFC4422] is a framework to Authentication and Security Layer (SASL) [RFC4422] is a framework to
provide authentication and "security layers" for connection based provide authentication and "security layers" for connection based
protocols, also using a variety of mechanisms. This document protocols, also using a variety of mechanisms. This document
describes how to use a GSS-API mechanism as though it were a SASL describes how to use a GSS-API mechanism as though it were a SASL
mechanism. This facility is called "GS2" -- a moniker that indicates mechanism. This facility is called GS2 -- a moniker that indicates
that this is the second GSS-API->SASL mechanism bridge. The original that this is the second GSS-API->SASL mechanism bridge. The original
GSS-API->SASL mechanism bridge was specified by [RFC2222], now GSS-API->SASL mechanism bridge was specified by [RFC2222], now
[RFC4752]; we shall sometimes refer to the original bridge as "GS1" [RFC4752]; we shall sometimes refer to the original bridge as GS1 in
in this document. this document.
All GSS-API mechanisms are implicitly registered for use within SASL All GSS-API mechanisms are implicitly registered for use within SASL
by this specification. The SASL mechanisms defined in this document by this specification. The SASL mechanisms defined in this document
are known as the "GS2 family of mechanisms". are known as the GS2 family of mechanisms.
The GS1 bridge failed to gain wide deployment for any GSS-API The GS1 bridge failed to gain wide deployment for any GSS-API
mechanism other than The "Kerberos V5 GSS-API mechanism" [RFC1964] mechanism other than The "Kerberos V5 GSS-API mechanism" [RFC1964]
[RFC4121], and has a number of problems that lead us to desire a new [RFC4121], and has a number of problems that lead us to desire a new
bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1 bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1
did not support channel binding [RFC5056]. These problems and the did not support channel binding [RFC5056]. These problems and the
opportunity to create the next SASL password-based mechanism, SCRAM opportunity to create the next SASL password-based mechanism, SCRAM
[I-D.newman-auth-scram], as a GSS-API mechanism used by SASL [I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL
applications via GS2, provide the motivation for GS2. applications via GS2, provide the motivation for GS2.
In particular, the current consensus of the SASL community appears to In particular, the current consensus of the SASL community appears to
be that SASL "security layers" (i.e., confidentiality and integrity be that SASL "security layers" (i.e., confidentiality and integrity
protection of application data after authentication) are too complex protection of application data after authentication) are too complex
and, since SASL applications tend to have an option to run over a and, since SASL applications tend to have an option to run over a
Transport Layer Security (TLS) [RFC5246] channel, redundant and best Transport Layer Security (TLS) [RFC5246] channel, redundant and best
replaced with channel binding. replaced with channel binding.
GS2 is designed to be as simple as possible. It adds to GSS-API GS2 is designed to be as simple as possible. It adds to GSS-API
skipping to change at page 5, line 34 skipping to change at page 5, line 34
If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2
implementation need some other mechanism to map mechanism OIDs to implementation need some other mechanism to map mechanism OIDs to
SASL name internally. In this case, the implementation can only SASL name internally. In this case, the implementation can only
support the mechanisms for which it knows the SASL name. If the support the mechanisms for which it knows the SASL name. If the
GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation
cannot map the OID to a SASL mechanism name using some other means, cannot map the OID to a SASL mechanism name using some other means,
it cannot use the particular GSS-API mechanism since it does not know it cannot use the particular GSS-API mechanism since it does not know
its SASL mechanism name. its SASL mechanism name.
If the GSS_Inquire_SASLname_for_mech call is successful, but provides
a zero length string [FIXME: is this a good idea? --simon], it means
the GSS-API mechanism did not have a registered mechanism name. In
this case, the GS2 implementation can derive the SASL mechanism name
from the GSS-API mechanism OID as follows.
3.1. Generating SASL mechanism names from GSS-API OIDs 3.1. Generating SASL mechanism names from GSS-API OIDs
For GSS-API mechanisms whose SASL names are not defined together with For GSS-API mechanisms whose SASL names are not defined together with
the GSS-API mechanism or in this document, the SASL mechanism name is the GSS-API mechanism or in this document, the SASL mechanism name is
concatenation of the string "GS2-" and the Base32 encoding [RFC4648] concatenation of the string "GS2-" and the Base32 encoding [RFC4648]
(with an upper case alphabet) of the first 55 bits of the binary (with an upper case alphabet) of the first 55 bits of the binary
SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER
encoding [CCITT.X690.2002], including the tag and length octets, of encoding [CCITT.X690.2002], including the tag and length octets, of
the GSS-API mechanism's Object Identifier. The Base32 rules on the GSS-API mechanism's Object Identifier. The Base32 rules on
padding characters and characters outside of the base32 alphabet are padding characters and characters outside of the base32 alphabet are
skipping to change at page 8, line 11 skipping to change at page 8, line 9
Note that when using a GS2 mechanism the SASL client is always a GSS- 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 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 the SASL client calls GSS_Init_sec_context and the server calls
GSS_Accept_sec_context. GSS_Accept_sec_context.
All the SASL authentication messages exchanged are exactly the same All the SASL authentication messages exchanged are exactly the same
as the security context tokens of the GSS-API mechanism, except for as the security context tokens of the GSS-API mechanism, except for
the initial security context token. the initial security context token.
Also, the server SHOULD refrain from sending GSS-API error tokens The client and server MAY send GSS-API error tokens (tokens output by
(tokens output by GSS_Init_sec_context or GSS_Accept_sec_context GSS_Init_sec_context() or GSS_Accept_sec_context() when the major
along with a major status code other than GSS_S_COMPLETE or status code is other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED).
GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions. As this indicate an error condition, after sending the token, the
sending side should fail the authentication.
The initial security context token is modified as follows: The initial security context token is modified as follows:
o The [RFC2743] section 3.1 initial context token header MUST be o The [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
skipping to change at page 10, line 20 skipping to change at page 10, line 19
application channel binding data in the GSS-API channel binding input application channel binding data in the GSS-API channel binding input
to GSS_Accept_sec_context. If the client channel binding flag was to GSS_Accept_sec_context. If the client channel binding flag was
"y" and the server does support channel binding then the server MUST "y" and the server does support channel binding then the server MUST
fail authentication. If the client channel binding flag was "p" the fail authentication. If the client channel binding flag was "p" the
server MUST include application channel binding data in the GSS-API server MUST include application channel binding data in the GSS-API
channel binding input to GSS_Accept_sec_context. channel binding input to GSS_Accept_sec_context.
For more discussions of channel bindings, and the syntax of the For more discussions of channel bindings, and the syntax of the
channel binding data for various security protocols, see [RFC5056]. channel binding data for various security protocols, see [RFC5056].
5.1. Channel Binding to TLS Channels
If an external TLS channel is to be bound into the GS2
authentication, and if the channel was established using a X.509
[RFC5280] server certificate to authenticate the server, then the GS2
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 GS2
authentication, and if the channel was established either without the
use of any X.509 server certificate to authenticate the server, or
with a non X.509 server certificate, then the GS2 client and server
MUST use the 'tls-unique' channel binding type.
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: na=someuser,<initial context token with standard C: na=someuser,<initial context token with standard
header removed> header removed>
S: Send reply context token as is S: Send reply context token as is
skipping to change at page 13, line 5 skipping to change at page 13, line 31
o GSS_S_COMPLETE indicates successful completion, and that output o GSS_S_COMPLETE indicates successful completion, and that output
parameters holds correct information. parameters holds correct information.
o GSS_S_BAD_MECH indicates that a desired_mech was unsupported by o GSS_S_BAD_MECH indicates that a desired_mech was unsupported by
the GSS-API implementation. the GSS-API implementation.
The GSS_Inquire_SASLname_for_mech call is used to get the SASL The GSS_Inquire_SASLname_for_mech call is used to get the SASL
mechanism name for a GSS-API mechanism. It also returns a name mechanism name for a GSS-API mechanism. It also returns a name
and description of the mechanism in a human readable form. and description of the mechanism in a human readable form.
The output variable sasl_mech_name will hold the IANA registered
mechanism name for the GSS-API mechanism, or if none is
registered, a mechanism named computed from the OID as
described in section 3.1 of this document.
10.1. gss_inquire_saslname_for_mech 10.1. gss_inquire_saslname_for_mech
The C binding for the GSS_Inquire_SASLname_for_mech call is as The C binding for the GSS_Inquire_SASLname_for_mech call is as
follows. follows.
OM_uint32 gss_inquire_saslname_for_mech( OM_uint32 gss_inquire_saslname_for_mech(
OM_uint32 *minor_status, OM_uint32 *minor_status,
const gss_OID desired_mech, const gss_OID desired_mech,
gss_buffer_t sasl_mech_name, gss_buffer_t sasl_mech_name,
gss_buffer_t mech_name, gss_buffer_t mech_name,
skipping to change at page 16, line 12 skipping to change at page 17, line 12
first client authentication message, and starting with a character first client authentication message, and starting with a character
other than "F", "n", "y" or "p". The server could accept the other than "F", "n", "y" or "p". The server could accept the
opportunistic proposal (reply token prefixed with a byte indicating opportunistic proposal (reply token prefixed with a byte indicating
acceptance) or reject it along with an indication of the server's acceptance) or reject it along with an indication of the server's
acceptable sec layers and max buffer size. In the latter case the acceptable sec layers and max buffer size. In the latter case the
GSS-API security context token exchange must be abandoned and GSS-API security context token exchange must be abandoned and
recommenced, although this would be a detail of the GS2 bridge not recommenced, although this would be a detail of the GS2 bridge not
exposed to the SASL application. The negotiation would be protected exposed to the SASL application. The negotiation would be protected
via GSS channel binding, as with the rest of GS2.] via GSS channel binding, as with the rest of GS2.]
13. Interoperability with the SASL "GSSAPI" mechanism 13. Interoperability with the SASL GSSAPI mechanism
The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL
under the name "GSSAPI", see GSSAPI mechanism [RFC4752]. The under the name GSSAPI, see GSSAPI mechanism [RFC4752]. The Kerberos
Kerberos V5 mechanism may also be used with the GS2 family. This V5 mechanism may also be used with the GS2 family. This causes an
causes an interoperability problem, which is discussed and resolved interoperability problem, which is discussed and resolved below.
below.
13.1. The interoperability problem 13.1. The interoperability problem
The SASL "GSSAPI" mechanism is not wire-compatible with the Kerberos The SASL "GSSAPI" mechanism is not wire-compatible with the Kerberos
V GSS-API mechanism used as a SASL GS2 mechanism. V GSS-API mechanism used as a SASL GS2 mechanism.
If a client (or server) only support Kerberos V5 under the "GSSAPI" If a client (or server) only support Kerberos V5 under the "GSSAPI"
name and the server (or client) only support Kerberos V5 under the name and the server (or client) only support Kerberos V5 under the
GS2 family, the mechanism negotiation will fail. GS2 family, the mechanism negotiation will fail.
skipping to change at page 17, line 5 skipping to change at page 18, line 5
13.3. Additional Recommendations 13.3. Additional Recommendations
If the application requires security layers then it MUST prefer the If the application requires security layers then it MUST prefer the
SASL "GSSAPI" mechanism over "GS2-KRB5" or "GS2-KRB5-PLUS". SASL "GSSAPI" mechanism over "GS2-KRB5" or "GS2-KRB5-PLUS".
If the application can use channel binding to an external channel If the application can use channel binding to an external channel
then it is RECOMMENDED that it select Kerberos V5 through the GS2 then it is RECOMMENDED that it select Kerberos V5 through the GS2
mechanism rather than the "GSSAPI" mechanism. mechanism rather than the "GSSAPI" mechanism.
14. Mechanisms that negotiate other mechanisms 14. GSS-API Mechanisms that negotiate other mechanisms
A GSS-API mechanism that negotiate other mechanisms interact badly A GSS-API mechanism that negotiate other mechanisms interact badly
with the SASL mechanism negotiation. There are two problems. The with the SASL mechanism negotiation. There are two problems. The
first is an interoperability problem and the second is a security first is an interoperability problem and the second is a security
concern. The problems are described and resolved below. concern. The problems are described and resolved below.
14.1. The interoperability problem 14.1. The interoperability problem
If a client implement GSS-API mechanism X, potentially negotiated If a client implement GSS-API mechanism X, potentially negotiated
through a GSS-API mechanism Y, and the server also implement GSS-API through a GSS-API mechanism Y, and the server also implement GSS-API
skipping to change at page 21, line 19 skipping to change at page 22, line 19
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.
[I-D.newman-auth-scram] [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[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-newman-auth-scram-12 (work in progress), March 2009. draft-ietf-sasl-scram-00 (work in progress), May 2009.
[I-D.ietf-kitten-extended-mech-inquiry] [I-D.ietf-kitten-extended-mech-inquiry]
Williams, N., "Extended Generic Security Service Mechanism Williams, N., "Extended Generic Security Service Mechanism
Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-06 Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-06
(work in progress), April 2009. (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.
 End of changes. 18 change blocks. 
46 lines changed or deleted 65 lines changed or added

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