Subject: [Unbearable] Benjamin Kaduk's No Objection on draft-ietf-tokbind-https-15: (with COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 May 2018 06:51:58 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-tokbind-https-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

---

From: Nick Harper <[email-masked]>
Date: Thu, 10 May 2018 07:18:20 -0700

On Thu, May 10, 2018 at 6:51 AM, Benjamin Kaduk <[email-masked]> wrote:

> For Token Binding messages appearing after renegotiation, the EKM used is
the one computed after renegotiation (different from the one before
renegotiation). If we used the same EKM for the whole connection, then
draft-ietf-tokbind-protocol wouldn't have to require the application
mapping (in this case, draft-ietf-tokbind-https) to specify the interaction
with renegotiation, and draft-ietf-tokbind-https wouldn't need to impose
any restrictions on when renegotiation can occur.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 May 2018 16:53:49 -0500

> any restrictions on when renegotiation can occur.

I'm imagining a case like

<TLS handshake with only the server authenticating, token binding negotiated>

GET /some/protected/resource HTTP/1.1
Sec-Token-Binding: <blob>

<Server initiates renegotiation to authenticate client>

HTTP/1.1 200 OK
[data]

>From the server's perspective, the token binding was successfully
negotiated and the presented binding validates.  The EKM needed to
do so is from before the renegotiation.

I don't think this is problematic per se; I just want to make sure
we're on the same page.

-Benjamin

---

From: Andrei Popov <[email-masked]>
Date: Thu, 10 May 2018 22:17:18 +0000

> From the server's perspective, the token binding was successfully negotiated and the presented binding validates.  The EKM needed to do so is from before the renegotiation.
Correct. In your example, the HTTP GET was encrypted using keys derived from the master secret of the original TLS session. The TB message contained therein signs the EKM derived from the master secret of the original TLS session.

An HTTP GET following the renegotiation will be encrypted using keys derived from the master secret of the renegotiated TLS session. Any TB contained therein will sign the EKM derived from the master secret of the renegotiated TLS session.

Cheers,

Andrei

-----Original Message-----
From: Unbearable <[email-masked]> On Behalf Of Benjamin Kaduk
Sent: Thursday, May 10, 2018 2:54 PM
To: Nick Harper <[email-masked]>
Cc: John Bradley <[email-masked]>; IETF Tokbind WG <[email-masked]>; The IESG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Unbearable] Benjamin Kaduk's No Objection on draft-ietf-tokbind-https-15: (with COMMENT)

On Thu, May 10, 2018 at 07:18:20AM -0700, Nick Harper wrote:
> > To be clear, this means that the EKM used is the one from before the 
> > renegotiation, corresponding in the somewhat-common use case of 
> mapping (in this case, draft-ietf-tokbind-https) to specify the 
> interaction with renegotiation, and draft-ietf-tokbind-https wouldn't 
> need to impose any restrictions on when renegotiation can occur.

HTTP/1.1 200 OK
[data]

>From the server's perspective, the token binding was successfully
negotiated and the presented binding validates.  The EKM needed to do so is from before the renegotiation.

I don't think this is problematic per se; I just want to make sure we're on the same page.

-Benjamin

_______________________________________________
Unbearable mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Funbearable&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cb764a5ba6a62423a7d1e08d5b6c08bf8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636615860455141303&sdata=767ecoDYOj3vD3xsuqmH1uYh7NKrf5%2BPyC2lqmXLfT8%3D&reserved=0