Re: [Unbearable] ramifications of longer EKMs

[Brian Campbell <[e-mail]>]

>
> Then what we have in option 4) is an IDP that supports a subset, rather
> than superset, of its RP’s TB key parameters. Which is a known type of
> misconfiguration that can happen between the IDP and RPs.
>

I wouldn't characterize it as misconfiguration but rather just different
domains supporting different sets of TB key params. And could happen even
if the sets were the same but prioritized differently.


> In any case, the TB key parameters negotiation would not be very robust if
> we say that a given signature scheme really requires a 64-byte EKM, but may
> also be used with a 32-byte EKM if the binding is Referred…


The negotiation is only for the TB key parameters for the provided binding.
I'm just suggesting that the EKM length choice for the whole TB message
could be tied to that.  It seemed like an okay simplification at what felt
like a low cost of signing over less data in the case of the referred TB
otherwise using a longer EKM.  You don't seem to see it as okay though and
there's yet to be any other opinions expressed on it. So I can let that
idea go.


On Thu, Feb 23, 2017 at 1:13 PM, Andrei Popov <[e-mail]>
wrote:

> Ø  Are you suggesting that tokbind-tls-term should have more than one
> model?
>
> Alternatively, we may end up with more than one tokbind-tls-termJ.
>
>
>
> Ø  Or that the “dumb/slim” TTRP model is most likely to be the desired
> model?
>
> It seems undesirable to prevent “dumb/slim” TTRPs, regardless of what tokbind-tls-term
> ends up saying.
>
>
>
> Ø  Yes, that's an accurate description of what I'd proposed as option 4)
>
> Then what we have in option 4) is an IDP that supports a subset, rather
> than superset, of its RP’s TB key parameters. Which is a known type of
> misconfiguration that can happen between the IDP and RPs.
>
> In any case, the TB key parameters negotiation would not be very robust if
> we say that a given signature scheme really requires a 64-byte EKM, but may
> also be used with a 32-byte EKM if the binding is Referred…
>
>
>
> *From:* Brian Campbell [mailto:[e-mail]]
> *Sent:* Thursday, February 23, 2017 5:18 AM
> *To:* Andrei Popov <[e-mail]>
> *Cc:* IETF Tokbind WG <[e-mail]>
> *Subject:* Re: [Unbearable] ramifications of longer EKMs
>
>
>
> Sure, this design would work. My point is that the tokbind-tls-term
> document cannot require one particular model of TB processing, because if
> this one model does not meet a data center’s requirements/architecture, the
> document is easily ignored. And it would be particularly undesirable to
> lose the “dumb/slim” TTRP model.
>
>
>
> Are you suggesting that tokbind-tls-term should have more than one model?
> Or that the “dumb/slim” TTRP model is most likely to be the desired model?
>
> Backend could pass the TB key parameters to the TTRP, or these could be
> part of the TTRP configuration. All the “dumb/slim” TTRP needs to know is
> TB protocol version and a prioritized list of TB key parameter IDs.
>
> Sure, that prioritized list of TB key parameter IDs is still the TTRP
> 'supporting' them in that it will use them in negotiation.
>
> The TB key parameter IDs the TTRP is willing/able to use will need to be
> the intersection of the supported TB key parameters of each of the
> backends. This might be cumbersome in some cases but is just the way it has
> to be for the “dumb/slim” TTRP model.
>
>
>
> Let’s say a client negotiates signature scheme A with the RP, and
> signature scheme A calls for a 64-byte EKM. Then the client negotiates a
> signature scheme B with the IDP, and signature scheme B calls for a 32-
> byte EKM. The client sends Provided and Referred bindings to this IDP,
> and the Referred binding uses signature scheme A in combination with an EKM
> length 32 (which does not agree with the signature scheme definition). Is
> this what you’re proposing as option 4), or did I get it wrong?
>
> Yes, that's an accurate description of what I'd proposed as option 4)
>
>
>
>
>
> On Wed, Feb 22, 2017 at 6:03 PM, Andrei Popov <[e-mail]>
> wrote:
>
> Correction inlineJ.
>
>
>
> *From:* Unbearable [mailto:[e-mail]] *On Behalf Of *Andrei
> Popov
> *Sent:* Wednesday, February 22, 2017 4:39 PM
> *To:* Brian Campbell <[e-mail]>
> *Cc:* IETF Tokbind WG <[e-mail]>
> *Subject:* Re: [Unbearable] ramifications of longer EKMs
>
>
>
> Ø  I'm not sure I follow this?
>
> Ø  I'd think, if this kind of model was used, a TTRP could do all the TB
> validation work and just expose the TB ID(s) to the backend where they can
> bind to whatever tokens/cookies they are issuing.
>
> Sure, this design would work. My point is that the tokbind-tls-term
> document cannot require one particular model of TB processing, because if
> this one model does not meet a data center’s requirements/architecture, the
> document is easily ignored. And it would be particularly undesirable to
> lose the “dumb/slim” TTRP model.
>
> Ø  The backend apps would only be able to use TB key parameters that the
> TTRP supports but that's pretty much true of the other model too - the TTRP
> still is the one negotiating.
>
> Backend could pass the TB key parameters to the TTRP, or these could be
> part of the TTRP configuration. All the “dumb/slim” TTRP needs to know is
> TB protocol version and a prioritized list of TB key parameter IDs.
>
> Ø  It only defeats the purpose of having per-signature-scheme EKM lengths
> in the case of a refereed TB using a longer EKM than the provided.
>
> Let’s say a client negotiates signature scheme A with the RP, and
> signature scheme A calls for a 64-byte EKM. Then the client negotiates a
> signature scheme B with the IDP, and signature scheme B calls for a 32-
> byte EKM. The client sends Provided and Referred bindings to this IDP,
> and the Referred binding uses signature scheme A in combination with an EKM
> length 32 (which does not agree with the signature scheme definition). Is
> this what you’re proposing as option 4), or did I get it wrong?
>
>
>