Re: [Unbearable] ramifications of longer EKMs

[Andrei Popov <[e-mail]>]

Ø  Are you suggesting that tokbind-tls-term should have more than one model?
Alternatively, we may end up with more than one tokbind-tls-term☺.


Ø  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]<mailto:[e-mail]>> wrote:
Correction inline☺.

From: Unbearable [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Andrei Popov
Sent: Wednesday, February 22, 2017 4:39 PM
To: Brian Campbell <[e-mail]<mailto:[e-mail]>>
Cc: IETF Tokbind WG <[e-mail]<mailto:[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?