Re: [Unbearable] (late, sorry) WGLC question on establishing the binding or not

On Tue, Dec 20, 2016 at 11:53 AM, Brian Campbell <bcampbell@pingidentity.com
> wrote:

> Thanks Andrei, some further discussion inline...
>
> On Mon, Dec 19, 2016 at 5:37 PM, Andrei Popov <Andrei.Popov@microsoft.com>
> wrote:
>
>> Ø  What should a server do if it receives an HTTP request without a
>> Sec-Token-Binding header on a TLS connection where token binding was
>> negotiated in the handshake?
>>
>> This means TB is not established with this client, see TBNEGO: “If the
>> client does not support the Token Binding protocol version selected by the
>> server, then the connection proceeds without Token Binding.”
>>
> I knew I'd seen something like that somewhere but couldn't conjure it up.
> Thanks for the pointer/reminder.
>
> But in defense of my own dumb question, that clearly covers the case where
> the client doesn't support the TB version that the server chose. But
> doesn't address the case where the client and server both indicate exactly
> the same versions during negotiation but no TB message is sent at the
> application layer.
>
>
> Ø  The case where the client and server both indicate exactly the same
>> versions during negotiation but no TokenBindingMessage is sent, for
>> example, seems like it should be a failure condition in the same vein as a
>> mismatch between the negotiated TokenBindingKeyParameters and in the the
>> TokenBindingKeyParameters of the  provided_token_binding TokenBindingID.
>>
>>
>>
>> We could special-case and say that if a server picks the exact TB version
>> a client sent, and the client’s subsequent request does not contain the TB
>> message, then the request MUST be rejected.
>>
>> However, in practice this feels like a failure case for no good reason.
>>
>>
>>
>> I think we have 4 possibilities:
>>
>> 1.       The client sends a TB message and a bound token => the server
>> verifies per TBPROTO.
>>
>> 2.       The client sends a TB message and no bound token => the server
>> verifies per TBPROTO.
>>
>> 3.       The client sends no TB message and a bound token => the server
>> rejects per TBPROTO.
>>
>> 4.       The client sends no TB message and no bound token => we could
>> require that this be rejected, if the server picked the client’s offered TB
>> version, but why create this failure case?
>>
> I'm not sure to be honest. That's why I'm asking. I don't fully understand
> the reasoning behind the requirements that exist between the handshake
> negotiation to checking the TB message. And the treatment of this case
> feels a bit inconsistent to me. If TB was not negotiated but a TB message
> is sent, reject the bindings. If TB was negotiated but the keyparams of the
> provided TB in the TB message doesn't match the negotiated keyparams,
> reject the bindings. When the TB version negotiated is identical but a TB
> message isn't sent, it would seem to suggest at least a misbehaving client.
> Maybe that's okay though. Even as I write it, it doesn't seem as
> inconsistent as it did in my mind before. But I'm asking to try and better
> understand the ramifications of the case. And the others. Are there
> implications beyond a misbehaving client in the case of a mismatch between
> the key parameters type that was negotiated and the key parameters type of
> the provided_token_binding in the TB message?
>
> Since in this case (client and server sent exact same TB version in nego)
a server knows that the client supports TB, so if the client doesn't send a
TB message, either some sort of weird attack is happening (which we
definitely don't want), or the client is buggy and negotiated TB when it
shouldn't have. I would suggest that when servers can detect buggy clients,
they be as strict as possible, which would mean TB should say that a server
SHOULD reject the TB message (and maybe close the connection) in this case.

>
>

>
>
>
>
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>
>