Re: [Unbearable] ramifications of longer EKMs

[Anthony Nadalin <[e-mail]>]

I’m not sure the value of standardizing the tokbind-tls-term, not sure how much interoperability requirements there are here, maybe this should be an experimental until we figure out if there is a need and if so what are the requirements

From: Unbearable [mailto:[e-mail]] On Behalf Of Brian Campbell
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?