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 Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
