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

Sergey Beryozkin <sberyozkin@gmail.com> Thu, 28 February 2013 17:30 UTC

Return-Path: <sberyozkin@gmail.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 5644721F8B33 for <oauth@ietfa.amsl.com>; Thu, 28 Feb 2013 09:30:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.559
X-Spam-Level:
X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, 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 dM0vRFSavZ7l for <oauth@ietfa.amsl.com>; Thu, 28 Feb 2013 09:30:32 -0800 (PST)
Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 997B321F88C1 for <oauth@ietf.org>; Thu, 28 Feb 2013 09:30:31 -0800 (PST)
Received: by mail-ee0-f42.google.com with SMTP id b47so1676281eek.15 for <oauth@ietf.org>; Thu, 28 Feb 2013 09:30:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=RuWuUqmiRyaWx6xbe9X3J3C+De4NKiPbnTQNEorWsIg=; b=rCnm38eG6R+QBQEHbpAO4nrpezm8pGsRAEVMBE37xLQUNcrY+I44s3IKKXUygmQVwl pJbffzpgQr8/hfdmbnwDwXQOuIbVc4guoy/K+kOQ9ml+8tu/ZtnX+8nZLqZhfe0tnGq2 T2vcqO6GhWyhWojfl1Yt5vz2TTGodQvh/TdSDqf+UZmwir/4Yuk/+M+m0GUT8EI3qNO3 9Efco8a9jZDhg2jmz7iPX0ZMUSjhgkFQibk5cktPR2DoAVoEpmwwnByt5XqSUmI3dym9 HMoM/zpJFL1hrwIAdU00RoW1T6Z0t908JrPNPg2AQvDtfqr1eBcW5TyzI9wQUTloKA+g c46Q==
X-Received: by 10.14.182.137 with SMTP id o9mr18793162eem.13.1362072629286; Thu, 28 Feb 2013 09:30:29 -0800 (PST)
Received: from [192.168.2.5] ([79.97.76.201]) by mx.google.com with ESMTPS id u44sm12918262eel.7.2013.02.28.09.30.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 28 Feb 2013 09:30:28 -0800 (PST)
Message-ID: <512F9432.3000701@gmail.com>
Date: Thu, 28 Feb 2013 17:30:26 +0000
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: oauth@ietf.org
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> <512F8E1D.2060408@gmail.com>
In-Reply-To: <512F8E1D.2060408@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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:30:33 -0000

On 28/02/13 17:04, Sergey Beryozkin wrote:
> Hi
> On 28/02/13 13:14, William Mills wrote:
>> I'm actually advocating that we change MAC to be a JWT extension.
> IMHO, having a simpler option, plus, going forward, a possible JWT
> profile (client to RS path) would work better -
>
> Why would JWT completely take over ? May be it should be possible indeed
> to have it as a JWT extension - should it be part of the relevant JWT
> assertion spec, where JWT is used as a possible grant ?
We are talking about access tokens here I've just realized, looking at 
other emails...still may be JWT assertion spec may be expanded in 
principle...

Sergey


>
> Thanks, Sergey
>>
>> ------------------------------------------------------------------------
>> *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
>
>