idnits 2.17.1 draft-kucherawy-sender-auth-header-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.2b on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1084. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1095. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1102. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1108. -- The document has an RFC 3978 Section 5.2(b) Derivative Works Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: As stated in Section 2.1, this header field SHOULD be treated as though it were a trace header field as defined in section 3.6 of [MAIL], and hence MUST not be reordered and MUST be prepended to the message, so that there is generally some indication upon delivery of where in the chain of handling MTAs the message authentication was done. -- 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 (November 5, 2007) is 6018 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) == Missing Reference: 'Internet' is mentioned on line 165, but not defined == Missing Reference: 'CFWS' is mentioned on line 270, but not defined == Missing Reference: 'RFC2822' is mentioned on line 565, but not defined ** Obsolete undefined reference: RFC 2822 (Obsoleted by RFC 5322) == Missing Reference: 'TBD' is mentioned on line 598, but not defined ** Obsolete normative reference: RFC 2822 (ref. 'MAIL') (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 2554 (ref. 'AUTH') (Obsoleted by RFC 4954) -- Obsolete informational reference (is this intentional?): RFC 4870 (ref. 'DOMAINKEYS') (Obsoleted by RFC 4871) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) -- Duplicate reference: RFC2434, mentioned in 'IANA-HEADERS', was also mentioned in 'IANA-CONSIDERATIONS'. -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. 'IANA-HEADERS') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 4408 (ref. 'SPF') (Obsoleted by RFC 7208) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 17 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: Standards Track November 5, 2007 5 Expires: May 8, 2008 7 Message Header Field for Indicating Message Authentication Status 8 draft-kucherawy-sender-auth-header-09 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 This document may not be modified, and derivative works of it may not 17 be created. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 8, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This memo defines a new message header field for use with electronic 44 mail messages to indicate the results of message authentication 45 efforts. Mail user agents (MUAs) may use this message header field 46 to relay that information in a convenient way to users or to make 47 sorting and filtering decisions. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. Definition and Format of the Header . . . . . . . . . . . . . 6 56 2.1. General Description . . . . . . . . . . . . . . . . . . . 6 57 2.2. Formal Definition . . . . . . . . . . . . . . . . . . . . 6 58 2.3. Authentication Identifier Fields . . . . . . . . . . . . . 8 59 2.4. Result Values . . . . . . . . . . . . . . . . . . . . . . 9 60 2.5. Definition Of Initial Methods . . . . . . . . . . . . . . 10 61 2.6. Extension Fields . . . . . . . . . . . . . . . . . . . . . 10 62 3. The 'iprev' Authentication Method . . . . . . . . . . . . . . 11 63 4. Adding The Header Field To A Message . . . . . . . . . . . . . 12 64 4.1. Header Position and Interpretation . . . . . . . . . . . . 12 65 5. Removing The Header Field . . . . . . . . . . . . . . . . . . 14 66 6. Conformance and Usage Requirements . . . . . . . . . . . . . . 15 67 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 68 7.1. The Authentication-Results: header . . . . . . . . . . . . 16 69 7.2. Email Authentication Method Name Registry . . . . . . . . 16 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 71 8.1. Forged Headers . . . . . . . . . . . . . . . . . . . . . . 18 72 8.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 18 73 8.3. Other Protocols . . . . . . . . . . . . . . . . . . . . . 19 74 8.4. Header Position . . . . . . . . . . . . . . . . . . . . . 19 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 76 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 77 9.2. Informative References . . . . . . . . . . . . . . . . . . 20 78 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 79 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 23 80 Appendix C. Authentication-Results Examples . . . . . . . . . . . 24 81 C.1. Trivial case; header field not present . . . . . . . . . . 24 82 C.2. Nearly-trivial case; service provided, but no 83 authentication done . . . . . . . . . . . . . . . . . . . 25 84 C.3. Service provided, authentication done . . . . . . . . . . 25 85 C.4. Service provided, several authentications done, single 86 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 87 C.5. Service provided, several authentications done, 88 different MTAs . . . . . . . . . . . . . . . . . . . . . . 27 89 C.6. Service provided, multi-tiered authentication done . . . . 29 90 Appendix D. Public Discussion . . . . . . . . . . . . . . . . . . 31 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 92 Intellectual Property and Copyright Statements . . . . . . . . . . 33 94 1. Introduction 96 This memo defines a new message header field for electronic mail 97 messages which presents the results of a message authentication 98 effort in a machine-readable format. The intent is to create a place 99 to collect such data when message authentication mechanisms are in 100 use so that a Mail User Agent (MUA) can provide a recommendation to 101 the user as to the trustworthiness of the message's origin and 102 content. 104 This memo defines both the format of this new header field, and 105 discusses the implications of its presence or absence. 107 [UPDATE PRIOR TO FINAL VERSION] At the time of publication of this 108 draft, [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and [SPF] are the 109 published e-mail authentication methods in common use. As various 110 methods emerge, it is necessary to prepare for their appearance and 111 encourage convergence in the area of interfacing these filters to 112 MUAs. 114 Although [SPF] defined a header field called Received-SPF for this 115 purpose, that header field is specific to the conveyance of SPF 116 results only and thus is insufficient to satisfy the requirements 117 enumerated below. 119 1.1. Purpose 121 The header field defined in this memo is expected to serve several 122 purposes: 124 1. Convey to MUAs from filters and Mail Transfer Agents (MTAs) the 125 results of various message authentication checks being applied; 127 2. Provide a common location for the presentation of this data; 129 3. Create an extensible framework for specifying new authentication 130 methods as such emerge; 132 4. Convey the results of message authentication tests to later 133 filtering agents within the same "trust domain", as such agents 134 might apply more or less stringent checks based on message 135 authentication results. 137 1.2. Requirements 139 This memo establishes no new requirements on existing protocols or 140 servers, as there is currently no standard place for the described 141 data to be collected or presented. 143 1.3. Definitions 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC2119. 149 A "border MTA" is an MTA which acts as a gateway between the general 150 Internet and the users within an organizational boundary. 152 A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA which 153 actually enacts delivery of a message to a user's inbox or other 154 final delivery. 156 An "intermediate MTA" is an MTA which handles messages after a border 157 MTAs and before a delivery MTA. 159 +-----+ +-----+ +------------+ 160 | MUA |-->| MSA |-->| Border MTA | 161 +-----+ +-----+ +------------+ 162 | 163 | 164 V 165 [Internet] 166 | 167 | 168 V 169 +-----+ +-----+ +------------------+ +------------+ 170 | MUA |<--| MDA |<--| Intermediate MTA |<--| Border MTA | 171 +-----+ +-----+ +------------------+ +------------+ 173 Generally it is assumed that the work of applying message 174 authentication schemes takes place at a border MTA or a delivery MTA. 175 This specification is written with that assumption in mind. However, 176 there are some sites at which the entire mail infrastructure consists 177 of a single host. In such cases, such terms as "border MTA" and 178 "delivery MTA" may well apply to the same machine or even the very 179 same agent. It is also possible that message authentication could 180 take place on an intermediate MTA. Although this document doesn't 181 specifically include such cases, they are not meant to be excluded 182 from this specification. 184 See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail 185 system architecture. 187 2. Definition and Format of the Header 189 This section gives a general overview of the format of the header 190 field being defined, and then provides more formal specification. 192 2.1. General Description 194 The new header field being defined here is called "Authentication- 195 Results". It is a Structured Header Field as defined in [MAIL] and 196 thus all of the related definitions in that document apply. 198 This new header field MUST be added at the top of the message as it 199 transits MTAs which do authentication checks so some idea of how far 200 away the checks were done can be inferred. It therefore should be 201 treated as a Trace Header Field as defined in [MAIL] and thus all of 202 the related definitions in that document apply. 204 The value of the header field (after removing [MAIL] comments) 205 consists of an authentication identifier and then a series of 206 "method=result" statements indicating which authentication method(s) 207 were applied and their respective results, and then, for each applied 208 method, a "property=value" statement indicating which message 209 property was evaluated. 211 The header field MAY appear more than once in a single message, or 212 more than one result MAY be represented in a single header field, or 213 a combination of these MAY be applied. 215 2.2. Formal Definition 217 Formally, the header field is specified as follows: 219 header = "Authentication-Results:" [CFWS] authserv-id 220 [CFWS] [version] *(";" methodspec *propspec [CFWS]) 222 authserv-id = dot-atom-text 223 ; see below for a description of this element; 224 ; "dot-atom-text" is defined in section 3.2.4 of [MAIL] 226 version = "version=" 1*DIGIT [CFWS] 227 ; indicates which version of this specification is in use; 228 ; this draft is version "1" 230 methodspec = [CFWS] method [CFWS] "=" [CFWS] result 231 ; indicates which authentication method was evaluated 233 propspec = [CFWS] ptype [CFWS] "." [CFWS] property [CFWS] "=" value 234 ; an indication of which properties of the message 235 ; were evaluated by the authentication scheme being 236 ; applied to yield the reported result 238 method = token [ "/" version ] 239 ; a method indicates which method's result is 240 ; represented by "value", and is one of the methods 241 ; explicitly defined as valid in this document 242 ; or is an extension method as defined below 244 version = 1*( ALPHA / DIGIT ) 0*( "." 1*( ALPHA / DIGIT ) ) 245 ; indicates which version of the method was applied 247 result = "pass" / "hardfail" / "softfail" / "neutral" / 248 "temperror" / "permerror" 249 ; an indication of the results of the attempt to 250 ; authenticate the message 252 ptype = "smtp" / "header" / "body" / "policy" 253 ; indicates whether the property being evaluated was 254 ; a parameter to an [SMTP] command, or was a value taken 255 ; from a message header field, or was some property of 256 ; the message body, or some other property evaluated by 257 ; the receiving MTA 259 property = token 260 ; if "ptype" is "smtp", this indicates which [SMTP] 261 ; command provided the value which was evaluated by the 262 ; authentication scheme being applied; if "ptype" is 263 ; "header", this indicates from which header field the 264 ; value being evaluated was extracted; if "ptype" is 265 ; "body", this indicates the offset into the body at which 266 ; content of interest was detected; if "ptype" is "policy" 267 ; then this indicates the name of the policy which caused 268 ; this header field to be added (see below) 270 value = [CFWS] token [CFWS] / mailbox 271 ; the value extracted from the message property defined 272 ; by the "ptype.property" construction; if the value 273 ; identifies a mailbox, then it is a "mailbox" 274 ; as defined in section 3.4 of [MAIL]; 275 ; "mailbox" allows CFWS 277 The "token" is as defined in section 5.1 of [MIME]. 279 See Section 2.3 for a description of the "authserv-id" element. 281 The list of commands eligible for use with the "smtp" ptype can be 282 found in [SMTP] and subsequent amendments. 284 "CFWS" is as defined in section 3.2.3 of [MAIL]. 286 The "propspec" may be omitted if for example the method was unable to 287 extract any properties to do its evaluation yet has a result to 288 report. 290 The "ptype" and "property" values used by each authentication method 291 should be defined in the specification for that method (or its 292 amendments). 294 The "ptype" and "property" are case-insensitive. 296 A "ptype" value of "policy" indicates a policy decision about the 297 message not specific to a property of the message that could be 298 extracted. For example, if a method would normally report a 299 "ptype.property" of "header.From" and no From: header field was 300 present, the method can use "policy" to indicate that no conclusion 301 about the authenticity of the message could be reached. 303 If the parsed "ptype.property" construction clearly identifies a 304 mailbox (in particular, smtp.mail, smtp.rcpt, header.from, 305 header.sender), then the "value" MUST be a "mailbox". Other 306 properties (e.g. smtp.helo) may be evaluated, but the property MUST 307 still be expressed as a "token" for simplified parsing. 309 2.3. Authentication Identifier Fields 311 Every Authentication-Results header field has an authentication 312 identifier field ("authserv-id" above) which is a single result 313 identifier. This is similar in syntax to a fully-qualified domain 314 name. 316 The authentication identifier field provides a unique identifier that 317 refers to the authenticating service within a given mail 318 administrative domain. The uniqueness of the identifier is 319 guaranteed by the mail administrative domain that generates it and 320 must pertain to exactly that one mail administrative domain. This 321 identifier is intended to be machine-readable and not necessarily 322 meaningful to users. MUAs may use this identifier to determine 323 whether or not the data contained in an Authentication-Results header 324 field can be trusted. 326 For tracing and debugging purposes, the authentication identifier 327 SHOULD be the domain name of the MTA performing the authentication 328 check whose result is being reported. 330 Examples of valid authentication identifiers are mail.example.org, 331 engineering.example.net and ms1.newyork.example.com. 333 2.4. Result Values 335 The six possible values of the "result" are: 337 pass: The message passed the authentication tests. (This may 338 require accessing an authentication policy of some kind published 339 by the sending domain.) 341 hardfail: The message failed the authentication tests. (This may 342 require accessing an authentication policy of some kind published 343 by the sending domain.) 345 softfail: The message failed the authentication tests, and the 346 authentication method has either an explicit (published by the 347 sending domain) or implicit policy, but the policy being used 348 doesn't require successful authentication of all messages from 349 that domain. 351 neutral: The authentication method completed without errors, but was 352 unable to reach either a positive or negative result about the 353 message. 355 temperror: A temporary (recoverable) error occurred attempting to 356 authenticate the message; either the process couldn't be completed 357 locally, or (for methods requiring a policy to be accessed) there 358 was a temporary failure retrieving the sending domain's policy. A 359 later retry may produce a more final result. 361 permerror: A permanent (unrecoverable) error occurred attempting to 362 authenticate the message; either the process couldn't be completed 363 locally, or (for methods requiring a policy to be accessed) there 364 was a permanent failure retrieving the sending domain's policy. A 365 later retry is unlikely to yield a final result. 367 New methods not specified in this document MUST indicate which of 368 these should be returned when exceptions such as syntax errors are 369 detected. 371 2.5. Definition Of Initial Methods 373 As they are currently existing specifications for message 374 authentication, it is appropriate to define an authentication method 375 identifier for each of [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and 376 [SPF]. Therefore, the authentication method identifiers "auth", 377 "dkim", "domainkeys", "senderid" and "spf" respectively are hereby 378 defined for MTAs applying those specifications for e-mail message 379 authentication. See Section 7 for details. 381 2.6. Extension Fields 383 Additional authentication method identifiers may be defined in the 384 future by later revisions or extensions to this specification. 385 Extension identifiers beginning with "x-" will never be defined as 386 standard fields; such names are reserved for experimental use. 387 Method identifiers NOT beginning with "x-" MUST be registered with 388 the Internet Assigned Numbers Authority (IANA) and published in an 389 RFC. See Section 7 for further details. 391 Extension identifiers may be defined for the following reasons: 393 1. To allow additional information from emergent authentication 394 systems to be communicated to MUAs. The names of such 395 identifiers should reflect the name of the method being defined, 396 but should not be needlessly long. 398 2. To allow the creation of "sub-identifiers" which indicate 399 different levels of authentication and differentiate between 400 their relative strengths, e.g. "auth1-weak" and "auth1-strong". 402 Authentication method implementors are encouraged to provide adequate 403 information, via [MAIL] comments if necessary, to allow an MUA 404 developer to understand or relay ancilliary details of authentication 405 results. For example, if it might be of interest to relay what data 406 was used to perform an evaluation, such information could be relayed 407 as a comment in the header field, such as: 409 Authentication-Results: mx.example.com; 410 foo=pass bar.baz=blob (2 of 3 tests OK) 412 3. The 'iprev' Authentication Method 414 This section defines an authentication method called "iprev". 416 "iprev" is an attempt to verify that a client appears to be valid 417 based on some DNS queries. In particular, upon receiving a session 418 initiation of some kind from a client, the IP address of the client 419 peer is queried for matching names (i.e. a number-to-name 420 translation, also known as a "reverse lookup" or a "PTR" record 421 query). Once that result is acquired, a lookup of each of the names 422 (i.e. a name-to-number translation, or an "A" record query) thus 423 retrieved is done. The response to this second check should result 424 in at least one mapping to the client's IP address. 426 A successful test using this algorithm constitutes a result of "pass" 427 since the domain in which the client's PTR claims it belongs has 428 confirmed that claim. A failure to match constitutes a "hardfail". 429 There is no case in which "softfail" or "neutral" can be returned. 430 The remaining "temperror" and "permerror" cases refer respectively to 431 temporary and permanent DNS query errors. 433 4. Adding The Header Field To A Message 435 This specification makes no attempt to evaluate the relative 436 strengths of various message authentication methods that may become 437 available. As such, the order of the presented authentication 438 methods and results MUST NOT be used to determine the importance or 439 strength of any given method over another. Instead, the MUA must 440 interpret the result of each method based on its knowledge of what 441 that method evaluates. 443 The "method" MUST refer to an authentication method declared in the 444 IANA registry, or an extension method as defined in Section 2.6. See 445 Section 7 for further information about the registered methods. 447 An MTA compliant with this specification MUST add this header field 448 (after performing one or more message authentication tests) to 449 indicate at which host which the test was done, which test got 450 applied and what the result was. If an MTA applies more than one 451 such test, it MUST either add this header field once per test, or one 452 header field indicating all of the results. An MTA MUST NOT add a 453 result to an existing header. 455 An MTA MAY add this header field containing only the authentication 456 identifier portion to indicate explicitly that no message 457 authentication schemes were applied prior to delivery of this 458 message. 460 4.1. Header Position and Interpretation 462 In order to ensure non-ambiguous results and avoid the impact of 463 false header fields, an MUA SHOULD NOT interpret this header field 464 unless specifically instructed to do so by the user. That is, this 465 interpretation should not be "on by default". Naturally then, users 466 would not activate such a feature unless they are certain the header 467 field will be added by the receiving MTA that accepts the mail that 468 is ultimately read by the MUA, and instances of the header field 469 appearing to be from within the trust domain but actually added by 470 foreign MTAs will be removed before delivery. 472 Furthermore, an MUA SHOULD NOT interpret this header field unless the 473 authentication identifier it bears appears to be one within its own 474 trust domain as configured by the user. 476 An MUA MUST ignore any result reported using a "result" not specified 477 in this document, or a "ptype" not listed in the corresponding 478 registry for such values as defined in Section 7. 480 An MUA should not reveal these results to end users unless the 481 results are accompanied by, at a minimum, some associated reputation 482 data about the message that was authenticated. 484 As stated in Section 2.1, this header field SHOULD be treated as 485 though it were a trace header field as defined in section 3.6 of 486 [MAIL], and hence MUST not be reordered and MUST be prepended to the 487 message, so that there is generally some indication upon delivery of 488 where in the chain of handling MTAs the message authentication was 489 done. 491 Further discussion of this can be found in the Section 8 below. 493 5. Removing The Header Field 495 For security reasons, a border MTA conforming to this specification 496 MUST delete any discovered instance of this header field which claims 497 to have been added within its trust boundary. For example, a border 498 MTA for example.com receiving a message from outside of its mail 499 domain MUST delete any instance of this header field bearing an 500 authentication identifier indicating the header field was added 501 within example.com prior to adding its own header fields. However, 502 care must be taken not to remove header fields added on messages that 503 remain entirely within the originator's trust boundary (e.g. local- 504 to-local mail). 506 Furthermore, a border MTA MAY elect simply to remove all instances of 507 this header field on mail crossing its trust into its trust boundary. 509 A formal definition of "trust boundary" is deliberately not made 510 here. It is entirely possible that a border MTA for example.com 511 might explicitly trust authentication results asserted by upstream 512 host example.net even though they exist in completely disjoint 513 administrative boundaries. In that case the border MTA MAY elect not 514 to delete those results; moreover, the upstream host doing some 515 authentication work could apply a signing technology such as [DKIM] 516 on its own results to assure downstream hosts of their authenticity. 517 An example of this is provided in Appendix C. 519 Similarly, in the case of messages signed using [DKIM] or other 520 message signing methods that sign headers, this may invalidate one or 521 more signature on the message if they included the header field to be 522 removed at the time of signing. This behaviour can be desirable 523 since there's little value in validating the signature on a message 524 with forged headers. However, signing agents MAY therefore elect to 525 omit these header fields from signing to avoid this situation. 527 6. Conformance and Usage Requirements 529 An MTA or gateway conforms to this specification if it applies one or 530 more message authentication mechanisms and inserts a header field 531 corresponding to this specification after doing so and prior to 532 delivery (per Section 4) and removes apparently improper headers (per 533 Section 5). 535 MTAs that are relaying mail rather than delivering it, i.e. are not 536 part of an intended recipient's trust boundary, MAY perform message 537 authentication or even take actions based on the results found, but 538 SHOULD NOT add an "Authentication-Results" header field if relaying 539 (rather than rejecting or discarding at the gateway). Conversely, an 540 MTA doing local delivery and some form of message authentication MUST 541 add this header field prior to delivery the message in order to be 542 compliant. An exception to the former case is described in 543 Section 5. 545 A minimal implementation that does at least one message 546 authentication check will add the header field defined by this memo 547 prior to invoking local delivery procedures. 549 This specification places no restrictions on the processing of the 550 header field's contents by user agents or distribution lists. It is 551 presented to those packages solely for their own information. 553 7. IANA Considerations 555 IANA is requested to register a new header field and to create a new 556 table as described below. 558 7.1. The Authentication-Results: header 560 Per [IANA-HEADERS], the "Authentication-Results:" header field is 561 added to the IANA Permanent Message Header Field Registry. The 562 following is the registration template: 564 Header field name: Authentication-Results 565 Applicable protocol: mail ([RFC2822]) 566 Status: Standard 567 Author/Change controller: IETF 568 Specification document(s): [TBD] 569 Related information: 570 Requesting review of any proposed changes and additions to 571 this field is recommended. 573 7.2. Email Authentication Method Name Registry 575 Names of message authentication methods supported by this 576 specification must be registered with IANA, with the exception of 577 experimental names as described in Section 2.6. 579 New entries are assigned only for values that have been documented in 580 a published RFC that has IETF Consensus, per [IANA-CONSIDERATIONS]. 581 Each method must register a name, the specification that defines it, 582 one or more "ptype" values appropriate for use with that method, and 583 which "property" value(s) should be reported by that method. 585 The initial set of entries in this registry is as follows: 587 +------------+----------+--------+----------------+--------------------+ 588 | Method | defined | ptype | property | value | 589 +------------+----------+--------+----------------+--------------------+ 590 | auth | RFC2554 | smtp | auth | authenticated user | 591 +------------+----------+--------+----------------+--------------------+ 592 | dkim | RFC4871 | header | d | value of | 593 | | | | | signature "d" tag | 594 | | | +----------------+--------------------+ 595 | | | | i | value of | 596 | | | | | signature "i" tag | 597 +------------+----------+--------+----------------+--------------------+ 598 | dkim-ssp | [TBD] | header | from | value of From | 599 | | | | | header field | 600 | | | | | w/comments removed | 601 +------------+----------+--------+----------------+--------------------+ 602 | domainkeys | RFC4870 | header | from | value of From | 603 | | | | | header field | 604 | | | | | w/comments removed | 605 | | | +----------------+--------------------+ 606 | | | | sender | value of Sender | 607 | | | | | header field | 608 | | | | | w/comments removed | 609 +------------+----------+--------+----------------+--------------------+ 610 | iprev | this | policy | iprev | client IP address | 611 | | document | | | | 612 +------------+----------+--------+----------------+--------------------+ 613 | senderid | RFC4406 | header | name of header | value of header | 614 | | | | field used by | field used by PRA | 615 | | | | PRA | w/comments removed | 616 | | +--------+----------------+--------------------+ 617 | | | smtp | from | envelope sender | 618 +------------+----------+--------+----------------+--------------------+ 619 | spf | RFC4408 | smtp | from | envelope sender | 620 | | +--------+----------------+--------------------+ 621 | | | smtp | helo | HELO parameter | 622 | | +--------+----------------+--------------------+ 623 | | | smtp | ehlo | EHLO parameter | 624 +------------+----------+--------+----------------+--------------------+ 625 8. Security Considerations 627 The following security considerations apply when applying or 628 processing the "Authentication-Results" header field: 630 8.1. Forged Headers 632 An MUA that accesses a mailbox whose mail is handled by a non- 633 conformant MTA, and understands Authentication-Results header fields, 634 could potentially make false conclusions based on forged header 635 fields. A malicious user or agent could forge a header field using 636 the destination MX for a receiving domain as the hostname token in 637 the value of the header, and with the rest of the value claim that 638 the message was properly authenticated. The non-conformant MTA would 639 fail to strip the forged header field, and the MUA could 640 inappropriately trust it. 642 It is for this reason an MUA should not have processing of the 643 "Authentication-Results" header field enabled by default; instead it 644 should be ignored, at least for the purposes of enacting filtering 645 decisions, unless specifically enabled by the user after verifying 646 that the MTA is compliant. It is acceptable to have an MUA aware of 647 this specification, but have an explicit list of hostnames whose 648 "Authentication-Results" header fields are trustworthy; however, this 649 list should initially be empty. 651 Proposed alternate solutions to this problem are nascent. Possibly 652 the simplest is a digital signature on the header field that can be 653 verified by a posted public key. Another would be a means to 654 interrogate the MTA that added the header field to see if it is 655 actually providing any message authentication services and saw the 656 message in question, but this isn't especially palatable. In either 657 case, a method needs to exist to verify that the host that appears to 658 have added the header field (a) actually did so, and (b) is 659 legitimately adding that header field for this delivery. 661 8.2. Misleading Results 663 Until some form of service for querying the reputation of a sending 664 agent is widely deployed, the existence of this header field 665 indicating a "pass" does not render the message trustworthy. It is 666 possible for an arriving piece of spam or other undesirable mail to 667 pass checks by several of the methods enumerated above (e.g. a piece 668 of spam signed using [DKIM] by the originator of the spam). In 669 particular, this issue is not resolved by forged header removal 670 discussed above. 672 Hence, MUAs must take some care with use of this header even after 673 possibly malicious headers are scrubbed. There are several potential 674 heuristics that can be used to determine whether an authentication 675 results header is valid. For instance, an MUA could determine after 676 several replies that the user has replied to valid messages. 677 Alternatively, after many messages that contain the same results from 678 diverse paths, the MUA may decide to record that the sender is valid. 679 Similarly, when a different results header field appears, an MUA may 680 decide the older data is no longer trustworthy. In all of these 681 cases prudence dictates that the user be queried in these situations 682 until implementors have had some deployment experience. 684 8.3. Other Protocols 686 Mitigation of the forged header attack can also be accomplished by 687 moving the authentication results data into meta-data associated with 688 the message. In particular, an [SMTP] extension could be established 689 which is used to communicate authentication results from the border 690 MTA to intermediate and delivery MTAs; the latter of these could 691 arrange to store the authentication results as meta-data retrieved 692 and rendered along with the message by an [IMAP] client aware of a 693 similar extension in that protocol. The delivery MTA would be told 694 to trust data via this extension only from MTAs it trusts, and border 695 MTAs would not accept data via this extension from any source. There 696 is no vector in such an arrangement for forgery of authentication 697 data by an outside agent. 699 8.4. Header Position 701 Despite the requirements of [MAIL], header fields can sometimes be 702 reordered enroute by intermediate MTAs. The goal of requiring header 703 field addition only at the top of a message is an acknowledgement 704 that some MTAs do reorder header fields, but most do not. Thus, in 705 the general case, there will be some indication of which MTAs (if 706 any) handled the message after the addition of the header field 707 defined here. 709 9. References 711 9.1. Normative References 713 [MAIL] Resnick, P., "Internet Message Format", RFC 2822, 714 April 2001. 716 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 717 Extensions (MIME) Part One: Format of Internet Message 718 Bodies", RFC 2045, November 1996. 720 9.2. Informative References 722 [AUTH] Myers, J., "SMTP Service Extension for Authentication", 723 RFC 2554, March 1999. 725 [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 726 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 727 Signatures", RFC 4817, May 2007. 729 [DOMAINKEYS] 730 Delany, M., "Domain-based Email Authentication Using 731 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 732 May 2007. 734 [I-D.DRAFT-CROCKER-EMAIL-ARCH] 735 Crocker, D., "Internet Mail Architecture", 736 I-D draft-crocker-email-arch, May 2007. 738 [IANA-CONSIDERATIONS] 739 Alvestrand, H. and T. Narten, "Guidelines for Writing an 740 IANA Considerations Section in RFCs", RFC 2434, 741 October 1998. 743 [IANA-HEADERS] 744 Klyne, G., Nottingham, M., and J. Mogul, "Registration 745 Procedures for Message Header Fields", RFC 2434, 746 September 2004. 748 [IMAP] Crispin, M., "Internet Message Access Protocol - Version 749 4rev1", RFC 3501, March 2003. 751 [SENDERID] 752 Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 753 RFC 4406, April 2006. 755 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 756 April 2001. 758 [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 759 for Authorizing Use of Domains in E-Mail, Version 1", 760 RFC 4408, April 2006. 762 Appendix A. Acknowledgements 764 The author wishes to acknowledge the following for their review and 765 constructive criticism of this proposal: Eric Allman, Mark Delany, 766 Jim Fenton, Tony Hansen, Paul Hoffman, Eliot Lear, John Levine, Miles 767 Libbey, Charles Lindsey, S. Moonesamy, Juan Altmayer Pizzorno, 768 Michael Thomas. 770 Appendix B. Legacy MUAs 772 Implementors of this proposal should be aware that many MUAs are 773 unlikely to be retrofit to support the new header field and its 774 semantics. In the interests of convenience and quicker adaptation, a 775 delivery MTA might want to consider adding things that are processed 776 by existing MUAs in addition to the Authentication-Results header 777 field. One suggestion is to include a Priority: header field, on 778 messages that don't already have such a header field, containing a 779 value that reflects the strength of the authentication that was 780 accomplished, e.g. "low" for weak or no authentication, "normal" or 781 "high" for good or strong authentication. 783 Some modern MUAs can already filter based on the content of this 784 header field. However, there is keen interest in having MUAs make 785 some kind of graphical representation of this header field's meaning 786 to end users. Until this capability is added, other interim means of 787 conveying authentication results may be necessary while this proposal 788 and its successors are adopted. 790 Appendix C. Authentication-Results Examples 792 This section presents some examples of the use of this header field 793 to indicate authentication results. 795 C.1. Trivial case; header field not present 797 The trivial case: 799 Received: from mail-router.example.com 800 (mail-router.example.com [192.0.2.1]) 801 by server.sendmail.com (8.11.6/8.11.6) 802 with ESMTP id g1G0r1kA003489; 803 Fri, Feb 15 2002 17:19:07 -0800 804 From: sender@example.com 805 Date: Fri, Feb 15 2002 16:54:30 -0800 806 To: receiver@sendmail.com 807 Message-Id: <12345.abc@example.com> 808 Subject: here's a sample 810 Hello! Goodbye! 812 Example 1: Trivial case 814 The "Authentication-Results" header field is completely absent. The 815 MUA may make no conclusion about the validity of the message. This 816 could be the case because the message authentication services were 817 not available at the time of delivery, or no service is provided, or 818 the MTA is not in compliance with this specification. 820 C.2. Nearly-trivial case; service provided, but no authentication done 822 A message that was delivered by an MTA that conforms to this 823 specification but provides no actual message authentication service: 825 Authentication-Results: mail-router.example.com 826 Received: from mail-router.example.com 827 (mail-router.example.com [192.0.2.1]) 828 by server.sendmail.com (8.11.6/8.11.6) 829 with ESMTP id g1G0r1kA003489; 830 Fri, Feb 15 2002 17:19:07 -0800 831 From: sender@example.com 832 Date: Fri, Feb 15 2002 16:54:30 -0800 833 To: receiver@sendmail.com 834 Message-Id: <12345.abc@example.com> 835 Subject: here's a sample 837 Hello! Goodbye! 839 Example 2: Header present but no authentication done 841 The "Authentication-Results" header field is present, indicating that 842 the delivering MTA (which is named in the value of the header field) 843 conforms to this specification. The absence of any method and result 844 tokens indicates that no message authentication was done. 846 C.3. Service provided, authentication done 848 A message that was delivered by an MTA that conforms to this 849 specification and applied some message authentication: 851 Authentication-Results: mail-router.example.com; 852 spf=pass smtp.mail=sender@example.com 853 Received: from dialup-1-2-3-4.example.net 854 (dialup-1-2-3-4.example.net [192.0.2.200]) 855 by mail-router.example.com (8.11.6/8.11.6) 856 with ESMTP id g1G0r1kA003489; 857 Fri, Feb 15 2002 17:19:07 -0800 858 From: sender@example.net 859 Date: Fri, Feb 15 2002 16:54:30 -0800 860 To: receiver@example.com 861 Message-Id: <12345.abc@example.net> 862 Subject: here's a sample 864 Hello! Goodbye! 866 Example 3: Header reporting results 867 The "Authentication-Results" header field is present, indicating that 868 the border MTA (which is identified in the value of the header field) 869 conforms to this specification. Furthermore, the message was 870 authenticated by that MTA via the method specified in [SPF]. The MUA 871 could extract and relay this extra information if desired. 873 C.4. Service provided, several authentications done, single MTA 875 A message that was relayed inbound via a single MTA that conforms to 876 this specification and applied three different message authentication 877 checks: 879 Authentication-Results: mail-router.example.com; 880 auth=pass (cram-md5) smtp.mail=sender@example.com; 881 spf=pass smtp.mail=sender@example.com 882 Authentication-Results: mail-router.example.com; 883 sender-id=pass header.from=sender@example.com 884 Received: from mail-router.example.com 885 (mail-router.example.com [192.0.2.1]) 886 by dialup-1-2-3-4.example.net (8.11.6/8.11.6) 887 with ESMTP id g1G0r1kA003489; 888 Fri, Feb 15 2002 17:19:07 -0800 889 Date: Fri, Feb 15 2002 16:54:30 -0800 890 To: receiver@example.net 891 From: sender@example.com 892 Message-Id: <12345.abc@example.com> 893 Subject: here's a sample 895 Hello! Goodbye! 897 Example 4: Headers reporting results from one MTA 899 The "Authentication-Results" header field is present, indicating the 900 delivering MTA (which is identified in the value of the header field) 901 conforms to this specification. Furthermore, the sender 902 authenticated herself/himself to the MTA via a method specified in 903 [AUTH], and both [SPF] and [SENDERID] checks were done and passed. 904 The MUA could extract and relay this extra information if desired. 906 Two "Authentication-Results" header fields are not required since the 907 same host did all of the checking. The authenticating agent could 908 have consolidated all the results into one header field. 910 This example illustrates a scenario in which a remote user on a 911 dialup connection (example.net) sends mail to a border MTA 912 (example.com) using SMTP authentication to prove identity. The 913 dialup provider has been explicitly authorized to relay mail as 914 "example.com" resulting in passes by the SPF and SenderID checks. 916 C.5. Service provided, several authentications done, different MTAs 918 A message that was relayed inbound by two different MTAs that conform 919 to this specification and applied multiple message authentication 920 checks: 922 Authentication-Results: auth-checker.example.com; 923 sender-id=hardfail header.from=sender@example.com; 924 dkim=pass (good signature) header.i=sender@example.com 925 Received: from mail-router.example.com 926 (mail-router.example.com [192.0.2.1]) 927 by auth-checker.example.com (8.11.6/8.11.6) 928 with ESMTP id i7PK0sH7021929; 929 Fri, Feb 15 2002 17:19:22 -0800 930 Authentication-Results: mail-router.example.com; 931 auth=pass (cram-md5) smtp.mail=sender@example.com; 932 spf=hardfail smtp.mail=sender@example.com 933 Received: from dialup-1-2-3-4.example.net 934 (dialup-1-2-3-4.example.net [192.0.2.200]) 935 by mail-router.example.com (8.11.6/8.11.6) 936 with ESMTP id g1G0r1kA003489; 937 Fri, Feb 15 2002 17:19:07 -0800 938 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=example.com; 939 t=1188964191; c=simple/simple; 940 h=From:Date:To:Message-Id:Subject; 941 bh=sEuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m70; 942 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 943 From: sender@example.com 944 Date: Fri, Feb 15 2002 16:54:30 -0800 945 To: receiver@sendmail.com 946 Message-Id: <12345.abc@example.com> 947 Subject: here's a sample 949 Hello! Goodbye! 951 Example 5: Headers reporting results from multiple MTAs 953 The "Authentication-Results" header field is present, indicating 954 conformance to this specification. It is present twice because two 955 different MTAs in the chain of delivery did authentication tests. 956 The first, "mail-router.example.com" reports that [AUTH] and [SPF] 957 were both used, and [AUTH] passed but [SPF] failed. In the [AUTH] 958 case, additional data is provided in the comment field, which the MUA 959 can choose to render if desired. 961 The second MTA, identifying itself as "auth-checker.example.com", 962 reports that it did a [SENDERID] test (which failed) and a [DKIM] 963 test (which passed). Again, additional data about one of the tests 964 is provided as a comment, which the MUA may choose to render. 966 Since different hosts did the two sets of authentication checks, the 967 header fields cannot be consolidated in this example. 969 This example illustrates more typical transmission of mail into 970 "example.com" from a user on a dialup connection "example.net". The 971 user appears to be legitimate as he/she had a valid password allowing 972 authentication at the border MTA using [AUTH]. The [SPF] and 973 [SENDERID] tests failed since "example.com" has not granted 974 "example.net" authority to relay mail on its behalf. However, the 975 [DKIM] test passed because the sending user had a private key 976 matching one of "example.com"'s published public keys and used it to 977 sign the message. 979 C.6. Service provided, multi-tiered authentication done 981 A message that had authentication done at various stages, one of 982 which was outside the receiving domain: 984 Authentication-Results: chicago.example.com; 985 dkim=pass (good signature) header.i=@mail-router.example.net; 986 dkim=hardfail (bad signature) header.i=@newyork.example.com 987 Received: from mail-router.example.net 988 (mail-router.example.net [192.0.2.250]) 989 by chicago.example.com (8.11.6/8.11.6) 990 for 991 with ESMTP id i7PK0sH7021929; 992 Fri, Feb 15 2002 17:19:22 -0800 993 DKIM-Signature: v=1; a=rsa-sha256; s=furble; 994 d=mail-router.example.net; t=1188964198; c=relaxed/simple; 995 h=From:Date:To:Message-Id:Subject:Authentication-Results; 996 bh=ftA9J6GtX8OpwUECzHnCkRzKw1uk6FNiLfJl5Nmv49E=; 997 b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3= 998 Authentication-Results: mail-router.example.net; 999 dkim=pass (good signature) header.i=@newyork.example.com 1000 Received: from smtp.newyork.example.com 1001 (smtp.newyork.example.com [192.0.2.220]) 1002 by mail-router.example.net (8.11.6/8.11.6) 1003 with ESMTP id g1G0r1kA003489; 1004 Fri, Feb 15 2002 17:19:07 -0800 1005 DKIM-Signature: v=1; a=rsa-sha256; s=gatsby; d=newyork.example.com; 1006 t=1188964191; c=simple/simple; 1007 h=From:Date:To:Message-Id:Subject; 1008 bh=sEu28nfs9fuZGD/pSr7ANysbY3jtdaQ3Xv9xPQtS0m7=; 1009 b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM= 1010 From: sender@newyork.example.com 1011 Date: Fri, Feb 15 2002 16:54:30 -0800 1012 To: meetings@example.net 1013 Message-Id: <12345.abc@newyork.example.com> 1014 Subject: here's a sample 1016 Example 6: Headers reporting results from multiple MTAs in different 1017 domains 1019 In this example we see multi-tiered authentication with an extended 1020 trust boundary. 1022 The message was sent from someone at example.com's New York office 1023 (newyork.example.com) to a mailing list managed at an intermediary. 1024 The message was signed at the origin using [DKIM]. 1026 The message was sent to a mailing list service provider called 1027 example.net which is used by example.com. There meetings@example.net 1028 is expanded to a long list of recipients, one of which is at the 1029 Chicago office. In this example, we will assume that the trust 1030 boundary for chicago.example.com includes the mailing list server at 1031 example.net. 1033 The mailing list server there first authenticated the message and 1034 affixed an Authentication-Results: header field indicating such. It 1035 then altered the message by affixing some footer text to the body 1036 including some administrivia such as unsubscription instructions. 1037 Finally, the mailing list server affixes a second [DKIM] signature 1038 and begins distribution of the message. 1040 The border MTA for chicago.example.com explicitly trusts results from 1041 mail-router.example.net so that header is not removed. It performs 1042 evaluation of both signatures and determines that the first (most 1043 recent) is a "pass" but, because of the aforementioned modifications, 1044 the second is a "hardfail". However, the first signature included 1045 the Authentication-Results: header added at mail-router.example.net 1046 which validated the second signature. Thus, indirectly, it can be 1047 determined that the authentication claimed by both signatures are 1048 indeed valid. 1050 Appendix D. Public Discussion 1052 [REMOVE BEFORE PUBLICATION] 1054 Public discussion of this proposed specification is handled via the 1055 mail-vet-discuss@mipassoc.org mailing list. The list is open. 1056 Access to subscription forms and to list archives can be found at 1057 http://mipassoc.org/mailman/listinfo/mail-vet-discuss. 1059 Author's Address 1061 Murray S. Kucherawy 1062 Sendmail, Inc. 1063 6475 Christie Ave., Suite 350 1064 Emeryville, CA 94608 1065 US 1067 Phone: +1 510 594 5400 1068 Email: msk+ietf@sendmail.com 1070 Full Copyright Statement 1072 Copyright (C) The IETF Trust (2007). 1074 This document is subject to the rights, licenses and restrictions 1075 contained in BCP 78, and except as set forth therein, the authors 1076 retain all their rights. 1078 This document and the information contained herein are provided on an 1079 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1080 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1081 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1082 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1083 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1084 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1086 Intellectual Property 1088 The IETF takes no position regarding the validity or scope of any 1089 Intellectual Property Rights or other rights that might be claimed to 1090 pertain to the implementation or use of the technology described in 1091 this document or the extent to which any license under such rights 1092 might or might not be available; nor does it represent that it has 1093 made any independent effort to identify any such rights. Information 1094 on the procedures with respect to rights in RFC documents can be 1095 found in BCP 78 and BCP 79. 1097 Copies of IPR disclosures made to the IETF Secretariat and any 1098 assurances of licenses to be made available, or the result of an 1099 attempt made to obtain a general license or permission for the use of 1100 such proprietary rights by implementers or users of this 1101 specification can be obtained from the IETF on-line IPR repository at 1102 http://www.ietf.org/ipr. 1104 The IETF invites any interested party to bring to its attention any 1105 copyrights, patents or patent applications, or other proprietary 1106 rights that may cover technology that may be required to implement 1107 this standard. Please address the information to the IETF at 1108 ietf-ipr@ietf.org. 1110 Acknowledgment 1112 Funding for the RFC Editor function is provided by the IETF 1113 Administrative Support Activity (IASA).