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

[Dirk Balfanz <[e-mail]>]

Hi Benjamin,

thanks for the feedback. Most of it is addressed in the new draft (
https://tools.ietf.org/html/draft-ietf-tokbind-https-16). See below
(inline) for details.

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

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

Addressed in the new draft.


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

We couldn't come up with examples where we would have more than one, and
wanted to write the spec as narrow as possible for now.


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

Addressed in new draft.


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

See previous answers from Nick et al. It's a new EKM.


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

Addressed in new draft.


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

Correct - and that’s covered in the more general version of this
consideration in draft-ietf-tokbind-protocol. Here we point out that the
federation mechanism in particular focuses on the client<->Token Consumer
connection.



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

Addressed in new draft.

Thanks again for your thoughtful comments!

Dirk.