These problems all seem sovled with the new definition of age to not be necessarily related to time.
Adam On Wed, Jun 15, 2011 at 12:07 AM, Manger, James H <james.h.man...@team.telstra.com> wrote: > The MAC scheme’s cookie mode [draft-ietf-oauth-v2-http-mac-00, section 6] > says the cookie’s creation-time is used to determine the age that goes in > the nonce in a request. The creation-time is the time the client receives > the Set-Cookie response – unless the client already has a cookie with the > same name, domain, and path, in which case the creation-time of the existing > cookie is kept [rfc6265 HTTP state management mechanism, section 5.3, step > 11.3]. > > Is this going to cause complications in practice? > > A server will need to know if a client has an existing cookie before issuing > a new one. That should be possible as the old cookie will be included in the > request whose response contains the Set-Cookie header for the new cookie. > > There are some corner cases, such as an old cookie that expires after being > sent to the server, but before the new cookie is returned. Perhaps they are > rare enough to ignore. > > If a server crashes then reboots (loosing in-memory details about old > cookies) it cannot just issue new cookies. First it needs to issue an > expired cookie to clear the client’s cookie store (deleting the old cookie > that has a creation-time that the server no longer knows), then issue a new > cookie with a known creation-time. That sounds painful (ie will not be > implemented initially, but will eventually cause a nasty outage). > > > > It might encourage people to tack the creation-time into the cookie-value. > Do that without integrity protection, however, and you are open to replay > attacks. > > > > -- > > James Manger > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth