Hi Watson, > I want to make sure I understand the big picture of Token Binding and why it > works the way it does: in particular, it replaces the TLS client > authentication mechanism with a new one. Client authentication occurs outside the Token Binding protocol. Client authentication often results in a token being issued to the client by the server. The Token Binding protocol helps prevent the export and replay of this token.
> Token binding, as I understand it, involves the client generating a separate > certificate for each endpoint. But this certificate is not used in the normal > client authentication protocol. Instead it's used to sign a tls_unique > channel binding value. Token Binding uses a private/public key pair, without issuer, subject, or the numerous other attributes of a certificate. > This certificate isn't used for client authentication. Instead the server > filters out provided tokens using the token binding ID. Correct, the Token Binding Key is not used for client authentication. The server receiving a bound token can ensure that the sender of this token is in possession of the private Token Binding key. Which means that stealing a token is not sufficient to impersonate the client; the attacker would also have to extract the Token Binding key (which is supposed to be strongly protected, e.g. HW-bound). > ... the TLS implementation must fish out a signed value represented as > application data, or export the tls_unique binding to let the application > verify the binding. In my opinion, the TLS implementation should not be parsing application data, so export of the TLS_UNIQUE would IMHO be the right approach. This is, however, an implementation choice. > Also underspecified: referred token bindings The Token Binding Protocol I-D references a companion HTTPS Token Binding I-D (http://tools.ietf.org/html/draft-balfanz-https-token-binding-00), which talks about Federation use cases involving referred token bindings (please see section 3). > One part missing is specifying how to do RSA signatures. Is it PSS or PKCS > 1.5? I hope it's PSS. Yes, we'll need to address this in the next revision of the I-D. > However, what was wrong with OBC which reused existing TLS authentication > mechanisms? Is this something we can fix in TLS 1.3, or not? The Token Binding protocol is designed to function at the application layer and does not require any TLS changes (apart from fixing the triple-handshake vulnerability). This also means that, if needed, Token Binding could be made to work with security protocols other than TLS. Cheers, Andrei -----Original Message----- From: Uta [mailto:[email protected]] On Behalf Of Watson Ladd Sent: Wednesday, November 5, 2014 9:49 PM To: [email protected] Subject: [Uta] Understanding Token Binding Dear all, I want to make sure I understand the big picture of Token Binding and why it works the way it does: in particular, it replaces the TLS client authentication mechanism with a new one. Token binding, as I understand it, involves the client generating a separate certificate for each endpoint. But this certificate is not used in the normal client authentication protocol. Instead it's used to sign a tls_unique channel binding value. This certificate isn't used for client authentication. Instead the server filters out provided tokens using the token binding ID. This is different from what appears on Browser-Auth.net in two ways: the existing TLS client authentication mechanism isn't used, and the application layer/TLS interaction is new: the TLS implementation must fish out a signed value represented as application data, or export the tls_unique binding to let the application verify the binding. This is underspecified in the draft, which may be okay. (Also underspecified: referred token bindings) One part missing is specifying how to do RSA signatures. Is it PSS or PKCS 1.5? I hope it's PSS. I don't see any obvious security problems, and I can see some real deployment advantages: certificate privacy is preserved without renegotiation, and this works just like cookies for the web app developer, assuming there is enough work done by the web server. The UI advantage is not trivial. However, what was wrong with OBC which reused existing TLS authentication mechanisms? Is this something we can fix in TLS 1.3, or not? Sincerely, Watson Ladd _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
