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

From: Yoav Nir <[email-masked]>
Date: Tue, 5 Nov 2013 08:13:51 +0000

Hi

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.

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).

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.

Section 1.2 outlines the protocol, and section 1.3 discusses API constraints. The interesting stuff (the protocol) begins in section 3, about a third of the way through the document.

I find section 3 clear, although I would have rather had the examples close by rather than all the way down in section 7. Nit: section 3.1 refers to the ABNF in the previous section, but the ABNF has moved to section 3.1.2.

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.

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.

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?

Section 8 looks good.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Fri, 8 Nov 2013 00:23:06 -0600

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!

> 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:
>
> 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
--