OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Web-browser Binding Vulnerabilities + "Cures"


True. This was one of the drawbacks we accepted. Indeed, integrated services
from different providers are not possible... We are using a combination of
Username/Passwords stored in our Portal servel together with SSL client
authentication for achieving the rest. 
But this is not really satisfactory; therefore, we would like to participate
in the S2ML standardizatio for getting a both secure and usable solution. 

Sachar

-----Original Message-----
From: Orchard, David [mailto:dorchard@jamcracker.com]
Sent: Dienstag, 16. Januar 2001 21:25
To: Paulus, Sachar; anders.rundgren@telia.com;
security-services@lists.oasis-open.org
Subject: RE: Web-browser Binding Vulnerabilities + "Cures"


And how do you do cross domain cookies so that domain A can send info to
Domain B?  We haven't found many browsers that support this lack of cookie
privacy.

Dave Orchard
XML Architect
Jamcracker Inc.,    14000 Homestead Dr., Sunnyvale, CA 94086
p: 408.864.5118     f: 408.725.4310

Named to Red Herring's list of 100 Most Important Companies:
www.redherring.com/mag/issue79/herring100/jamcracker.html


> -----Original Message-----
> From: Paulus, Sachar [mailto:sachar.paulus@sap.com]
> Sent: Monday, January 15, 2001 11:25 PM
> To: 'Anders Rundgren'; S2ML
> Subject: RE: Web-browser Binding Vulnerabilities + "Cures"
> 
> 
> That is what SAP experienced too. Therefore, our SSO solution uses
> (digitally signed user info in) cookies....
> 
> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com]
> Sent: Freitag, 12. Januar 2001 13:30
> To: S2ML
> Subject: Web-browser Binding Vulnerabilities + "Cures"
> 
> 
> The following does IMO apply to many schemes including S2ML:
> 
> The use of references to assertions etc. in the form of URLs which are
> usually given to an
> authenticated client by a credential issuer using an HTTP 301 
> (redirect) has
> at least one
> problem: A credential consumer cannot easily determine if it 
> is the original
> client that
> handed over the URL containing such a reference. A simple 
> browser URL window
> snooper program could "snatch" such tokens and transport them 
> to somebody
> else.
> In spite of secure https transports.
> 
> The only "cures" I can think of are putting the critical data 
> in a cookie
> [sorry :-( ], which requires a
> fairly deep browser hack [open source would make it trivial 
> though :-) ] to
> snatch, and IP bindings.
> The latter is not universal due to proxies (all clients on 
> the same proxy
> looks like one IP for the credential
> consumer) etc. but it does improve the binding a bit.
> 
> Note: I don't insist that the current binding scheme should 
> be changed, this
> is simply "information".
> 
> Anders
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC