Subject: RE: [dix] Federated Digest Auth

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 2 Mar 2006 07:10:05 -0800

I forgot to mention, you can use the standard HTTP content negotiation
mechanism to select form encoded or SAML assertions in the exchange
between the relying party and the registry.

A good way to think of it is that the exchange between the relying party
and the registry is simply a standard HTTP request/response. The only
difference is that the authentication data is provided by a different
party, the user that initiated the original request rather than the
relying party making the federated auth request.

The key advantage here is that the protocol is safe against
man-in-the-middle attacks, provided that is the user interface for the
browser does not allow a downgrade attack to BASIC auth. This is of
course a security failure that needs fixing regardless.

What this scheme does not provide is a way for the end user to control
the specific attributes that are released. 

What it does very well is to provide transparent authentication, there
is no need for the user to log in because the browser will do that
automatically using the existing cache mechanism once it recognizes that
the site has already been visited. The user only needs to provide
credentials once per session, unlike cookies however the user is
required to resupply the credentials at least once and the browser knows
that the data is credential data.

> -----Original Message-----
> From: Hallam-Baker, Phillip [mailto:[email-masked]] 
> Sent: Wednesday, March 01, 2006 10:30 PM
> To: Digital Identity Exchange
> Subject: RE: [dix] Federated Digest Auth
> 
> > From: Dick Hardt [mailto:[email-masked]]
> 
> > How would this move around other identity data? My interest 
> in DIX is 
> > to be able to move around all kinds of identity data. To me, that 
> > means that the site needs to be able to say "here is what I 
> want", the 
> > user has an opportunity to select what to release, and then 
> it is sent 
> > to the site.
> 
> Here are some fake messages I created for the design. I can 
> generate some genuine data tommorow (server is upstairs).
> 
> OK three parties:
> 
> Client (user), Relying party and Registry
> 
> Following the Digest auth spec the protocol begins with a 
> request from the client which results in a refused response 
> containing a challenge:
> 
> HTTP/1.0 401 Unauthorised
> Server: SokEvo/0.9
> Date: Sun, 10 Apr 2005 20:26:47 GMT
> WWW-Authenticate: Digest realm="low@portableidentifier"
> 	qop="auth,auth-int",
>  	nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
> Content-Type: text/html
> Content-Length: 311
> 
> The client responds using standard Digest Auth
> 
> GET /dir/index.html HTTP/1.0
> Host: localhost
> Authorization: Digest username="[email-masked]",
> 	realm="low@portableidentifier",
> 	nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
> 	uri="/dir/index.html",
> 	qop=auth,
> 	nc=00000001,
> 	cnonce="0a4f113b",
> 	response="6629fae49393a05397450978507c4ef1"
> 
> The relying party locates the registry server to authenticate 
> users in sxip.com using the SRV mechanism.
> 
> The response from the user is now relayed to the registry. 
> The uri value, realm &ct are replaced by the ha2 hash value:
> 
> GET / HTTP/1.0
> Host: localhost
> Authorization: Digest username="[email-masked]",
> 	realm="low@portableidentifier",
> 	nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
> 	ha2="39aff3a2bab6126f332b942af96d3366",
> 	qop=auth,
> 	nc=00000001,
> 	cnonce="0a4f113b",
> 	response="6629fae49393a05397450978507c4ef1"
> 
> The registry replies either 200 OK or 401 unauthorized.
> 
> HTTP/1.0 200 Accept
> Server: SokEvo/0.9
> Date: Sun, 10 Apr 2005 20:27:42 GMT
> 
> If you want attributes with that you simply add content to 
> the request and response:
> 
> 
> GET /?ask=name+ZIP+ShoeSize HTTP/1.0
> Host: localhost
> Authorization: Digest username="[email-masked]",
> 	realm="low@portableidentifier",
> 	nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
> 	ha2="39aff3a2bab6126f332b942af96d3366",
> 	qop=auth,
> 	nc=00000001,
> 	cnonce="0a4f113b",
> 	response="6629fae49393a05397450978507c4ef1"
> 
> HTTP/1.0 200 OK
> Server: SokEvo/0.9
> Date: Sun, 10 Apr 2005 20:27:42 GMT
> 
> Name=Dick+Hardt&zip=90210&ShoeSize=10
> 
> 
> Or you can return a SAML token or use POST or whatever. You 
> can use the rest of DIX at this point.
> 
> Although this is limited to username/password type auth it is 
> still possible to use a one time password token provided that 
> the registry can access the list of expected password values. 
> 
> If you are doing PKI based auth then you are going to need a 
> new client anyway. The way I would handle this is using a 
> prefixed TXT record:
> 
> _authprot.sxip.com 	TXT "T=AUTHPROT P=DIGEST,SAML,DIX"
> _digest.tcp.sxip.com	SRV 1,1,1,1, 80, digestreg.sxip.com
> 
> 
> It may be possible to use NAPTR. Although this is not 
> supported in certain DNS servers it is already required by 
> SIP. Given the critical nature of SIP it is arguable that 
> NAPTR will deploy.
> 
> _______________________________________________
> dix mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dix
> 
> 

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

---

From: Dick Hardt <[email-masked]>
Date: Thu, 2 Mar 2006 08:36:18 -0800

> the specific attributes that are released.

IMHO it is critical for the user to control the release.

LID et al have some mechanism for allowing site to query the registry  
and have the user control the release (which I don't fully understand)

I think there is something from your previous post though in how a  
Rich Client can negotiate with the site leveraging existing standards.

-- Dick