RE: one time use saml artifact

[Simon Godik <sgodik@crosslogix.com>]

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