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

Adam Barth <ietf@adambarth.com> Tue, 14 June 2011 01:41 UTC

Return-Path: <ietf@adambarth.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 3461D11E80AE for <oauth@ietfa.amsl.com>; Mon, 13 Jun 2011 18:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.414
X-Spam-Level:
X-Spam-Status: No, score=-3.414 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 cmhO+BR12KK6 for <oauth@ietfa.amsl.com>; Mon, 13 Jun 2011 18:41:31 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94D7511E80A5 for <oauth@ietf.org>; Mon, 13 Jun 2011 18:41:31 -0700 (PDT)
Received: by iwn39 with SMTP id 39so5866430iwn.31 for <oauth@ietf.org>; Mon, 13 Jun 2011 18:41:31 -0700 (PDT)
Received: by 10.42.170.129 with SMTP id f1mr6881525icz.190.1308015690569; Mon, 13 Jun 2011 18:41:30 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by mx.google.com with ESMTPS id er6sm1784792ibb.40.2011.06.13.18.41.29 (version=SSLv3 cipher=OTHER); Mon, 13 Jun 2011 18:41:29 -0700 (PDT)
Received: by iwn39 with SMTP id 39so5866407iwn.31 for <oauth@ietf.org>; Mon, 13 Jun 2011 18:41:29 -0700 (PDT)
Received: by 10.42.218.1 with SMTP id ho1mr6543972icb.474.1308015689033; Mon, 13 Jun 2011 18:41:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.52.4 with HTTP; Mon, 13 Jun 2011 18:40:59 -0700 (PDT)
In-Reply-To: <255B9BB34FB7D647A506DC292726F6E112867EEDE0@WSMSG3153V.srv.dir.telstra.com>
References: <255B9BB34FB7D647A506DC292726F6E112867EEDE0@WSMSG3153V.srv.dir.telstra.com>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 13 Jun 2011 18:40:59 -0700
Message-ID: <BANLkTi=fWxjWY1dmA=Js+_gdw2jPdHcxnw@mail.gmail.com>
To: "Manger, James H" <James.H.Manger@team.telstra.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Cc: oauth <oauth@ietf.org>
Subject: Re: [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:41:32 -0000

On Mon, Jun 13, 2011 at 6:11 PM, Manger, James H
<James.H.Manger@team.telstra.com> wrote:
> 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”).

That was the original plan, but cookie values tend to be longer than
cookie names and it seemed silly to repeat the value twice in the
request.  (It's bad enough to repeat the name.)

> 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.

Yep.

> Repeating the
> cookie name should be less overhead as it will usually be quite short.

Correct.

> 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?

Nope.  Sending the value in the Cookie header is important to help
servers implement this scheme without breaking themselves.

> 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.

Indeed.

> A “normal” MAC library would use the id field in a “Authorization: MAC”
> header to lookup the secret key.

You're welcome to use the protocol that way.  Just encode that
information into the cookie name.

> 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.

It's not a big deal either way in practice.  Folks will be
cross-checking the cookies with the Mac anyway.  It's better to send
things once rather than have duplication.

Adam


> [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,