Token Binding over HTTP
RFC 8473

Note: This ballot was opened for revision 12 and is now closed.

(Ben Campbell) (was Discuss) Yes

Comment (2018-06-26 for -17)
No email
send info
Thanks for addressing my DISCUSS and substantive comments in pre-submission text. I did not check editorial comments.

I have one remaining (non-blocking) question on section 6: Are the “applications” from paragraph 3 the same as those from paragraph 2? It seems like paragraph 2 is talking more about local APIs (at least, I see that was mentioned in the text in version 17 but not in 18), but paragraph 3 uses an example of a signal from a server. (I can accept that the difference in control may be weak enough for web applications that the distinction does not matter.)

(Eric Rescorla) Yes

(Adam Roach) Yes

Comment (2018-05-07 for -14)
No email
send info
Thanks to everyone who worked on this document. I am balloting "Yes", but
still have a handful of comments, including several that I believe are
rather important.



>  Once a client and server have negotiated the Token Binding Protocol
>  with HTTP/1.1 or HTTP/2 (see [I-D.ietf-tokbind-protocol] and
>  [I-D.ietf-tokbind-negotiation])

Presuming this document is intended to cover use of TLS 1.3, I believe this
list needs to also include [I-D.ietf-tokbind-tls13].



>  When a client receives the Include-Referred-Token-Binding-ID header,
>  it includes the referred token binding even if both the Token
>  Provider and the Token Consumer fall under the same eTLD+1 and the
>  provided and referred token binding IDs are the same.  Note that the
>  referred token binding is sent only on the request resulting from the
>  redirect and not on any subsequent requests to the Token Provider.

I think this needs some clarification about handling of multiple redirections of
the transaction. E.g.: Token Consumer sends a 3xx to redirect the user to a
Token Provider (using, perhaps, an endpoint that is in the process of being
migrated), and then the Token Provider sends an additional 3xx to get the
client to the correct server.  Presumably, the inclusion of the referred token
binding should survive both redirections, but this text might be read as
preventing that.



>  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'm somewhat less sanguine about this than Alexey is: we've had 3xx-class
response codes registered as recently as three years ago, and I see no reason to
believe that the future won't hold additional development work on HTTP overall.

While I understand that 305 and 306 are deprecated, and the use of the header
field is nonsensical in 304 and, to a lesser degree, in 300, it seems that there
is no harm that results in any of these cases if *this* document doesn't
prohibit them.

Taken one at a time -- In the case of 300, the presence of the header field
would indicate that whichever option was followed by the user agent would
receive a copy of the token binding, which is as sensible a thing for a server
to ask for as 300 is in the first place.

In the case of 304, there is no server to receive the token binding, so no harm
could possible be induced.

For 305 and 306, to the extent that these are used any more (and they're not),
the request will arrive back at the same origin that sent the response; which,
again, causes no information to be divulged that should not be.

I would strongly recommend changing this to cover all codes in the 300-399
range, for the purpose of forward-compatibility with new redirection codes.



>  The TLS Extension for Token Binding Protocol Negotiation
>  [I-D.ietf-tokbind-negotiation]

Same comment as above regarding [I-D.ietf-tokbind-tls13].



>  | {EKMn}Ksm: | EKM for server "n", signed by private key of TBID    |
>  |            | "m", where "n" must represent server receiving the   |
>  |            | ETBMSG, if a conveyed TB's type is                   |
>  |            | provided_token_binding, then m = n, else if TB's     |
>  |            | type is referred_token_binding, then m != n. E.g.,   |
>  |            | see step 1b in diagram below.                        |

I was able, with some effort, to muddle through these words and (I think) figure
out the intention, but the construction is very difficult to follow. I think you
want to swap the comma after "ETBMSG" for a period.



>  [fetch-spec]
>             WhatWG, "Fetch", Living Standard ,
>             <>.

I share Alexey's concern about a normative reference to a living document. I
would like to suggest referencing a specific snapshot (e.g., commit hash), but
the specific referenced document makes this infeasible by means of an
aggressive red-box warning that effectively precludes doing so. I agree that
understanding the document is not a prerequisite to understanding or
implementing this one, and so agree that (for the time being) moving the
document to the informative reference section is advisable.

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

Alissa Cooper (was Discuss) No Objection

Comment (2018-07-11)
No email
send info
Thank you for addressing my DISCUSS.

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Comment (2018-05-10 for -15)
No email
send info
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

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

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

   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

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

(Suresh Krishnan) (was Yes) No Objection

Warren Kumari No Objection

Comment (2018-05-09 for -14)
No email
send info
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: , 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 ]

(Mirja Kühlewind) No Objection

Comment (2018-04-26 for -13)
No email
send info
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"
"the user agent should also
   discard Token Binding key pairs from such modes after the session is over"

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

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

Comment (2018-05-06 for -14)
No email
send info
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\

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

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

              WhatWG, "Fetch", Living Standard ,

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.

Alvaro Retana No Objection

Martin Vigoureux No Objection