[mail-vet-discuss] Authentication vs. Authorization

[Douglas Otis]

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.from=jon-doe at e-commerce-are-us.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.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/mail-vet-discuss/attachments/20081027/40300836/attachment.html