The reason the Session header mechanism I propose does not address cookie scoping is that there is already a perfectly adequate confidentiality and integrity solution in the hands of the Server: encrypt the cookie contents and append a MAC to the end.
The only situation where I see cookie stealing as a problem is where the cookie is a bearer token. Since the client never looks at cookie content there is no good reason not to encrypt if the data is at all confidential. Cookie overwriting is a little more complicated as merely being able to detect overwriting is not the same as being able to prevent a denial of cookie attack. If people think the existing scope mechanism in cookies is insufficient, I am open to extending the Session draft to add an origin cookie type capability. Or we can redefine the cookie handling as well if that is needed to ensure backwards compatibility. On the issue of preventing replay attacks, the session continuation draft I wrote describes two application scenarios. The first being the Web browser scenario, the second being Web Services. The Web service I have developed that uses the draft uses nonces passed in the protocol to prevent replay attacks. Web Services typically require much stronger replay attack prevention than Web Browsing. But this is easier to achieve since some of the checking lives more naturally in the Web Service protocol layer than the HTTP binding. I don't see the need to prevent replay attacks in Web Browsing except in the very special case of forms entry which servers can check themselves by using a nonce passed in a hidden form field. I should probably add a section to the draft explaining the reasoning there.
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
