draft-ietf-appsawg-rfc7001bis-07.txt   draft-ietf-appsawg-rfc7001bis-08.txt 
Individual submission M. Kucherawy Individual submission M. Kucherawy
Internet-Draft April 21, 2015 Internet-Draft May 5, 2015
Obsoletes: 7001, 7410 Obsoletes: 7001, 7410
(if approved) (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: October 23, 2015 Expires: November 6, 2015
Message Header Field for Indicating Message Authentication Status Message Header Field for Indicating Message Authentication Status
draft-ietf-appsawg-rfc7001bis-07 draft-ietf-appsawg-rfc7001bis-08
Abstract Abstract
This document specifies a message header field called Authentication- This document specifies a message header field called Authentication-
Results for use with electronic mail messages to indicate the results Results for use with electronic mail messages to indicate the results
of message authentication efforts. Any receiver-side software, such of message authentication efforts. Any receiver-side software, such
as mail filters or Mail User Agents (MUAs), can use this header field as mail filters or Mail User Agents (MUAs), can use this header field
to relay that information in a convenient and meaningful way to users to relay that information in a convenient and meaningful way to users
or to make sorting and filtering decisions. or to make sorting and filtering decisions.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 23, 2015. This Internet-Draft will expire on November 6, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 47 skipping to change at page 2, line 47
4. Adding the Header Field to a Message . . . . . . . . . . . . . 23 4. Adding the Header Field to a Message . . . . . . . . . . . . . 23
4.1. Header Field Position and Interpretation . . . . . . . . . 25 4.1. Header Field Position and Interpretation . . . . . . . . . 25
4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 26 4.2. Local Policy Enforcement . . . . . . . . . . . . . . . . . 26
5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26 5. Removing Existing Header Fields . . . . . . . . . . . . . . . 26
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
6.1. The Authentication-Results Header Field . . . . . . . . . 27 6.1. The Authentication-Results Header Field . . . . . . . . . 27
6.2. "Email Authentication Methods" Registry Description . . . 28 6.2. "Email Authentication Methods" Registry Description . . . 28
6.3. "Email Authentication Methods" Registry Update . . . . . . 29 6.3. "Email Authentication Methods" Registry Update . . . . . . 29
6.4. "Email Authentication Property Types" Registry . . . . . . 30 6.4. "Email Authentication Property Types" Registry . . . . . . 30
6.5. "Email Authentication Result Names" Description . . . . . 31 6.5. "Email Authentication Result Names" Description . . . . . 31
6.6. "Email Authentication Result Names" Update . . . . . . . . 31 6.6. "Email Authentication Result Names" Update . . . . . . . . 32
6.7. SMTP Enhanced Stauts Codes . . . . . . . . . . . . . . . . 32 6.7. SMTP Enhanced Stauts Codes . . . . . . . . . . . . . . . . 33
7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 32 7.1. Forged Header Fields . . . . . . . . . . . . . . . . . . . 33
7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 34 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 35
7.3. Header Field Position . . . . . . . . . . . . . . . . . . 34 7.3. Header Field Position . . . . . . . . . . . . . . . . . . 35
7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 35 7.4. Reverse IP Query Denial-of-Service Attacks . . . . . . . . 35
7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 35 7.5. Mitigation of Backscatter . . . . . . . . . . . . . . . . 35
7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 35 7.6. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 35
7.7. Attacks against Authentication Methods . . . . . . . . . . 35 7.7. Attacks against Authentication Methods . . . . . . . . . . 36
7.8. Intentionally Malformed Header Fields . . . . . . . . . . 35 7.8. Intentionally Malformed Header Fields . . . . . . . . . . 36
7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 36 7.9. Compromised Internal Hosts . . . . . . . . . . . . . . . . 36
7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 36 7.10. Encapsulated Instances . . . . . . . . . . . . . . . . . . 36
7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 36 7.11. Reverse Mapping . . . . . . . . . . . . . . . . . . . . . 37
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8.1. Normative References . . . . . . . . . . . . . . . . . . . 36 8.1. Normative References . . . . . . . . . . . . . . . . . . . 37
8.2. Informative References . . . . . . . . . . . . . . . . . . 37 8.2. Informative References . . . . . . . . . . . . . . . . . . 37
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 39 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 40
Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 39 Appendix B. Legacy MUAs . . . . . . . . . . . . . . . . . . . . . 40
Appendix C. Authentication-Results Examples . . . . . . . . . . . 40 Appendix C. Authentication-Results Examples . . . . . . . . . . . 40
C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 40 C.1. Trivial Case; Header Field Not Present . . . . . . . . . . 41
C.2. Nearly Trivial Case; Service Provided, but No C.2. Nearly Trivial Case; Service Provided, but No
Authentication Done . . . . . . . . . . . . . . . . . . . 41 Authentication Done . . . . . . . . . . . . . . . . . . . 41
C.3. Service Provided, Authentication Done . . . . . . . . . . 42 C.3. Service Provided, Authentication Done . . . . . . . . . . 42
C.4. Service Provided, Several Authentications Done, Single C.4. Service Provided, Several Authentications Done, Single
MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 MTA . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
C.5. Service Provided, Several Authentications Done, C.5. Service Provided, Several Authentications Done,
Different MTAs . . . . . . . . . . . . . . . . . . . . . . 44 Different MTAs . . . . . . . . . . . . . . . . . . . . . . 44
C.6. Service Provided, Multi-Tiered Authentication Done . . . . 46 C.6. Service Provided, Multi-Tiered Authentication Done . . . . 46
C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 47 C.7. Comment-Heavy Example . . . . . . . . . . . . . . . . . . 47
Appendix D. Operational Considerations about Message Appendix D. Operational Considerations about Message
Authentication . . . . . . . . . . . . . . . . . . . 48 Authentication . . . . . . . . . . . . . . . . . . . 48
Appendix E. Change History . . . . . . . . . . . . . . . . . . . 49 Appendix E. Change History . . . . . . . . . . . . . . . . . . . 49
E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 49 E.1. RFC7001 to -00 . . . . . . . . . . . . . . . . . . . . . . 49
E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 50 E.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 50 E.3. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 50 E.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.5. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 50 E.5. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 50
E.6. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 51 E.6. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 51
E.7. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 51 E.7. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 51
E.8. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 51 E.8. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 51
E.9. -07 to -08 . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document describes a header field called Authentication-Results This document describes a header field called Authentication-Results
for electronic mail messages that presents the results of a message for electronic mail messages that presents the results of a message
authentication effort in a machine-readable format. The intent of authentication effort in a machine-readable format. The intent of
the header field is to create a place to collect such data when the header field is to create a place to collect such data when
message authentication mechanisms are in use so that a Mail User message authentication mechanisms are in use so that a Mail User
Agent (MUA) and downstream filters can make filtering decisions Agent (MUA) and downstream filters can make filtering decisions
and/or provide a recommendation to the user as to the validity of the and/or provide a recommendation to the user as to the validity of the
skipping to change at page 27, line 50 skipping to change at page 27, line 50
[RFC5451] added the Authentication-Results header field to the IANA [RFC5451] added the Authentication-Results header field to the IANA
"Permanent Message Header Field Names" registry, per the procedure "Permanent Message Header Field Names" registry, per the procedure
found in [IANA-HEADERS]. That entry is to be updated to reference found in [IANA-HEADERS]. That entry is to be updated to reference
this document. The following is the registration template: this document. The following is the registration template:
Header field name: Authentication-Results Header field name: Authentication-Results
Applicable protocol: mail ([MAIL]) Applicable protocol: mail ([MAIL])
Status: Standard Status: Standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document(s): [this RFC] Specification document(s): [this RFC]
Related information: Related information: none
Requesting review of any proposed changes and additions to
this field is recommended.
6.2. "Email Authentication Methods" Registry Description 6.2. "Email Authentication Methods" Registry Description
Names of message authentication methods supported by this Names of message authentication methods supported by this
specification are to be registered with IANA, with the exception of specification are to be registered with IANA, with the exception of
experimental names as described in Section 2.7.6. Along with each experimental names as described in Section 2.7.6. Along with each
method is recorded the properties that accompany the method's result. method is recorded the properties that accompany the method's result.
The "Email Authentication Parameters" group, and within it the "Email The "Email Authentication Parameters" group, and within it the "Email
Authentication Methods" registry, were created by [RFC5451] for this Authentication Methods" registry, were created by [RFC5451] for this
skipping to change at page 28, line 38 skipping to change at page 28, line 37
permitted. The designated expert can also handle requests to mark permitted. The designated expert can also handle requests to mark
any current registration as "deprecated". any current registration as "deprecated".
No two entries can have the same combination of method, ptype, and No two entries can have the same combination of method, ptype, and
property. property.
An entry in this registry contains the following: An entry in this registry contains the following:
Method: the name of the method; Method: the name of the method;
Defined: a reference to the document that created this entry, if any Definition: a reference to the document that created this entry, if
(see below); any (see below);
ptype: a "ptype" value appropriate for use with that method; ptype: a "ptype" value appropriate for use with that method;
property: a "property" value matching that "ptype" also appropriate property: a "property" value matching that "ptype" also appropriate
for use with that method; for use with that method;
Value: a brief description of the value to be supplied with that Value: a brief description of the value to be supplied with that
method/ptype/property tuple; method/ptype/property tuple;
Status: the status of this entry, which is either: Status: the status of this entry, which is either:
active: The entry is in current use. active: The entry is in current use.
deprecated: The entry is no longer in current use. deprecated: The entry is no longer in current use.
Version: a version number associated with the method (preferably Version: a version number associated with the method (preferably
starting at "1"). starting at "1").
The "Defined" field will typically refer to a permanent document, or The "Definition" field will typically refer to a permanent document,
at least some descriptive text, where additional information about or at least some descriptive text, where additional information about
the entry being added can be found. This in turn would reference the the entry being added can be found. This might in turn reference the
document where the method is defined so that all of the semantics document where the method is defined so that all of the semantics
around creating or interpreting an Authentication-Results header around creating or interpreting an Authentication-Results header
field using this method, ptype, and property can be understood. field using this method, ptype, and property can be understood.
6.3. "Email Authentication Methods" Registry Update 6.3. "Email Authentication Methods" Registry Update
The following changes are to be made to this registry upon approval The following changes are to be made to this registry upon approval
of this document: of this document:
1. The current entry for the "auth" method shall have its "property" 1. The "Defined" field shall be renamed to "Definition", to be
field changed to "mailfrom", and its "Defined" field changed to consistent with the other registries in this group.
this document.
2. The entry for the "dkim" method, "header" ptype and "b" property 2. The current entry for the "auth" method shall have its "property"
field changed to "mailfrom", and its "Definition" field changed
to this document.
3. The entry for the "dkim" method, "header" ptype and "b" property
shall now reference [RFC6008] as its defining document, and the shall now reference [RFC6008] as its defining document, and the
reference shall be removed from the description. reference shall be removed from the description.
3. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf" 4. All other "dkim", "domainkeys", "iprev", "sender-id", and "spf"
method entries shall have their "Defined" fields changed to this method entries shall have their "Definition" fields changed to
document. this document, as this document contains a complete description
of the registry and these corresponding values.
4. All "smime" entries have their "Defined" fields changed to 5. All "smime" entries have their "Definition" fields changed to
[SMIME-REG]. [SMIME-REG].
5. The "value" field of the "smime" entry using property "smime- 6. The "value" field of the "smime" entry using property "smime-
part" shall be changed to read: "The MIME body part reference part" shall be changed to read: "The MIME body part reference
that contains the S/MIME signature. See Section 3.2.1 of RFC7281 that contains the S/MIME signature. See Section 3.2.1 of RFC7281
for full syntax." for full syntax."
6. The following entry is to be added: 7. The following entry is to be added:
Method: auth Method: auth
Defined: [this document]
Definition: [this document]
ptype: smtp ptype: smtp
property: auth property: auth
Value: identity confirmed by the AUTH command Value: identity confirmed by the AUTH command
Status: active Status: active
Version: 1 Version: 1
7. The values of the "domainkeys" entries for ptype "header" are 8. The values of the "domainkeys" entries for ptype "header" are
updated as follows: updated as follows:
from: contents of the [MAIL] From: header field, after removing from: contents of the [MAIL] From: header field, after removing
comments, and removing the local-part and following "@" if not comments, and removing the local-part and following "@" if not
authenticated authenticated
sender: contents of the [MAIL] Sender: header field, after sender: contents of the [MAIL] Sender: header field, after
removing comments, and removing the local-part and following removing comments, and removing the local-part and following
"@" if not authenticated "@" if not authenticated
8. All entries for "dkim-adsp" and "domainkeys" shall have their 9. All entries for "dkim-adsp" and "domainkeys" shall have their
Status values changed to "deprecated", reflecting the fact that Status values changed to "deprecated", reflecting the fact that
the corresponding specifications now have Historical status. the corresponding specifications now have Historical status.
Their "Definition" fields shall also be modified to include a
reference to this document.
6.4. "Email Authentication Property Types" Registry 6.4. "Email Authentication Property Types" Registry
[PTYPES-REGISTRY] created the Email Authentication Property Types [PTYPES-REGISTRY] created the Email Authentication Property Types
registry. registry.
Entries in this registry are subject to the Expert Review rules as Entries in this registry are subject to the Expert Review rules as
described in [IANA-CONSIDERATIONS]. Each entry in the registry described in [IANA-CONSIDERATIONS]. Each entry in the registry
requires the following values: requires the following values:
skipping to change at page 31, line 7 skipping to change at page 31, line 15
Description: A brief description of what sort of information this Description: A brief description of what sort of information this
"ptype" is meant to cover. "ptype" is meant to cover.
For new entries, the Designated Expert needs to assure that the For new entries, the Designated Expert needs to assure that the
description provided for the new entry adequately describes the description provided for the new entry adequately describes the
intended use. An example would be helpful to include in the entry's intended use. An example would be helpful to include in the entry's
defining document, if any, although entries in the "Email defining document, if any, although entries in the "Email
Authentication Methods" registry or the "Email Authentication Result Authentication Methods" registry or the "Email Authentication Result
Names" registry might also serve as examples of intended use. Names" registry might also serve as examples of intended use.
IANA shall update this registry to show Section 2.3 of this document As this is a complete re-statement of the definition and rules for
as the current definitions for the "body", "header", "policy" and this registry, IANA shall update this registry to show Section 2.3 of
"smtp" entries of that registry. this document as the current definitions for the "body", "header",
"policy" and "smtp" entries of that registry. References to
[RFC7001] shall be removed.
6.5. "Email Authentication Result Names" Description 6.5. "Email Authentication Result Names" Description
Names of message authentication result codes supported by this Names of message authentication result codes supported by this
specification must be registered with IANA, with the exception of specification must be registered with IANA, with the exception of
experimental codes as described in Section 2.7.7. A registry was experimental codes as described in Section 2.7.7. A registry was
created by [RFC5451] for this purpose. [RFC6577] added the "status" created by [RFC5451] for this purpose. [RFC6577] added the "status"
column, and [RFC7001] updated the rules governing that registry. column, and [RFC7001] updated the rules governing that registry.
New entries are assigned only for values that have received Expert New entries are assigned only for values that have received Expert
skipping to change at page 31, line 41 skipping to change at page 32, line 5
Auth Method: an authentication method for which results are being Auth Method: an authentication method for which results are being
returned using the header field defined in this document; returned using the header field defined in this document;
Code: a result code that can be returned for this authentication Code: a result code that can be returned for this authentication
method; method;
Specification: either free form text explaining the meaning of this Specification: either free form text explaining the meaning of this
method-code combination, or a reference to such a definition. method-code combination, or a reference to such a definition.
Status: the status of this entry, which is either:
active: The entry is in current use.
deprecated: The entry is no longer in current use.
6.6. "Email Authentication Result Names" Update 6.6. "Email Authentication Result Names" Update
The following changes are to be made to this registry on publication This document includes a complete description of the registry,
of this document: obsoleting [RFC7001]. Accordingly, the following changes are to be
made to this registry on publication of this document:
o The "Defined" field shall be removed. o The "Defined" field shall be removed.
o The "Meaning" field shall be renamed to "Specification", as o The "Meaning" field shall be renamed to "Specification", as
described above. described above.
o The "Auth Method" field shall appear before the "Code" field. o The "Auth Method" field shall appear before the "Code" field.
o For easier searching, the table shall be arranged such that it is o For easier searching, the table shall be arranged such that it is
sorted first by Auth Method, then by Code within each Auth Method sorted first by Auth Method, then by Code within each Auth Method
skipping to change at page 32, line 34 skipping to change at page 32, line 51
iprev: [this document] Section 2.7.3 iprev: [this document] Section 2.7.3
o All entries for "dkim-adsp" that are missing an explicit reference o All entries for "dkim-adsp" that are missing an explicit reference
to a defining document shall have [ADSP] added to their to a defining document shall have [ADSP] added to their
Specification fields. Specification fields.
o All entries for "dkim-adsp" and "domainkeys" shall have their o All entries for "dkim-adsp" and "domainkeys" shall have their
Status values changed to "deprecated", reflecting the fact that Status values changed to "deprecated", reflecting the fact that
the corresponding specifications now have Historical status. the corresponding specifications now have Historical status.
Their "Specification" fields shall also be modified to include a
reference to this document.
6.7. SMTP Enhanced Stauts Codes 6.7. SMTP Enhanced Stauts Codes
The entry for X.7.25 in the Enumerated Status Codes sub-registry of The entry for X.7.25 in the Enumerated Status Codes sub-registry of
the SMTP Enhanced Status Codes registry is to be updated to refer to the SMTP Enhanced Status Codes registry is to be updated to refer to
this document. this document instead of [RFC7001].
7. Security Considerations 7. Security Considerations
The following security considerations apply when adding or processing The following security considerations apply when adding or processing
the Authentication-Results header field: the Authentication-Results header field:
7.1. Forged Header Fields 7.1. Forged Header Fields
An MUA or filter that accesses a mailbox whose messages are handled An MUA or filter that accesses a mailbox whose messages are handled
by a non-conformant MTA, and understands Authentication-Results by a non-conformant MTA, and understands Authentication-Results
skipping to change at page 52, line 5 skipping to change at page 52, line 5
o Correction to "smime-part" prose. o Correction to "smime-part" prose.
o Examples that use SMTP AUTH now claim "with ESMTPA" in the o Examples that use SMTP AUTH now claim "with ESMTPA" in the
Received fields. Received fields.
E.8. -06 to -07 E.8. -06 to -07
o Wording around the S/MIME results. o Wording around the S/MIME results.
E.9. -07 to -08
o Clarifications in IANA Considerations.
Author's Address Author's Address
Murray S. Kucherawy Murray S. Kucherawy
270 Upland Drive 270 Upland Drive
San Francisco, CA 94127 San Francisco, CA 94127
US US
EMail: superuser@gmail.com EMail: superuser@gmail.com
 End of changes. 29 change blocks. 
45 lines changed or deleted 66 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/