Notion of session

[George_Robert_Blakley_III@tivoli.com]

On the call today we discussed whether the specification ought to include a
notion of session.

Here's my cut at some text capturing this issue:

================

Our specification will define a set of tokens which assert security
properties.

When an asserting party transmits an assertion to a relying party, it has
several options for scoping the set of requests to
which the assertion is intended to apply:

(1) It can transmit the assertion together with a request with the
intention that the assertion's validity be scoped to that request only

     (1) (a) The asserting party can explicitly scope the assertion to the
request by binding the two together in some way (e.g. a signature), or
     (1) (b) The asserting party can rely upon a protocol binding to
provide scoping of the assertion to the single request.

(2) It can transmit the assertion with the intention that the assertion's
validity should extend to a sequence of requests.  In this case,
     there needs to be a way to designate which requests are in the scope
of the assertion and which are not.

     (2) (a) The asserting party can explicitly create a session to which
the assertion is bound (using some facility we
          define which enables the creation of a protocol-independent
notion of session which can be imbedded
          in protocols as part of a binding specification), or
     (2) (b) The asserting party can rely upon a protocol binding to create
a session and bind the assertion to the session.

=================

Now that I've described the issue, I'll take the liberty of telling you how
I think it ought to be resolved.

(1) (a) can be handled by simply instructing users of our specification to
use XMLDsig to sign a compound document consisting of a
     request and an assertion token.  Given that we can do this without any
new mechanisms and that we have a requirement
     to rely upon XMLDsig for signing assertions anyway, I suggest that
this is what we should do.
(1) (b) requires no work in core tokens and does not require us to create
any new mechanisms (e.g. session identifiers, request-response
     protocols, etc...).  It does require the designers of protocol
bindings to think about how assertion tokens are scoped.  I think
     this is appropriate; here the action is simply to tell binding
developers what their responsibilities are.

(2) (b) again requires no work in core tokens and doesn't require us to
invent new mechanisms.  Again it puts this burden on the
     developers of bindings.  Again I think this is appropriate and again I
think it imposes on us an obligation to describe what
     binding developers need to do.
(2) (a) Would require us to do a lot of work.  We'd have to

     * define a session identifier format
     * define some request-response protocols for creating and destroying
sessions independent of the particular protocol
       within which the sessions are created.  These request-response
protocols would presumably have to be able to
       be imbedded within: stateful session-oriented communication
protocols, stateless session-oriented communication
       protocols, and store-and-forward communication protocols.  These
request-response protocols would also have
       to deal with all kinds of error cases, termination and restart,
out-of-sequence problems, etc...  Finally, these request-response
       protocols would probably have to deal with issues of session
protection to guard against hijacking, replay, man-in-the-middle
       attacks, and so on.

       However, many of the characteristics which would have to be designed
into such a protocol suite to take care of hard
       cases like use of raw HTTP (no statefulness, no security built in)
would be wasted effort in easier cases like HTTPS,
       where the "carrier protocol" has already solved many of the
problems.

       Furthermore, designing this protocol would create dependencies on a
session identifier generation facility and on
       cryptographic and key distribution mechanisms specific to our spec.
rather than inherent in the protocols to which our
       spec is bound.

       Given all this, I would strongly prefer that we NOT include (2) (a)
in our scope.

--bob

Bob Blakley
Chief Scientist, Security
Tivoli Systems, Inc.