Owner/Change controller:
Note: (Any other information that the author deems relevant may be
added here.)
and sending it via electronic mail to IANA at <iana@iana.org>.
While this registration procedure does not require expert review,
authors of SASL mechanisms are encouraged to seek community review
and comment whenever that is feasible. Authors may seek community
review by posting a specification of their proposed mechanism as an
Internet-Draft. SASL mechanisms intended for widespread use should
be standardized through the normal IETF process, when appropriate.
7.1.2. Family Name Registration Procedure
As noted above, there is no general naming convention for SASL
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> and carbon copying 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 disapprove the request
with notice to the 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 pursue 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
owner, request IANA to attach their comment to the SASL mechanism
registration itself by sending mail to <iana@iana.org>. At IANA’s
sole discretion, IANA may attach the comment to the SASL mechanism’s
registration.
7.1.4. Change Control
Once a SASL mechanism registration has been published by IANA, the
author may request a change to its definition. The change request
follows the same procedure as the registration request.
The owner of a SASL mechanism may pass responsibility for the SASL
mechanism to another person or agency by informing IANA; this can be
done without discussion or review.
The IESG may reassign responsibility for a SASL mechanism. The most
common case of this will be to enable changes to be made to
mechanisms where the author of the registration has died, has moved
out of contact, or is otherwise unable to make changes that are
important to the community.
SASL mechanism registrations may not be deleted; mechanisms that are
no longer believed appropriate for use can be declared OBSOLETE by a
change to their "intended usage" field; such SASL mechanisms will be
clearly marked in the lists published by IANA.
The IESG is considered to be the owner of all SASL mechanisms that
are on the IETF standards track.
7.2. Registration Changes
The IANA has updated the SASL mechanisms registry as follows:
1) Changed the "Intended usage" of the KERBEROS_V4 and SKEY mechanism
registrations to OBSOLETE.
2) Changed the "Published specification" of the EXTERNAL mechanism to
this document as indicated below:
Subject: Updated Registration of SASL mechanism EXTERNAL
Family of SASL mechanisms: NO
SASL mechanism name: EXTERNAL
Security considerations: See A.3 of RFC 4422
Published specification (optional, recommended): RFC 4422
Person & email address to contact for further information:
Alexey Melnikov <Alexey.Melnikov@isode.com>
Intended usage: COMMON
Owner/Change controller: IESG <iesg@ietf.org>
Note: Updates existing entry for EXTERNAL
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2244] Newman, C. and J. G. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November
1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
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
Information Interchange, ANSI X3.4-1986.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version
3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
61633-5), as amended by the "Unicode Standard Annex
#27: Unicode 3.1"
(http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
[CharModel] Whistler, K. and M. Davis, "Unicode Technical Report
#17, Character Encoding Model", UTR17,
<http://www.unicode.org/unicode/reports/tr17/>, August
2000.
[Glossary] The Unicode Consortium, "Unicode Glossary",
<http://www.unicode.org/glossary/>.
8.2. Informative References
[RFC3206] Gellens, R., "The SYS and AUTH POP Response Codes", RFC
3206, February 2002.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[SASL-GSSAPI] Melnikov, A. (Editor), "The Kerberos V5 ("GSSAPI") SASL
Mechanism", Work in Progress, May 2006.
[UTR36] Davis, M., "(Draft) Unicode Technical Report #36,
Character Encoding Model", UTR17,
<http://www.unicode.org/unicode/reports/tr36/>,
February 2005.
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
Progress.
[DIGEST-MD5] Leach, P., C. Newman, and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism", Work in Progress,
March 2006.
9. Acknowledgements
This document is a revision of RFC 2222 written by John Myers.
This revision is a product of the IETF Simple Authentication and
Security Layer (SASL) Working Group.
The following individuals contributed significantly to this revision:
Abhijit Menon-Sen, Hallvard Furuseth, Jeffrey Hutzelman, John Myers,
Luke Howard, Magnus Nystrom, Nicolas Williams, Peter Saint-Andre, RL
’Bob’ Morgan, Rob Siemborski, Sam Hartman, Simon Josefsson, Tim
Alsop, and Tony Hansen.
Appendix A. The SASL EXTERNAL Mechanism
This appendix is normative.
The EXTERNAL mechanism allows a client to request the server to use
credentials established by means external to the mechanism to
authenticate the client. The external means may be, for instance, IP
Security [RFC4301] or TLS [RFC4346] services. In absence of some a
priori agreement between the client and the server, the client cannot
make any assumption as to what external means the server has used to
obtain the client’s credentials, nor make an assumption as to the
form of credentials. For example, the client cannot assume that the
server will use the credentials the client has established via TLS.
A.1. EXTERNAL Technical Specification
The name of this mechanism is "EXTERNAL".
The mechanism does not provide a security layer.
The mechanism is capable of transferring an authorization identity
string. If empty, the client is requesting to act as the identity
the server has associated with the client’s credentials. If non-
empty, the client is requesting to act as the identity represented by
the string.
The client is expected to send data first in the authentication
exchange. Where the client does not provide an initial response data
in its request to initiate the authentication exchange, the server is
to respond to the request with an empty initial challenge and then
the client is to provide its initial response.
The client sends the initial response containing the UTF-8 [RFC3629]
encoding of the requested authorization identity string. This
response is non-empty when the client is requesting to act as the
identity represented by the (non-empty) string. This response is
empty when the client is requesting to act as the identity the server
associated with its authentication credentials.
The syntax of the initial response is specified as a value of the
<extern-initial-resp> production detailed below using the Augmented
Backus-Naur Form (ABNF) [RFC4234] notation.
external-initial-resp = authz-id-string
authz-id-string = *( UTF8-char-no-nul )
UTF8-char-no-nul = UTF8-1-no-nul / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-no-nul = %x01-7F
where the <UTF8-2>, <UTF8-3>, and <UTF8-4> productions are as defined
in [RFC3629].
There are no additional challenges and responses.
Hence, the server is to return the outcome of the authentication
exchange.
The exchange fails if
- the client has not established its credentials via external means,
- the client’s credentials are inadequate,
- the client provided an empty authorization identity string and the
server is unwilling or unable to associate an authorization
identity with the client’s credentials,
- the client provided a non-empty authorization identity string that
is invalid per the syntax requirements of the applicable
application protocol specification,
- the client provided a non-empty authorization identity string
representing an identity that the client is not allowed to act as,
or
- the server is unwilling or unable to provide service to the client
for any other reason.
Otherwise the exchange is successful. When indicating a successful
outcome, additional data is not provided.
A.2. SASL EXTERNAL Examples
This section provides examples of EXTERNAL authentication exchanges.
The examples are intended to help the readers understand the above
text. The examples are not definitive. The Application
Configuration Access Protocol (ACAP) [RFC2244] is used in the
examples.
The first example shows use of EXTERNAL with an empty authorization
identity. In this example, the initial response is not sent in the
client’s request to initiate the authentication exchange.
S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
C: a002 AUTHENTICATE "EXTERNAL"
S: + ""
C: + ""
S: a002 OK "Authenticated"
The second example shows use of EXTERNAL with an authorization
identity of "fred@example.com". In this example, the initial
response is sent with the client’s request to initiate the
authentication exchange. This saves a round-trip.
S: * ACAP (SASL "DIGEST-MD5")
C: a001 STARTTLS
S: a001 OK "Begin TLS negotiation now"
<TLS negotiation, further commands are under TLS layer>
S: * ACAP (SASL "DIGEST-MD5" "EXTERNAL")
C: a002 AUTHENTICATE "EXTERNAL" {16+}
C: fred@example.com
S: a002 NO "Cannot assume requested authorization identity"
A.3. Security Considerations
The EXTERNAL mechanism provides no security protection; it is
vulnerable to spoofing by either client or server, active attack, and
eavesdropping. It should only be used when adequate security
services have been established.
Appendix B. Changes since RFC 2222
This appendix is non-normative.
The material in RFC 2222 was significantly rewritten in the
production of this document.
RFC 2222, by not stating that the authorization identity string was a
string of Unicode characters, let alone character data, implied that
the authorization identity string was a string of octets.
- The authorization identity string is now defined as a string of
Unicode characters. The NUL (U+0000) character is prohibited.
While protocol specifications are responsible for defining the
authorization identity form, as well as the Unicode string syntax
and related semantics, mechanism specifications are responsible
for defining how the Unicode string is carried in the
authentication exchange.
- Deleted "If so, when the client does not send data first, the
initial challenge MUST be specified as being an empty challenge."
The following technical change was made to the EXTERNAL mechanism:
- The authorization identity string is to be UTF-8 encoded.
Note that protocol and mechanism specification requirements have
been significantly tightened. Existing protocol and mechanism
specifications will need to be updated to meet these requirements.
Editors’ Addresses
Alexey Melnikov
Isode Limited
5 Castle Business Village
36 Station Road
Hampton, Middlesex,
TW12 2BX, United Kingdom
EMail: Alexey.Melnikov@isode.com
URI: http://www.melnikov.ca/
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).