draft-ietf-sasl-gs2-05.txt   draft-ietf-sasl-gs2-06.txt 
Network Working Group S. Josefsson Network Working Group S. Josefsson
Intended status: Standards Track Intended status: Standards Track
Expires: July 13, 2007 Expires: August 10, 2007
Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
draft-ietf-sasl-gs2-05 draft-ietf-sasl-gs2-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 July 13, 2007. This Internet-Draft will expire on August 10, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document describes how to use a Generic Security Service This document describes how to use a Generic Security Service
Application Program Interface (GSS-API) mechanism in the the Simple Application Program Interface (GSS-API) mechanism in the the Simple
Authentication and Security Layer (SASL) framework. This is done by Authentication and Security Layer (SASL) framework. This is done by
defining a new SASL mechanism family, called GS2. This mechanism defining a new SASL mechanism family, called GS2. This mechanism
family offers a number of improvements over the previous SASL/GSS-API family offers a number of improvements over the previous SASL/GSS-API
mechanism: it is more general, uses fewer messages for the mechanism: it is more general, uses fewer messages for the
authentication phase in some cases, and supports a SASL-specific authentication phase in some cases, and supports a SASL-specific
skipping to change at page 16, line 30 skipping to change at page 16, line 30
fields are not mentioned. fields are not mentioned.
An authentication exchange using GS2 may look like: An authentication exchange using GS2 may look like:
C: Request authentication exchange C: Request authentication exchange
S: Send ["", ""] token S: Send ["", ""] token
C: Send [GSS_Init_sec_context, ""] token C: Send [GSS_Init_sec_context, ""] token
... ...
S: After PROT_READY is set, S: After PROT_READY is set,
send [GSS_Accept_sec_context, send [GSS_Accept_sec_context,
wrap_length, GS2_Wrap(server_qops | server_maxbuf] GS2_Wrap(server_qops | server_maxbuf]
... ...
C: After PROT_READY is set, C: After PROT_READY is set,
send [GSS_Init_sec_context, send [GSS_Init_sec_context,
wrap_length, GS2_Wrap (client_qop | client_maxbuf | GS2_Wrap (client_qop | client_maxbuf | authzid)]
authzid)]
S: Send [GSS_Accept_sec_context, ""] token S: Send [GSS_Accept_sec_context, ""] token
C: Send [GSS_Init_sec_context, ""] token C: Send [GSS_Init_sec_context, ""] token
... ...
S: Outcome of authentication exchange S: Outcome of authentication exchange
Because GSS-API authentication is initiated by the client, the length Because GSS-API authentication is initiated by the client, the length
field will be 0 in the initial token from the server to the client field will be 0 in the initial token from the server to the client
when the protocol profile does not support additional information to when the protocol profile does not support additional information to
be sent together with the authentication request. be sent together with the authentication request.
skipping to change at page 31, line 44 skipping to change at page 31, line 44
ISO Standard 8824, December 1990. ISO Standard 8824, December 1990.
16.2. Informative References 16.2. Informative References
[9] Mockapetris, P., "Domain names - concepts and facilities", [9] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, [10] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964,
June 1996. June 1996.
[11] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API [11] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
Negotiation Mechanism", RFC 2478, December 1998. Simple and Protected Generic Security Service Application
Program Interface (GSS-API) Negotiation Mechanism", RFC 4178,
October 2005.
[12] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication [12] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication
and Security Layer (SASL) Mechanism", RFC 4752, November 2006. and Security Layer (SASL) Mechanism", RFC 4752, November 2006.
[13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", [13] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
RFC 2025, October 1996. RFC 2025, October 1996.
[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006. Protocol Version 1.1", RFC 4346, April 2006.
skipping to change at page 34, line 7 skipping to change at page 34, line 7
WWW http://www.saunalahti.fi/~asokan/research/mitm.html. WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
Author's Address Author's Address
Simon Josefsson Simon Josefsson
Email: simon@josefsson.org Email: simon@josefsson.org
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 9 change blocks. 
14 lines changed or deleted 15 lines changed or added

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