Subject: RE: [dix] Federated Digest Auth

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 1 Mar 2006 19:30:08 -0800

> 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

---

From: Robert Yates <[email-masked]>
Date: Thu, 02 Mar 2006 11:32:32 -0500

Or, with this approach modified, to be more along the lines of dmd0

>GET /dir/index.html HTTP/1.0
The username passed is the persona-url
Authorization: Digest username="dix:/sxip.com/employees/dick",

>	response="6629fae49393a05397450978507c4ef1"
The relying party locates a homesite-url for the persona-url using the 
persona document.  (What if there is more than one homesite?)

The relying party makes a call to the homesite-url with a 
"dix:/message-type" of "dix:/verify-digest-request".  It also passes 
parameters for realm, nonce, ha2, qop, nc, cnonce and response.

The homesite responds with a dix:/true or dix:/false as outlined in 
section 5.10.3.4. of dmd0

Rob