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

[Mohammad Jafari <mjafari@edmondsci.com>]

I second this.

> -----Original Message-----
> From: security-services@lists.oasis-open.org [mailto:security-
> services@lists.oasis-open.org] On Behalf Of Rainer Hoerbe
> Sent: Wednesday, July 03, 2013 2:47 PM
> To: Cantor, Scott
> Cc: OASIS SSTC
> Subject: Re: [security-services] question re saml-channel-binding-ext
> 
> 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.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that generates
> this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php