rfc2222.txt

用C#开发实现SMTP相关技术,能接收到带附件的邮件服务功能.

   There is no naming convention for SASL mechanisms; any name that
   conforms to the syntax of a SASL mechanism name can be registered.

   While the registration procedures do not require it, 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.

6.1.  Comments on SASL mechanism registrations

   Comments on registered SASL mechanisms should first be sent to the
   "owner" of the mechanism.  Submitters of comments may, after a
   reasonable attempt to contact the owner, request IANA to attach their
   comment to the SASL mechanism registration itself.  If IANA approves
   of this the comment will be made accessible in conjunction with the
   SASL mechanism registration itself.

6.2.  Location of Registered SASL Mechanism List

   SASL mechanism registrations will be posted in the anonymous FTP
   directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-
   mechanisms/" and all registered SASL mechanisms will be listed in the
   periodically issued "Assigned Numbers" RFC [currently STD 2, RFC
   1700].  The SASL mechanism description and other supporting material
   may also be published as an Informational RFC by sending it to "rfc-
   [e-mail]" (please follow the instructions to RFC authors [RFC
   2223]).







Myers                       Standards Track                     [Page 6]

RFC 2222                          SASL                      October 1997


6.3.  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, 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 which are
   no longer believed appropriate for use can be declared OBSOLETE by a
   change to their "intended use" 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 which
   are on the IETF standards track.

6.4.  Registration Template

   To: [e-mail]
   Subject: Registration of SASL mechanism X

   SASL mechanism name:

   Security considerations:

   Published specification (optional, recommended):

   Person & email address to contact for further information:

   Intended usage:

   (One of COMMON, LIMITED USE or OBSOLETE)

   Author/Change controller:

   (Any other information that the author deems interesting may be
   added below this line.)






Myers                       Standards Track                     [Page 7]

RFC 2222                          SASL                      October 1997


7.    Mechanism definitions

   The following mechanisms are hereby defined.

7.1.  Kerberos version 4 mechanism

   The mechanism name associated with Kerberos version 4 is
   "KERBEROS_V4".

   The first challenge consists of a random 32-bit number in network
   byte order.  The client responds with a Kerberos ticket and an
   authenticator for the principal "service.hostname@realm", where
   "service" is the service name specified in the protocol's profile,
   "hostname" is the first component of the host name of the server with
   all letters in lower case, and where "realm" is the Kerberos realm of
   the server.  The encrypted checksum field included within the
   Kerberos authenticator contains the server provided challenge in
   network byte order.

   Upon decrypting and verifying the ticket and authenticator, the
   server verifies that the contained checksum field equals the original
   server provided random 32-bit number.  Should the verification be
   successful, the server must add one to the checksum and construct 8
   octets of data, with the first four octets containing the incremented
   checksum in network byte order, the fifth octet containing a bit-mask
   specifying the security layers supported by the server, and the sixth
   through eighth octets containing, in network byte order, the maximum
   cipher-text buffer size the server is able to receive.  The server
   must encrypt using DES ECB mode the 8 octets of data in the session
   key and issue that encrypted data in a second challenge.  The client
   considers the server authenticated if the first four octets of the
   un-encrypted data is equal to one plus the checksum it previously
   sent.

   The client must construct data with the first four octets containing
   the original server-issued checksum in network byte order, the fifth
   octet containing the bit-mask specifying the selected security layer,
   the sixth through eighth octets containing in network byte order the
   maximum cipher-text buffer size the client is able to receive, and
   the following octets containing the authorization identity.  The
   client must then append from one to eight zero-valued octets so that
   the length of the data is a multiple of eight octets. The client must
   then encrypt using DES PCBC mode the data with the session key and
   respond with the encrypted data.  The server decrypts the data and
   verifies the contained checksum.  The server must verify that the
   principal identified in the Kerberos ticket is authorized to connect
   as that authorization identity.  After this verification, the
   authentication process is complete.



Myers                       Standards Track                     [Page 8]

RFC 2222                          SASL                      October 1997


   The security layers and their corresponding bit-masks are as follows:

      1 No security layer
      2 Integrity (krb_mk_safe) protection
      4 Privacy (krb_mk_priv) protection

   Other bit-masks may be defined in the future; bits which are not
   understood must be negotiated off.

   EXAMPLE: The following are two Kerberos version 4 login scenarios to
   the IMAP4 protocol (note that the line breaks in the sample
   authenticators are for editorial clarity and are not in real
   authenticators)

     S: * OK IMAP4 Server
     C: A001 AUTHENTICATE KERBEROS_V4
     S: + AmFYig==
     C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
        +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
        WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
     S: + or//EoAADZI=
     C: DiAF5A4gA+oOIALuBkAAmw==
     S: A001 OK Kerberos V4 authentication successful


     S: * OK IMAP4 Server
     C: A001 AUTHENTICATE KERBEROS_V4
     S: + gcfgCA==
     C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
        +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
        WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
     S: A001 NO Kerberos V4 authentication failed

7.2.  GSSAPI mechanism

   The mechanism name associated with all mechanisms employing the
   GSSAPI [RFC 2078] is "GSSAPI".

7.2.1 Client side of authentication protocol exchange

   The client calls GSS_Init_sec_context, passing in 0 for
   input_context_handle (initially) and a targ_name equal to output_name
   from GSS_Import_Name called with input_name_type of
   GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
   "service@hostname" where "service" is the service name specified in
   the protocol's profile, and "hostname" is the fully qualified host
   name of the server.  The client then responds with the resulting
   output_token.  If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED,



Myers                       Standards Track                     [Page 9]

RFC 2222                          SASL                      October 1997


   then the client should expect the server to issue a token in a
   subsequent challenge.  The client must pass the token to another call
   to GSS_Init_sec_context, repeating the actions in this paragraph.

   When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes
   the following actions: If the last call to GSS_Init_sec_context
   returned an output_token, then the client responds with the
   output_token, otherwise the client responds with no data.  The client
   should then expect the server to issue a token in a subsequent
   challenge.  The client passes this token to GSS_Unwrap and interprets
   the first octet of resulting cleartext as a bit-mask specifying the
   security layers supported by the server and the second through fourth
   octets as the maximum size output_message to send to the server.  The
   client then constructs data, with the first octet containing the
   bit-mask specifying the selected security layer, the second through
   fourth octets containing in network byte order the maximum size
   output_message the client is able to receive, and the remaining
   octets containing the authorization identity.  The client passes the
   data to GSS_Wrap with conf_flag set to FALSE, and responds with the
   generated output_message.  The client can then consider the server
   authenticated.

7.2.2 Server side of authentication protocol exchange

   The server passes the initial client response to
   GSS_Accept_sec_context as input_token, setting input_context_handle
   to 0 (initially).  If GSS_Accept_sec_context returns
   GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
   to the client in challenge and passes the resulting response to
   another call to GSS_Accept_sec_context, repeating the actions in this
   paragraph.

   When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes
   the following actions: If the last call to GSS_Accept_sec_context
   returned an output_token, the server returns it to the client in a
   challenge and expects a reply from the client with no data.  Whether
   or not an output_token was returned (and after receipt of any
   response from the client to such an output_token), the server then
   constructs 4 octets of data, with the first octet containing a bit-
   mask specifying the security layers supported by the server and the
   second through fourth octets containing in network byte order the
   maximum size output_token the server is able to receive.  The server
   must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE
   and issue the generated output_message to the client in a challenge.
   The server must then pass the resulting response to GSS_Unwrap and
   interpret the first octet of resulting cleartext as the bit-mask for
   the selected security layer, the second through fourth octets as the
   maximum size output_message to send to the client, and the remaining



Myers                       Standards Track                    [Page 10]

RFC 2222                          SASL                      October 1997


   octets as the authorization identity.  The server must verify that
   the src_name is authorized to authenticate as the authorization
   identity.  After these verifications, the authentication process is
   complete.

7.2.3 Security layer

   The security layers and their corresponding bit-masks are as follows:

     1 No security layer
     2 Integrity protection.
       Sender calls GSS_Wrap with conf_flag set to FALSE
     4 Privacy protection.
       Sender calls GSS_Wrap with conf_flag set to TRUE

   Other bit-masks may be defined in the future; bits which are not
   understood must be negotiated off.

7.3.  S/Key mechanism

   The mechanism name associated with S/Key [RFC 1760] using the MD4
   digest algorithm is "SKEY".

   The client sends an initial response with the authorization identity.

   The server then issues a challenge which contains the decimal
   sequence number followed by a single space and the seed string for
   the indicated authorization identity.  The client responds with the
   one-time-password, as either a 64-bit value in network byte order or
   encoded in the "six English words" format.

   The server must verify the one-time-password.  After this
   verification, the authentication process is complete.

   S/Key authentication does not provide for any security layers.