Re: [Unbearable] ramifications of longer EKMs

[Brian Campbell <[e-mail]>]

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