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: AuthnAssn


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

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.

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