[websec] Session continuation mechanism -01

[Phillip Hallam-Baker <[e-mail]>]

I have just submitted an updated version of the session continuation draft.

http://www.ietf.org/id/draft-hallambaker-httpsession-01.txt

I didn't bring the first version to the list attention as I was not
convinced all the parts really worked. I have since re-engineered the
replay prevention mechanism and I think the result is more sensible.

There is code, but this version is not tracking it (yet). I modified the
examples to get the draft out the door so don't go checking it :-)


The basic idea here is that this is a more or less drop in replacement for
HTTP cookies but with much better security properties. To signal that it
can accept session continuation in place of cookies, a client adds an
Accept-Session header to a request. If the server accepts the offer of
using session management it returns a response with a Set-Session header.

After the context is set up, the client and server both add Session headers
to request and response messages.


The main change is on replay attack prevention which I now think needs to
be different for requests and responses.

Response replay attack prevention is easy. Just put a nonce in the request
and the server returns in in the response. Problem solved. No need to keep
any state or muck about with clocks.

Request replay attack is trickier and I don't think we even want to try to
do the job in HTTP, certainly not the whole job. If people want really
solid request replay attack prevention for a Web service then they should
write the code into their Web Service because HTTP does not have enough
visibility into their transaction to know when the nonces should be there
or not.


The same mechanism could be extended to cover public key techniques
(digital signatures).

-- 
Website: http://hallambaker.com/