Authentication-Results Header Field Appeal
draft-otis-auth-header-appeal-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 20, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

The proposed [I‑D.kucherawy‑sender‑auth‑header] (Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” January 2009.) defines a header field used to capture email verification results obtained at border receptions has been approved for publication. However, serious deficiencies remain in its secure use and has prompted an appeal of the publication decision. This new header field is to convey to Mail User Agents (MUA) and downstream processes the verification results that are intended to augment handling decisions and message annotations that might be made visible to recipients. For such use, it is crucial to include within an "authenticated-results" header, a truly authenticated identity.

The draft acknowledges that it confuses authorization with authentication in section 1.5.2. This confusion has lead the draft to incorrectly elevate the authorization of an SMTP client into the authentication of an email-address domain. Elevating the *authorization* of the SMTP client into the *authentication* of an email-address domain incorrectly assumes current email practices adequately restrict the use of an email-address domain based upon the originating IP address of the SMTP client. In an era of carrier grade NATs, virtual servers, aggregated services, and other techniques that overload the IP address, this assumption is neither safe nor practical.

Although the draft explicitly declares Sender-ID and SPF as the authorization of the transmitting SMTP client, it fails to offer the authenticated identity being trusted. A truly authenticated identity is essential for reputation assessments which section 4.1 indicates should be made prior to results being revealed. A reputation check of a truly authenticated identifier is often a necessary step needed to mitigate fraud and abuse. In addition, it is unfair to attribute fraud or abuse to the unauthenticated identifiers. Even so, the header offers no assurance that any reputation check has been made, nor does it ensure that an authenticated identity, the IP address of the SMTP client, can be determined by the MUA or downstream process. The goal of the appeal is to ensure adequate information is available when annotating email.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Table of Contents

1.  Introduction
2.  IPv6, SPF macros, and local-parts
3.  Recommended Modifications
4.  IANA Considerations
5.  Security Considerations
6.  References
    6.1.  References - Normative
    6.2.  References - Informative
§  Authors' Addresses

1.  Introduction

In the requested review of [I‑D.otis‑auth‑header‑sec‑issues] (Otis, D., “Authentication-Results Header Field Security Issues,” January 2009.), Barry Leiba made the following remarks:

In other words, Doug considers that it's the IP address, not the ADMD, that has been "authenticated". I disagree, but this is a tricky area, because we're not wading in a typical sort of authentication pool here -- SPF is actually blending identity, authentication, and authorization.

As I see it, the SPF model is that the *identity* to be authenticated is taken from the SMTP MAIL FROM command (for Sender-ID it's derived through the PRA algorithm), the IP address supplies the authentication *credentials*, and the DNS lookup both verifies the credentials (completing the authentication) and returns the authorization information in one, combined response ("the entity with these credentials is authorized to send mail on behalf of the identity 'example.com'.").

Lets start with the *authorization* aspect. When evaluating SPF compliance, it is common for virtual SPF records to be used that impose a CIDR range on MX record targets whenever an SPF record is not available. As such, SPF results leave the issue of there being any real *authorization* in doubt.

In addition, Sender-ID (Lyon, J. and M. Wong, “Sender ID: Authenticating E-Mail,” April 2006.) [RFC4406] in section 2 indicates the use of Mail From, in addition to the PRA:

On the other hand, the MAIL-FROM version of the test seeks to authenticate the mailbox that would receive Delivery Status Notifications (DSNs, or bounces) for the message. In simple cases, this too is who the mail is from. However, third-party mailers, forwarders, and mailing list servers MUST specify an address under their control, and SHOULD arrange that DSNs received at this address are forwarded to the original bounce address.

In both cases, the domain associated with an e-mail address is what is authenticated; no attempt is made to authenticate the local-part. A domain owner gets to determine which SMTP clients speak on behalf of addresses within the domain; a responsible domain owner should not authorize SMTP clients that will lie about local parts.

Since Sender-ID permits the use of either version of the SPF records to be applied against the PRA, version 2 records must then be published whenever authorization of a PRA is not intended. This retro-active mandate is to prevent the misapplication of SPF (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.) [RFC4408] records against PRA header fields. The conflict as to whether just the Mail From or the PRA has been authorized by SPF version 1 records has left the intended scope of the SPF record in doubt.

The [I‑D.kucherawy‑sender‑auth‑header] (Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” January 2009.) fails to indicate which version of an SPF record had been discovered, or whether any record had been discovered allowing recipients a means to gauge risk. It is not just whether SMTP clients lie about local-parts, it is whether an IP address ensures only authorizing domains can send the Mail Froms or PRAs containing the authorizing domain. Since such IP address restrictions are not in common practice, nor can such restrictions be assured not to interfere with existing email practices, a premise that SPF authorization implies the authentication of any Mail From or PRA from an authorized SMTP client should be regarded as dangerously ill founded. Including just the email-address domain as being authenticated makes the header deceptive.

[I‑D.kucherawy‑sender‑auth‑header] (Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” January 2009.) introduces a header field, which because of its label, can mislead recipients into believing that it contains "Authentication-Results". The use of phrases rather than result codes belies the draft's introductory claim that this header is not intended for direct human consumption. MUAs, such as Apple Mail, are able to directly display this header above a message following minor user accessible setting changes.

In the case of Sender-ID or SPF, the deceptive nature of this header could have been remedied by including the "authenticated" IP address of the SMTP client, in addition to the authorizing domain. This IP address must be passed to the SPF record verification process by the receiving MTA, and is essential for either Sender-ID and SPF processing. Only an authenticated identity is able to serve as a safe basis for reputation. A reputation check of the authenticated source is strongly recommended by section 4.1.

Without the presence of an authenticated identity within the Authenticated-Results header, there can not be any practical or timely remedy against compromised SMTP client access or BGP spoofing. With hundreds of millions of compromised systems organized into bot-nets, no assumption regarding unauthenticated identifiers should be considered safe. This concern is not about allowing MUAs a means to repeat a verification process, the inclusion of the IP address of the SMTP client is to provide the MUA or downstream process with the authenticated identity that is being trusted to protect the email-address. In the case of Sender-ID or SPF, the identity being trusted to protect the use of Mail From or the PRA is the SMTP client identified by its IP addresses.

The places within the [I‑D.kucherawy‑sender‑auth‑header] (Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” January 2009.) that purport either Sender-ID or SPF as authenticating the originating domain overlook the dangerous and misleading assumptions needed to arrive at that conclusion. Just as it would not be safe give someone a negative credit rating based upon transactions not substantiated through some form of authentication, a domain must not be held accountable for incorrect assumptions made by receiving MTAs. Doing so would be highly disruptive, coercive, and unfair.

While there are cases where a domain is controlled by a bad actor, often use of the bad domain is brief. Difficulties imposed by Sender-ID or SPF in determining whether a domain originated a fraudulent or abusive message also imposes delays in the assignment of negative reputations. Any delay is likely to make any effort at protection less effective than when using the already authenticated IP address of the SMTP client.

Negative reputations based upon the IP address of the SMTP client are fairly common, and many are automated and assigned nearly immediately. Since security is fragile, whenever a server suffers from a security breach, rather than blocking all mail from a domain to mitigate fraudulent messages, assigning a negative rating to an affected SMTP client IP addresses mitigates a problem without completely blocking all messages from the domain. The domain would then be free to issue warning messages regarding the nature of the security breach. Such notification would not be possible if only the reputation of the authorizing domain was expected to serve as a mitigation solution.

2.  IPv6, SPF macros, and local-parts

When IPv6 becomes more commonly used, white-listing IP addresses will be needed as a solution for dealing with the increased address range. There are currently no practical solutions able to scale to the challenging range of IP addresses that might be controlled by bad actors. This means problems related to IPv6 will result in the removal of white-listed IP addresses.

Unlike most DNS resources that segregate IPv4 and IPv6 datasets, SPF consolidates both IPv4 and IPv6 addresses into a common list comprised of a chain of DNS transactions. SPF also includes macros used by recipients that can expand the IP address of the SMTP client into labels used in subsequent DNS queries. Expressing an IPv6 address using the SPF macro in the reverse order nibble form can comprise a query containing more than 32 labels. If the local-part macros are used to locate MX records, the MX targets can comprise a set of 100 separate hostnames. Local-part macros could also be used to chain SPF record sets.

Unfortunately, the Authentication-Header draft may actually encourage use of this dangerous local-part macro. Section 2.4.3 requires local-part authentication before it is to be included within the Authentication-Results header. In addition, there is nothing to indicate whether the local-part played a role in obtaining SPF results. The danger imposed by the use of the local-part macro is inherent in the query required to support both an IPv6 expansion, in conjunction with the expansion of local-part macros induced by possibly cached SPF records. The local-part, along with a range of IP addresses made readily possible by IPv6, can be manipulated to induce a flurry of large DNS transactions directed toward any otherwise uninvolved domain, all directed by cached DNS records.

The SPF local-part macro would allow a cached DNS record to be repeatedly exploited by a spam campaign without the attacker consuming any of their additional resources beyond that used to send their spam campaign. It is never a good idea to allow free attacks. The previous draft regarding the SPF DoS concern was never fully understood, nor was the basis of the concern acknowledged by SPF proponents.

Logically, local-part macros would not safely provide a positive result without the query also being combined with the IP address list of authorized SMTP clients in some form. This means an address list structure would need to be repeated for each of the domain's users. Rcpt To provides a simpler, lower overhead, and more expedient way to determine whether a NDN should be returned without the risk associated with SPF's active content being placed within DNS resource records. Several parsers ignore local-part macro expansion since they rarely play any role in providing positive results.

The typical target of a DDoS attack is often not the email-providers that might enable the attack. Often attacks are directed toward those attempting to mitigate abuse by issuing the status of a range of IP addresses. Since these protective services may have been problematic for the providers, there exists a level of animosity toward what may appear to be conflicting goals.

3.  Recommended Modifications

Change Section 2.4.3 FROM:

If the retrieved sender policies used to evaluate [SPF] and [SENDERID] do not contain explicit provisions for authenticating the local-part (see section 3.4.1 of [MAIL]) of an address, the "pvalue" reported along with results for these mechanisms SHOULD NOT include the local-part.

TO:

To discourage exploitation risks, the entity that has been authenticated (the IP address of the SMTP client) SHOULD BE included. The "pvalue" reported along with results for these mechanisms SHOULD NOT include the local-part, but instead the local-part SHOULD BE replaced with the IP address used to evaluate the SPF record after being converted to a string using conventional dotted quad notation for IPv4, or the 16 bit hexadecimal notation defined by [RFC3513] (Hinden, R. and S. Deering, “Internet Protocol Version 6 (IPv6) Addressing Architecture,” April 2003.), section 2.2, and terminated by the "@" symbol.

Change Section 4 FROM:

End users making direct use of this header field may inadvertently trust information that has not been properly vetted. If, for example, a basic [SPF] result were to be relayed which claims an authenticated addr-spec, the local-part of that addr-spec has actually not been authenticated. Thus, an MTA adding this header field SHOULD NOT include any data which has not been authenticated by the method(s) being applied. Moreover, MUAs SHOULD NOT render to users such information if it is presented by a method known not to authenticate it.

TO:

End users making direct use of this header field may inadvertently trust information that has not been properly vetted. [SPF] results SHOULD BE handled as specified by section 3.4.3. In general, an MTA adding this header field SHOULD NOT include any data which has not been authenticated by the method(s) being applied. Moreover, MUAs SHOULD NOT render to users such information if it is presented by a method known not to authenticate it. An exception is to be made for an Authorizing domain only when it accompanies the authenticated IP address of the SMTP client.

4.  IANA Considerations

This document requires no IANA consideration.

5.  Security Considerations

This draft intends to describe serious security concerns raised by the [I‑D.kucherawy‑sender‑auth‑header] (Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” January 2009.) draft. The contained recommendations are expected to reduce the security concerns.

6.  References

6.1. References - Normative

6.2. References - Informative

Authors' Addresses