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

[Yoav Nir <[e-mail]>]

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