[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: AuthnAssn
-----Original Message----- From: Flinn, Don [mailto:DFlinn@hitachisoftware.com] Sent: Saturday, July 07, 2001 10:59 PM To: 'security-services@lists.oasis-open.org' Subject: AuthnAssn Please excuse a question from the new guy. If my concern has been discussed and resolved please point me at the pertinent documents. In my understanding of SAML, if a client accesses a target using an AuthnAssn obtained from a SALM Authentication Service, the AuthnAssn is used as proof of the client's authenticated identity to the target, e.g. the PDP. Therefore, if I steal the AuthnAssn then I can be that client. (This theft can be done in a number of ways.) In order to defeat this attack the client must prove to the target that it has a secret known only to the client. The AuthnAssn doesn't do this. The AuthnAssn is authentication evidence that has been authenticated and signed by a trusted third party, but nowhere do I see unequivocal proof tying the AuthnAssn to the client that can be verified by the target. Therefore, I assert that the client hasn't authenticated itself to the target. [Prateek Mishra] Briefly, the Assertion structure includes an "authenticator" or "holder of key" element whose purpose is to ensure a cryptographic connection between assertions and a subject (or the payload provided by a subject). There is no model of assertion use called out in the core assertions draft, this is the subject of the bindings and security considerations drafts. At FTF #3 Prateek brought up this situation with a browser. It appears to me that this is a general case not just a browser. The solution that Prateek proposed, using a one-time ticket, seems to defeat single sign-on. Also, if I, the man in the middle, intercept that message and don't let it through, I can use the one-time ticket and be accepted as the original client. [Prateek Mishra] I would urge you to study the web browser profile more carefully. The profile requires use of HTTPS (therefore your MITM would need to break SSL). The web browser profile definitely supports inter-site SSO in a controlled way; I am unable to understand why you feel there is any contradiction between SSO and a "one-use" ticket. In the web browser profile, one interaction with the AP generates a one-use ticket for sign on to a RP. The recent bindings con-call has also gone over this material in some detail and you may want to consult the recently published minutes. - prateek Trivial point - I think that Assr is a clearer contraction of Assertion than Assn -:) Don
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC