-----Original Message----- From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Ilari Liusvaara Sent: Thursday, November 06, 2014 4:54 AM To: Watson Ladd Cc: uta@ietf.org Subject: Re: [Uta] Understanding Token Binding
On Wed, Nov 05, 2014 at 09:48:53PM -0800, Watson Ladd wrote: > > 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. It does not replace TLS client authentication. [TF] The answer of whether token binding replaces client authentication is more dependent on the role of the site. One of the objectives of token authentication protocols such as oauth and SAML is to abstract the authentication technology used with the identity provider from the relying party. An identity provider can use whatever authentication technology it chooses (including TLS client authentication) and then issues a token to the client which is then presented to the relying party. Hitherto, the only forms of tokens widely used were Bearer Tokens where possession of the token authenticates the user. Bearer tokens have no cryptographic binding between the token and the TLS session with the relying party so there is no cryptographic proof of the absence of a MITM. This draft allows holder of key tokens to be use used where there is cryptographic proof of the absence of a MITM. TLS client authentication is typically used by relying parties today in high assurance situations where they need strong MITM resistance became there was no alternative. This draft will allow relying parties to use a common apache to all authentication. Which will result in a more consistent user experience. > 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. I do see obvious security problems, but those problems already exist and this does not make those problems any worse. > However, what was wrong with OBC which reused existing TLS > authentication mechanisms? Is this something we can fix in TLS 1.3, or > not? IIRC, wanting to leave the existing TLS auth "field" to other purposes (I don't recall exact reasons, I think those were covered in some IETF meeting). Also, on use of ALPN: Stuff like this (combined with some other proposals) is exactly what I had in mind when I said that using ALPN for feature negotiation does not scale. -Ilari _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
