Review of draft-merrells-dix-00.txt

From: Eric Rescorla
Date: 2006-02-10
Review of draft-merrells-dix-00.txt
 
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).