idnits 2.17.1 draft-ietf-imap-auth-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1994) is 10879 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-imap-imap4- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'IMAP4' ** Obsolete normative reference: RFC 1508 (Obsoleted by RFC 2078) -- Possible downref: Non-RFC (?) normative reference: ref. 'SKEY' Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. G. Myers 2 Internet Draft: IMAP4 Authentication Mechanisms Carnegie Mellon 3 Document: internet-drafts/draft-ietf-imap-auth-01.txt June 1994 5 IMAP4 Authentication mechanisms 7 Status of this memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a 18 ``working draft'' or ``work in progress``. 20 To learn the current status of any Internet-Draft, please check the 21 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 23 munnari.oz.au. 25 This is a draft document of the IETF IMAP Working Group. It is a 26 preliminary specification of several authentication mechanisms for 27 use by the AUTHENTICATE command of the IMAP4 protocol. 29 A revised version of this draft document will be submitted to the RFC 30 editor as a Proposed Standard for the Internet Community. Discussion 31 and suggestions for improvement are requested. This document will 32 expire before 31 December 1994. Distribution of this draft is 33 unlimited. Comments are solicited and should be sent to 34 imap@CAC.Washington.EDU. 36 Introduction 38 The Internet Message Access Protocol, Version 4 [IMAP4] contains the 39 AUTHENTICATE command, for identifying and authenticating a user to an 40 IMAP4 server and for optionally negotiating a protection mechanism 41 for subsequent protocol interactions. This document describes 42 several authentication mechanisms for use by the IMAP4 AUTHENTICATE 43 command. 45 Kerberos version 4 authentication mechanism 47 The authentication type associated with Kerberos version 4 is 48 ``KERBEROS_V4''. 50 The data encoded in the first ready response contains a random 32-bit 51 number in network byte order. The client should respond with a 52 Kerberos ticket and an authenticator for the principal 53 "imap.hostname@realm", where "hostname" is the first component of the 54 host name of the server with all letters in lower case and where 55 "realm" is the Kerberos realm of the server. The encrypted checksum 56 field included within the Kerberos authenticator should contain the 57 server provided 32-bit number in network byte order. 59 Upon decrypting and verifying the ticket and authenticator, the 60 server should verify that the contained checksum field equals the 61 original server provided random 32-bit number. Should the 62 verification be successful, the server must add one to the checksum 63 and construct 8 octets of data, with the first four octets containing 64 the incremented checksum in network byte order, the fifth octet 65 containing a bit-mask specifying the protection mechanisms supported 66 by the server, and the sixth through eighth octets containing, in 67 network byte order, the maximum cipher-text buffer size the server is 68 able to receive. The server must encrypt the 8 octets of data in the 69 session key and issue that encrypted data in a second ready response. 70 The client should consider the server authenticated if the first four 71 octets the un-encrypted data is equal to one plus the checksum it 72 previously sent. 74 The client must construct data with the first four octets containing 75 the original server-issued checksum in network byte order, the fifth 76 octet containing the bit-mask specifying the selected protection 77 mechanism, the sixth through eighth octets containing in network byte 78 order the maximum cipher-text buffer size the client is able to 79 receive, and the following octets containing a user name string. The 80 client must then append from one to eight octets so that the length 81 of the data is a multiple of eight octets. The client must then PCBC 82 encrypt the data with the session key and respond to the second ready 83 response with the encrypted data. The server decrypts the data and 84 verifies the contained checksum. The username field identifies the 85 user for whom subsequent IMAP operations are to be performed; the 86 server must verify that the principal identified in the Kerberos 87 ticket is authorized to connect as that user. After these 88 verifications, the authentication process is complete. 90 The protection mechanisms and their corresponding bit-masks are as 91 follows: 93 1 No protection mechanism 94 2 Integrity (krb_mk_safe) protection 95 4 Privacy (krb_mk_priv) protection 97 EXAMPLE: The following are two Kerberos version 4 login scenarios 98 (note that the line breaks in the sample authenticators are for 99 editorial clarity and are not in real authenticators) 101 S: * OK IMAP4 Server 102 C: A001 AUTHENTICATE KERBEROS_V4 103 S: + AmFYig== 104 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 105 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 106 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 107 S: + or//EoAADZI= 108 C: DiAF5A4gA+oOIALuBkAAmw== 109 S: A001 OK Kerberos V4 authentication successful 111 S: * OK IMAP4 Server 112 C: A001 AUTHENTICATE KERBEROS_V4 113 S: + gcfgCA== 114 C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT 115 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd 116 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh 117 S: A001 NO Kerberos V4 authentication failed 119 GSSAPI authentication mechanism 121 The authentication type associated with all mechanisms employing the 122 GSSAPI [RFC1508] is ``GSSAPI''. 124 The first ready response issued by the server contains no data. The 125 client should call GSS_Init_sec_context, passing in 0 for 126 input_context_handle (initially) and a targ_name equal to output_name 127 from GSS_Import_Name called with input_name_type of NULL and 128 input_name_string of "SERVICE:imap@hostname" where "hostname" is the 129 fully qualified host name of the server with all letters in lower 130 case. The client must then respond with the resulting output_token. 131 If GSS_Init_sec_context returns GSS_CONTINUE_NEEDED, then the client 132 should expect the server to issue a token in a subsequent ready 133 response. The client must pass the token to another call to 134 GSS_Init_sec_context. 136 If GSS_Init_sec_context returns GSS_COMPLETE, then the client should 137 respond with any resulting output_token. If there is no 138 output_token, the client should respond with no data. The client 139 should then expect the server to issue a token in a subsequent ready 140 response. The client should pass this token to GSS_Unseal and 141 interpret the first octet of resulting cleartext as a bit-mask 142 specifying the protection mechanisms supported by the server and the 143 second through fourth octets as the maximum size output_message to 144 send to the server. The client should construct data, with the first 145 octet containing the bit-mask specifying the selected protection 146 mechanism, the second through fourth octets containing in network 147 byte order the maximum size output_message the client is able to 148 receive, and the remaining octets containing a user name string. The 149 client must pass the data to GSS_Seal with conf_flag set to FALSE, 150 and respond with the generated output_message. The client can then 151 consider the server authenticated. 153 The server must issue a ready response with no data and pass the 154 resulting client supplied token to GSS_Accept_sec_context as 155 input_token, setting acceptor_cred_handle to NULL (for "use default 156 credentials"), and 0 for input_context_handle (initially). If 157 GSS_Accept_sec_context returns GSS_CONTINUE_NEEDED, the server should 158 return the generated output_token to the client in a ready response 159 and pass the resulting client supplied token to another call to 160 GSS_Accept_sec_context. 162 If GSS_Accept_sec_context returns GSS_COMPLETE, then if an 163 output_token is returned, the server should return it to the client 164 in a ready response and expect a reply from the client with no data. 165 Whether or not an output_token was returned, the server then should 166 then construct 4 octets of data, with the first octet containing a 167 bit-mask specifying the protection mechanisms supported by the server 168 and the second through fourth octets containing in network byte order 169 the maximum size output_token the server is able to receive. The 170 server must then pass the plaintext to GSS_Seal with conf_flag set to 171 FALSE and issue the generated output_message to the client in a ready 172 response. The server must then pass the resulting client supplied 173 token to GSS_Unseal and interpret the first octet of resulting 174 cleartext as the bit-mask for the selected protection mechanism, the 175 second through fourth octets as the maximum size output_message to 176 send to the client, and the remaining octets as the user name. Upon 177 verifying the src_name is authorized to authenticate as the user 178 name, The server should then consider the client authenticated. 180 The protection mechanisms and their corresponding bit-masks are as 181 follows: 183 1 No protection mechanism 184 2 Integrity protection. 186 Sender calls GSS_Seal with conf_flag set to FALSE 187 4 Privacy protection. 188 Sender calls GSS_Seal with conf_flag set to TRUE 190 S/Key authentication mechanism 192 The authentication type associated with S/Key [SKEY] is ``SKEY''. 194 The first ready response issued by the server contains no data. The 195 client responds with the user name string. 197 The data encoded in the second ready response contains the decimal 198 sequence number followed by a single space and the seed string for 199 the indicated user. The client responds with the one-time-password, 200 as either a 64-bit value in network byte order or encoded in the "six 201 English words" format. 203 Upon successful verification of the one-time-password, the server 204 should consider the client authenticated. 206 S/Key authentication does not provide for any protection mechanisms. 208 EXAMPLE: The following are two S/Key login scenarios. 210 S: * OK IMAP4 Server 211 C: A001 AUTHENTICATE SKEY 212 S: + 213 C: bW9yZ2Fu 214 S: + OTUgUWE1ODMwOA== 215 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== 216 S: A001 OK S/Key authentication successful 218 S: * OK IMAP4 Server 219 C: A001 AUTHENTICATE SKEY 220 S: + 221 C: c21pdGg= 222 S: + OTUgUWE1ODMwOA== 223 C: BsAY3g4gBNo= 224 S: A001 NO S/Key authentication failed 226 References 228 [IMAP4] Crispin, Mark R., "Internet Message Access Protocol - 229 Version 4", Work in Progress of the IETF IMAP WG, draft-ietf-imap- 230 imap4-??.txt. Check Internet Drafts listing for latest version. 232 [RFC1508] Linn, John, "Generic Security Service Application Program 233 Interface", RFC 1508. 235 [SKEY] Haller, Neil M. "The S/Key One-Time Password System", 236 Bellcore, Morristown, New Jersey, October 1993, 237 thumper.bellcore.com:pub/nmh/docs/ISOC.symp.ps 239 Security Considerations 241 Security issues are discussed throughout this memo. 243 Author's Address 245 John G. Myers 246 Carnegie-Mellon University 247 5000 Forbes Ave. 248 Pittsburgh PA, 15213-3890 250 Email: jgm+@cmu.edu 252 This document will expire before December 25, 1994.