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

[Rainer Hoerbe <rainer@hoerbe.at>]

This is a useful insight. It wold be a pity to keep it buried past page 1 of a search engine. I propose to discuss the options for adding this text to some document or wik at the next call.

- Rainer

>> 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.