Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10

Phil Hunt <phil.hunt@oracle.com> Fri, 17 May 2013 23:30 UTC

Return-Path: <phil.hunt@oracle.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 BE02721F961E for <oauth@ietfa.amsl.com>; Fri, 17 May 2013 16:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.173
X-Spam-Level:
X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.426, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 tuR7VONov1Nt for <oauth@ietfa.amsl.com>; Fri, 17 May 2013 16:29:55 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 99C4321F961D for <oauth@ietf.org>; Fri, 17 May 2013 16:29:55 -0700 (PDT)
Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r4HNTrd4030146 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 17 May 2013 23:29:54 GMT
Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4HNTqPK004440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 May 2013 23:29:53 GMT
Received: from abhmt116.oracle.com (abhmt116.oracle.com [141.146.116.68]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r4HNTpxZ006892; Fri, 17 May 2013 23:29:52 GMT
Received: from [192.168.1.89] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 17 May 2013 16:29:51 -0700
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Phil Hunt <phil.hunt@oracle.com>
In-Reply-To: <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com>
Date: Fri, 17 May 2013 16:29:50 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <99D23FB9-19C3-40DF-9989-30F6686091DA@oracle.com>
References: <C0CE9538-4B72-4882-9462-B08A2D386720@oracle.com> <51965446.2070404@mitre.org> <84E4E4E6-EA02-4141-BA6D-77A0B3F76E7A@oracle.com> <3701BFCE-3D0F-45A3-955E-7486904B98B3@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Mailer: Apple Mail (2.1283)
X-Source-IP: acsinet21.oracle.com [141.146.126.237]
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Client Credential Expiry and new Registration Access Token - draft-ietf-oauth-dyn-reg-10
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, 17 May 2013 23:30:00 -0000

John,

Thanks for jumping in.

1.  I do buy the implied argument that some client credential types do expire (eg. bearer assertions). Therefore the expiry issue has to be dealt with.  I would prefer to handle this by allowing an exception whereby expired assertions could be used to re-register (only). This shouldn't be a big security issue since we're talking about an expired client refreshing with its issuer rather then a third party trusting an expired token. 

I just don't think adding another token, the registration access token, that in turn (by your argument) should expire, actually helps.  It just adds another layer to the problem and increases complexity.  It solves nothing.

2. You seem to be describing a different usage than Justin is.  The way he explains the draft, there is no developer cycle at all.  He's saying every client gets a registration token and a client token.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com





On 2013-05-17, at 10:40 AM, John Bradley wrote:

> 1 No reasonable security profile is going to let you use the same symmetric password over long time periods.  It will be brute forced given enough time.   
> The rotation time will depend on entropy and the rate an attacker can submit attempts.    I would expect profiles to look at SP-800-63 for guidance as essentially a password for the client.
> 
> 2 the registration interface is likely used by a developer who probably doesn't want the client instances (say native clients) to be able to update the configuration directly.  using the client secret credential for updates would break the separation.   Registration my be done by the client itself or by a developer as a separate process.
> 
> John B.
> 
> On 2013-05-17, at 7:27 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
>> Justin,
>> 
>> Your reason was you copied connect. Ok. I was looking for a technical reason.  A security reason.
>> 
>> BTW.  Mike Jones says expiry wasn't the reason.  
>> 
>> Phil
>> 
>> @independentid
>> www.independentid.com
>> phil.hunt@oracle.com
>> 
>> 
>> 
>> 
>> 
>> On 2013-05-17, at 9:01 AM, Justin Richer wrote:
>> 
>>> The separation between these two is necessary: Not all clients have client_secret, and you want the lifecycle/management of the registration to be protected. This is what the registration access token was made for. In older versions of Connect's registration, the client_secret was forced on all clients in order to provide this, but then you had public clients with a client_secret that they couldn't use to get tokens, and it was a bad disconnect.
>>> 
>>> The requirement for client secrets to expire or otherwise be rotated by the server came from several implementors in the Connect WG. There's an easy way to indicate that they don't expire, and a fairly straightforward way for them to be rotated (client does a GET on its client configuration endpoint url, with its registration access token as auth).
>>> 
>>> -- Justin
>>> 
>>> On 05/16/2013 05:35 PM, Phil Hunt wrote:
>>>> All,
>>>> 
>>>> In the dynamic registration draft, a new token type is defined called the "registration access token". Its use is intended to facilitate clients being able to update their registration and obtain new client credentials over time.  The client credential is issued on completion of the initial registration request by a particular client instance.
>>>> 
>>>> It appears the need for the registration access token arises from the implied assertion that client credentials should expire.
>>>> --> Is anyone expiring client credentials?
>>>> 
>>>> To date, we haven't had much discussion about client credential expiry. It leads me to the following questions:
>>>> 
>>>> 1.  Is there technical value with client credential/token expiry?  Keep in mind that client credential is only used with the token endpoint over TLS connection. It is NOT used to access resources directly.
>>>> 
>>>> 2.  If yes, on what basis should client credential/token expire?
>>>> a.  Time?
>>>> b.  A change to the client software (e.g. version update)?
>>>> c.  Some other reason?
>>>> 
>>>> 3. Is it worth the complication to create a new token type (registration access token) just to allow clients to obtain new client tokens?  Keep in mind that client tokens are only usable with the AS token endpoint.  Why not instead use a client token for dyn reg and token endpoint with the rule that once a client token has expired (if they expire), an expired token may still be used at the registration end-point.
>>>> 
>>>> 4. Are there other reasons for the registration token?
>>>> 
>>>> Thanks,
>>>> 
>>>> Phil
>>>> 
>>>> @independentid
>>>> www.independentid.com
>>>> phil.hunt@oracle.com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>