|
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 -- 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 [email protected] https://www1.ietf.org/mailman/listinfo/dix
