[foaf-protocols] some more .net code for an FOAFSSL.org RP site, interworking with foafssl.org IDP (with Unit Test).

Peter Williams home_pw at msn.com
Thu Feb 25 18:10:50 CET 2010


Concerning digest auth, summarized for easy reading at
http://en.wikipedia.org/wiki/Digest_access_authentication:-

 

Could we eliminate the timestamp field from foafssl.org . by instead
including in the tobesigned URI by foafssl.org such as the field:
"response="0a502730da3d65464ab71b2aece3b52c"?

 

Here is the rule.

 

If the requesting party (foaf.me) forwards on the 302 message to the IDP
(foafssl.org) an "Authorization: Digest ." header and if the header includes
a response field, replace the timestamp field in the to be signed material
with the response field. 

 

Do this, and the IDP's signed assertion ties back cryptographically into a
specific point in the sequence of browser<->RP interactions (e.g. after nc=1
but before nc=2)

 

 

 

From: foaf-protocols-bounces at lists.foaf-project.org
[mailto:foaf-protocols-bounces at lists.foaf-project.org] On Behalf Of Peter
Williams
Sent: Tuesday, February 23, 2010 10:10 AM
To: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] some more .net code for an FOAFSSL.org RP
site, interworking with foafssl.org IDP (with Unit Test).

 

Interesting extended flow, applying digest auth. Distinguishes names, from
different observer points.

 

 

USER to SP, wanting access to a resource

 

X-GET: /foafdotme.aspx HTTP/1.1

Host: me:8080

Authorization: Digest
username="pwilliams",realm="rapnt",nonce="+Upgraded+v171d455c90b2989903a515d
c157e97d1d16b3fc83abb4ca01acaa0f3071584c6f0eb4893538e8d85bf3cc5ed8faa9f32ccc
0227cc1c8dbdad",uri="/foafdotme.aspx",cnonce="+Upgraded+v176e10a14d267150d31
ae27082fcf57f372328da90443735407c45f1bf0cc95a0",nc=00000001,algorithm=MD5-se
ss,response="0a502730da3d65464ab71b2aece3b52c",qop="auth",charset=utf-8,hash
ed-dirs="service-name,channel-binding",service-name="HTTP/3SJCHK1.rapnt.com"
,channel-binding="00000000000000000000000000000000"

Accept-Language: en-US

Accept-Encoding: gzip, deflate

Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application,
application/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash,
application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword,
*/*

Connection: Keep-Alive

<cr><lf>

<No contents to display>

 

Note how the browser (upon foafme challenge) includes the service-name (and
hashes this value under the secret shared for realm\username between user,
Idp and SP. (It also shows how to reference channel binding tokens, assuming
the transport channel and policy was doing channel binding tokens).

 

Note that unlike the Host header (as seen by the user In the browser), the
service-name is the registered public name of the IP address (presumably
from secure DNS). IN security world, this is known as the audience name (who
I think Im talking to, as user).

 

 

 

 

 

SP to IDP, wanting a user-consented, SP-authorized identity assertion
(supported by a foaf card).

 

HTTP/1.1 302 Found

X-WebID-Status: notpresent

location:
https://foafssl.org:443/srv/idp?authreqissuer=http%3a%2f%2fme%3a8080%2ffoafd
otme.aspx

expires: -1

content-type: text/html; charset=utf-8

Authorization: Digest
username="pwilliams",realm="rapnt",nonce="+Upgraded+v171d455c90b2989903a515d
c157e97d1d16b3fc83abb4ca01acaa0f3071584c6f0eb4893538e8d85bf3cc5ed8faa9f32ccc
0227cc1c8dbdad",uri="/foafdotme.aspx",cnonce="+Upgraded+v176e10a14d267150d31
ae27082fcf57f372328da90443735407c45f1bf0cc95a0",nc=00000001,algorithm=MD5-se
ss,response="0a502730da3d65464ab71b2aece3b52c",qop="auth",charset=utf-8,hash
ed-dirs="service-name,channel-binding",service-name="HTTP/3SJCHK1.rapnt.com"
,channel-binding="00000000000000000000000000000000"

pragma: no-cache

cache-control: no-cache

 

Note that as SP I append the challenge's response from the user (see above)
to the 302 redirect, so the IDP can see the same hashed-response that the SP
saw on the first column of the protocol state table.

 

The point is. we could treat that header value as an "authorization token" -
where the SP is "authorizing" the IDP to speak for the user (and mint
assertions, as an agent of the user). Only an IDP with the shared secret for
realm/username can verify the authorization token, of course. The act of
sharing that value, with the effect that an IDP can now verify the SP's act
of authorization, would have been  the classical act of "delegation of
authority"  where such (offline) delegation enables the IDP to then process
authorization tokens at runtime., enacting the IDP's delegated powers for
the user who in realtime "consents" to a continuing relationship between SP
and IDP (on the topic of that user).

 

Note, the IDP gets a hashed copy of service-name (the user's intended
'audience', as seen from the browser's view of the internet). It also gets a
reference to the CBT shared between browser and SP.

 

Note that the authreqissuer value on the insecure GET header can be verified
- given data from the hashed authorization token (service-name + uri)

 

 

 

 

 IDP to SP

 

X-GET:
/foafdotme.aspx?webid=http%3A%2F%2Ffoaf.me%2Fpeter34%23me&ts=2010-02-23T09%3
A21%3A33-0800&sig=UGwPOn%2BVdhjDFwmZQOsn9CzCKgsspGwJf5tZ54yiRD8aGFYpnOHXH0Se
u89J%2FZwk6um1u8aKv2saNYqziWk9Mhd%2FO7hFTfbtIVbw7A2ezRgTtd%2FkFN2Bmk7%2BZouY
wMbnG6YYII6W5O5MiPR8yBhqiLKxg34vDDCE4VaIh9IQtcM%3D HTTP/1.1

Host: me:8080

Authorization: Digest
username="pwilliams",realm="rapnt",nonce="+Upgraded+v171d455c90b2989903a515d
c157e97d1dde31fc92abb4ca010fc207fd292b7a0777cf3bbe1cfe85e24e69eacd935a17dd8e
33c369e23f6657",uri="/foafdotme.aspx?webid=http%3A%2F%2Ffoaf.me%2Fpeter34%23
me&ts=2010-02-23T09%3A21%3A33-0800&sig=UGwPOn%2BVdhjDFwmZQOsn9CzCKgsspGwJf5t
Z54yiRD8aGFYpnOHXH0Seu89J%2FZwk6um1u8aKv2saNYqziWk9Mhd%2FO7hFTfbtIVbw7A2ezRg
Ttd%2FkFN2Bmk7%2BZouYwMbnG6YYII6W5O5MiPR8yBhqiLKxg34vDDCE4VaIh9IQtcM%3D",cno
nce="+Upgraded+v176e10a14d267150d31ae27082fcf57f31a12da28f12678e22e061129ea8
38b34",nc=00000001,algorithm=MD5-sess,response="88c804ed538ef49f342966b24480
998d",qop="auth",charset=utf-8,hashed-dirs="service-name,channel-binding",se
rvice-name="HTTP/3SJCHK1.rapnt.com",channel-binding="00000000000000000000000
000000000"

Accept-Language: en-US

Accept-Encoding: gzip, deflate

Accept: image/jpeg, image/gif, image/pjpeg, application/x-ms-application,
application/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash,
application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword,
*/*

Connection: Keep-Alive

<cr><lf>

<No contents to display>

 

 

Here we see the IDP's response to the SP (as relayed via the browser
intermediary)

 

Note, it includes the browser's latest digest header. 

 

Under the browser hashed state allowing for running macs  across multiple
HTTP req/resp interchanges (sequenced by nc value), one sees in the digest
header's uri the assertion from the IDP.

 

 

What I find interesting about the trace is its highlighting the role of the
browser, as channel intermediary. The browser is using SSL nonces when
talking to the IDP, and digest nonces when talking to the SP. 

 

Perhaps the  signature from the IDP should be hashed additionally over the
shared secret AND the values of service-name and challenge binding token.
The SP would thus know the IDP intends its assertion to be processed, but
only over an browser-SP channel identified using the  channel-binding-token.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20100225/ec5dac06/attachment-0001.htm 


More information about the foaf-protocols mailing list