Re: [http-auth] First review of the Rest-Auth draft

[Nico Williams <[e-mail]>]

On Tue, Nov 05, 2013 at 08:13:51AM +0000, Yoav Nir wrote:
> I have reviewed draft-ietf-httpauth-rest-auth-01. This is done with no
> hats - it is not a SecDir review, nor a chair or shepherd review. My
> comments have no more or less weight than those of any other
> participant.

Thanks for your review!

> The proposal moves the authentication outside of the HTTP layer, and into the application layer. The benefits of this are:
>  1. Works through unmodified routers and proxies (including TLS proxies)
>  2. Creates a resource that represents the session, and can be deleted for a logout.
>  3. Can re-use many existing mechanisms.
>  4. RESTful, so it supports clustering.
>  5. Easily implemented in application interfaces such as CGI, FastCGI, and others.
>  
> It should be noted that all this information is in the Abstract, and
> most of it should probably be moved to the Introduction (section 1).

Hmm, yeah, the abstract needs to be short.  It's also the place to put
the attention grabbers, if you can make them short enough.

> Section 1.1 has a longish review of the state of authentication on the
> web. We could probably do without it, but as long as it's confined to
> that one section, we can leave it at that, but discussion of
> alternative methods also fills up section 2.

Sure.  I'd love to get rid of that.

> I find section 3 clear, although I would have rather had the examples
> close by rather than all the way down in section 7. [...]

Ah, good point.

> I would have liked to see examples for and within each sub-section of
> section 3, because those help me make sense of things better than
> ABNF.

I agree.  I'll make this change.

> Section 6 describes how the server side of Rest-Auth can be done with
> a single server, multiple server or an HTTP "router". For the
> multi-server case, it is assumed that they will have some shared media
> on which to store the resource representing the session. This is
> indicated by the three words (many servers) "sharing server state". I
> think that this requirement should be stated more explicitly. For a
> static site, a cluster could consist of several replicated servers.
> Not so for a site implementing Rest-Auth.

A static site might not honor session logout, for example, and encode
all session state in an encrypted cookie.  Or it might use expiring,
renewable session state cookes + memcached to record logouts.

Session logout, incidentally, can be implemented with a probabilistic
data structure (false positives -> re-login, but this can be automatic
on the client side).

> Section 7 finally has the example to make this all fall into place.
> However, looking at figure 3, there is one thing that's still missing:
> How does the client get the resource. See the first transaction in
> figure 3 looks like this:
>
>   C->S: GET /some-resources HTTP/1.1
>         Host: A.example
>  
>   S->C: HTTP/1.1 401 Unauthorized
>         WWW-Authenticate: RA-SA-SCRAM-SHA-1 \
>                           http://A.example/rest-sa-scram \ 
>                           s=session-ID,MIC r=no
>         WWW-ChannelBinding-Types: tls-server-end-point
>                 
> And the last one looks like this:
>   S->C: HTTP/1.1 200
>         Content-Type: application/octet-stream
>         Content-Length: nnn
>  
>         v=rmF9pqV8S7suAoZWja4dJRkFsKQ=
>          Content-Type: application/octet-stream
>     
> So the authentication process created some SCRAM-specific parameter
> "v", and a resource called "/restauth-9d0af5f680d4ff46". When the
> client tries again to fetch "/some-resources", what data should be
> passed in the Authorization header?

The session URI / state cookie and binding.

Nico
--