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