Re: [OAUTH-WG] [Openid-specs-ab] -00 of draft-bradley-stateless-oauth-client

John Bradley <ve7jtb@ve7jtb.com> Sun, 03 November 2013 17:04 UTC

Return-Path: <ve7jtb@ve7jtb.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 0FAD821E80FA for <oauth@ietfa.amsl.com>; Sun, 3 Nov 2013 09:04:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 KUR9lluLpnq5 for <oauth@ietfa.amsl.com>; Sun, 3 Nov 2013 09:04:09 -0800 (PST)
Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9B211E815F for <oauth@ietf.org>; Sun, 3 Nov 2013 09:04:09 -0800 (PST)
Received: by mail-pd0-f178.google.com with SMTP id x10so5809325pdj.37 for <oauth@ietf.org>; Sun, 03 Nov 2013 09:04:08 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Ota6xYxIYjkY2lNiVbwmYyZK+QOc+WNI0pWljI/zuOI=; b=lO4H0Jce142cKyGOfh4BHN7vxqzngjFTitu0SC0vuKm0RZirKGHcTNTYk3TmyVu6Sv UCbekg+sfrQsJ54ECzTdNsji9BWbZOWKw3apLIwKLxFSXEBxnvtxnqRooPvDtv2C9Zph rM71pK461nVq2vgE4Ltw9nYVi/+SNkJPkpDu7gUOp7XFkskPH48/RKx+QOpzju42v1Q4 ambMSnHm6hA88Gx/WEHp6+FhOIQjBA2c+iqBWS5jKCensvQU6R6i0b/40HWimzqsHafX VQK3RjC6QXrhP61ORdXqkdsqQtZLC0l5iZR5YF+3Qn4egoWCWSZd2zpdY817A8/h0Ibs wWtQ==
X-Gm-Message-State: ALoCoQn/oCr0lwjqPM/5F+Gb2Kz2l3qaCnaotKHbG2ZV3ng4XzFRecuwyPSuprqKIHaWCSeMVDiJ
X-Received: by 10.68.251.133 with SMTP id zk5mr13559755pbc.69.1383498247722; Sun, 03 Nov 2013 09:04:07 -0800 (PST)
Received: from [192.168.5.199] (199-91-80-194.ip.van.radiant.net. [199.91.80.194]) by mx.google.com with ESMTPSA id ye1sm27216371pab.19.2013.11.03.09.04.04 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Nov 2013 09:04:06 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_F60D0755-CCE6-4196-B7CC-F9EC2BB585C2"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <CA+k3eCSR+hVFsYnbOzvmxc771kHpe8k1V_Lfo+LFVOy34J=7ow@mail.gmail.com>
Date: Sun, 3 Nov 2013 09:04:01 -0800
Message-Id: <E4A70B26-1CD7-409F-8A17-AC2A28E3F884@ve7jtb.com>
References: <CA+k3eCSR+hVFsYnbOzvmxc771kHpe8k1V_Lfo+LFVOy34J=7ow@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
X-Mailer: Apple Mail (2.1816)
Cc: "<openid-specs-ab@lists.openid.net>" <openid-specs-ab@lists.openid.net>, oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] [Openid-specs-ab] -00 of draft-bradley-stateless-oauth-client
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: Sun, 03 Nov 2013 17:04:14 -0000

YEs in my other response to Hannes I noted that in the simple case of a one to one relationship between a AS and a registration server AES_CBC_HMAC_SHA2 is probably the best way to do integrity(must not say signing or the crypto wonks go nuts)  and confidentiality if a symetric secret is included in the JWT.

The need for confidentiality goes away if the client is using a asymmetric key to authenticate.

Separately I have been dealing with several OAuth clients (Websites) that have been compromised and lost all of there OAuth 1 tokens and secrets as well as all of there Oauth 2 tokens.
We can put it down to bad security, but having long lived access tokens and there secrets hanging around in databases is a tempting target.  
It is also challenging for a client to protect there symmetric client secret in these cases as it is typically in some file on the disk.

There may at some point be a push to use asymmetric keys from a HSM to secure access to the token endpoint and keep the lifetime of the access tokens short.

One thing that is a limitation of encoding information in the client_id is that we don't currently allow the client_id to change during updated in client registration.
If we did then the JWT could contain some fixed id for the client that the AS would use as the key for authorizations.

I was trying to stay inside the scope of the current drafts.    
Our options are to allow client_id to change  this requires only a change in dynamic registration, and not the rest of the client logic, or to crate a separate parameter for client_assertion that would contain the signed information including the client_id sending the client_id twice.

I think allowing the client_id to be reference or assertion  as determined by the AS is more in keeping with what we are doing with access tokens.  
I don't think that should require any change to clients,  though it would require change to server logic to treat the incoming client_id as a reference or assertion to the actual client identifier rather than always being a literal.

I think it is worth discussing.

John B.



On Nov 3, 2013, at 8:36 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

> Some musings on http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00
> 
> Abstract: "... allowing for fully stateless operation." --> saying that the statelessness is on the AS side might avoid some confusion. The client is still going to have to maintain state. 
> 
> The kid is header rather than a claim.
> 
> "The issuer SHOULD sign the JWT with JWS ...  issuer MAY encrypt the JWT with JWE." --> this text seems a little off given that the most common case, I'd think, would be an AS who issues these client id JWTs only for its own consumption using JWE's AES_CBC_HMAC_SHA2 which gives encryption and integrity protection.
> 
> Does the relationship between the "iat" and "exp" claims here and the "client_secret_expires_at" and "client_id_issued_at" parameters of dyn reg need to be explained or explored more? Strikes me as potentially problematic.
> 
> And what happens when one of these JWT client ids expires or needs to be updated? Or the keys used to create or verify them expire? I know the answer thus far has been that the client will just have to get a new one. But I feel like that might be too limiting in practice. I'd like to further pursue understanding/defining how these kinds of client ids might be used in conjunction with a longer lived way to identify the client that allows the client id (i.e. the metadata) to change but can allow correlation across such changes (the sub claim in this doc even suggests that a client might have such an identifier).
> 
> As was pointed out in another review, there's a difference between documenting how it's possible for an AS to issue "stateless" client ids for its own use and defining something that allows for some other party to issue such ids. It may make sense to discuss them in the same document but I believe it'd be valuable to have the doc acknowledge and address the difference more.
> 
> 
> 
> 
>  
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab@lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab