Token Binding over HTTP
draft-ietf-tokbind-https-18

Thank you for a well written and easily understood document - it is unusual to be able to cover like this in such an easily understood manner.

I'd suggest looking at Tim Chown's excellent OpsDir review: https://datatracker.ietf.org/doc/review-ietf-tokbind-https-14-opsdir-lc-chown-2018-05-08/ , especially the bit about a "diagram of the relationship between the various elements in a federated scenario"

Some text about what to do with a (hypothetical) status code 309 might be helpful - this says it MUST be ignored; does this mean a -bis document if / when it is released? Could the document describe how to decide if future 30x codes are acceptible? Or it is clear that there will never be >308?.

[ Edit: You probably want RFC 8174 instead of RFC 2119 ]

I have mostly nits and questions for this document, but see further down, there might be some minor bugs.

In Section 2:

2.  The Sec-Token-Binding HTTP Request Header Field

     Sec-Token-Binding = EncodedTokenBindingMessage

   The header field name is Sec-Token-Binding and its single value,
   EncodedTokenBindingMessage, is a base64url encoding of a single
   TokenBindingMessage, as defined in [I-D.ietf-tokbind-protocol], using
   the URL- and filename-safe character set described in Section 5 of
   [RFC4648], with all trailing padding characters '=' omitted and
   without the inclusion of any line breaks, whitespace, or other
   additional characters.

   For example:

  Sec-Token-Binding: AIkAAgBBQFzK4_bhAqLDwRQxqJWte33d7hZ0hZWHwk-miKPg4E\
                     9fcgs7gBPoz-9RfuDfN9WCw6keHEw1ZPQMGs9CxpuHm-YAQM_j\
                     aOwwej6a-cQBGU7CJpUHOvXG4VvjNq8jDsvta9Y8_bPEPj25Gg\
                     mKiPjhJEtZA6mJ_9SNifLvVBTi7fR9wSAAAA

I think you should explain here that \ at the end of each line denotes line continuation and that it is not actually a part of the value.


Later in the same section:

   The TokenBindingMessage MAY also contain exactly one TokenBinding
   structure with TokenBindingType of referred_token_binding, as
   specified in Section 5.3.  In addition to the latter, or rather than
   the latter, the TokenBindingMessage MAY contain other TokenBinding
   structures.

This sentence made me wonder whether it is Ok for a compliant implementation to only process the first 2 TokenBinding structures and ignore the rest?

   This is use case-specific, and such use cases are
   outside the scope of this specification.



At the top of page 11 (Section 5.3):

   This header field has only meaning if the HTTP status code is 301,
   302, 303, 307 or 308, and MUST be ignored by the client for any other
   status codes.

I just want to point out to other reviewers that this list is non extensible
and will not work with any future 3XX status codes (however unlikely they are).
I am still trying to decide how I feel about that ;-).


In 7.3, next to the last paragraph:

   If A has a pre-existing relationship with S (perhaps has an account
   on S), it now appears to the server S as if A is connecting to it,
   even though it is really C.  (If the server S does not simply use
   Token Binding IDs to identify clients, but also uses bound
   authentication cookies, then A would also have to trick C into
   sending one of A's cookies to S, which it can do through a variety of

C's cookies?

   means - inserting cookies through Javascript APIs, setting cookies
   through related-domain attacks, etc.)  In other words, A tricked C
   into logging into A's account on S.  This could lead to a loss of

Not sure whether A is correct here either.

   privacy for C, since A presumably has some other way to also access
   the account, and can thus indirectly observe A's behavior (for

"C's behaviour"? A can always know A's behaviour.

   example, if S has a feature that lets account holders see their
   activity history on S).


11.1.  Normative References

   [fetch-spec]
              WhatWG, "Fetch", Living Standard ,
              <https://fetch.spec.whatwg.org/>.

I am looking forward to having a discussion within IESG to having a normative reference to a non stable document ;-). However, in this case I am not convinced that the reference needs to be normative, as it is only used to explain why "Sec-" header field prefix was used.

Thank you for addressing my DISCUSS.

I agree with Alexey about clarifying that backslashes are only for readability.

I'm curious why Section 2 limits to at most one referred_token_binding.


Section 2

   A TokenBindingMessage is validated by the server as described in
   Section 4.2.  ("Server Processing Rules") of
   [I-D.ietf-tokbind-protocol].

Nit: no period after "4.2".

   [...] If validation fails and a Token Binding
   is rejected, any associated bound tokens MUST also be rejected by the
   server.

I repeat my remark about "associated" from tokbind-protocol.


Section 2.1

It seems a little unusual to see "Applications other than Web
browsers MAY [...]", though I do not object.


Section 3

To be clear, this means that the EKM used is the one from before
the renegotiation, corresponding in the somewhat-common use case of
renegotiation for optional client authentication to the
unauthenticated-client state, right?


Section 5.3

   As illustrated in Section 5.5, when a client receives this header
   field, it should take the TokenBindingID of the provided TokenBinding
   from the referrer and create a referred TokenBinding with it to
   include in the TokenBindingMessage on the redirect request.  In other
   words, the Token Binding message in the redirect request to the Token
   Provider now includes one provided binding and one referred binding,
   the latter constructed from the binding between the client and the
   Token Consumer.

I'm not really an HTTP expert, but is "redirect request" the right
term (as opposed to, say, "redirected request" or "post-redirect
request")?

   The TokenBindingMessage SHOULD contain a TokenBinding with
   TokenBindingType referred_token_binding.

At this point we may have lost track of what "The
TokenBindingMessage" refers to -- some explicit scope (the message
sent to the Token Provider after following the redirect) could be
helpful.


Section 7.1

   The goal of the Federated Token Binding mechanisms is to prevent
   attackers from exporting and replaying tokens used in protocols
   between the client and Token Consumer, [...]

Do we actually need to limit the scope to Token Consumer?  The Token
Provider may also issue tokens that we want to protect, after all.


Section 7.2

Do we need to repeat the normative statements already made in
[TBPROTO]?  Maybe we can just say that [TBPROTO] requires these
things to be used, to protect against [TRIPLE-HS].

Maybe use normative SHOULDs in sec 8.2:
"HTTPS clients such as Web user agents should therefore provide a user
   interface for discarding Token Binding key pairs"
and 
"the user agent should also
   discard Token Binding key pairs from such modes after the session is over"

Nit:
1) In abstract: s/This Internet-Draft/This document/
2) Maybe provide a refernce for SAML