On Thu, Jun 9, 2011 at 10:25 PM, Adam Barth <i...@adambarth.com> wrote:
>
> What happens when the client wants to send more than one request at a
> time to the server? For example, when loading a web page, browsers
> often open multiple sockets to send multiple request in parallel to
> improve performance.
In my example, I changed it with each request just to show how it
might work if the server changed it with every request. FWIW, section
3.2.3 of RFC2617 covers exactly this tradeoff.
>
> The normal flow in the browser setting does not use 401 and is as follows:
OK, but there's still an initial challenge that fulfills the same
role. I wasn't clear on the coordination present between the first and
second requests below. Now I am.
>
> Client ----> Server (HTTPS)
> GET /login
>
> Server ----> Client (HTTPS)
> 200 OK
> Set-Cookie: SID=3048jhseofhoesdfdf; MAC-Key=OIneoiunf;
> MAC-Algorithm=hmac-sha-1; Path=/
>
> Client ----> Server (HTTPS)
> POST /login
> Authorization: MAC id="SID", nonce="2:ion308r32"; mac="ow8fnwnougview4t0="
> username=sayrer&password=tacotacotaco
>
> The session is now established. Commonly, we'd expect the session to
> contain a mix of HTTP and HTTPS requests. Each request comes with a
> new nonce and a mac, etc.
>
Perhaps some confusion has been caused by my use of the word "nonce".
I have been using it as Digest does, where the server nonce is only
sent with an authentication challenge, and then reused by the client
until the server decides it is stale. So, the client can use the same
server nonce many times. In the flow above, a server nonce would be
sent in the first response, and then reused by the client.
A client nonce is still worth including (just a random string), but I
still think giving the server a way to determine the age of the
credentials without relying on the client would be more reliable.
Let's call my proposed addition the "opaque" parameter. The client
sends it back unchanged, just like the id. In the example below, the
Client ----> Server (HTTPS)
GET /login
Server ----> Client (HTTPS)
200 OK
Set-Cookie: SID=3048jhseofhoesdfdf; MAC-Key=OIneoiunf;
MAC-Algorithm=hmac-sha-1; Path=/;
Opaque='MTMwNzcyNjExMjofeosXZh7sTFT1mBGkKAw6AoOOQQ=='
Client ----> Server (HTTPS)
POST /login
Authorization: MAC id="SID", nonce="2:ion308r32"; mac="ow8fnwnougview4t0=";
Opaque='MTMwNzcyNjExMjofeosXZh7sTFT1mBGkKAw6AoOOQQ=='
username=sayrer&password=tacotacotaco
Below, I included a little python session showing a simple example of
how this might work. It allows the server to check the age of the
credentials, check that it generated the age that was given, and
/then/ hit the authentication database.
This is just one use of an opaque field that servers might want to
try. I suppose this data could get stuffed into the SID too. Is that
the idea?
- Rob
>>> import hashlib
>>> import base64
>>> import time
>>> private_key = "foobar"
>>> timestamp = str(int(time.time()))
>>> timestamp
'1307726112'
>>> m = hashlib.sha1()
>>> m.update(timestamp + private_key)
>>> base64.b64encode(timestamp + ":" + m.digest())
'MTMwNzcyNjExMjofeosXZh7sTFT1mBGkKAw6AoOOQQ=='
>>> # our outgoing opaque value ^^
...
>>> # incoming request
...
>>> incoming_opaque =
>>> base64.b64decode('MTMwNzcyNjExMjofeosXZh7sTFT1mBGkKAw6AoOOQQ==')
>>> incoming_opaque
'1307726112:\x1fz\x8b\x17f\x1e\xecLT\xf5\x98\x11\xa4(\x0c:\x02\x83\x8eA'
>>> timestamp = int(incoming_opaque[:incoming_opaque.find(':')])
>>> timestamp
1307726112
>>> # now check the hash
...
>>> incoming_hash = incoming_opaque[incoming_opaque.find(':') + 1:]
>>> m = hashlib.sha1()
>>> m.update(str(timestamp) + private_key)
>>> m.digest() == incoming_hash
True
>>> # now look at the MAC
...
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
