Subject: [dix] Email Verification with Dix - a Possible Method?

From: "Sappenin Technologies LLC" <[email-masked]>
Date: Thu, 8 Jun 2006 00:29:12 -0400

This post offers a discussion about incorporating some sort of email
verification into the DIX protocol, either in the main DIX spec itself, or
along-side DIX in a sub or related spec.  In particular, I propose an email
verification solution that allows domain owners to assert ownership over an
email address, and link that ownership to a DIX persona-url.  To be clear, I
view the method proposed in this post as one method (of many possibilities)
that DIX ServiceProviders _could_ use to high effectiveness.

I'm not sure to what degree "email verification in DIX" has been discussed
on this list, but I'd like to offer a few arguments in favor of my proposed
scheme (or something like it), as well as a sample flow of how such a scheme
might work in the context of DIX.  Any feedback and/or comments are welcome.

david

[email-masked]

--

First, the primary reason that DIX should have the capability to validate
email addresses in particular (and not necessarily other "verifiable" pieces
of information) is that most websites today use an email-address as a unique
identifier (think username).  When these sites transition to DIX, they (the
sites) will rely on a persona-url being associated with, and possibly the
actual owner of, a given email address.  This is a lot of verification work
to be done.  Further, while the transition to DIX will move people to a
persona-url-based identifier, and away from an email-based identifier,
verified email addresses will still be required by each Service Provider
that relies on the validity of an email address belonging to a given
persona.

It has been offered that external solutions already exist to solve the
problem of email address verification, and as such, the challenge of such
verification should _not_ be included in the DIX spec.  Two common
approaches that I have seen (that already exist outside of DIX) are as
follows:

Approach 1.) Use a 3rd party signed claim about the email address, where the
service provider trusts the third party making the assertion.

This is probably the most secure solution, since this would use some form of
cryptographic signatures to assert validity.  However, IMHO _many_ people
are not going to go through the hassle of getting a "verified" email
address.  It will probably cost money (I'm thinking of Verisign), and the
average person won't really understand the benefit of getting "verified", at
least initially.  Plus, it's one extra hassle for a person who already
"owns" their email address.

Approach 2.) The ServiceProvider does some sort of email verification once
it receives the email address for the first time.  e.g. - SP sends an email
to <[email-masked]> saying "you signed up for geeknews.com, please
click this link to complete your signup".  This is not a terrible solution
(many companies employ this today for email verification), although I have
heard arguments against using such mechanisms.  In the end, however, this
solution requires end-user work at potentially every new Service Provider,
which is annoying to the user, and may hinder anti-phishing initiatives (by
continuing to confuse end-users trying to decipher legitimate from forged
emails).

It would be better if the end-user only needed to establish email ownership
once (with their IdP), in a way that all ServiceProviders could then trust
and verify (and that didn't necessarily involve a certificate-based 3rd
party signed assertions that may or may not cost money/be difficult to use).

Thus, I propose a third approach that allows domain owners to assert
ownership over email addresses, and then link that ownership to a DIX
persona-url via the DIX protocol (or DIX-like mechanisms).

Approach 3.) Automatic Email Verification by a Service Provider

We know that a given email is always owned by the domain that the email sits
in.  For example, microsoft.com is the authoritative domain for the email
address <[email-masked]>.  Likewise, sxip.com is authoritative for
sxip.com email addresses, and so on.  Therefore, the domain owner is the
best entity to verify an email address!  In lieu of a signed 3rd party
assertion, or an email with a "verify-me" link, domain owners can facilitate
email verification in the following way:

3.1) Service Provider receives a Fetch-Response with an email address
<[email-masked]> that the SP wishes to verify.  Assume the following:

            a1) The proposal introduces a new service called the
"email_verification_service" that receives requests to validate a given
email address.  This service can run on any machine in any domain (more on
this in later sections).

a2) The DIX IdP's "Fetch-Response" contains a field called
"email_verifier_hash" that is an SHA hash of 1.) Beth's persona's email
address, and 2.) A secret number (preferably long) that only the
email_verification_service knows.  For example: SHA1(email_address +
email_verification_secret_id) ==> SHA1("[email-masked]" + "A939....3939")
==> [email_verifier_hash].  To clarify, only the
email_authentication_service knows what the email_verification_secret_id is.
Conversely, the "email_verifier_hash" is given to the IdP upon account
creation (once), and freely passed around between IdP, SP, and
email_verifier_service.

3.2a) To verify the email address <[email-masked]>, the ServiceProvider
navigates to http://example.com (the domain specified in Beth's email
address), and follows the DIX discovery protocol to find a DIX.html file or
the root document. *** This is despite the fact that Beth specified a
different IdP during her regular DIX auth session.***

3.2b) If http://example.com has no DIX capability, then fallback to email
verification approaches 1 or 2 above, or possibly deny the login, or take
some other measure.

3.3a) If http://example.com has DIX capability, then the root document (or
DIX.html) might contain regular DIX Links, but will also contain a new link
that indicates an endpoint URL that has email authority for the specified
example.com domain.  For example, the Link could be something like:  <LINK
REL="urn:ietf:params:DIX:email-verification_service_endpoint"
HREF="http://www.example.com/smtp/endpoint">.  Alternatively, Beth's domain
(example.com) might delegate this authority to an endpoint in a different
domain using something like <LINK
REL="urn:ietf:params:DIX:email-verification_service_endpoint"
HREF="http://www.verifier.com/smtp/endpoint">.  Whatever the case, the
example.com domain owner asserts this link since the domain owner should
have control of the DIX.html or root html document in its domain.

3.3b) The designated 'email-endpoint' HREF is used as a service endpoint URL
to determine if a given email address/persona-url combo is valid.  This
email_verification query would look something like this:

ServiceProvider sends email-verification-endpoint (which is, e.g.,
http://www.verifier.com/smtp/endpoint) the following:

a.) SHA1(email_address + email_verification_id), which is equivalent to the
email_verifier_hash provided in the fetch response from the IdP.

b.) persona-url=http://homesite.org/493838 ==> Also provided in the fetch
response from the IdP.

The email_verification_endpoint will perform a lookup based on the supplied
information (email_verifier_hash and persona-url), and respond with
something like "DIX:true" if the persona url actually "owns" the indicated
email address.  Otherwise, the response should be something like
"DIX:false", or perhaps "DIX:unknown" if the verification_server is not
sure(?).

** Notice that an eavesdropper will not know which email is being verified
**

*** By proving (via domain ownership) that a given persona-url is linked to
a given email address, the email_verification_service can vouch that a given
persona-url controls or doesn't control a given email address.***

Potential Problems (and resolutions)

--------

P1.) What if the secret email_verification_id is guessed or compromised?

[Answer] First, the secret verification id is never passed out to remote
sites, and should be different for each email address.  If an attacker
somehow figured out the secret email_verification_id, the attacker would
still need to know the associated persona-url that matched the specified
email address.  

In the worst case, if an attacker knew all 3 pieces of info (email address,
persona-url, and secret key), he would only be able to figure out if a
single email is valid for a given persona-url.  It wouldn't tell the
attacker anything more about the email address in question, nor about the
persona's other personal info, nor about any other email addresses that may
or may not exist.  The secret key is really used to mask the email address
so that a casual eavesdropper will not know which email is being verified,
and to prevent spam trolling on the email_verification_service.

P2.) Couldn't someone else's email_verification_service vouch for my email
address without my permission?

[Answer] No.  The email_verification_protocol specifies that a Service
Provider perform a DIX discovery at the root domain of the specified email
address.  So, example.com is the first place to go in order to verify any
"example.com" email address.  Only the specified domain of an email address
can delegate to a different domain for email_verification (via DIX
discovery).

P3.) What if I don't control my domain's root page (i.e., a yahoo.com email
address)?

[Answer] Worst case, you would need to fallback on solution 1 or 2 above, or
urge the entity that does control your domain to embrace DIX.

P4.) How does the email_verification_service assert control over a given
email address in the first place?

[Answer] Basically, a user who actually controls an email address needs to
login to the email_verification_service to get the process started.  The
mechanism employed for login is email_verification_service
implementation-defined.  The email_verification_service could have some
non-DIX method of allowing a given user to login with their email address
(perhaps using the same login/password that the email account uses, since
the domain owner already knows this anyway).  In any event, after somehow
logging in, the user tells the email_verification_service what persona-url
is linked to their specific email address(es), and the
email_verification_service does the rest through the protocol.

P5.) If the IdP and the email_verification service aren't the same thing
(i.e., separate domains or servers), how do the IdP and the
Email_Verification_Service share the secret email_verification_id for
comparison purposes?

[Answer]  They don't.  The IdP is given an SHA Hash of the "email address" +
the secret email_verification_id.  This hash value can then be sent out to
various Service Providers, since this hash value is just another DIX
parameter that gets filled in when a user creates a new IdP account.  It is
feasible that an email_verification_service could somehow use a DIX store
method to propagate this information, but this requires further thought.

SUMMARY

-------

The main purpose of the email_verification_service is that a domain owner
should be the one to vouch for who controls an email address.   In addition,
DIX ServiceProviders that use the proposed email_verification_service can
automatically determine if a given persona-url is linked to a given email,
and can trust that determination because it is made by the owners of the
domain that controls the email address.  In the final analysis, no
continuing end-user interaction is required for each ServiceProvider that
wishes to validate an email address.  Plus, email_verification as laid out
in this post is not a requirement.  SP's could use alternative methods to
verify an email if, for instance, a given email domain doesn't support the
email verification service, or the SP determines that a stronger method of
email verification should be used.

_______________________________________________
dix mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dix

---

From: Dick Hardt <[email-masked]>
Date: Wed, 7 Jun 2006 23:18:38 -0700

Hi David

Interesting concept to distribute email verification. A modification  
on it would be *if* we get secure DNS, that the domain would be able  
to have a public key available and it could digitally sign the email  
to the persona URL. This lets the world not have to *trust* a  
centralized email verification service.

Having said that, I think there is a good likelyhood that trusted  
email verification services will be offered for free, which means  
that A1 may become widely adopted if it is as simple as todays email  
process, but that the user only has to do it once. Since only one (or  
maybe a few) sites do the verification, each domain does not need to  
do any config and the user can have any email address.

To pick up on the value of verified email, there is another use of an  
verified email address (or for the privacy conscience, a verified  
hash of an email address). ACLs. It is a total pain to give certain  
people access to a resource. Many of the private space wikis use  
email invites. Taking that a step further, you enter in the email  
addresses of who you would like to have access (email is an easy ID  
for people), and your invitees prove they own that email address --  
essentially it is the attribute that grants them access.

-- Dick

On 7-Jun-06, at 9:29 PM, Sappenin Technologies LLC wrote:

> This post offers a discussion about incorporating some sort of  
> email verification into the DIX protocol, either in the main DIX  
> spec itself, or along-side DIX in a sub or related spec.  In  
> particular, I propose an email verification solution that allows  
> domain owners to assert ownership over an email address, and link  
> that ownership to a DIX persona-url.  To be clear, I view the  
> method proposed in this post as one method (of many possibilities)  
> I'm not sure to what degree "email verification in DIX" has been  
> discussed on this list, but I'd like to offer a few arguments in  
> favor of my proposed scheme (or something like it), as well as a  
> sample flow of how such a scheme might work in the context of DIX.   
> Any feedback and/or comments are welcome.
>
>
>
> david
>
> [email-masked]
>
>
>
> --
>
>
>
> First, the primary reason that DIX should have the capability to  
> validate email addresses in particular (and not necessarily other  
> “verifiable” pieces of information) is that most websites today use  
> an email-address as a unique identifier (think username).  When  
> these sites transition to DIX, they (the sites) will rely on a  
> persona-url being associated with, and possibly the actual owner  
> of, a given email address.  This is a lot of verification work to  
> be done.  Further, while the transition to DIX will move people to  
> a persona-url-based identifier, and away from an email-based  
> identifier, verified email addresses will still be required by each  
> Service Provider that relies on the validity of an email address  
> belonging to a given persona.
>
>
>
> It has been offered that external solutions already exist to solve  
> the problem of email address verification, and as such, the  
> challenge of such verification should _not_ be included in the DIX  
> spec.  Two common approaches that I have seen (that already exist  
> outside of DIX) are as follows:
>
>
>
> Approach 1.) Use a 3rd party signed claim about the email address,  
> where the service provider trusts the third party making the  
> assertion.
>
> This is probably the most secure solution, since this would use  
> some form of cryptographic signatures to assert validity.  However,  
> IMHO _many_ people are not going to go through the hassle of  
> getting a "verified" email address.  It will probably cost money  
> (I'm thinking of Verisign), and the average person won't really  
> understand the benefit of getting "verified", at least initially.   
> Plus, it’s one extra hassle for a person who already “owns” their  
> email address.
>
>
>
> Approach 2.) The ServiceProvider does some sort of email  
> verification once it receives the email address for the first  
> time.  e.g. - SP sends an email to <[email-masked]>  
> saying "you signed up for geeknews.com, please click this link to  
> complete your signup".  This is not a terrible solution (many  
> companies employ this today for email verification), although I  
> have heard arguments against using such mechanisms.  In the end,  
> however, this solution requires end-user work at potentially every  
> new Service Provider, which is annoying to the user, and may hinder  
> anti-phishing initiatives (by continuing to confuse end-users  
> trying to decipher legitimate from forged emails).
>
>
>
> It would be better if the end-user only needed to establish email  
> ownership once (with their IdP), in a way that all ServiceProviders  
> could then trust and verify (and that didn't necessarily involve a  
> certificate-based 3rd party signed assertions that may or may not  
> cost money/be difficult to use).
>
>
>
> Thus, I propose a third approach that allows domain owners to  
> assert ownership over email addresses, and then link that ownership  
> to a DIX persona-url via the DIX protocol (or DIX-like mechanisms).
>
>
>
> We know that a given email is always owned by the domain that the  
> email sits in.  For example, microsoft.com is the authoritative  
> domain for the email address <[email-masked]>.  Likewise,  
> sxip.com is authoritative for sxip.com email addresses, and so on.   
> Therefore, the domain owner is the best entity to verify an email  
> address!  In lieu of a signed 3rd party assertion, or an email with  
> a "verify-me" link, domain owners can facilitate email verification  
> in the following way:
>
>
>
> 3.1) Service Provider receives a Fetch-Response with an email  
> address <[email-masked]> that the SP wishes to verify.  Assume  
> the following:
>
>
>
> "email_verification_service" that receives requests to validate a  
> given email address.  This service can run on any machine in any  
> domain (more on this in later sections).
>
>
>
> "email_verifier_hash" that is an SHA hash of 1.) Beth's persona's  
> email address, and 2.) A secret number (preferably long) that only  
> the email_verification_service knows.  For example: SHA1 
> (email_address + email_verification_secret_id) ==> SHA1 
> ("[email-masked]" + "A939....3939") ==> [email_verifier_hash].   
> To clarify, only the email_authentication_service knows what the  
> email_verification_secret_id is.  Conversely, the  
> "email_verifier_hash" is given to the IdP upon account creation  
> (once), and freely passed around between IdP, SP, and  
> email_verifier_service.
>
>
>
> 3.2a) To verify the email address <[email-masked]>, the  
> ServiceProvider navigates to http://example.com (the domain  
> specified in Beth’s email address), and follows the DIX discovery  
> protocol to find a DIX.html file or the root document. *** This is  
> despite the fact that Beth specified a different IdP during her  
> regular DIX auth session.***
>
> 3.2b) If http://example.com has no DIX capability, then fallback to  
> email verification approaches 1 or 2 above, or possibly deny the  
> login, or take some other measure.
>
>
>
> 3.3a) If http://example.com has DIX capability, then the root  
> document (or DIX.html) might contain regular DIX Links, but will  
> also contain a new link that indicates an endpoint URL that has  
> email authority for the specified example.com domain.  For example,  
> the Link could be something like:  <LINK  
> HREF="http://www.example.com/smtp/endpoint">.  Alternatively,  
> Beth's domain (example.com) might delegate this authority to an  
> endpoint in a different domain using something like <LINK  
> HREF="http://www.verifier.com/smtp/endpoint">.  Whatever the case,  
> the example.com domain owner asserts this link since the domain  
> owner should have control of the DIX.html or root html document in  
> its domain.
>
>
>
> 3.3b) The designated 'email-endpoint' HREF is used as a service  
> endpoint URL to determine if a given email address/persona-url  
> combo is valid.  This email_verification query would look something  
> like this:
>
>
>
> a.) SHA1(email_address + email_verification_id), which is  
> equivalent to the email_verifier_hash provided in the fetch  
> response from the IdP.
>
> b.) persona-url=http://homesite.org/493838 ==> Also provided in the  
> fetch response from the IdP.
>
>
>
> The email_verification_endpoint will perform a lookup based on the  
> supplied information (email_verifier_hash and persona-url), and  
> respond with something like "DIX:true" if the persona url actually  
> "owns" the indicated email address.  Otherwise, the response should  
> be something like "DIX:false", or perhaps "DIX:unknown" if the  
> verification_server is not sure(?).
>
>
>
> ** Notice that an eavesdropper will not know which email is being  
> verified **
>
> *** By proving (via domain ownership) that a given persona-url is  
> linked to a given email address, the email_verification_service can  
> vouch that a given persona-url controls or doesn't control a given  
> email address.***
>
>
>
>
>
> [Answer] First, the secret verification id is never passed out to  
> remote sites, and should be different for each email address.  If  
> an attacker somehow figured out the secret email_verification_id,  
> the attacker would still need to know the associated persona-url  
> that matched the specified email address.
>
>
>
> In the worst case, if an attacker knew all 3 pieces of info (email  
> address, persona-url, and secret key), he would only be able to  
> figure out if a single email is valid for a given persona-url.  It  
> wouldn't tell the attacker anything more about the email address in  
> question, nor about the persona's other personal info, nor about  
> any other email addresses that may or may not exist.  The secret  
> key is really used to mask the email address so that a casual  
> eavesdropper will not know which email is being verified, and to  
> prevent spam trolling on the email_verification_service.
>
>
>
> P2.) Couldn't someone else's email_verification_service vouch for  
> my email address without my permission?
>
> [Answer] No.  The email_verification_protocol specifies that a  
> Service Provider perform a DIX discovery at the root domain of the  
> specified email address.  So, example.com is the first place to go  
> in order to verify any "example.com" email address.  Only the  
> specified domain of an email address can delegate to a different  
> domain for email_verification (via DIX discovery).
>
>
>
> P3.) What if I don't control my domain's root page (i.e., a  
> yahoo.com email address)?
>
> [Answer] Worst case, you would need to fallback on solution 1 or 2  
> above, or urge the entity that does control your domain to embrace  
> DIX.
>
>
>
> P4.) How does the email_verification_service assert control over a  
> given email address in the first place?
>
> [Answer] Basically, a user who actually controls an email address  
> needs to login to the email_verification_service to get the process  
> started.  The mechanism employed for login is  
> email_verification_service implementation-defined.  The  
> email_verification_service could have some non-DIX method of  
> allowing a given user to login with their email address (perhaps  
> using the same login/password that the email account uses, since  
> the domain owner already knows this anyway).  In any event, after  
> somehow logging in, the user tells the email_verification_service  
> what persona-url is linked to their specific email address(es), and  
> the email_verification_service does the rest through the protocol.
>
>
>
> P5.) If the IdP and the email_verification service aren't the same  
> thing (i.e., separate domains or servers), how do the IdP and the  
> Email_Verification_Service share the secret email_verification_id  
> for comparison purposes?
>
> [Answer]  They don't.  The IdP is given an SHA Hash of the "email  
> address" + the secret email_verification_id.  This hash value can  
> then be sent out to various Service Providers, since this hash  
> value is just another DIX parameter that gets filled in when a user  
> creates a new IdP account.  It is feasible that an  
> email_verification_service could somehow use a DIX store method to  
> propagate this information, but this requires further thought.
>
>
>
> SUMMARY
>
> -------
>
> The main purpose of the email_verification_service is that a domain  
> owner should be the one to vouch for who controls an email  
> address.   In addition, DIX ServiceProviders that use the proposed  
> email_verification_service can automatically determine if a given  
> persona-url is linked to a given email, and can trust that  
> determination because it is made by the owners of the domain that  
> controls the email address.  In the final analysis, no continuing  
> end-user interaction is required for each ServiceProvider that  
> wishes to validate an email address.  Plus, email_verification as  
> laid out in this post is not a requirement.  SP’s could use  
> alternative methods to verify an email if, for instance, a given  
> email domain doesn’t support the email verification service, or the  
> SP determines that a stronger method of email verification should  
> be used.
>
>
>

---

From: "David Fuelling" <[email-masked]>
Date: Thu, 8 Jun 2006 11:03:36 -0400

Hi Dick,

Great points, especially wrt to secure DNS.  

DH> Interesting concept to distribute email verification. A modification 
DH> on it would be *if* we get secure DNS, that the domain would be able 
DH> to have a public key available and it could digitally sign the email 
DH> to the persona URL. This lets the world not have to *trust* a 
DH> centralized email verification service.

Just to clarify (not sure if you actually meant this or not) that the scheme
I had in mind would allow an email_verification_service at every domain
(potentially).  If a given domain didn't want to actually run the
verification service, they could delegate the responsibility to whomever,
via dix discovery.  There wouldn't be a centralized verification service
(unless everybody delegated to the same service).  

You're right, though...secure DNS could make the whole thing much more
secure (although, in the current DNS system, it seems like it would be
pretty difficult for a random attacker somewhere on the net to spoof a
conversation between a random email address domain and a random SP.  It
seems to me that the attacker would probably need to have compromised the SP
or the email_verification_service, or an ISP thereof to perform a DNS
spoofing attack)....though I'm not an expert in that realm.

David
[email-masked]

> -----Original Message-----
> From: Dick Hardt [mailto:[email-masked]]
> Sent: Thursday, June 08, 2006 2:19 AM
> To: [email-masked]; Digital Identity Exchange
> Subject: Re: [dix] Email Verification with Dix - a Possible Method?
> 
> Hi David
>