[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] question re saml-channel-binding-ext
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]