home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1731 < prev    next >
Text File  |  1994-12-20  |  11KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                           J. Myers
  8. Request for Comments: 1731                               Carnegie Mellon
  9. Category: Standards Track                                  December 1994
  10.  
  11.  
  12.                     IMAP4 Authentication Mechanisms
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22.  
  23. 1. Introduction
  24.  
  25.    The Internet Message Access Protocol, Version 4 [IMAP4] contains the
  26.    AUTHENTICATE command, for identifying and authenticating a user to an
  27.    IMAP4 server and for optionally negotiating a protection mechanism
  28.    for subsequent protocol interactions.  This document describes
  29.    several authentication mechanisms for use by the IMAP4 AUTHENTICATE
  30.    command.
  31.  
  32.  
  33. 2. Kerberos version 4 authentication mechanism
  34.  
  35.    The authentication type associated with Kerberos version 4 is
  36.    "KERBEROS_V4".
  37.  
  38.    The data encoded in the first ready response contains a random 32-bit
  39.    number in network byte order.  The client should respond with a
  40.    Kerberos ticket and an authenticator for the principal
  41.    "imap.hostname@realm", where "hostname" is the first component of the
  42.    host name of the server with all letters in lower case and where
  43.    "realm" is the Kerberos realm of the server.  The encrypted checksum
  44.    field included within the Kerberos authenticator should contain the
  45.    server provided 32-bit number in network byte order.
  46.  
  47.    Upon decrypting and verifying the ticket and authenticator, the
  48.    server should verify that the contained checksum field equals the
  49.    original server provided random 32-bit number.  Should the
  50.    verification be successful, the server must add one to the checksum
  51.    and construct 8 octets of data, with the first four octets containing
  52.    the incremented checksum in network byte order, the fifth octet
  53.    containing a bit-mask specifying the protection mechanisms supported
  54.    by the server, and the sixth through eighth octets containing, in
  55.  
  56.  
  57.  
  58. Myers                                                           [Page 1]
  59.  
  60. RFC 1731            IMAP4 Authentication Mechanisms        December 1994
  61.  
  62.  
  63.    network byte order, the maximum cipher-text buffer size the server is
  64.    able to receive.  The server must encrypt the 8 octets of data in the
  65.    session key and issue that encrypted data in a second ready response.
  66.    The client should consider the server authenticated if the first four
  67.    octets the un-encrypted data is equal to one plus the checksum it
  68.    previously sent.
  69.  
  70.    The client must construct data with the first four octets containing
  71.    the original server-issued checksum in network byte order, the fifth
  72.    octet containing the bit-mask specifying the selected protection
  73.    mechanism, the sixth through eighth octets containing in network byte
  74.    order the maximum cipher-text buffer size the client is able to
  75.    receive, and the following octets containing a user name string.  The
  76.    client must then append from one to eight octets so that the length
  77.    of the data is a multiple of eight octets. The client must then PCBC
  78.    encrypt the data with the session key and respond to the second ready
  79.    response with the encrypted data.  The server decrypts the data and
  80.    verifies the contained checksum.  The username field identifies the
  81.    user for whom subsequent IMAP operations are to be performed; the
  82.    server must verify that the principal identified in the Kerberos
  83.    ticket is authorized to connect as that user.  After these
  84.    verifications, the authentication process is complete.
  85.  
  86.    The protection mechanisms and their corresponding bit-masks are as
  87.    follows:
  88.  
  89.       1 No protection mechanism
  90.       2 Integrity (krb_mk_safe) protection
  91.       4 Privacy (krb_mk_priv) protection
  92.  
  93.  
  94.    EXAMPLE: The following are two Kerberos version 4 login scenarios
  95.    (note that the line breaks in the sample authenticators are for
  96.    editorial clarity and are not in real authenticators)
  97.  
  98.       S: * OK IMAP4 Server
  99.       C: A001 AUTHENTICATE KERBEROS_V4
  100.       S: + AmFYig==
  101.       C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
  102.          +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
  103.          WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
  104.       S: + or//EoAADZI=
  105.       C: DiAF5A4gA+oOIALuBkAAmw==
  106.       S: A001 OK Kerberos V4 authentication successful
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Myers                                                           [Page 2]
  115.  
  116. RFC 1731            IMAP4 Authentication Mechanisms        December 1994
  117.  
  118.  
  119.       S: * OK IMAP4 Server
  120.       C: A001 AUTHENTICATE KERBEROS_V4
  121.       S: + gcfgCA==
  122.       C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
  123.          +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
  124.          WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
  125.       S: A001 NO Kerberos V4 authentication failed
  126.  
  127.  
  128. 3. GSSAPI authentication mechanism
  129.  
  130.    The authentication type associated with all mechanisms employing the
  131.    GSSAPI [RFC1508] is "GSSAPI".
  132.  
  133.    The first ready response issued by the server contains no data.  The
  134.    client should call GSS_Init_sec_context, passing in 0 for
  135.    input_context_handle (initially) and a targ_name equal to output_name
  136.    from GSS_Import_Name called with input_name_type of NULL and
  137.    input_name_string of "SERVICE:imap@hostname" where "hostname" is the
  138.    fully qualified host name of the server with all letters in lower
  139.    case.  The client must then respond with the resulting output_token.
  140.    If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client
  141.    should expect the server to issue a token in a subsequent ready
  142.    response.  The client must pass the token to another call to
  143.    GSS_Init_sec_context.
  144.  
  145.    If GSS_Init_sec_context returns GSS_COMPLETE, then the client should
  146.    respond with any resulting output_token.  If there is no
  147.    output_token, the client should respond with no data.  The client
  148.    should then expect the server to issue a token in a subsequent ready
  149.    response.  The client should pass this token to GSS_Unseal and
  150.    interpret the first octet of resulting cleartext as a bit-mask
  151.    specifying the protection mechanisms supported by the server and the
  152.    second through fourth octets as the maximum size output_message to
  153.    send to the server.  The client should construct data, with the first
  154.    octet containing the bit-mask specifying the selected protection
  155.    mechanism, the second through fourth octets containing in network
  156.    byte order the maximum size output_message the client is able to
  157.    receive, and the remaining octets containing a user name string.  The
  158.    client must pass the data to GSS_Seal with conf_flag set to FALSE,
  159.    and respond with the generated output_message.  The client can then
  160.    consider the server authenticated.
  161.  
  162.    The server must issue a ready response with no data and pass the
  163.    resulting client supplied token to GSS_Accept_sec_context as
  164.    input_token, setting acceptor_cred_handle to NULL (for "use default
  165.    credentials"), and 0 for input_context_handle (initially).  If
  166.    GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should
  167.  
  168.  
  169.  
  170. Myers                                                           [Page 3]
  171.  
  172. RFC 1731            IMAP4 Authentication Mechanisms        December 1994
  173.  
  174.  
  175.    return the generated output_token to the client in a ready response
  176.    and pass the resulting client supplied token to another call to
  177.    GSS_Accept_sec_context.
  178.  
  179.    If GSS_Accept_sec_context returns GSS_COMPLETE, then if an
  180.    output_token is returned, the server should return it to the client
  181.    in a ready response and expect a reply from the client with no data.
  182.    Whether or not an output_token was returned, the server then should
  183.    then construct 4 octets of data, with the first octet containing a
  184.    bit-mask specifying the protection mechanisms supported by the server
  185.    and the second through fourth octets containing in network byte order
  186.    the maximum size output_token the server is able to receive.  The
  187.    server must then pass the plaintext to GSS_Seal with conf_flag set to
  188.    FALSE and issue the generated output_message to the client in a ready
  189.    response.  The server must then pass the resulting client supplied
  190.    token to GSS_Unseal and interpret the first octet of resulting
  191.    cleartext as the bit-mask for the selected protection mechanism, the
  192.    second through fourth octets as the maximum size output_message to
  193.    send to the client, and the remaining octets as the user name.  Upon
  194.    verifying the src_name is authorized to authenticate as the user
  195.    name, The server should then consider the client authenticated.
  196.  
  197.    The protection mechanisms and their corresponding bit-masks are as
  198.    follows:
  199.  
  200.       1 No protection mechanism
  201.       2 Integrity protection.
  202.         Sender calls GSS_Seal with conf_flag set to FALSE
  203.       4 Privacy protection.
  204.         Sender calls GSS_Seal with conf_flag set to TRUE
  205.  
  206.  
  207. 4. S/Key authentication mechanism
  208.  
  209.    The authentication type associated with S/Key [SKEY] is "SKEY".
  210.  
  211.    The first ready response issued by the server contains no data.  The
  212.    client responds with the user name string.
  213.  
  214.    The data encoded in the second ready response contains the decimal
  215.    sequence number followed by a single space and the seed string for
  216.    the indicated user.  The client responds with the one-time-password,
  217.    as either a 64-bit value in network byte order or encoded in the "six
  218.    English words" format.
  219.  
  220.    Upon successful verification of the one-time-password, the server
  221.    should consider the client authenticated.
  222.  
  223.  
  224.  
  225.  
  226. Myers                                                           [Page 4]
  227.  
  228. RFC 1731            IMAP4 Authentication Mechanisms        December 1994
  229.  
  230.  
  231.    S/Key authentication does not provide for any protection mechanisms.
  232.  
  233.  
  234.    EXAMPLE: The following are two S/Key login scenarios.
  235.  
  236.       S: * OK IMAP4 Server
  237.       C: A001 AUTHENTICATE SKEY
  238.       S: +
  239.       C: bW9yZ2Fu
  240.       S: + OTUgUWE1ODMwOA==
  241.       C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
  242.       S: A001 OK S/Key authentication successful
  243.  
  244.  
  245.       S: * OK IMAP4 Server
  246.       C: A001 AUTHENTICATE SKEY
  247.       S: +
  248.       C: c21pdGg=
  249.       S: + OTUgUWE1ODMwOA==
  250.       C: BsAY3g4gBNo=
  251.       S: A001 NO S/Key authentication failed
  252.  
  253.  
  254. 5. References
  255.  
  256.    [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
  257.    RFC 1730, University of Washington, December 1994.
  258.  
  259.    [RFC1508] Linn, J., "Generic Security Service Application Program
  260.    Interface", RFC 1508, Geer Zolot Associates, September 1993.
  261.  
  262.    [SKEY] Haller, Neil M. "The S/Key One-Time Password System",
  263.    Bellcore, Morristown, New Jersey, October 1993,
  264.    thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Myers                                                           [Page 5]
  283.  
  284. RFC 1731            IMAP4 Authentication Mechanisms        December 1994
  285.  
  286.  
  287. 6. Security Considerations
  288.  
  289.    Security issues are discussed throughout this memo.
  290.  
  291.  
  292. 7. Author's Address
  293.  
  294.    John G. Myers
  295.    Carnegie-Mellon University
  296.    5000 Forbes Ave.
  297.    Pittsburgh PA, 15213-3890
  298.  
  299.    EMail: jgm+@cmu.edu
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Myers                                                           [Page 6]
  339.  
  340.