[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Fwd: one time use saml artifact -- from Bob Blakley
- From: "George Robert Blakley III"<George_Robert_Blakley_III/Tivoli_Systems@us.ibm.com>
- To: pmishra@netegrity.com
- Date: Tue, 17 Jul 2001 09:32:25 -0500
Prateek, Jeff, Eve, Prateek notes in his message that my replies to Simon don't appear on the bindings list. Actually, I think it's worse than that -- I think my messages are getting bounced from all the lists because of my new email address, which isn't on the OASIS list of approved submitter IDs. I presume this will be a problem for evites also. Who do I talk to to get put back in action? --bob Bob Blakley (email: blakley@us.tivoli.com phone: +1 512 436 1564) Chief Scientist, Security, Tivoli Systems, Inc. "Mishra, Prateek" <pmishra@netegrity.com> on 07/16/2001 05:07:59 PM To: "'Simon Godik'" <sgodik@crosslogix.com>, "'blakley@tivoli.com'" <blakley@tivoli.com> cc: "'security-bindings@lists.oasis-open.org'" <security-bindings@lists.oasis-open.org> Subject: RE: one time use saml artifact I just wanted to make sure I had captured the issues associated with this thread. (1) This discussion addresses Section 3.1 (Web Browser Profile) from bindings draft 0.4 (2) The issue identified here is that the AuthenticationQuery should have some means to query against a generic notion of SAML artifact (e.g., the elementary SAML artifact described in bindings draft 0.4 or others) vs. the current proposal which supports only query against assertion ID. (3) The AP in the web browser profile creates (1) an AuthenticationAssertion (2) a "one-time use" SAML artifact used by the RP to retrieve the assertion from the AP. The profile will (does not as yet) RECOMMEND that the (1) AuthenticationAssertion be scoped using the AudienceRestriction as narrowly as possible (2) AuthenticationAssertion should have the shortest possible lifetime consistent with the time taken by the RP to retrieve it from the AP. Finally, we also assume that both RP and AP have their own independent sessioning mechanisms which may cookie-based, URL-based whatever. The point being that the AuthenticationAssertion is not meant a substitute for state management at either party. It only provides a kind of short-lived "visa" for the user to pass from one party to another without having to sign on a second time. Given all of this, I am not sure whether we need to discuss whether the AuthenticationAssertion issued by the AP is re-usable or not. That is a private matter for the AP; if the AP can guarantee that the SAML artifact is a "one-time use" artifact then we are done. Bob: one the weird aspects of this thread is that none of your responses to Simon actually appear on the bindings list. - prateek -----Original Message----- From: Simon Godik [mailto:sgodik@crosslogix.com] Sent: Thursday, July 12, 2001 11:16 AM To: 'George_Robert_Blakley_III@tivoli.com' Cc: 'security-bindings@lists.oasis-open.org' Subject: RE: one time use saml artifact Bob, On your last point about sessions, I assume that assertion is generated and assosiated with a session. In case of web browser profile redirect, I think that session is established with S and there is no session with D yet. Here is another point that is not clear to me. I assume that random number included in the artifact and assertion_id are different (ff3 doc mentioned assertion id in the artifact, but later on it was replaced with random number). If it is true how are we supposed to issue saml query in step 4 of browser profile? (fig 1, pg 11, ftf3-bindings.doc) We can query assertion by id or by subject but we do not have either. Simon -----Original Message----- From: George_Robert_Blakley_III@tivoli.com [ mailto:George_Robert_Blakley_III@tivoli.com <mailto:George_Robert_Blakley_III@tivoli.com> ] Sent: Wednesday, July 11, 2001 10:24 AM To: sgodik@crosslogix.com Cc: 'George_Robert_Blakley_III@tivoli.com'; 'security-bindings@lists.oasis-open.org' Subject: RE: one time use saml artifact Simon, >I'm addressing one-time-use of saml artifact: If saml artifact is generated and passed to >the browser it should be good for one-time use only. I presume that authentication >assertion is generated at the time of user authentication. Authentication assertion is >stored in the issuing server S. SAML artifact is generated some time later (within assertion >validity interval). Assertion reference embeds this saml artifact and additional info >such as assertion id (which is not in the artifact) and is communicated to the destination >site D: assertion(ass_id) <-- assertion_ref(ass_id, saml_art(random_number)) >Now assertion reference is decoupled from assertion. After use D is supposed to discard >assertion_ref, and you can not reuse saml artifact any more to get to the assertion. So, to paraphrase, this is a one-time-use reference to a persistent assertion. >Other implementaions of one-time-use saml-artifact are definetely possible, but if there >is no redirection they will put more burden on the issuing server. (imo). > >-- Stale-assertion >If assertion is stale it will be discarded by the issuing party S. If D is still able >to pull stale assertion it should detect that it has expired. I don't understand why anything new is necessary to achieve this; the base assertion structure already contains an issue-instant and not-valid-before and not-valid-after times. The assertion artifact doesn't need to have any mechanism for making the assertion expire. Nor is expiration of the artifact itself much of a concern if it's truly a one-use item. >-- Man-in-the-middle. >I assume that all communication is over SSL, so UA<->S, UA<->D, and S<->D authenticate >each other. So D is a trusted party and is supposed to discard assertion_ref after one >use. To paraphrase again, I think what you're saying here is that dealing with man-in-the-middle attacks is not a goal. >-- Assertion reuse. >I do not address assertion reuse and it is not prevented. But you do want to prevent re-use of the reference, right? >>-- why do we want to create a >>-- one-time reference which can be used to retrieve a many-time assertion? > >I assume that assertion is generated when authentication takes place, not when http >transfer to another protected site is requested. Every time you visit dispatch page >whithin assertion validity interval the only thing you have to do is generate new >assertion reference. I'm afraid I'm still confused. Perhaps what you're saying is that you are worried about servers which don't preserve state across invocations, and you don't want to force the client to re-send the assertion every time he visits the page. Presumably this case would be useful mostly when the server retains assertions but doesn't have any notion of a session to tie the assertion to the client's repeated visits. In this case the client gets a new assertion reference and sends it to the server, which can use it to figure out which of the assertions it already has cached should be used for the new request. If this is the scenario, then the assertion reference is essentially being used as a session id, except that it varies every time you visit the server (kind of like the constantly changing values your garage door opener remote control uses each time you open the door). But if this is the goal, I don't understand why we have this mechanism AND a session mechanism. Is this indeed the scenario, or am I still confused? Thanks, --bob Bob Blakley (email: blakley@us.tivoli.com phone: +1 512 436 1564) Chief Scientist, Security, Tivoli Systems, Inc. ------------------------------------------------------------------ To unsubscribe from this elist send a message with the single word "unsubscribe" in the body to: security-bindings-request@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC