Subject: [Unbearable] New and Updated I-Ds

From: Andrei Popov <[email-masked]>
Date: Fri, 29 May 2015 23:54:21 +0000

In Dallas we agreed to define a new TLS extension for Token Binding key parameters negotiation, instead of using ALPN.

Today I've submitted TLS Extension for Token Binding Protocol Negotiation  I-D: https://datatracker.ietf.org/doc/draft-popov-tokbind-negotiation/

I have also updated the Token Binding Protocol I-D: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-01
The updated version has the following changes:

-          Removed ALPN negotiation text;

-          Added a Security Considerations sub-section discussing Token Binding key sharing between applications;

-          Minor edits, nits, etc.

Comments are very welcome!

Cheers,

Andrei

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 30 May 2015 09:33:56 +0300

> Comments are very welcome!

Some comments (might have been asked earlier, or not):

[NEGOTIATION]

1)

[TBNEGO] and [HTTPSTB] (?) don't seem to be linked, like for example
[I-D.ietf-tls-session-hash] is.

2)

"3.  Token Binding Protocol Message"

"This message MUST be sent in the client's first application protocol
message."

"The server MUST terminate the connection if the use of the Token
Binding protocol has been successfully negotiated via [TBNEGO] within
the TLS handshake, but the client's first application message does
not contain the Token Binding message."

What if first application protocol message is for something that is not
valid for binding, but subsequent messages may be?

This can happen in some situations with HTTP/2. Some eTLDs (in the cookie
sense) do respond to HTTP requests, and non-eTLDs might be coalesced to
those connections.

[TBNEGO]

3)

rsa2048_pkcs1.5_sha256(0) ... IIRC, that algorithm is known to be
broken. Is it for backward compatiblity? The security considerations
do not say anything about this, or how to use it safely (most likely
via giving reference).

4)

"3.  Token Binding Negotiation Server Hello Extension"

"'key_parameters_list' contains exactly one Token Binding key
parameters identifier selected by the server from the client's list."

Is there reason for this restriction to just one algorithm? Why it
is not "what server can verify" list (i.e. capability adverstiment)?

Already established token bindings may have various algorithms, and
if multiple token bindings are subsequently coalesced into same
connection (may happen with HTTP/2), one may get multiple types of
provided_token_binding's.

[HTTPSB]

5)

"3.5.  Negotiated Key Parameters"

"The client MUST use the signature algorithm negotiated with the
Token Consumer in the referred_token_binding TokenBinding of the
TokenBindingMessage, even if that signature algorithm is different
from the one negotiated with the origin that the header is sent to."

This means that the message may be signed by algorithm that the
server doesn't understand and thus can't verify. Does there need to
be security considerations for this?

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Sun, 31 May 2015 05:23:15 +0000

Hi Ilari,

Thanks for reviewing the I-Ds.

1) Will fix with the next update.

2) It may be a good idea to remove this requirement from [TBNEGO]. E.g. [HTTPSTB] specifies exactly how TB messages are encapsulated in HTTP.

3) If you're referring to the use of PKCS, this is due to hardware limitations: most (if not all) TPMs only support PKCS. And storing TB keys in a TPM is probably a security win, even if it involves PKCS.

4) This may have advantages, but it also increases complexity. Let's see what others think.

5) This would only happen if an RP negotiated TB key parameters unsupported by the RP's designated IDP, which is arguably a misconfiguration. In this case, the IDP would simply not bind the token. Here's what [HTTPSTB] says on this subject:
"  Token Providers SHOULD support all the SignatureAndHashAlgorithms
   specified in the Token Binding Protocol [TBPROTO].  If a token
   provider does not support the SignatureAndHashAlgorithm specified in
   the referred_token_binding TokenBinding in the TokenBindingMessage,
   it MUST issue an unbound token."

BTW, if we did #4 above (negotiated multiple TB key parameter sets), then the client would know all the key parameters it has in common with the IDP, and would not send unsupported token bindings to the IDP when the RP is misconfigured. This might be more elegant.

Cheers,

Andrei

-----Original Message-----
From: Ilari Liusvaara [mailto:[email-masked]] 
Sent: Friday, May 29, 2015 11:34 PM
To: Andrei Popov
Cc: [email-masked]
Subject: Re: [Unbearable] New and Updated I-Ds

On Fri, May 29, 2015 at 11:54:21PM +0000, Andrei Popov wrote:
> Today I've submitted TLS Extension for Token Binding Protocol 
> Negotiation  I-D: 
> https://datatracker.ietf.org/doc/draft-popov-tokbind-negotiation/
> 
> I have also updated the Token Binding Protocol I-D: 
> https://tools.ietf.org/html/draft-ietf-tokbind-protocol-01

[NEGOTIATION]

1)

[TBNEGO] and [HTTPSTB] (?) don't seem to be linked, like for example [I-D.ietf-tls-session-hash] is.

2)

"This message MUST be sent in the client's first application protocol message."

"The server MUST terminate the connection if the use of the Token Binding protocol has been successfully negotiated via [TBNEGO] within the TLS handshake, but the client's first application message does not contain the Token Binding message."

What if first application protocol message is for something that is not valid for binding, but subsequent messages may be?

This can happen in some situations with HTTP/2. Some eTLDs (in the cookie
sense) do respond to HTTP requests, and non-eTLDs might be coalesced to those connections.

[TBNEGO]

3)

rsa2048_pkcs1.5_sha256(0) ... IIRC, that algorithm is known to be broken. Is it for backward compatiblity? The security considerations do not say anything about this, or how to use it safely (most likely via giving reference).

4)

"'key_parameters_list' contains exactly one Token Binding key parameters identifier selected by the server from the client's list."

Is there reason for this restriction to just one algorithm? Why it is not "what server can verify" list (i.e. capability adverstiment)?

Already established token bindings may have various algorithms, and if multiple token bindings are subsequently coalesced into same connection (may happen with HTTP/2), one may get multiple types of provided_token_binding's.

[HTTPSB]

5)

"The client MUST use the signature algorithm negotiated with the Token Consumer in the referred_token_binding TokenBinding of the TokenBindingMessage, even if that signature algorithm is different from the one negotiated with the origin that the header is sent to."

This means that the message may be signed by algorithm that the server doesn't understand and thus can't verify. Does there need to be security considerations for this?

-Ilari