Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 01 November 2013 18:49 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 AAB0711E80DE for <oauth@ietfa.amsl.com>; Fri, 1 Nov 2013 11:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSbbjCQfIkqy for <oauth@ietfa.amsl.com>; Fri, 1 Nov 2013 11:49:11 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id CE96611E813D for <oauth@ietf.org>; Fri, 1 Nov 2013 11:49:09 -0700 (PDT)
Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M4Gup-1VsslD4BBD-00roQ2 for <oauth@ietf.org>; Fri, 01 Nov 2013 19:49:09 +0100
Message-ID: <5273F7A2.70409@gmx.net>
Date: Fri, 01 Nov 2013 19:49:06 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: John Bradley <ve7jtb@ve7jtb.com>
References: <5273E5AD.7010408@gmx.net> <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com>
In-Reply-To: <3F75FA0B-CAC3-439A-866B-CFE116FADA4E@ve7jtb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:qFbuTTYWwNr3JssBMpBES4sbI/c3PQeXNd9PnOu9BTfwXILw67U HBe0i/umc1S6fp6X4mxpGnoy95g1p76Fp1rYvteIHmhaNiYXrNC+0qYG7d9zENVrnYw+bQ7 7gB8qJxBkoF3ENMpl63T8pDj4QPQj9/1r+GKsckzLYDRVKiUaLTvgCIvlsUj5pAH/q7Sf+k 9ZUpvNTWG1gF+kqsztAVw==
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-bradley-stateless-oauth-client-00
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: Fri, 01 Nov 2013 18:49:15 -0000

Hi John,

thanks for the super-quick response.


Am 01.11.13 19:18, schrieb John Bradley:
> The client_id would continue to be opaque to the client as it is now.
> The AS can send a JWE using AES_128_CBC_HMAC_SHA_256 to encrypt and
> provide integrity if it is using a symmetric key (probably the
> simplest thing if we are talking about a single registration endpoint
> paired with a single AS)  In more complicated scenarios where perhaps
> a group of AS share a single registration endpoint you probably want
> to use asymmetric signature  then asymmetric encryption + integrity.
> Those are deployment decisions that need to be documented but can be
> transparent to teh client.

Maybe it would be good to state that in the document that this is a 
possible option without introducing further complications (other than 
the verification procedure is different). If the AS signs the JWT then 
it just needs to compare whether the issuer field matches what it had 
previously put in there. If someone else signs the JWT then it needs to 
check with some trust anchor store or something similar whether it 
trusts that specific issuer.


>
> Sorry to my mind it is obvious that the JWT would be integrity
> protected/signed for all clients including clients using asymmetric
> authentication to the token endpoint, and and
> signed+encrypted+integrity for clients using symmetric
> authentication.   That can be made clearer.

It would be good to say that because the effort is rather low and there 
are benefits in doing so.

>
> It might make sense to assume the issuer is just the AS but the AS
> can do that without the benefit of a spec now, as there is no
> interoperability issue.
>
> The spec defining the JWT structure and signing and encryption
> methods has the most benefit when you don't have such a tight
> coupling between registration and AS.
>
> That is likely why Justin and I didn't think a spec was necessary for
> the simple case other than to show people this is possible with the
> existing registration spec.

I think there is value in providing that information for implementers 
even though it does not require new extensions or so.

>
> I am OK with strengthening the wording on signing/integrity
> protecting and encryption.  eg if a symmetric key is included the JWT
> MUST be encrypted.

Cool.
>
> I don't necessarily want to make any algorithm a must as that limits
> algorithm agility in the future.
OK.

>
> Thanks for giving it a read, see you Sunday I expect.
Unfortunately not since I am unable to attend the upcoming IETF meeting. 
Derek will run the show.

Ciao
Hannes

>
> John B.
>
>
> On Nov 1, 2013, at 2:32 PM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net> wrote:
>
>> Hi John, Hi all,
>>
>> I read your document and here a few remarks.
>>
>> In the dynamic client registration conference calls the topic of
>> the stateless client was raised since there was the argument in the
>> air that the current OAuth 2.0 RFC requires clients to be stateless
>> due to the nature of the client identifier.
>>
>> It seems that you have found a way to make the client stateless
>> with regard to the client identifier (i.e., that the authorization
>> server does not need to store information about the client) by
>> dumping state information in the client identifier itself. In your
>> case you use a JWT, which is clever.
>>
>> Since RFC 6749 explicitly says that the client identifier string
>> size is left undefined  and that the client should avoid making
>> assumptions about the identifier size I don't see a problem with
>> the proposed approach.
>>
>> Now, there is one issue that I am wondering about. The client
>> identifier itself is not sufficient for authorizing the client (for
>> confidential clients). Instead, there is typically the need to have
>> a secret. Now, the secret is not conveyed in the JWT, at least not
>> in the way you have define it. You could of course do that and
>> there is a document that provides prior art, see
>> http://www.ietf.org/rfc/rfc5077 The story essentially is that the
>> structure (JWT in your case) includes the key but of course then
>> you have to encrypt the entire blob.
>>
>> In the case of public clients wouldn't you want to mandate at least
>> a digital signature or a keyed message digest for the JWT since
>> otherwise there is the risk that the client changes some of the
>> parameters to impersonate someone?
>>
>> A few other questions:
>>
>> * You write: "The issuer SHOULD sign the JWT with JWS in such a way
>> that the signature can be verified by the authorization server. "
>>
>> I believe what you want to say is the following: The authorization
>> creates the client identifier (using the JWT) and the client does
>> not parse the received content since it treats it as opaque.
>> However, the authorization server MUST be able to process and
>> verify received client identifiers it previously created, which
>> requires to apply cryptographic processing when a JWT is signed
>> (using a JWS) and when a JWT is encrypted (using a JWE).
>>
>> (I ignore the issue that I believe the JWT needs to be signed [for
>> public clients] and encrypted [for confidential clients].)
>>
>> * You should submit the document as draft-bradley-oauth; this makes
>> it easier to find the document.
>>
>> * You write: " The issuer MAY encrypt the JWT with JWE. "
>>
>> I think you want to be stronger by saying that JWE MUST be used
>> when the authorization server wants to apply confidentiality
>> protection of the JWT. While the authorization server could use
>> other techniques as well the purpose of the document is to describe
>> one way to accomplish the goal and therefore it makes sense to be
>> specific.
>>
>> I would even go as far as suggesting specific algorithms to use, as
>> an example.
>>
>> * Although not stated directly I believe you allow the client
>> identifier to be created by a party other than the authorization
>> server. While this would theoretically make sense wouldn't it be
>> useful to just assume that the issuer is the authorization server?
>>
>> Ciao Hannes _______________________________________________ OAuth
>> mailing list OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>