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/
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
