Lynn, your postings are pretty long-winding so they are hard to grip but the thing I considered "solved" was that a relying party would use a received login ticket to actually impersonate the client somewhere else. As SAML tickets are just time-stamped, a target (relying party) ID was added to thwart such uses. Regarding SSO authentication "leakage" I don't think I have much to say as there could be any numbers of _implementation_ flaws which I do not bother too much with when designing _protocols_. But I sure do when it comes to _products_ of course...
BTW, OBI Express as well as .PAY use a challenge-response- and Web Service Discovery-extended version of SAML, which eliminates ticket reply and dependency on synchronized server- clocks, as well as offering enhanced robustness versus URL- breakage and a better user-interface in case of relying party server-errors. Run it in "debug" mode to see all the gory stuff: https://buyer.x-obi.com/BigCars/Default I just saw the definition of SSO, but this is not the only one :-). Using an electronic ID-card and SSL client-authentication to multiple independent authorities (a scandinavian thing), a citizen must type the card PIN-code at each site but I would still call it SSO. But if you would like to call it something else I can probably live with that too... Semi-SSO? :-) Anders ----- Original Message ----- From: <[EMAIL PROTECTED]> To: "Anders Rundgren" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "'Internet-Payments'" <[EMAIL PROTECTED]> Sent: Sunday, July 14, 2002 21:57 Subject: Re: NEWS: 3D-Secure and Passport ... oh yes, the issue wasn't reply type of attack for impersonation .... the issue was leakage of valid authentication information thru some accidental or purposeful fault in the SSO infrastructure. lots of authentication protocols have reply resistance ... say in the case of a digital signature orientation for RADIUS .... the server transmits a time or other unique/random value. The user returns a message with the servers time/unique-value, userid ... signed with their digital signature. Say a traditional RADIUS implementation transmits "enter userid" (this can be in the clear as if it appears on a terminal .... or encapsulated in a PPP message; .... I've seen ISPs do their front-end radius with routing by sending down "enter userid" .... if it comes back with straight userid ... then it is assumbed to be something like telnet .... if it comes back with some prefix and some separation character preceding the userid .... then it may be assumbed to be PPP and the person is logging in to PPP ... then there are the ISPs that only allow PPP). In any case ... they might send down "7/14/02 13:00:00.xx enter userid" ... in which case that whole character string is included in a signed reply. One issue has to do with whether you have a "chatter" authentication protocol .... taking one or more exchanges of messages (where both parties could contributed to the contents as a replay prevention measure) ... or a "transaction" authentication protocol ... here everything is piggy-backed in a single message (aka like in x9.59 where only one party gets to contribute information for replay resistant purposes). Also, note the original wasn't whether the relying party couldn't tell whether it was an SSO or a direct authentication operation .... the issue was whether any leakage of (authentication) information from an SSO feature could result in a relying party authorizing a fraudulent operation.(regardless of whether the audit trail subsequently showed whether not things originated from SSO or not). I'm not sure which you were referring to as being "solved" .... some replay attack remediation by having a ticker marked for a specific target site (relying party) ... minimizing using previously issued tickets in some sort of replay (with the same or different relying party, also various forms of "insider attacks" also involve use of priviledged information for fraudulent transactions on the same site). [EMAIL PROTECTED] on 7/14/2002 11:27 am wrote: This is solved in SAML/Liberty/OBI Express etc. by marking the signed SSO "ticket" with a target site which eliminates impersonation.
