mail-vet-discuss
[Top] [All Lists]

Re: [mail-vet-discuss] Authentication vs. Authorization

2008-10-27 14:35:56

On Oct 24, 2008, at 8:03 PM, Tony Hansen wrote:

Doug, I think I figured out where you took a left turn and came to the wrong conclusions about the Authentication-Results header.

The Authentication-Results header indicates the results of *us* proving the authenticity of something in the message.

http://www.ietf.org/internet-drafts/draft-kucherawy-sender-auth-header-16.txt

In the case of Sender-ID, this method only determines whether or not an SMTP client has been authorized. An authorized SMTP client does _not_ authenticate the associated email-address, even though the Authentication-Results header appears to imply that an email-address is being authenticated. In fact, for most of results included in this header, _nothing_ is being authenticated. In the case of Sender-ID or SPF, the IP address associated with the SMTP client is _not_ being captured in this header, unless a reverse lookup is also being made. It seems rather doubtful MTAs will be expected to make reverse DNS assessments due to the high latency caused by DNS timeouts from the lack of publication or the high number publication errors in the ARPA namespace.

In other words, *we've* authenticated the DKIM and DK signatures, and we're communicating *our* authentication results to our MUAs.

Both recipients and those writing MUAs to annotate messages may not understand what is _not_ being done. After all, this draft describes all the methods as "authentication". This Authentication-Results header communicates the method with "pass" and:

"d" and "i" tag with DKIM                            this is okay
From header field with ADSP-DKIM        dangerously misleading
From or Sender field with domainkeys   dangerously misleading
ip address of SMTP client with iprev       this is okay
PRA with Sender-ID extremely dangerously misleading
MAILFROM HELO with SPF                     dangerously misleading

Even for DKIM the Authentication-Results header can be misleading. With ADSP-DKIM, the email-address associated with the signature is _not_ assured to have been authenticated. Compliance with ADSP currently requires use of an "Author Signature" which specifically prohibits the signing domain from using an "on-behalf-of" value to indicate what they authenticate. However, a recipient or the MUA writer may logically conclude that the email-address was authenticated when it was not. ADSP could have allowed the "on-behalf-of" to comply with the DKIM spec, where it then would be safer to note the matching components of the From header field as having been authenticated.

Using ADSP in conjunction with DKIM in an implied "authentication" manner clearly goes beyond the DKIM charter. The Authentication- Results header implies DKIM in conjunction with ADSP is to assert the identity of the Author! This is especially wrong when compliance to ADSP, due to the "Author Signature" definition, actually prevents the signing-domain any means to refute or to prevent the misleading Authentication-Results header from being added.

http://tools.ietf.org/html/draft-ietf-dkim-ssp-06
states:
,---
|6. Security Considerations
|
| Security considerations in the ADSP are mostly related to attempts on
| the part of malicious senders to represent themselves as authors for
| whom they are not authorized to send mail, often in an attempt to
| defraud either the recipient or an Alleged Author.
'---

Ironically, the "Author-Signature" definition does not clarify what is to be done when a signature added by a domain is not "on-behalf-of" the From header field. Since the ADSP record is domain wide, must email now only be sent on behalf of the From header field, and never on behalf of the Sender header field?

Is ADSP, Sender-ID, and a misleading Authentication-Results header a clever way to create significant liabilities for providers that grant access based upon the authentication of an entity not reflected in the DKIM/From or the Sender-ID/PRA? One might note these two schemes can be applied simultaneously and be in conflict with each other. ADSP, Sender-ID, and Authentication-Results headers will be placing many providers at significant risk. It is best not to lie about what is being authenticated, even when dictated by an ill considered drafts.

We are *not* communicating whether that original token was an authentication or authorization of anything. We are only communicating what we've proven. We're providing the results of *our* authentication process.

The element verified and that should be included, but may not be, within a border-check header is:
  for ADSP-DKIM or domainkeys  is the _validated domain_,
and for SPF or Sender-ID is the _authorized IP address of the SMTP client_.

Including an email-address within a header with such a misleading label will surely endanger a great many recipients and leave them prone to confidence artists.

What new term for authentication must be invented when there really is AUTHENTICATION?

-Doug

Describing these SPF/Sender-ID results as "authentication" will mean domains publishing SPF records are now in jeopardy of dangerously misleading recipients whenever a shared outbound server is employed somewhere. The risk will become painfully apparent whenever a bad actor's only "authentication" credential is having sent email through one of the authorized SMTP clients. There are _many_ cases where independent domains share a common outbound server. While path registration may help reduce a range of spoofed DSNs, it is NEVER safe to refer to this mechanism as an AUTHENTICATION method. This is not the first time that this concern has been raised. A correction now should be preferred over a change at a much later date. It is shameful to be sloppy about something that will prove _extremely_ misleading.

AUTHENTICATION-RESULTS:  my-trusted-isp.com; sender-id=pass 
header(_dot_)from=jon-doe(_at_)e-commerce-are-us(_dot_)com

Someone reading this header added by their trusted ISP will logically come to a horribly wrong conclusion. They are likely to believe that the email-address "jon-doe(_at_)e-commerce-are-us(_dot_)com" had been authenticated. Despite the outrageously misleading header label, the information contained within the header only indicates that the SMTP client had been authorized. An authorized SMTP client must not be misrepresented as providing an assurance of the authenticity of the email-address! Why make it so damn easy for con-artists?

It would be ludicrous to suggest that all domains should not use shared outbound servers, or that all outbound severs should authenticate the use of every email-address within a PRA location.

-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html 
<Prev in Thread] Current Thread [Next in Thread>