RE: one time use saml artifact

[Hal Lockhart <hal.lockhart@entegrity.com>]

I have found the discussion on one time use SAML artifacts very confusing. 

It is my understanding that it has been proposed that SAML generate an
Artifact to be returned via cookie or encoded URL to the browser. This
Artifact will act as a bearer instrument equivalent to an Authentication
Assertion. Obviously, the Artifact must contain sufficient information to
identify the corresponding Assertion.

It has further been proposed that this Artifact have the property of being
one time or single use. That is to say, whenever the browser presents the
Artifact it will be given a new one with the same properties, but a
different value.

If this is not correct, I hope somebody will be kind enough to tell me.

I would like to agree with those suggesting that one time use should NOT be
a requirement for the Artifact.

First, let me note that no requirement or use case specifically mandates the
use of a one time Artifact as opposed to a static value.

Second, as been pointed out by Bob, the one time Artifact provides only a
very weak incremental security benefit. Anyone who intercepts or constructs
one can use it immediately. The legitimate user may not make another request
for some time. Further, in the absence of dynamic sessions, the last
Artifact is good until the Authentication Assertion expires, which could
well be some hours.

In order to achieve this modest security benefit, I believe it will be
necessary to implement a complex, error prone protocol which will have
significant, negative performance implications. Although I have not seen
such a protocol proposed in any of the relevant documents or emails, I have
arrived at this conclusion by reasoning from first principles.

In order to to implement a one time artifact over a group of web servers in
a single signon environment, I believe it would be necessary for the various
servers to communicate with each other over a back channel. Although they
could use some previously agreed scheme for rekeying the Artifact value, it
will still be necessary for the server contacted by the browser to inform
all the others that a new value must be computed. In my experience such a
protocol will be difficult to keep synchronised in the face of various
transient and permanent error conditions.

It addition, as the number of sites increases, the performance impact will
be severe. If servers must request an update (pull) the latency of every web
hit will greatly increase. Conversly, if the occurance of each hit is
propagated, broadcast fashion (push), an enormous amount of back channel
bandwidth will be required.

Perhaps my logic is in error. I would be pleased to see an alternative
proposal for implementing a one time artifact over a number of web servers.

----------------------------------------------------------------

If it is accepted that a one time Artifact is not required, I would like to
repeat a proposal I made earlier this year. The currently proposed Artifact
scheme encrypts several values relating to the subject. This would permit
the retrieval of the corresponding Authentication Assertion.

In general the Artifact is subject to two attacks. It may be intercepted and
it may be guessed or derived from other information.

The use of SSL is sufficient to prevent interception. Therefore, the key
property is that it not be guessed or derived.

I propose a scheme based on a cryptographic hash function. First, a unique,
random value of 100-300 bits is generated. This value is used as the
Artifact value. Then a cryptographic hash of this value is calculated, using
for example, SHA1. The hash value is used as an identifier of the Assertion.
For example, it could be combined with a DNS name and used as the Assertion
Id. Or it could be stored in another field in the Assertion. The point is
that it be possible to retreive the Assertion using this value.

Any information that might be desired in the Artifact is instead stored in
the Authentication Assertion.

Because the value of the Artifact is random, it cannot be guessed. Because
the hash is one way, the Artifact can not be derived from the Assertion.

There are a number of advantages to this scheme.

1. Any scheme using encryption will either be subject to eventual exposure
or will have to implement some form of manual or online key management
protocol. A hash completely eliminates this, with no loss in security.

2. If the Artifact contains subject information, some servers will use it
directly, without requesting the Artifact it corresponds to. This will make
it nearly impossible to implement a dynamic session protocol, because it
will be impossible for the session authority to know what servers have been
accessed by a particular user.

3. A hash is much faster and more efficient that a reversible encryption.

---------------------------------------------------------------------------

The Shoboleth scheme requires the ability to request the attributes of user,
without revealing the identity of that user. Further, the attributes
revealed are a function of the requestor.

This can be accomodated by SAML in the following way. These capabilities are
required.

1. The ability to issue an Authentication Assertion whose subject is an
"blinded" identifier which can be mapped by an Authentication or Attribute
Authority to a particualr subject, but which has a different value each time
it is issued for the same subject.

2. The ability to construct an Attribute Assertion for a subject identified
by an Authentication Assertion with a "blinded" subject identifier. The
Attribute Assertion would be constructed on demand and only contain the
attributes appropriate for the requestor, but the means of doing this would
not be specified by SAML.

The session would go like this.

1. The user would signon and receive a SAML Artifact.

2. The user would present the Artifact, allowing a target server to retrieve
the associated "blinded" Authentication Assertion. 

3. From this, the necessary Attribute Assertion could be obtained.

Steps 2 & 3 could be combined in one request/response sequence.

The assertions could also be passed via the user or pushed from the home
site.

This scheme is independant of either one time Artifacts or hashed vs.
encrypted Artifacts.

Hal