On Thu, Jun 9, 2011 at 7:03 PM, Robert Sayre <say...@gmail.com> wrote: > On Wed, Jun 8, 2011 at 11:30 PM, Adam Barth <i...@adambarth.com> wrote: >> >> Maybe I'm not completely clear how a mechanism with a server-supplied >> nonce would work. How do you avoid having to make a round-trip to the >> server for every request? > > Maybe I'm confused about the expected flow here. It's not clear to me > where the initial credentials are coming from, or how much the server > knows about the MAC credentials. The specification has multiple > servers (resource servers and authorization servers) in play > sometimes, but other times it refers to "the server". Also, section 4 > makes it seem like quite a lot coordination is expected between the > authorization server and the resource server. This might all be > obvious to someone who lives and breathes OAuth, but I think it is > worth clarifying. > > Here's what I was thinking: The example in section 1.1 includes an > initial 401 response. If that initial 401 response is expected, then > the server can include some domain-wide data in the WWW-Authenticate > header, and refresh it at will, even in successful responses. > > GET /resource/1 HTTP/1.1 > Host: example.com > > ... > > HTTP/1.1 401 Unauthorized > WWW-Authenticate: MAC opaque="abc123abc123" > > ... > > GET /resource/1 HTTP/1.1 > Host: example.com > Authorization: MAC ... opaque="abc123abc123" > > ... > > HTTP/1.1 200 OK > WWW-Authenticate: MAC opaque="def456def456" > > ... > > GET /resource/2 HTTP/1.1 > Host: example.com > Authorization: MAC ... opaque="def456def456" > > > That opaque string can be anything the server wants, and it can change > with every request, or less often. Adding this field could help > servers even if it doesn't , in cases where a misbehaving client is > getting the client nonce wrong. > > If the goal of the scheme is to avoid encountering a 401 even for the > initial request, then I suggest updating the example in section 1.1.
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. The normal flow in the browser setting does not use 401 and is as follows: 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. >>> That makes sense. I'm having trouble reconciling the Design >>> Constraints section (1.1) with the section on Entropy of MAC Keys >>> (7.5). How long are these keys supposed to be around in practice? >> >> I'd recommend using a MAC key of roughly the same length as the block >> size of the MAC. For example, for hmac-sha-1, I'd use 20 bytes. > > I was asking about how often keys might expire. Section 7.5 says > something like 2 weeks. What can we reasonably expect from the use > cases we have in mind? Yes. Their lifetime should be commensurate with session cookies. (This mechanism really just adds a little more security to session cookies.) Adam _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
