Fwd: one time use saml artifact -- from Bob Blakley

[Jeff Hodges <jhodges@oblix.com>]

---

• 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

---