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

[Nico Williams <[e-mail]>]

On Wed, Nov 06, 2013 at 06:29:24PM +0200, Ilari Liusvaara wrote:

Thanks for the detailed review!

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

Yeah, when I wrote that text I'd no idea what the schedule for HTTP/2.0
was going to be.

> OAuth2 [RFC6749]. IIRC, in most common modes, OAuth1 isn't bearer token.

Thanks.

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

I'll include an eref to

https://developer.mozilla.org/en-US/Persona/Protocol_Overview

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

https://tools.ietf.org/html/draft-ietf-abfab-aaa-saml

"A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and
Confirmation Methods for SAML"

I'll add the reference.

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

The thing I had in mind here was the Android credential manager API.
That API basically has the app get a token that the app then sends in
some HTTP request.  No allowance is made for multiple round trips and
such things.

My workaround for such constraints is to have the CM API run any token
exchanges that are longer than .5 round trips and have the app send the
last token, say.

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

Yes, good point.  Normally there's no assumption that there must be a
1-1 connection in, connection out mapping in a proxy, but HTTP/Negotiate
ruins that.  In practice it's not common to have to use Negotiate past a
proxy -- this may be a reason why!

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

Right, so they can't be used with this.

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

I reworked one or the other somewhere in the middle and had pressing
deadlines, so this slipped.  Thanks for catching this!

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

X and Z are the same party though.

I'm thinking that "client wants replay protection" is a bad way to put
it.  It'd be better to say that the client wants no TLS and wants to
(must? ideally must, yeah) use MACs for session binding, then replay
protection is required.

I'll make this change.

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

Yup.

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

Yup.

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

Yup.

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

Right.

> As for error codes, I think:
> 
> - Bad sesion URI: 401
> - Multiple URIs not supported: 400

OK.

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

Good point.

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

Yeah.  Doing session crypto at the HTTP layer is very difficult, more
difficult than in other non-ordered datagram like protocols (like, say,
ONC RPC).

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

No, but just MACing the TLS channel binding is good enough.

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

They wouldn't be sent to clients, but they'd be useful in the clustered
server case!  Login to one server, then all the others can fetch the
session keys:

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

Hmmm, I guess we could have multiple sub-resources so that partial
authorization (e.g., observe authenticated ID and session start and
expiration times, but not session keys) could be expressed that way, but
that seems overly complicated.  If you get nothing, you weren't
authorized, if you get some things and not others, you were partially
authorized.  If you get everything, you were fully authorized.

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

Exactly.

> >    [[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?

Yes.  I'll make a note of it.

> >    The client and the server must each contribute 128-bit nonces.
> 
> How (i.e. what parameter name?)

Oops, I'll add that.

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

Not if session state is distributed.  Being able to use HTTP in the
server's side of the world for this is a win (as opposed to proprietary,
non-interoperable, vendor lock-in protocols).

Nico
--