RE: Indexical reference problem defined

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

That's the theory, now for practice.

Bob Blakely wrote:
> Thus we're left with an indexical reference.
> 
> But this is also very hard.  "Set up a session for him" won't 
> work out of
> the box -- ibm.com and oasis.org don't
> share a context, since I'm not currently in contact with oasis.org, so
> "him" has no meaning to oasis.org.
> The indexical reference problem, therefore, is to figure out 
> how to create
> a shared context between ibm.com
> and oasis.org which doesn't permit session splicing, 
> token-stealing, and
> other attacks, and which doesn't
> require new client software.

In the specific case of a standard Web Browser without modifications,
plug-ins or applets, the only mechanisms available to us are of the "Claim
Check" variety. A claim check has the property that it is issued to a holder
and they return it later to verify that they are the same party. In other
words, it is a bearer instrument. Anyone who can present the claim check can
impersonate the legitimate user. This is true of both cookies and encoded
URLs.

What are the threats to a claim check? There are basically two: interception
and guessing or deriving its value. The only way to protect against
interception in the Web Browser case is SSL. Since the cookie or encoded URL
must be sent with every request, this means either use SSL all the time or
accept some risk of interception. As crypto hardware becomes the norm,
perhaps more organizations will be willing to encrypt the entire session
when implementing SSO. In any event, there is nothing we can do about this
threat in the design of SAML.

The attacks of guessing or deriving the value are something we can work on.
Since SAML assertions will likely be widely available, it is dersirable that
it not be possible to derive the value from an Assertion. This makes the
hash of an assertion a particularly poor choice. An scheme which would allow
the value (or most of it) to be derived from knowledge if the SAML
specification would also be weak. 

The common way of handling this is to code up some information and encrypt
it under a symmetric key. The problem is that if the key does not change,
eventually it will become known. Either somebody will leak it, or by brute
force or cryptoanalysis it will be discovered. (Remember that generally the
unencrypted contents will be known.) This implies that SAML will have to
require a key management protocol, just to support basic Web Single Signon. 

A simpler alternative is to use a pure reference and a hash. For example,
start with a large random number (for the truly paranoid a unique number and
a random number) and hash it. Use the hash as an identifier in the
assertion. Use the unhashed value as the claim check. The claim check cannot
be guessed (it is random) or derived from the Assertion (hash is one way).
The actual URL or cookie will need to conatain some information about where
to get the Assertion from or its domain or such.

Hashes are fast and efficient. There will be no requirement for a key
management protocol. Finally, it will help with the distributed logout
problem. If claim checks contain assertion information, it will be tempting
to use them by themselves and not retrieve the actual assertions. To
implement distributed logout on a session, we need to be able to search out
and destroy every copy of assertions bound to that session. If references
are used, it will be easier for a small number of SAML servers to keep track
of what Application Servers have a copy of any given assertion. It will be
much harder to determine all the Application Servers to whom a browser has
given the claim check.

Hal