RE: [security-services] question re saml-channel-binding-ext

["Cantor, Scott" <cantor.2@osu.edu>]

> The problem of the abstract formulation that is required to cover general use
> cases is that it hides the intended short-term purpose. Both the Introduction
> (1) and Overview (2.2) are written from a HOW perspective, not addressing
> the WHY.

I wasn't trying to justify why I did it, and there's always room elsewhere to try to explain why other people might.

> My understanding was that HoK-Borwser-SSO allows you to bind the
> assertion the the TLS channel. I see that binding the subject to a certificate is
> different to binding a secure channel, but on the use case level both look like
> competing approaches.

The server certificate is not involved at all with HoK-SSO, while it's essentially the entire basis of CB in practical terms (the tls-unique CB type is basically impossible to support with the major stacks today, so you're left with the one based on the server cert).

The HoK case gives the client no assurance it's communicating with a legitimate server unless it does the trust evaluation itself. The CB case punts the process over to the IdP and substitutes the IdP verifying a SAML signature for the client verifying a TLS cert. This derives from my belief that TLS on the web is both a lost cause, and actively dangerous in practice as a tool for security protocols (like, say, OAuth).

I could have put such text in, yes (minus the gratuitious though IMHO fully accurate dig at OAuth).

Also note that HoK-SSO is itself based on client TLS, which is itself generally unworkable today due to the way TLS gets done. Even if you offload TLS, you *can* configure a SAML SP to supply that cert in its CB data and still make all that work. You can't do tls-unique, but you can't do that anyway.

-- Scott