rfc4422.txt

广泛使用的邮件服务器！同时

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
   <[e-mail]> and carbon copying IANA at <[e-mail]>.
   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.





Melnikov & Zeilenga         Standards Track                    [Page 24]

RFC 4422                          SASL                         June 2006


   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-
   [e-mail]> 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 <[e-mail]>.  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.












Melnikov & Zeilenga         Standards Track                    [Page 25]

RFC 4422                          SASL                         June 2006


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 <[e-mail]>
      Intended usage: COMMON
      Owner/Change controller: IESG <[e-mail]>
      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.



Melnikov & Zeilenga         Standards Track                    [Page 26]

RFC 4422                          SASL                         June 2006


   [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.



Melnikov & Zeilenga         Standards Track                    [Page 27]

RFC 4422                          SASL                         June 2006


   [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.



































Melnikov & Zeilenga         Standards Track                    [Page 28]

RFC 4422                          SASL                         June 2006


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 t