Subject: [dix] Review of draft-merrells-dix-00.txt

From: Eric Rescorla <[email-masked]>
Date: Sat, 11 Feb 2006 15:17:08 -0800

BACKGROUND
The idea behind DIX is to have a third-party authentication system
where a user can have a preexisting relationship with a third party
that then vouches for its identity to the system site/server that it
actually wants to communicate with. This is, of course, a pretty
common desire and there are already a lot of systems that do 
it (Kerberos, PKI, etc.). The particular scheme described in
this draft is based on Web forms, Javascript, and redirection.

SUMMARY OF THE DIX SCHEME
Here's my reconstruction of how the DIX scheme works from the 
document (which, unfortunately, does not contain a helpful
summary or diagram)

The DIX scheme involves at minimum three agents:

- The user's client (browser)
- The site that the user is trying to access (called the Membersite)
- The site that authenticates the user (called the Homesite)

When the user contacts the Membersite (1), it responds with a web
page prompting the user to enter the URL of its Homesite (2). The
user then enters the Homesite URL (3). The Membersite contacts the 
Homesite (4,5) to determine whether the Homesite can provide the
appropriate kind of authentication. If it can, the Membersite
sends the client a redirect (6) (using Javascript) to the
Homesite. In some way that's not entirely clear the Homesite
validates the request and returns a ticket to the Client (8)
The Client then (via Javascript?) sends the ticket to the
the Membersite (9). The Membersite contacts the Homesite with
a digest of the ticket in order to confirm its validity (10)
If the Homesite says its OK (11), the Membersite returns OK
to the Client (12)

  Client                       Membersite                    Homesite

1 Hello -------------------------->
2       <------- Enter homesite URL
3 Homesite URL ------------------->             
4                                  Get capabilities ---------->
5                                         <------------- Capabilities
6       <------ Redirect to Homesite  
7 Get Ticket-------------------------------------------------->
8       <----------------------------------------------------- Ticket
9 Ticket ------------------------->
10                               Verify ticket -------------->
11                               <-----------------------  Ticket OK
12      <------------------------ OK

There's one more detail that I haven't mentioned: in order to
enable automatic submission of the abovementioned form (2,3), 
this document specifies a particular form for the page 
(i.e., particular names for form input fields) so that
clients can detect it and auto-fill-in.

COMMENTS
I have four major concerns about this system as described:

- Relationship to existing work
- Use of Javascript
- Method of ticket validation

The remainder of this review details these issues.

Relationship To Existing Work
There has been a very large amount of work in delegated/federated
authentication systems, ranging from RADIUS/DIAMETER to 
Shibboleth, Liberty, and SAML. It's not clear from this document or from
the charter why something new is needed here. So, I think the 
first order of business to establish what properties are required
here that present systems don't provide.

Use of Javascript
Section 5.10.2.1 reads:

   The Membersite sends a fetch-request message to the Homesite through 
   the User's client via a redirected HTTP POST to their Homesite 
   Endpoint URL using JavaScript to autosubmit the form. 

I appreciate the rationale for this: you want things to work with
dumb clients but given that Javascript isn't any kind of IETF
standard--it's hard to see how we could require it in an IETF
standard. ECMASCript, perhaps. Even then, specifying this kind
of implementation detail is the kind of thing that IETF typically
stays out of. I appreciate that this is also a wire protocol issue,
but given that there's no specification of the exact JavaScript
incantation, it's not clear it makes sense to specify only
the language.

Method of ticket validation
This draft validates the ticket by having the Membersite send a digest
to the Homesite and get an ACK. It's not clear why this is desirable.
Wouldn't it be simpler to have the Homesite digitally sign the ticket
(the key could be delivered in the initial capabilities discovery
phase) and then let the Membersite do the verification directly?
I appreciate that there's a freshness concern, but this can 
be alleviated using the usual nonce-based anti-replay techniques.

	A suggested implementation of a signature function would be to use 
	the SHA1 algorithm, which takes as input a digest of the message and 
	a secret known only to the Homesite. 

	Signature = T ( S + Digest )  

	Where, Digest is message digest (defined above), S is the Homesite 
	Secret, T is the signature generation function, and '+' means string 
	concatentation. 

The technical term for a "signature" which can only be verified by
the holder of a symmetric secret is Message Authentication Code (MAC)
and there's a standard technique for performing MACs: HMAC (RFC 2104).

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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 11 Feb 2006 16:29:18 -0800

> standard. 

small procedural point:  the ietf does it all the time.

x.400 interoperability specs. IP-over-* specs. Anything using Unicode.

And so on.

(The subject line of this message is changed so that no one confuses this note 
with a comment on dix or your substantive review of it.)

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>

---

From: Johannes Ernst <[email-masked]>
Date: Sat, 11 Feb 2006 19:34:37 -0800

On Feb 11, 2006, at 15:17, Eric Rescorla wrote:

> the charter why something new is needed here...

Just having returned from a workshop at Harvard with many of the  
important players in the extended identity universe, in which we  
touched on most of the major existing standards and proposals (e.g.  
Microsoft's) in one way or another, I can relay that I have heard  
that concern repeatedly. Everybody pretty much now agrees that we  
need more interoperability, not more stovepipes.

Personally, as I have indicated previously on this list, I think  
there are a number of things that the IETF could usefully do  
complementing rather than replicating other people's work, but I  
concur that this has not be articulated so far.

> Method of ticket validation ...

Are you basically proposing a variation of OpenID authentication, or  
do I misunderstand you?

Johannes Ernst
NetMesh Inc.

  http://netmesh.info/jernst

---

From: Dave Crocker <[email-masked]>
Date: Sat, 11 Feb 2006 21:31:51 -0800

J> Just having returned from a workshop at Harvard with many of the
> important players in the extended identity universe, in which we touched 
> on most of the major existing standards and proposals (e.g. Microsoft's) 
> in one way or another, I can relay that I have heard that concern 
> repeatedly. Everybody pretty much now agrees that we need more 
> interoperability, not more stovepipes.

Yup.

It would help to separate identity from policy/credentials, just as it helps to 
separate identity from address.

One of the more curious things to observe is that the world of tcp/ip lower 
layers has been learning about the need to *separate* the semantic construct of 
identity from that of location, just as the upper-layered applications world 
seems to be deciding -- in my opinion, quite erroneously -- to *merge* semantic 
constructs.

d/
-- 

Dave Crocker

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 12 Feb 2006 17:08:46 -0800

> Are you basically proposing a variation of OpenID authentication, or

I'm not proposing anything. There are a number of ways to do the
kind of ticket verification that a DIX-type system would need. 
The digest exchange that DIX uses strikes me as one of the least
convenient.

---

From: John Merrells <[email-masked]>
Date: Mon, 13 Feb 2006 10:05:22 -0800

> incantation, it's not clear it makes sense to specify only

I've changed the wording so that auto submission is a 'should',
and that using ECMAScript is a 'could'.

Thanks

John

---

From: John Merrells <[email-masked]>
Date: Mon, 13 Feb 2006 10:07:55 -0800

On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote:

> actually wants to communicate with.

Yes, but there's more. We're also moving properties from one party
to the other, where the property could be self or third party asserted.

John

> This is, of course, a pretty

---

From: John Merrells <[email-masked]>
Date: Mon, 13 Feb 2006 10:09:36 -0800

> document (which, unfortunately, does not contain a helpful

Agreed.

I'll reflect your sequence diagram into the draft, and will provide
informational references to our engineering documents, which
include pretty pictures.

John

---

From: John Merrells <[email-masked]>
Date: Mon, 13 Feb 2006 10:17:29 -0800

On 11-Feb-06, at 3:17 PM, Eric Rescorla wrote:

> user then enters the Homesite URL (3).

Actually, we call it the Homesite Path. The user provides it, so it may
not be a well-formed URL, so we say Path and encourage the
Membersite to turn it into a URL. eg. yahoo.com -> http://yahoo.com/

> The Membersite contacts the
> appropriate kind of authentication.

Capability, rather than authentication. Yes, a capability could be
a means of authentication. ie. MS wants a HS that can perform
authentication with a Foo-Bar-Baz 2-factor device.

> If it can, the Membersite
> Homesite. In some way that's not entirely clear

True.

> the Homesite

Not sure it's a Ticket, but... the HS sends a message digest
and a signature that is a digest of the message digest and
a HS secret... if that's a ticket then yes.

The MS sends both the digest and the signature to the HS
for verification .

John

---

From: Joaquin Miller <[email-masked]>
Date: Mon, 13 Feb 2006 10:05:01 -0800

>The digest exchange that DIX uses strikes me as one of the least convenient.

Since it is ok for a contribution to this list to be open to the 
accusation of being pedantic:

Is there a digest exchange that DIX uses?

Or is it only that there is a digest exchange that an individual 
submission Internet Draft that describes one such implementation uses?

If the latter, is there a convenient name for the protocol(s) 
described in that individual submission draft?

Cordially, Joaquin

---

From: John Merrells <[email-masked]>
Date: Mon, 13 Feb 2006 10:31:12 -0800

> be alleviated using the usual nonce-based anti-replay techniques.

The motivation wasn't freshness. The dix:/message-id parameter
is a nonce that takes care of this.

The motivation was to get all the binary crypto code out of the MS to
ease adoption. We learnt from our prior experience with the SXIP
protocol that this was a barrier to adoption. Writing good DSIG code
for all platforms/stacks/languages is tedious and expensive and worse
increases the number of lines of code that a MS developer has to
write to enable a site. [SXIP 1.0 worked this way.]

Note that using dmd0 (*) as a layer a capability could be defined that
provided this improved signature handling alternative.

John

dmd0= draft-merrells-dix-00.txt

---

From: John Merrells <[email-masked]>
Date: Mon, 13 Feb 2006 10:34:01 -0800

> and there's a standard technique for performing MACs: HMAC (RFC 2104).

We looked at that... but decided what we were doing was different
in some way. I'll dig out my notes.

John

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Feb 2006 10:35:03 -0800

> write to enable a site. [SXIP 1.0 worked this way.]

Just to clarify, getting someone to install or dynamic language  
script or module is *way* easier then installing a binary.

XML DSIG libraries are not widely available at this time for the  
scripting platforms.

-- Dick

---

From: John Merrells <[email-masked]>
Date: Mon, 13 Feb 2006 10:36:38 -0800

> submission Internet Draft that describes one such implementation uses?

Yes.

> described in that individual submission draft?

It's called draft-merrells-dix-00.txt, or for shorthand I call it dmd0.

(Note that pre publication I called it dmd1, because I'd forgotten they
are  numbered from zero... silly me.)

John

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Feb 2006 10:42:14 -0800

> authentication with a Foo-Bar-Baz 2-factor device.

Uh, Capability has a pretty well understood meaning in information
security, and it doesn't seem to me that that matches what you're
doing here. I would advise finding a new name.

> The MS sends both the digest and the signature to the HS

Well, we're running a bit short on names (credential, ticket,
token, certificate, cookie, etc. being all taken) so I just
picked the one I thought was closest on the theory that
the term you were using "message" wasn't that evocative.

The bottom line here is that the Homesite sends the Membersite
a message through the client that vouches for the authentication/
properties/whatever of the client/user. Ticket seems like
as good a name as anything for that.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Feb 2006 10:51:41 -0800

> write to enable a site. [SXIP 1.0 worked this way.]

What do you mean "binary crypto code"? You've got a hash algorithm,
no? At worst, you could share a pairwise secret between the MS and
the HS during the initial discovery phase and use that to key
a MAC. (This is of course only safe if you're doing that exchange
over SSL/TLS, but that's true of your scheme too...)

Anyway, I don't really find this that convincing. Java certainly
comes with built-in public key functionality and there are modules
for Python, Perl and PHP (it's actually a compilation flag for PHP).
Yes, it's not zero effort, but it's not exactly prohibitive either.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Feb 2006 10:52:12 -0800

> XML DSIG libraries are not widely available at this time for the

Who said anything about XML DSIG? I just said you could use a digital
signature, which doesn't require XML at all.

-Ekr

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Feb 2006 10:56:04 -0800

> clients can detect it and auto-fill-in.

This also allows an enhanced browser to detect the request and  
rewrite the action for the page and process the request directly.  
This could include the enhanced browser acting as the Homesite. We  
have a prototype of this running now. It is pretty easy to do the  
protocol stuff. The data management is a little more work. :)

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Feb 2006 10:58:39 -0800

> here that present systems don't provide.

We define identity very broadly. There is much more to a person then  
being able to authenticate.

In discussions with many web sites, it is much more interesting to  
get properties about the user then to enable SSO.

Agree that the charter does not answer this question well.

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Feb 2006 11:02:38 -0800

> incantation, it's not clear it makes sense to specify only

The protocol works without the ECMAScript, the user would need to  
click another button to continue on with the exchange. The ECMAScript  
provides a more seamless use experience since a POST cannot be  
redirected, and we did not want to limit the data to what could sit  
on a URL, as well, did not want the data to have to be exposed by  
being on a URL. As noted in another email, an enhanced browser does  
not need to the ECMAScript. We see this as a boot strap method.

wrt. how it is positioned in the ID, I agree it is an implementation  
detail. How would you suggest that implementation hints like this are  
communicated?

-- Dick

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Feb 2006 11:04:09 -0800

> and there's a standard technique for performing MACs: HMAC (RFC 2104).

Our current implementation uses HMAC. Since the Homesite can use  
whatever it wants, we left it out of the spec.

You call the message a "ticket" -- perhaps you can elaborate on that?

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Feb 2006 11:06:15 -0800

> signature, which doesn't require XML at all.

A digital signature of what though? And there is key management etc.  
Would seem challenging to convince anyone to NOT be using XML DSIG  
for signing an XML message these days.

---

From: John Merrells <[email-masked]>
Date: Mon, 13 Feb 2006 11:07:53 -0800

> signature, which doesn't require XML at all.

Sorry, yes, was thinking of our SXIP 1.0 architecture, and signing of
property values, rather than generic digital signatures for message
verification.

John

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Feb 2006 11:08:33 -0800

Dick Hardt <[email-masked]> writes:

> A digital signature of what though? 

Whatever information you're digesting now. 

> And there is key management etc.

What key management? Just hand over the key during the capabilities
exchange.

> for signing an XML message these days.

If you say so. You seem perfectly happy to digest a bunch of data
without using any special XML pixie dust.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Feb 2006 11:09:20 -0800

> whatever it wants, we left it out of the spec.

Well, that's fine, but you shouldn't be recommending a technique
which is known to be inferior to HMAC.

> You call the message a "ticket" -- perhaps you can elaborate on that?

See my response to John.

-Ekr

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Feb 2006 11:10:36 -0800

> Yes, it's not zero effort, but it's not exactly prohibitive either.

Yes, hash algorithms are widely available on the platforms. (but even  
SHA-1 is not everywhere)

Public Key algorithms are not widely available on the dynamic  
language platforms.

Easy for Perl, Python, PHP and Ruby developers in addition to Java  
and .Net developers was a core goal of DIX.

---

From: [email-masked]
Date: Mon, 13 Feb 2006 14:12:33 -0500

I would suggest a clearly labeled non-normative section, probably toward the end of the document.
 
Terry 
 
-----Original Message-----
From: Dick Hardt <[email-masked]>
To: Digital Identity Exchange <[email-masked]>
Sent: Mon, 13 Feb 2006 11:02:38 -0800
Subject: Re: [dix] Review of draft-merrells-dix-00.txt

wrt. how it is positioned in the ID, I agree it is an implementation detail. How would you suggest that implementation hints like this are communicated?

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Feb 2006 11:15:19 -0800

> What key management? Just hand over the key during the capabilities

Requires state management. Current method does not require state. One  
of the goals of the capabilities would be able to extend DIX so that  
if a Membersite was able to maintain state, key exchange could happen  
and the Membersite could verify the message itself.

> without using any special XML pixie dust.

Digest of name / value pairs now. Easier to sidestep the XML  
standards police. :)

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Feb 2006 11:15:17 -0800

> Yes, hash algorithms are widely available on the platforms. (but even

Well, since your scheme requires SHA-1 implementations 
(see S 5.10.2.2), I don't see how non-universality of
SHA-1 can be an objection. And as I indicated, it's
possible to attack this problem using only SHA-1 (though
the solution is inferior to when PK is used).

> and .Net developers was a core goal of DIX.

I don't think you've addressed my point here. There are PK 
modules for all the major dynamic platforms for the price of
a recompile. I don't see how this is prohibitive.

-Ekr

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Feb 2006 11:16:30 -0800

> which is known to be inferior to HMAC.

I agree. Did not know we were recommending a different technique.  
Where is that mentioned?

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Feb 2006 11:19:49 -0800

> I agree. Did not know we were recommending a different technique.

Section 5.10.2.3.

-Ekr

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Feb 2006 11:20:03 -0800

> the solution is inferior to when PK is used).

Sorry I was not clear, my point was that even SHA-1, which we  
require, is not universally available.

> a recompile. I don't see how this is prohibitive.

Having been a tool vendor for those languages, it is not as simple as  
that. Our experience with SXIP 1.0 was that it was prohibitive for  
many, even when we supplied the binary.

---

From: Dick Hardt <[email-masked]>
Date: Mon, 13 Feb 2006 11:24:37 -0800

>> I agree. Did not know we were recommending a different technique.

Ok. I agree. We should recommend HMAC directly.

---

From: John Merrells <[email-masked]>
Date: Mon, 13 Feb 2006 13:27:52 -0800

> Ok. I agree. We should recommend HMAC directly.

I've changed that paragraph in dmd1 to state HMAC and reference the RFC.

"A suggested implementation of a signature function would be to use  
the HMAC mechanism with the SHA1 cryptographic hash function, which  
takes as input a digest of the message and a secret known only to the  
Homesite. [RFC2104]"

John