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

From: "Randy Smith" <[email-masked]>
Date: Mon, 2 Apr 2007 21:48:23 -0600

On 3/28/07, Jeff Macdonald <[email-masked]> wrote:
> On Wed, Mar 28, 2007 at 07:42:51AM -0600, Randy Smith wrote:
>
> > Since OpenID is built to allow authentication, among other things,
> > against 3rd party systems, it seems like an excellent way to allow and
> > recipient server to authenticate all users who wish to send or deliver
> > mail with their server.
>
> 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.

>
> 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.

>
> 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.

>
> --
> :: Jeff Macdonald | Principal Engineer, Messaging Technologies
> :: e-Dialog | [email-masked]
> :: 131 Hartwell Ave. | Lexington, MA 02421
> :: v: 781-372-1922 | f: 781-863-8118
> :: www.e-dialog.com
>
>

-- 
Randy Smith
http://vuser.org/
http://perlstalker.vuser.org/

---

From: Douglas Otis <[email-masked]>
Date: Tue, 3 Apr 2007 11:17:29 -0700

> 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.

> 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. : )

> 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