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

[Hallam-Baker, Phillip]

Take a look at Domain Keys Identified Mail. From: Sappenin Technologies LLC [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 12:29 AM To: dix@ietf.org Subject: [dix] Email Verification with Dix - a Possible Method? 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 PROTECTED]   --   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 PROTECTED]> 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 PROTECTED]>.  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 PROTECTED]> 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 PROTECTED]" + "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 PROTECTED]>, 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="">.  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="">.  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="" ==> 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
dix@ietf.org
https://www1.ietf.org/mailman/listinfo/dix