draft-ietf-sasl-rfc2222bis-13.txt   draft-ietf-sasl-rfc2222bis-14.txt 
INTERNET-DRAFT A. Melnikov, Ed. INTERNET-DRAFT A. Melnikov, Ed.
Intended Category: Standards Track ISODE Limited Intended Category: Standards Track ISODE Limited
Expires in six months K. Zeilenga, Ed. Expires in six months K. Zeilenga, Ed.
Obsoletes: RFC 2222 OpenLDAP Project Obsoletes: RFC 2222 OpenLDAP Project
10 November 2005 17 November 2005
Simple Authentication and Security Layer (SASL) Simple Authentication and Security Layer (SASL)
<draft-ietf-sasl-rfc2222bis-13.txt> <draft-ietf-sasl-rfc2222bis-14.txt>
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 have 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 aware 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. will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 16, line 26 skipping to change at page 16, line 26
5. Mechanism Requirements 5. Mechanism Requirements
SASL mechanism specifications MUST supply the following information: SASL mechanism specifications MUST supply the following information:
1) The name of the mechanism (see Section 3.1). This name MUST be 1) The name of the mechanism (see Section 3.1). This name MUST be
registered as discussed in Section 7.1. registered as discussed in Section 7.1.
2) A definition of the server-challenges and client-responses of the 2) A definition of the server-challenges and client-responses of the
authentication exchange, as well as: authentication exchange, as well as:
a) An indication whether the client is expected to send data first. a) An indication whether mechanism is client-first, variable, or
server-first. If a SASL mechanism is defined as client-first
and the client does not send an initial response, then the first
server challenge MUST be empty (the EXTERNAL mechanism is an
example of this case). If a SASL mechanism is defined as
variable, then the specification needs to state how the server
behaves when the initial client response is omitted (the
DIGEST-MD5 mechanism [DIGEST-MD5] is an example of this case).
If a SASL mechanism is defined as server-first then the client
MUST NOT send an initial client response (the CRAM-MD5 mechanism
[CRAM-MD5] is an example of this case).
b) An indication whether the server is expected to provide b) An indication whether the server is expected to provide
additional data when indicating a successful outcome. If so, if additional data when indicating a successful outcome. If so, if
the server sends the additional data as a challenge, the the server sends the additional data as a challenge, the
specification MUST indicate the response to this challenge is an specification MUST indicate the response to this challenge is an
empty response. empty response.
SASL mechanisms SHOULD be designed to minimize the number of SASL mechanisms SHOULD be designed to minimize the number of
challenges and responses necessary to complete the exchange. challenges and responses necessary to complete the exchange.
skipping to change at page 21, line 48 skipping to change at page 22, line 13
security considerations also apply where used. security considerations also apply where used.
7. IANA Considerations 7. IANA Considerations
7.1. SASL Mechanism Registry 7.1. SASL Mechanism Registry
SASL mechanism registry is maintained by IANA. The registry is SASL mechanism registry is maintained by IANA. The registry is
currently available at currently available at
<http://www.iana.org/assignments/sasl-mechanisms>. <http://www.iana.org/assignments/sasl-mechanisms>.
It is requested that this registry be updated to reflect that this The purpose of this registry is not only to ensure uniqueness of
document provides the definitive technical specification for SASL and values used to name SASL mechanisms, but to provide a definitive
that this section provides the registration procedures for this references to technical specifications detailing each SASL mechanism
registry. available for use on the Internet.
7.1.1. Registration Procedure There is no naming convention for SASL mechanisms; any name that
conforms to the syntax of a SASL mechanism name can be registered.
The procedure detailed in Section 7.1.1 is to be used for registration
of a value naming a specific individual mechanism.
The procedure detailed in Section 7.1.2 is to be used for registration
of a value naming a family of related mechanisms.
Comments may be included in the registry as discussed in Section 7.1.3
and may be changed as discussed in Section 7.1.4.
It is requested that the SASL mechanism registry be updated to reflect
that this document provides the definitive technical specification for
SASL and that this section provides the registration procedures for
this registry.
7.1.1. Mechanism Name Registration Procedure
IANA will register new SASL mechanism names on a First Come First
Served basis, as defined in BCP 26 [RFC2434]. IANA has the right to
reject obviously bogus registration requests, but will perform no
review of claims made in the registration form.
Registration of a SASL mechanism is requested by filling in the Registration of a SASL mechanism is requested by filling in the
following template: following template:
Subject: Registration of SASL mechanism X Subject: Registration of SASL mechanism X
Family of SASL mechanisms: (YES or NO)
SASL mechanism name (or prefix for the family): SASL mechanism name (or prefix for the family):
Security considerations: Security considerations:
Published specification (recommended): Published specification (recommended):
Person & email address to contact for further information: Person & email address to contact for further information:
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE) Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
Owner/Change controller: Owner/Change controller:
Note: (Any other information that the author deems interesting may Note: (Any other information that the author deems relevant may be
be added here .) added here .)
and sending it via electronic mail to <iana@iana.org>.
IANA has the right to reject obviously bogus registrations, but will
perform no review of claims made in the registration form. IANA will
register new values on a First Come First Served basis, as defined in
BCP 64 [RFC2434].
There is no naming convention for SASL mechanisms; any name that and sending it via electronic mail to IANA at <iana@iana.org>.
conforms to the syntax of a SASL mechanism name can be registered.
However, future specifications may reserve a portion of the SASL
mechanism namespace ("family of SASL mechanisms") for its own use,
detailing the registration rules for that portion of the namespace.
Each family of SASL mechanisms MUST be identified by a prefix.
While the registration procedures do not require expert review, While this registration procedures do not require expert review,
authors of SASL mechanisms are encouraged to seek community review and authors of SASL mechanisms are encouraged to seek community review and
comment whenever that is feasible. Authors may seek community review comment whenever that is feasible. Authors may seek community review
by posting a specification of their proposed mechanism as an by posting a specification of their proposed mechanism as an
Internet-Draft. SASL mechanisms intended for widespread use should be Internet-Draft. SASL mechanisms intended for widespread use should be
standardized through the normal IETF process, when appropriate. standardized through the normal IETF process, when appropriate.
7.1.2. Comments on SASL Mechanism Registrations 7.1.2. Family Name Registration Procedure
Comments on registered SASL mechanisms should first be sent to the As noted above, there is no general naming convention for SASL
"owner" of the mechanism and/or to the SASL WG mailing list. mechanisms. However, specifications may reserve a portion of the SASL
mechanism namespace for a set of related SASL mechanisms, a "family"
of SASL mechanisms. Each family of SASL mechanisms is identified by a
unique prefix, such as X-. Registration of new SASL mechanism family
names requires Expert Review as defined in BCP 26 [RFC2434].
Registration of a SASL family name is requested by filling in the
following template:
Subject: Registration of SASL mechanism family X
SASL family name (or prefix for the family):
Security considerations:
Published specification (recommended):
Person & email address to contact for further information:
Intended usage: (One of COMMON, LIMITED USE or OBSOLETE)
Owner/Change controller:
Note: (Any other information that the author deems relevant may be
added here .)
and sending it via electronic mail to the IETF SASL mailing list at
<ietf-sasl@imc.org> with copy to IANA at <iana@iana.org>. After
allowing two weeks for community input on the IETF SASL mailing list,
the expert will determine the appropriateness of the registration
request and either approve or disappove the request with notice to
requestor, the mailing list, and IANA.
The review should focus on the appropriateness of the requested family
name for the proposed use and the appropriateness of the proposed
naming and registration plan for existing and future mechanism names
in the family. The scope of this request review may entail
consideration of relevant aspects of any provided technical
specification, such as their IANA Considerations section. However
this review is narrowly focused on the appropriateness of the
requested registration and not on the overall soundness of any
provided technical specification.
Authors are encouraged to community review by posting the technical
specification as an Internet-Draft and soliciting comment by posting
to appropriate IETF mailing lists.
7.1.3. Comments on SASL Mechanism Registrations
Comments on a registered SASL mechanism/family should first be sent to
the "owner" of the mechanism/family and/or to the <ietf-sasl@imc.org>
mailing list.
Submitters of comments may, after a reasonable attempt to contact the Submitters of comments may, after a reasonable attempt to contact the
owner, request IANA to attach their comment to the SASL mechanism owner, request IANA to attach their comment to the SASL mechanism
registration itself by sending mail to <iana@iana.org>. At IANA's registration itself by sending mail to <iana@iana.org>. At IANA's
sole discretion, IANA may attach the comment to the SASL mechanism's sole discretion, IANA may attach the comment to the SASL mechanism's
registration. registration.
7.1.3. Change Control 7.1.4. Change Control
Once a SASL mechanism registration has been published by IANA, the Once a SASL mechanism registration has been published by IANA, the
author may request a change to its definition. The change request author may request a change to its definition. The change request
follows the same procedure as the registration request. follows the same procedure as the registration request.
The owner of a SASL mechanism may pass responsibility for the SASL The owner of a SASL mechanism may pass responsibility for the SASL
mechanism to another person or agency by informing IANA; this can be mechanism to another person or agency by informing IANA; this can be
done without discussion or review. done without discussion or review.
The IESG may reassign responsibility for a SASL mechanism. The most The IESG may reassign responsibility for a SASL mechanism. The most
skipping to change at page 24, line 45 skipping to change at page 26, line 20
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ('stringprep')", RFC 3454, Internationalized Strings ('stringprep')", RFC 3454,
December 2002. December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC 3629 (also STD 63), November 2003. 10646", RFC 3629 (also STD 63), November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005. Names and Passwords", RFC 4013, February 2005.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[ASCII] Coded Character Set--7-bit American Standard Code for [ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986. Information Interchange, ANSI X3.4-1986.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version [Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0" 3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
as amended by the "Unicode Standard Annex #27: Unicode as amended by the "Unicode Standard Annex #27: Unicode
3.1" (http://www.unicode.org/reports/tr27/) and by the 3.1" (http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2" "Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/). (http://www.unicode.org/reports/tr28/).
skipping to change at page 25, line 39 skipping to change at page 27, line 18
progress. progress.
[SASL-GSSAPI] Melnikov, A. (Editor), "SASL GSSAPI mechanisms", [SASL-GSSAPI] Melnikov, A. (Editor), "SASL GSSAPI mechanisms",
draft-ietf-sasl-gssapi-XX.txt, a work in progress. draft-ietf-sasl-gssapi-XX.txt, a work in progress.
[UTR36] Davis, M., "(Draft) Unicode Technical [UTR36] Davis, M., "(Draft) Unicode Technical
Report #36, Character Encoding Model", UTR17, Report #36, Character Encoding Model", UTR17,
<http://www.unicode.org/unicode/reports/tr36/>, February <http://www.unicode.org/unicode/reports/tr36/>, February
2005. 2005.
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism",
draft-ietf-sasl-crammd5-xx.txt, a work in progress.
[DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism",
draft-ietf-sasl-rfc2831bis-xx.txt, a work in progress.
9. Editors' Address 9. Editors' Address
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
5 Castle Business Village 5 Castle Business Village
36 Station Road 36 Station Road
Hampton, Middlesex, Hampton, Middlesex,
TW12 2BX, United Kingdom TW12 2BX, United Kingdom
Email: Alexey.Melnikov@isode.com Email: Alexey.Melnikov@isode.com
 End of changes. 14 change blocks. 
30 lines changed or deleted 108 lines changed or added

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