[OAUTH-WG] MAC: Cookie name or value as MAC key id

"Manger, James H" <James.H.Manger@team.telstra.com> Tue, 14 June 2011 01:11 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 CFA9B11E8075 for <oauth@ietfa.amsl.com>; Mon, 13 Jun 2011 18:11:27 -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=[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 nPCH8uRrs53W for <oauth@ietfa.amsl.com>; Mon, 13 Jun 2011 18:11:26 -0700 (PDT)
Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEA2228004 for <oauth@ietf.org>; Mon, 13 Jun 2011 18:11:25 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.65,361,1304258400"; d="scan'208,217"; a="39982969"
Received: from unknown (HELO ipcdni.tcif.telstra.com.au) ([10.97.216.212]) by ipoani.tcif.telstra.com.au with ESMTP; 14 Jun 2011 11:11:24 +1000
X-IronPort-AV: E=McAfee;i="5400,1158,6376"; a="28870138"
Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcdni.tcif.telstra.com.au with ESMTP; 14 Jun 2011 11:11:23 +1000
Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Tue, 14 Jun 2011 11:11:23 +1000
From: "Manger, James H" <James.H.Manger@team.telstra.com>
To: oauth <oauth@ietf.org>
Date: Tue, 14 Jun 2011 11:11:21 +1000
Thread-Topic: MAC: Cookie name or value as MAC key id
Thread-Index: AcwqL/kMOBs9DL99R+SHchOEYK5ihA==
Message-ID: <255B9BB34FB7D647A506DC292726F6E112867EEDE0@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_255B9BB34FB7D647A506DC292726F6E112867EEDE0WSMSG3153Vsrv_"
MIME-Version: 1.0
Subject: [OAUTH-WG] MAC: Cookie name or value as MAC key id
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: Tue, 14 Jun 2011 01:11:28 -0000

A comment on the MAC draft [draft-ietf-oauth-v2-http-mac-00]:



When MAC credentials are issued with a Set-Cookie response header [section 6] the spec says to use the cookie's name as the MAC key identifier (eg "id=SID"). It would make more sense to use the cookie's value (eg "id=31d4d96e407aad42").



I guess the intention is to include the cookie's value in the Cookie header so it in unnecessary to repeat it in the Authorization header. Repeating the cookie name should be less overhead as it will usually be quite short. This is a bit hacky, too hacky. Wouldn't it be better for a client that recognizes a special MAC cookie to use it to construct Authorization headers and omit it from Cookie headers? A client that doesn't understand the extra MAC-Key cookie attribute will treat the cookie as a normal cookie to return in a Cookie header.



A "normal" MAC library would use the id field in a "Authorization: MAC" header to lookup the secret key. A library for this spec will sometimes use the id field to lookup the secret key, but also sometimes use the id field to lookup a cookie then use that value to lookup the secret key. There is no explicit sign about which approach to follow in any given instance. It depends on how the MAC credentials were issued - which a protected resource shouldn't have to care about, and might not know.



There have been suggestions that the MAC calculation could/should cover the key id. In that situation it is even more crucial that the id field isn't just a name referring to the real value elsewhere - as then the security changes based on the syntax used to issue the credentials.





[Section 6, and 6.1.3]



     Set-Cookie: SID=31d4d96e407aad42; Path=/; Domain=example.com;

                 MAC-Key=8yfrufh348h; MAC-Algorithm=hmac-sha-1



   ...The cookie name "SID" is used as the MAC key identifier


   ...
   MAC key identifier
      is equal to the operative-cookie's name,





--

James Manger