|Subject:||Notion of session|
|Date:||Jan 31, 2001 10:30:46 am|
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 Blakley Chief Scientist, Security Tivoli Systems, Inc.