[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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 <jmacdonald@xxxxxxxxxxxx> 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