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).
The Javascript trick also needs an update of RFC 2109 because it's a potentially state-changing cross-site request which is outlawed by the RFC (except that nobody implements this part of the RFC anyway).