[OAUTH-WG] MAC: creation-time when a cookie is renewed

"Manger, James H" <James.H.Manger@team.telstra.com> Wed, 15 June 2011 07:07 UTC

Return-Path: <James.H.Manger@team.telstra.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C62B11E8096 for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 00:07:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDQIvrG3NtbF for <oauth@ietfa.amsl.com>; Wed, 15 Jun 2011 00:07:55 -0700 (PDT)
Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id A995611E8074 for <oauth@ietf.org>; Wed, 15 Jun 2011 00:07:51 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.65,369,1304258400"; d="scan'208,217"; a="38131404"
Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 15 Jun 2011 17:07:49 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6377"; a="28906912"
Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcbvi.tcif.telstra.com.au with ESMTP; 15 Jun 2011 17:07:49 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 15 Jun 2011 17:07:48 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: oauth <oauth@ietf.org>
Date: Wed, 15 Jun 2011 17:07:46 +1000
Thread-Topic: MAC: creation-time when a cookie is renewed
Thread-Index: AcwrKu36mUVVJEeMR/OCcKdO42HGTQ==
Message-ID: <255B9BB34FB7D647A506DC292726F6E11286961435@WSMSG3153V.srv.dir.telstra.com>
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-AU
Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E11286961435WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: [OAUTH-WG] MAC: creation-time when a cookie is renewed
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2011 07:07:56 -0000

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