RE: AuthnAssn

["Mishra, Prateek" <pmishra@netegrity.com>]

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