Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt

Justin Richer <jricher@mitre.org> Thu, 28 February 2013 17:09 UTC

Return-Path: <jricher@mitre.org>
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 E849C21F85D8 for <oauth@ietfa.amsl.com>; Thu, 28 Feb 2013 09:09:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.577
X-Spam-Level:
X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 rTvYP4nH1p5Z for <oauth@ietfa.amsl.com>; Thu, 28 Feb 2013 09:09:49 -0800 (PST)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B3ECA21F856F for <oauth@ietf.org>; Thu, 28 Feb 2013 09:09:48 -0800 (PST)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 582675311DBF; Thu, 28 Feb 2013 12:09:48 -0500 (EST)
Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 3C4F95311DBC; Thu, 28 Feb 2013 12:09:48 -0500 (EST)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 28 Feb 2013 12:09:47 -0500
Message-ID: <512F8F1E.3020400@mitre.org>
Date: Thu, 28 Feb 2013 12:08:46 -0500
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2
MIME-Version: 1.0
To: William Mills <wmills_92105@yahoo.com>
References: <20130225124642.7425.65145.idtracker@ietfa.amsl.com> <1361956373.9883.YahooMailNeo@web31807.mail.mud.yahoo.com> <21030204-8EA7-4FB0-9DD3-2B6C8CA57E02@gmx.net> <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com>
In-Reply-To: <1362057295.36069.YahooMailNeo@web31809.mail.mud.yahoo.com>
Content-Type: multipart/alternative; boundary="------------050206090801030609090305"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
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: Thu, 28 Feb 2013 17:09:50 -0000

What I don't quite get is what exactly would be presented and processed 
at each step. Who needs to know what piece? We don't want to have to 
push everything into JSON for the signing to take place (that much is 
clear), and we don't want the client to be pushing the MAC secret to the 
RS every time (that would make it a lot less secret, after all). But if 
we can reuse JWT, JWS, and other JOSE mechanisms to make some parts of 
the MAC pattern easier for programmers, I'm for it.

  -- Justin

On 02/28/2013 08:14 AM, William Mills wrote:
> I'm actually advocating that we change MAC to be a JWT extension.
>
> ------------------------------------------------------------------------
> *From:* Hannes Tschofenig <hannes.tschofenig@gmx.net>
> *To:* William Mills <wmills_92105@yahoo.com>
> *Cc:* Hannes Tschofenig <hannes.tschofenig@gmx.net>; "oauth@ietf.org" 
> <oauth@ietf.org>
> *Sent:* Thursday, February 28, 2013 2:28 AM
> *Subject:* Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
>
> Hi Bill,
>
> I believe you are misreading the document. In 
> draft-ietf-oauth-v2-http-mac the client still uses the MAC when it 
> accesses a protected resource.
> The only place where the JWT comes into the picture is with the 
> description of the access token. This matters from a key distribution 
> point of view. The session key for the MAC is included in the 
> encrypted JWT. The JWT is encrypted by the authorization server and 
> decrypted by the resource server.
>
> Information about how header fields get included in the MAC is 
> described in Section 5.
>
> The nonce isn't killed it is just called differently: seq-nr. The 
> stuff in the original MAC specification actually wasn't a nonce (from 
> the semantic point of view).
> The extension parameter is there implicitly by allowing additional 
> header fields to be included in the MAC computation.
>
> I need to look at the port number field again.
>
> Ciao
> Hannes
>
> On Feb 27, 2013, at 11:12 AM, William Mills wrote:
>
> > Just read the draft quickly.
> >
> > Since we're now leaning on JWT do we need to include the token in 
> this?  Why not just make an additional "Envelope MAC" thing and have 
> the signature include the 3 JWT parts in the signature base string?  
> That object then just becomes a JSON container for the kid, timestamp, 
> signature method, signature etc. That thing then is a 4th base64 
> encoded JSON thing in the auth header.
> >
> > How header fields get included in the signature needs definition.
> >
> > Why did you kill the port number, nonce, and extension parameter out 
> of the signature base string?
> >
> > The BNF appears to have no separators between values.
> >
> > -bill
> >
> >
> > From: "internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>" 
> <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
> > To: i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>
> > Cc: oauth@ietf.org <mailto:oauth@ietf.org>
> > Sent: Monday, February 25, 2013 4:46 AM
> > Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-v2-http-mac-03.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> > This draft is a work item of the Web Authorization Protocol Working 
> Group of the IETF.
> >
> >    Title          : OAuth 2.0 Message Authentication Code (MAC) Tokens
> >    Author(s)      : Justin Richer
> >                          William Mills
> >                          Hannes Tschofenig
> >    Filename        : draft-ietf-oauth-v2-http-mac-03.txt
> >    Pages          : 26
> >    Date            : 2013-02-25
> >
> > Abstract:
> >  This specification describes how to use MAC Tokens in HTTP requests
> >  to access OAuth 2.0 protected resources.  An OAuth client willing to
> >  access a protected resource needs to demonstrate possession of a
> >  crytographic key by using it with a keyed message digest function to
> >  the request.
> >
> >  The document also defines a key distribution protocol for obtaining a
> >  fresh session key.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-http-mac
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-03
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-http-mac-03
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org <mailto:OAuth@ietf.org>
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> >
>
>
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth