Subject: [Unbearable] Review by Michael Jones of draft-ietf-tokbind-protocol-13

From: Mike Jones <[email-masked]>
Date: Wed, 15 Mar 2017 01:05:55 +0000

I read draft-ietf-tokbind-protocol-13 cover-to-cover today and identified these issues with the text.

MOST IMPORTANT - FULLY DEFINE REJECTION SEMANTICS:  There are lots of places in the draft where it says things like "the server rejects the binding" (e.g., Section 2, paragraph 3).  What the text does not say is something along the lines of "the server rejects the binding and discards all data sent along with the rejected Token Binding message".  People may be assuming that discarding the data associated with a failed token binding is obvious, but I think it needs to be explicitly stated.  One could easily read the current text and think that "rejects the binding" just means ignoring the Token Binding message and continuing processing and delivering TLS the data as if the Token Binding extension were not used.

Likewise, in places where it says things like "any associated bound tokens MUST also be rejected by the server" it should probably be said that the application must discard the entire contents of any communications using a bound security token not matching the token binding.  "Rejecting the token" doesn't seem like a thorough enough description of the intent.

Please look at all the occurrences of "reject" in the draft and consider beefing up the rejection descriptions.

ACKNOLWEDGE THAT HASHES OF TBIDs CAN BE USED:  In the sentence in the Introduction "When issuing a security token to a client that supports Token Binding, a server includes the client's Token Binding ID in the token", please add "(or a cryptographic hash of it)" after "the client's Token Binding ID".  Note that both OAuth Token Binding https://tools.ietf.org/html/draft-ietf-oauth-token-binding-02 and OpenID Connect Token Binding http://openid.net/specs/openid-connect-token-bound-authentication-1_0.html use a hash of the Token Binding ID in security tokens, rather than the Token Binding ID itself, for space reasons.  This common technique should be explicitly allowed.

NITS:

Change "Paypal" to "PayPal".
Change "associeted" to "associated".

Other than that, looks good!

                                                                -- Mike

---

From: Andrei Popov <[email-masked]>
Date: Wed, 15 Mar 2017 01:20:05 +0000

Hi Mike,

Thanks for your comments.

?  MOST IMPORTANT - FULLY DEFINE REJECTION SEMANTICS:

?  Likewise, in places where it says things like "any associated bound tokens MUST also be rejected by the server" it should probably be said that the application must discard the entire contents of any communications using a bound security token not matching the token binding

I think the language in Section 4.2 is better:
"If a Token Binding is rejected, any associated bound tokens MUST also
   be rejected by the server.  The effect of this is application-
   specific, e.g. failing requests, a requirement for the client to re-
   authenticate and present a different token, or connection
   termination."
In the Token Binding protocol spec, we can't define one way of handling rejected tokens for all possible applications.

?  ACKNOLWEDGE THAT HASHES OF TBIDs CAN BE USED:
Per Section 5, we are explicitly allowing any method of binding tokens:

"The specific method of generating bound

   security tokens is application-defined and beyond the scope of this

   document."
I don't mind mentioning the hash of the TB ID in section 5, which is dedicated to this question. It is probably better to keep the Introduction concise.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, March 14, 2017 6:06 PM
To: [email-masked]
Subject: [Unbearable] Review by Michael Jones of draft-ietf-tokbind-protocol-13

NITS:

                                                                -- Mike

---

From: Mike Jones <[email-masked]>
Date: Wed, 15 Mar 2017 21:32:24 +0000

Thinking about this a bit more, the statement that I think is missing about rejection semantics is that rejecting mismatching token bound communications (and unbound communications that should have been bound) is *always* an application-level action - not something done by the TLS or Token Binding layers.  I think that this should be said somewhere in the introduction.  Then it will be clear what party is doing the rejecting when phrases like "rejects the binding" are used.

I'm fine adding the hashed TBID language in Section 5.

One other nit I ran into:  Add a comma after "Otherwise" in "Otherwise the Token Binding is successfully established".

                                                                -- Mike

From: Andrei Popov
Sent: Tuesday, March 14, 2017 6:20 PM
To: Mike Jones <[email-masked]>; [email-masked]
Subject: RE: Review by Michael Jones of draft-ietf-tokbind-protocol-13

Hi Mike,

   document."

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Tuesday, March 14, 2017 6:06 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Unbearable] Review by Michael Jones of draft-ietf-tokbind-protocol-13

NITS:

                                                                -- Mike