idnits 2.17.00 (12 Aug 2021) /tmp/idnits20598/draft-kucherawy-sender-auth-caps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 17, 2009) is 4775 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 5451 (ref. 'AUTH-RESULTS') (Obsoleted by RFC 7001) == Outdated reference: draft-crocker-email-arch has been published as RFC 5598 -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft Sendmail, Inc. 4 Intended status: Informational April 17, 2009 5 Expires: October 19, 2009 7 Indicating Message Authentication System Parameters 8 draft-kucherawy-sender-auth-caps-01 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 19, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This memo defines simple extensions to IMAP, POP3 and SMTP to permit 47 a user's message reading software (Mail User Agent, or MUA) to 48 determine the properties of its environment with respect to available 49 message authentication services. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. SMTP AUTHSERV Extension . . . . . . . . . . . . . . . . . . . 6 56 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2. Framework for the AUTHSERV SMTP Extension . . . . . . . . 6 58 3.3. Details . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. IMAP AUTHSERV Capability . . . . . . . . . . . . . . . . . . . 8 60 5. POP3 AUTHSERV Capability . . . . . . . . . . . . . . . . . . . 9 61 6. Using DNS to Advertise Authentication Service . . . . . . . . 10 62 7. Conformance and Usage Requirements . . . . . . . . . . . . . . 11 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 64 8.1. SMTP Extension Registration . . . . . . . . . . . . . . . 12 65 8.2. IMAP Extension Registration . . . . . . . . . . . . . . . 12 66 8.3. POP3 Extension Registration . . . . . . . . . . . . . . . 12 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 70 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 71 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 72 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 16 73 B.1. Example use of SMTP extension . . . . . . . . . . . . . . 16 74 B.2. Example use of IMAP extension . . . . . . . . . . . . . . 17 75 B.3. Example use of POP3 extension . . . . . . . . . . . . . . 18 76 Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 19 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 1. Introduction 81 The message header field defined in [AUTH-RESULTS] can be used to 82 relay to MUAs or other internal filtering agents the results of 83 message authentication efforts performed by upstream Mail Transport 84 Agents (MTAs). As messaging is generally not secure by default, 85 there exist some vectors for allowing forgeries of that header field 86 through to user agents or filters which might then take inappropriate 87 action. (See the Security Considerations section of that memo for 88 details.) 90 Part of the work required to secure those vectors involves securing 91 the channel between MTAs and user agents such that the contents of 92 the header field can be trusted. Another important need is to handle 93 the configuration of that channel as automatically as possible. 95 There are two important facilities needed toward this end: 97 1. An [SMTP] extension: User agents can contact upstream MTAs within 98 their administrative domains to see if those MTAs are conforming 99 to the security requirements of [AUTH-RESULTS], and possibly also 100 determine what token(s) those MTAs use when generating 101 Authentication-Results header fields. 103 2. [IMAP] and/or [POP3] extensions: User agents can contact their 104 message store servers to determine what token(s) authorized MTAs 105 use when generating the authentication results header fields, 106 which also implicitly notifies the MUA that the administrative 107 domain conforms to the security requirements of [AUTH-RESULTS]. 109 2. Definitions 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC2119. 115 An "MTA" is a Mail Transfer Agent, or any agent which uses [SMTP] or 116 its extensions to format and transport a message. 118 An "MDA" is a Mail Delivery Agent (also sometimes referred to as 119 "LDA" or Local Delivery Agent), or any agent which has access to 120 receive a message from an MTA and write it into the receiving user's 121 "inbox". 123 An "MUA" is a Mail User Agent, or any software which retrieves and 124 displays messages on behalf of a user. It may use [IMAP] or [POP3]. 126 A "border MTA" is an MTA which acts as a gateway between the general 127 Internet and the users within an organizational boundary. 129 An "intermediate MTA" is an MTA which handles messages after a border 130 MTAs and before a delivery MTA. 132 +-----+ +-----+ +------------+ 133 | MUA |-->| MSA |-->| Border MTA | 134 +-----+ +-----+ +------------+ 135 | 136 | 137 V 138 +----------+ 139 | Internet | 140 +----------+ 141 | 142 | 143 V 144 +-----+ +-----+ +------------------+ +------------+ 145 | MUA |<==| MDA |<==| Intermediate MTA |<==| Border MTA | 146 +-----+ +-----+ +------------------+ +------------+ 148 Generally it is assumed that the work of applying message 149 authentication schemes takes place at a border MTA or a delivery MTA. 150 This specification is written with that assumption in mind. However, 151 there are some sites at which the entire mail infrastructure consists 152 of a single host. In such cases, such terms as "border MTA" and 153 "delivery MTA" may well apply to the same machine or even the very 154 same agent. It is also possible that message authentication could 155 take place on an intermediate MTA. Although this document doesn't 156 specifically include such cases, they are not meant to be excluded 157 from this specification. 159 See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail 160 system architecture. 162 In the figure shown above, the double-lines indicate the portions of 163 the transport of a message where this protocol would be applied. 164 Note also that the Local Mail Transfer Protocol [LMTP] could benefit 165 from a similar extension. 167 "authserv-id" is imported from [AUTH-RESULTS]. 169 3. SMTP AUTHSERV Extension 171 3.1. Description 173 This section defines a new [SMTP] extension which enables user agents 174 and downstream filters to interrogate an MTA as to whether or not it 175 conforms to the security requirements of [AUTH-RESULTS]. In 176 particular, it reveals (a) that it conforms to that memo's 177 requirements, and (b) what "authserv-id" that MTA uses when adding 178 Authentication-Results header fields to messages inbound. 180 3.2. Framework for the AUTHSERV SMTP Extension 182 Per the requirements of [SMTP], the framework for the AUTHSERV 183 Extension is as follows: 185 1. The name of the SMTP service extension is "Authserv-ID"; 187 2. The SMTP buffer length is extended by 256 bytes on servers 188 offering this service extension; 190 3. The EHLO keyword value associated with the extension is AUTHSERV; 192 4. The parameter used with the AUTHRES EHLO keyword is an 193 "authserv-id" as defined above, and is optional; 195 5. No additional parameters are added to the MAIL command; 197 6. No additional parameters are added to the RCPT command; 199 7. No additional SMTP verbs are defined by this extension; and 201 8. The next subsection discusses how support for the extension 202 affects the behaviour of a server and client SMTP session. 204 3.3. Details 206 If an MTA is compliant with that specification, it SHOULD use this 207 extension to advertise the "authserv-id" it uses when generating new 208 Authentication-Results header fields. An MUA can then use SMTP to 209 query the upstream MTA by issuing an EHLO command to determine 210 whether or not the MTA implements the specification in the header 211 field memo and also what "authserv-id" it should expect. Once the 212 presence or absence of this information is determined by the MUA, it 213 would simply issue a QUIT command and disconnect. 215 The SMTP server MAY choose not to include the "authserv-id" token in 216 use if there is some practical reason to do so. In this case, the 217 server is simply announcing that it conforms to the remaining 218 security issues discussed in [AUTH-RESULTS]. 220 This SMTP extension adds no new SMTP functionality per se. Rather, 221 it simply provides a means for an MUA attempting to implement 222 [AUTH-RESULTS] to acquire important security information about its 223 environment. 225 4. IMAP AUTHSERV Capability 227 A new [IMAP] capability called AUTHSERV is defined. 229 Prior to authentication, it has no value associated with it, i.e. the 230 capability reported is simply "AUTHSERV". After authentication, it 231 always has a value associated with it, namely the "authserv-id" 232 string used within the administrative domain represented by the IMAP 233 server to declare validated authentication results, i.e. it becomes 234 "AUTHSERV=authserv-id". 236 The [ABNF] defining the capability's syntax is as follows: 238 authserv-cap := AUTHSERV [ "=" authserv-id ] 240 The advertisement of this capability to a client 242 1. MAY be considered by the client to be a statement that the 243 administrative domain is compliant with the security requirements 244 of [AUTH-RESULTS]; and 246 2. in the post-authentication form, contains the "authserv-id" 247 string which will be present on all Authentication-Results header 248 fields which the client can use when determining courses of 249 action based on the results of prior message authentication 250 efforts. 252 5. POP3 AUTHSERV Capability 254 The formal definition, per [POP3-CAPA]: 256 CAPA tag: AUTHSERV 258 Arguments: "authserv-id" string used within the administrative 259 domain 261 Added commands: none 263 Standard commands affected: none 265 Announced states / possible differences: both / yes (see below) 267 Commands valid in states: n/a 269 Specification reference: this document 271 Discussion: A new [POP3] capability called AUTHSERV is defined. It 272 MUST have a value associated with it in the TRANSACTION state, 273 namely the "authserv-id" string used within the administrative 274 domain represented by the POP3 server to declared validated 275 authentication results. It MUST NOT have a value in the 276 AUTHENTICATION state. The advertisement of this capability to a 277 client 279 1. MAY be considered by the client to be a statement that the 280 administrative domain is compliant with the security 281 requirements of [AUTH-RESULTS]; and 283 2. contains the "authserv-id" string which will be present on all 284 Authentication-Results header fields which the client could 285 use when determining courses of action based on the results of 286 prior message authentication efforts. 288 6. Using DNS to Advertise Authentication Service 290 An ADMD can place the "authserv-id" token in a text resource record 291 (TXT) for MUAs to query. For this purpose, the label "_authservid" 292 is reserved in the DNS namespace at the same location as the top of 293 the ADMD. 295 The name for the label "_authservid" was chosen because any domain 296 name that includes it as one of its labels cannot be a valid host 297 name. There will never be any accidental overlap with a valid domain 298 name. Further, it is safe to create a rule that says that a TXT DNS 299 record that comes from a domain name that includes a "_authservid" 300 label will always have the content defined in this document. 302 7. Conformance and Usage Requirements 304 Section 3, Section 4 and Section 5 are each individual specifications 305 containing proposals supporting the goals specified in Section 1 and 306 in [AUTH-RESULTS]. Use of them in any combination (other than 307 "none") constitutes minimal conformance to this specification and 308 support of the header field memo. 310 8. IANA Considerations 312 This section discusses actions requested by IANA, per 313 [IANA-CONSIDERATIONS]. 315 8.1. SMTP Extension Registration 317 IANA is requested to register the AUTHSERV extension to SMTP, 318 referencing this memo as its defining document. 320 8.2. IMAP Extension Registration 322 This document constitutes registration of the AUTHSERV IMAP 323 capability in the imap4-capabilities registry. 325 8.3. POP3 Extension Registration 327 This document constitutes registration of the AUTHSERV POP3 328 capability in the pop3-extension-mechanism registry. 330 9. Security Considerations 332 This memo serves to address some of the security considerations 333 within [AUTH-RESULTS]. In particular, the focus of this memo is to 334 provide the means to determine automatically whether the 335 administrative domain in which an MUA finds itself is (or claims to 336 be) conformant with the security considerations of that memo, and 337 furthermore to acquire a key piece of information to be used in 338 carrying out the work described there. It is not an attempt to 339 resolve any of those considerations, other than simplifying to some 340 extent the work of configuring MUAs, thus leaving fewer places for 341 misconfigurations to occur and security problems to form. 343 Consult that document for further discussion of security issues. 345 10. References 347 10.1. Normative References 349 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 350 Specifications: ABNF", RFC 5234, January 2008. 352 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 353 4rev1", RFC 3501, March 2003. 355 [POP3-CAPA] 356 Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension 357 Mechanism", RFC 2449, November 1998. 359 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 360 October 2008. 362 10.2. Informative References 364 [AUTH-RESULTS] 365 Kucherawy, M., "Message Header Field for Indicating 366 Message Authentication Status", RFC 5451, April 2009. 368 [I-D.DRAFT-CROCKER-EMAIL-ARCH] 369 Crocker, D., "Internet Mail Architecture", 370 draft-crocker-email-arch (work in progress), May 2007. 372 [IANA-CONSIDERATIONS] 373 Alvestrand, H. and T. Narten, "Guidelines for Writing an 374 IANA Considerations Section in RFCs", RFC 2434, 375 October 1998. 377 [LMTP] Meyers, J., "Local Mail Transport Protocol", RFC 2033, 378 October 1996. 380 [POP3] Meyers, J. and M. Rose, "Post Office Protocol - Version 381 3", RFC 1939, May 1996. 383 Appendix A. Acknowledgements 385 The author wishes to acknowledge the following for their review and 386 constructive criticism of this proposal: Alexey Melnikov 388 Appendix B. Examples 390 This section presents some examples of the use of these extensions. 391 In all cases, "C:" represents a transmission by the client and "S:" 392 represents a transmission by the server. 394 B.1. Example use of SMTP extension 396 An example use of the AUTHSERV SMTP extension: 398 C: (establishes connection to SMTP server) 399 S: 220 server.example.com ESMTP; Fri, 10 Oct 2008 13:52:37 -0700 (PDT) 400 C: EHLO myname.example.com 401 S: 250-ENHANCEDSTATUSCODES 402 S: 250-PIPELINING 403 S: 250-8BITMIME 404 S: 250-SIZE 405 S: 250-DSN 406 S: 250-DELIVERBY 407 S: 250-AUTHSERV authserver.example.com 408 S: 250 HELP 409 C: QUIT 410 S: 221 server.example.com closing connection 411 S: (closes connection channel) 413 The client has connected to the SMTP server and issued the EHLO 414 command to determine whether or not the SMTP server claims to support 415 the requirements of the header memo. From this the client learns 416 that in fact it does conform, and furthermore knows what 417 "authserv-id" will be used by this MTA when communicating 418 authentication results. 420 B.2. Example use of IMAP extension 422 An example use of the AUTHSERV IMAP capability (server replies 423 wrapped here for legibility): 425 C: (establishes connection to IMAP server) 426 S: * OK IMAP server IMAP4rev1 ready 427 C: x CAPABILITY 428 S: * CAPABILITY CAPABILITY IMAP4 IMAP4rev1 UIDPLUS 429 AUTHSERV 430 S: x OK CAPABILITY COMPLETED 431 (authentication takes place) 432 C: x CAPABILITY 433 S: * CAPABILITY CAPABILITY IMAP4 IMAP4rev1 UIDPLUS 434 AUTHSERV=authserv.example.com 435 S: x OK CAPABILITY COMPLETED 436 (session continues) 438 The client connects and requests capabilities, immediately learning 439 that this administrative domain complies with the security 440 requirements of the header memo. After authentication, the client 441 issues a second request for capabilities at which point the local 442 "authserv-id" in use is revealed. 444 B.3. Example use of POP3 extension 446 An example use of the AUTHSERV POP3 capability (server replies 447 wrapped here for legibility): 449 C: (establishes connection to IMAP server) 450 S: +OK POP3 server ready 451 C: CAPA 452 S: +OK Capability list follows 453 S: TOP 454 S: USER 455 S: SASL CRAM-MD5 456 S: RESP-CODES 457 S: AUTHSERV 458 S: . 459 (authentication takes place) 460 C: CAPA 461 S: +OK Capability list follows 462 S: TOP 463 S: USER 464 S: SASL CRAM-MD5 465 S: RESP-CODES 466 S: AUTHSERV authserv.example.com 467 S: . 468 (session continues) 470 The client connects and requests capabilities, immediately learning 471 that this administrative domain complies with the security 472 requirements of the header memo. After authentication, the client 473 issues a second request for capabilities at which point the local 474 "authserv-id" in use is revealed. 476 Appendix C. Public Discussion 478 [REMOVE BEFORE PUBLICATION] 480 Public discussion of this proposed specification is handled via the 481 mail-vet-discuss@mipassoc.org mailing list. The list is open. 482 Access to subscription forms and to list archives can be found at 483 http://mipassoc.org/mailman/listinfo/mail-vet-discuss. 485 Author's Address 487 Murray S. Kucherawy 488 Sendmail, Inc. 489 6475 Christie Ave., Suite 350 490 Emeryville, CA 94608 491 US 493 Phone: +1 510 594 5400 494 Email: msk+ietf@sendmail.com