Re: Mail Server Registries and Foreign Sender Authentication: A Proposal

On Apr 2, 2007, at 8:48 PM, Randy Smith wrote:

> On 3/28/07, Jeff Macdonald <[email protected]> wrote:
>> Randy, could you use OpenID terms in describing your SMTP extension?
>> I'm having trouble understanding how this would work from your
>> description in your blog. Adding PGP seems to add additional overhead
>> for what OpenID provides (unless I'm totally mis-understanding  
>> OpenID).
>> Here are what I think are some of the relevant terms:
>
> What I was think of was using the trust features of PGP to allow the
> server to make decisions based on how much the key is trusted and the
> "trustiness" of other keys in the chain. If a web of trust could be
> built by some other means than PGP, that's fine. It's the trust and
> key signing that's important here, not the encryption.

Perhaps someone could use OpenID for email submission.  Providers  
would need to establish another method to validate the holder of the  
OpenID.  OpenID might improve the user experience when offered as an  
option to those who's identity has already been validated by other  
means.  OpenID vouches for an ID, but does not exclude bad actors  
holding millions of such OpenIDs.  In such a case, when OpenID  
requires account details to change, some other method other than  
OpenID would be required.  Perhaps OpenID provides their public key  
to be used as another authentication alternative.

>> MTA terms:
>> C:      Sending MTA     - sending message
>> S:      Receiving MTA   - receiving message
>>
>> OpenID terms:
>> Consumer        - wants proof
>> End User        - wants to prove their identity to Consumer
>> User Agent      - End user web browser
>>
>> I is the Identity server
>>
>> Say there is a new ESMTP keyword, OPENID. Here's a breakdown loosely
>> following your example:
>>
>> C->S: connects
>> S->C: banner
>>
>> C->S: ehlo
>> S->C: OPENID is returned along with whatever else
>>
>> C->S: OPENID <url identifier>
>> S:      <becomes a Consumer>
>> S->I:   <fetches url identifier: Section 3.3 of OpenID spec>
>> S->C:   250 <identity provider URL: Section 3.5 of OpenID spec>
>>
>> S->I: associate with identity provider? Section 4.1.x
>>
>> C->I: go to identity provider? Section 4.2.x
>
> Honestly, I'm not sure as I'm not familiar with the details of Open
> ID. I think the best way would be for the server to verify the
> identity with the ID provider rather than trust the client.

OpenID will not function in a manner similar to that of kerberos.   
The user agent acknowledges a query, but contains no intelligence.   
This makes OpenID instantly available but somewhat fragile and poorly  
suited for automated authentications.  The OpenID could offer  
authorizations. : )

>> C->S: OPENID CRED <stuff from 4.2.2.3?>
>> S->C: 250 Ok Credentials are OK
>>
>> <continue with normal SMTP>
>>
>> I may of abused SMTP extensions in this example (re: OPENID CRED).
>
> That's pretty close to what I was thinking.

Review rfc2554 and rfc4409.  OpenID for SMTP authentication of  
outbound mail would likely need to restrict the selection of the  
Identity servers.  This would tend to make OpenID in this case a bit  
less open. : )

-Doug