[http-auth] Quick review of draft-ietf-httpauth-rest-auth-01

[Ilari Liusvaara <[e-mail]>]

> 1.  Introduction
> 
>    We propose a pattern for HTTP [RFC2616] [TODO: add reference to
>    HTTP/2.0 as well?] authentication mechanisms that, by being
>    "RESTful", obtains these goals naturally.

Reference for HTTP/2.0 would be draft-ietf-httpbis-http2

> 1.1.  Motivation
> 
>    o  various bearer token mechanisms [TODO: add examples, such as
>       OAuth];

OAuth2 [RFC6749]. IIRC, in most common modes, OAuth1 isn't bearer token.
 
>    o  various non-bearer token mechanisms which are not generalized or
>       generalizable to a larger universe of authentication mechanisms
>       [TODO: add examples, such as BrowserID].

It seems that locating reference for BrowserID isn't trivial, as most
refereces seem to go to Mozilla Persona (which is based on BrowserID but
probably isn't the same thing).

>    Enterprises and educational settings also often have RADIUS
>    [RFC2865], often used via EAP [RFC3748].  These could be supported by
>    the generic security mechanism based on EAP, RADIUS, and SAML being
>    developed by the ABFAB WG [TODO: add references!].  These mechanisms
>    in particular will be difficult to use via Negotiate because they
>    involve multiple round trips, which Negotiate supports half-
>    heartedly; see Section 2.1.

draft-ietf-abfab-gss-eap
draft-ietf-abfab-aaa-saml

Don't see anything about RADIUS.
 
> 1.3.  API-Imposed Constraints
> 
>    A typical constraining characteristic might be that an API assumes
>    the use of GET with tokens encoded into the URI or into a header, or
>    that the API makes no room for the use of headers in authentication
>    message exchanges.
> 
>    One way to work around such constraints may be to provide various
>    options in RESTauth.  Another might be to use OAuth 1.0 [RFC5849] or
>    2.0 [RFC6749] as a bridge: the API would use this framework under the
>    covers then obtain OAuth credentials from the server that the
>    application can then use in any way that the API's form allows for.

I can't parse this. How does OAuth come in here?
 
> 2.1.  In-band HTTP Authentication
 
>    Additionally, Negotiate can require multiple round trips but provides
>    no mechanism for explicitly associating a given GSS-API security
>    context token with a given GSS-API security context: it has to be
>    assumed that all messages are serialized and only one multi-round
>    trip security context establishment can be ongoing in any given HTTP
>    connection.

... And this causes major problems if there are proxies...

> 3.  Protocol
> 
>    And for applications that may not use TLS/HTTPS:
> 
>    o  the use of session keys as an option for integrity protection when
>       TLS is not used (a light-weight security mode); see
>       [I-D.williams-websec-session-continue-proto].

Non-bearer-token mechanisms tend to do replay protection...

> 3.1.  Negotiable Parameters
> 
> 3.1.2.  WWW-Authenticate Header Value Prefix Syntax
> 
>    For a DIGEST-like mechanism it might look like "WWW-Authenticate: RA-
>    Digest-SHA-256 tls-server-end-point session-ID no HE4SgWGrd/
>    3+O7t16HqusA==".  For example, the mechname for the Kerberos V5 GSS-
>    API mechanism might be "gss-krb5", and a WWW-Authenticate header
>    value for it might look like "WWW-Authenticate: RA-gss-krb5
>    http://foo.example/restauth-login tls-server-end-point channel-bound-
>    session-ID r=no".

These examples don't look to conform to the grammar given (missing r=, s=,
etc...)

> 3.1.3.  WWW-ChannelBinding-Types Header
> 
>    A new header is added by which servers MUST indicate which channel
>    binding [RFC5056] types -if any- they support for RESTauth
>    authentication; if the server does not support channel binding then
>    this header MUST be absent.  The header is named WWW-ChannelBinding-
>    Types.  Its values are channel binding types from the channel binding
>    type registry, such as the TLS channel binding types [RFC5929].

I think the wording is bit odd...
 
> 3.1.4.  WWW-ChannelBinding-Type Header
> 
>    A new header is added by which clients MUST indicate what channel
>    binding type they used when POSTing RESTauth authentication messages,
>    if any; if the client did not use channel binding then this header
>    MUST be absent.  If the mechanism used has its own method for
>    indicating the use of channel binding, then this header MAY be
>    ommitted.  The header is named WWW-ChannelBinding-Type.  Its value is
>    a channel binding type from the channel binding type registry
>    [RFC5929].

Same....
 
> 3.1.6.  WWW-ReplayProtection Header
> 
>    A new header is added by which clients MUST indicate whether they
>    desire replay protection when POSTing RESTauth authentication
>    messages.  The header is named WWW-SessionBinding-Type.  Its value is
>    "yes" or "no" (defaults to "no" if absent) as shown in Figure 1.
> 
>    Replay protection is to be used only when TLS [RFC5246] is not used,
>    and only if a session binding type of "MAC" is also requested.

Can this result in inconsistencies with session binding types?

I.e. X says do Y, but Z says not to do Y.

> 3.3.  Session Binding Types: Cookie, Channel Bound Session URI, and MAC
> 
>    A notion of session binding type is added for binding HTTP requests
>    to specific RESTauth login sessions.  Three types are provided:
> 
>    Cookies  The traditional HTTP cookie approach to session binding;

Bearer token.
 
>    Session URI  HTTP requests carry a WWW-Session-URI header identifying
>       the session(s) (similar to cookies, but without all the associated
>       baggage);

Bearer token.

>    Channel Bound Session URI  Like Session URI, but may only be used in
>       HTTPS connections with the same channel bindings.  (This implies
>       use of the 'tls-server-end-point' channel binding type.)

Bearer token, for the one server.

>    MAC  HTTP requests carry a WWW-Session-URI header identifying the
>       session(s) and a WWW-Session-MAC header that carries a MAC or MACs
>       binding the session URI(s) to the request.

This isn't a bearer token.

> 3.3.1.  The New WWW-Session-URI Header
> 
>    A new HTTP header is added called WWW-Session-URI whose values
>    consist of session URIs.  At least one session URI MUST be included.
>    Each session URI is an absoluteURI.  Session URIs MUST NOT have
>    unescaped commas (',') embedded in them.  Servers MAY fail to
>    implement support for multiple session URIs being referenced by a
>    single request, in which case they MUST answer with error code <TBD>.
>    Servers MUST validate the session URI before processing the request;
>    if the session URI is invalid the server MUST respond with a 401 (or
>    TBD?) status code.
> 
>    Note that referencing multiple session URIs is permitted, but this
>    may not be meaningful for the application, thus the server MAY reject
>    this (TODO: specify a status code for this?).

Maybe, reword the first paragraph, split it in two and remove the second
paragraph. Right now it seems bit redundant to me.

As for error codes, I think:

- Bad sesion URI: 401
- Multiple URIs not supported: 400
 
> 3.3.2.  The New WWW-Session-MAC Header
> 
>    [[anchor3: Describe the header, its values, algorithm agility, and
>    what the MAC is to be taken over.  Note too that this cannot apply to
>    request contents as we have to consider chunking, and besides, a MAC
>    of contents really has to go as a trailer, not a header.]]

Also, if contents are to be MAC'd, one could also want streaming MAC (have
fun when you get PUT with content-length of 47,215,243,334 (yes, I have
seen one in wild)).

These edge cases are what makes MACing payload hard (perhaps too hard
in general case).

>    [[anchor4: We may want to remove this anyways and leave it for a
>    session continuation spec.  Or we may want to require the use of
>    HTTPS.]]

HTTPs won't really solve all the problems this header would.

> 3.3.3.  To MAC or not to MAC; A MAC Trailer??
> 
>    [[anchor5: ...  This is only needed for RESTauth *without* TLS, which
>    will probably not be the common mode of use for RESTauth... unless we
>    can produce a MAC trailer extension for HTTP/2.0, in which case this
>    may well become a common mode of RESTauth usage.]]

Yeah, here TLS does protect things so that payload MACing is not needed.
 
> 4.  Representation of Authenticated Session Resources
> 
>    It will generally be useful to be able to GET a session resource to
>    obtain information about the authenticated user.  A GET on a session
>    resource which is not fully established SHOULD return an empty body.
> 
>    session_key_MAC_req  Session key for MACs in requests.
> 
>    session_key_MAC_resp  Session key for MACs in responses.

These seem bit eh, sensitive to include.
> 
>    The server MAY exclude any part of this when the entity requesting a
>    session resource is the session's user.  The server MUST exclude (or
>    respond with 401) all of the session resource's representation when
>    the entity requesting it is not authenticated or authorized to see
>    it.  The server SHOULD exclude locally-determined authorization_data
>    and/or user_id information when the entity requesting the resource is
>    the session's user.

If it is not authorized to see it, shouldn't the error be 403 then?
> 
> 
> 5.  Session URI Origin and Scope
> 
>    [[anchor9: TODO: Add a notion of session origin and scope.  The
>    origin can probably be determined naturally from the session URI.
>    The scope should be set by the server.  Perhaps we can also have the
>    scope reflected in the session URI's representation, which would
>    allow the scope of a session to change over time.]]

On some contexts, allowing URL to be valid across servers could be handy
(there being authentication servers and other servers).

>    [[anchor10: Clearly, using a session from one origin at another will
>    require a channel binding verification operation.  This will have to
>    be added.]]

Won't this really cause problems with bearer tokens?

> 7.2.1.  RESTauth Mechanism Names for SSHv2 Userauth Methods
> 
>    For hash agility reasons the hash function name is part of the SSHv2
>    RESTauth mechanism name.  To avoid "multi-level negotiation" the
>    SSHv2 userauth method name is also part of the RESTauth mechanism
>    name.
> 
>    The RESTauth mechanism name form for SSHv2 userauth methods, then,
>    is: ssh-<SSHv2-userauth-method-name>-<hash-function-name>.
> 
>    The following RESTauth mechanisms are defined here:
> 
>    o  ssh-publickey-SHA-256
> 
>    o  ssh-hostbased-SHA-256
> 
> 7.2.2.  Nonces
> 
>    The client and the server must each contribute 128-bit nonces.

How (i.e. what parameter name?)

>    This entire document deals with security considerations.  [Add more,
>    like about channel binding, same-origin-like constraints on the login
>    and session absolute URIs', ...]
> 
>    Note that though servers can GET/HEAD session resources, they MUST
>    only do it for session resources for recognized origins.  See
>    Section 8.1.2.

If it is for recognized origin, isn't the server likely to have other
knowledge of those sessions (or an other way to obtain such knowledge).


-Ilari