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

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 6 Nov 2013 18:29:24 +0200

> 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

---

From: Julian Reschke <[email-masked]>
Date: Wed, 06 Nov 2013 17:57:08 -0800

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

Please stop referencing RFC 2616. HTTPbis is past IETF LC.

> ...

Furthermore, the challenge does not conform to the grammar defined in 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p7-auth-24.html#challenge.and.response> 
(nor 
<http://greenbytes.de/tech/webdav/rfc2617.html#access.authentication.framework>).

Best regards, Julian

---

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

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

Thanks for the detailed review!

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

> probably isn't the same thing).

I'll include an eref to

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

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

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

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

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

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

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

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

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

> >    Cookies  The traditional HTTP cookie approach to session binding;

Yup.

> >       the session(s) (similar to cookies, but without all the associated

Yup.

> Bearer token, for the one server.

Yup.

> This isn't a bearer token.

Right.

> - Multiple URIs not supported: 400

OK.

> fun when you get PUT with content-length of 47,215,243,334 (yes, I have

Good point.

> These edge cases are what makes MACing payload hard (perhaps too hard

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

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

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

> 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

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

> (there being authentication servers and other servers).

Exactly.

> Won't this really cause problems with bearer tokens?

Yes.  I'll make a note of it.

> How (i.e. what parameter name?)

Oops, I'll add that.

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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Nov 2013 00:52:09 -0800

> Yeah, when I wrote that text I'd no idea what the schedule for HTTP/2.0

Exactly how is HTTP/2.0 relevant here?

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 08 Nov 2013 18:35:07 +0900

> Exactly how is HTTP/2.0 relevant here?

Lots of people outside the HTTPbis WG seem to confuse the HTTP/1.1 
update and HTTP/2.0.

Regards,   Martin.