Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method

Justin Richer <jricher@mitre.org> Thu, 25 April 2013 16:35 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 0A24821F93B9 for <oauth@ietfa.amsl.com>; Thu, 25 Apr 2013 09:35:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 47H4sIJcToIU for <oauth@ietfa.amsl.com>; Thu, 25 Apr 2013 09:35:38 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 02A6521F936D for <oauth@ietf.org>; Thu, 25 Apr 2013 09:35:38 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 93C9C2260055; Thu, 25 Apr 2013 12:35:33 -0400 (EDT)
Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8387D1F024A; Thu, 25 Apr 2013 12:35:33 -0400 (EDT)
Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 25 Apr 2013 12:35:33 -0400
Message-ID: <51795B41.9010401@mitre.org>
Date: Thu, 25 Apr 2013 12:35:13 -0400
From: Justin Richer <jricher@mitre.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Phil Hunt <phil.hunt@oracle.com>
References: <53250C00-9D1C-4E81-9AD6-E12241B875D9@oracle.com> <5178498B.3050406@mitre.org> <0E96125F-CFEC-4157-8A1E-3CFCA1C4D79F@oracle.com> <0C683171-29F6-47EA-A611-AB6394207353@ve7jtb.com> <E24D0C95-DBDF-430F-B8A7-FC4E67C255BD@oracle.com> <629E4582-16C4-4554-9591-39E6801FA0A8@ve7jtb.com> <51793297.4020102@mitre.org> <870ADA58-1706-40CD-97AC-A357CE1D6094@ve7jtb.com> <5B4EA19E-AA21-4EF1-962C-D2F028748CE1@oracle.com>
In-Reply-To: <5B4EA19E-AA21-4EF1-962C-D2F028748CE1@oracle.com>
Content-Type: multipart/alternative; boundary="------------040406090000080009010204"
X-Originating-IP: [129.83.31.58]
Cc: "oauth@ietf.org WG" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Questions on draft-ietf-oauth-dyn-reg-09 - token_endpoint_auth_method
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, 25 Apr 2013 16:35:40 -0000

On 04/25/2013 12:23 PM, Phil Hunt wrote:
> I am not sure what to think about this.
>
> 1. I don't want this spec to be incomplete because there is another 
> external spec published for a specific purpose.
If we needed a registry we could define it in this spec. If we chose a 
non-registry method (like how grant_type uses URIs) then it's 
self-contained. I prefer the latter, myself.

> 2. In general i would like to avoid negotiations. It seems to me that 
> any developer making a client for a mutli-site deployed service would 
> already be aware of what the generic service require and implement 
> based on that oob knowledge. Thus when the server merely informs, the 
> client should be prepared.
The client already has to be prepared because the server will inform, 
though. But by making it bidirectional (like all the other parameters) 
it gives the client a chance to ask based on whatever information it 
wants to. The server is perfectly free to ignore what the client asks 
for and just hand it something, just as it's free to do so for all fields.

> IMHO, though i understand the motivation, negotiation of client auth 
> creates more problems then it seems to solve in this case. Downgrade 
> attack is just one of the problems.
The parameters of the negotiation are going to be application-protocol 
specific and depend on things like a Discovery layer for them to be 
fully dynamic from a cold boot. And even then servers and clients that 
care about this value are going to have to know how to enforce it (it's 
the same as it is with grant_type, response_type, scope, and others).

If nothing else, it lets servers tell clients which auth method to use 
at the token endpoint. The client can be smart and try to figure out if 
it actually supports that method before trying it, or it can be dumb and 
ignore the returned value. But with this parameter in the protocol, both 
sides at least have a *chance* of doing the right thing.

  -- Justin

>
> Phil
>
> On 2013-04-25, at 7:21, John Bradley <ve7jtb@ve7jtb.com 
> <mailto:ve7jtb@ve7jtb.com>> wrote:
>
>> I am OK with having a registry,  Connect profiles the jwt assertions 
>> draft to add specifics around keying material for interoperability.
>> It may well be that people will want other methods including SAML 
>> assertions.
>>
>> While sending a list of methods the client supports to the server and 
>> getting back what is supported by the server works, it is awkward.
>>
>> My point is mostly that there are lots of other parameters that are 
>> set only by the server.  I don't know if we want to start adding them 
>> to registration just to allow for them to be discovered.   Using a 
>> simple .well-known discovery document seems simpler.
>>
>> So making token_endpoint_auth_method an array is not the end of the 
>> world and would work, but heads us in what I think is the wrong 
>> direction.
>>
>> John B.
>>
>> On 2013-04-25, at 10:41 AM, Justin Richer <jricher@mitre.org 
>> <mailto:jricher@mitre.org>> wrote:
>>
>>> John, I don't think that anybody's actually suggesting that we add 
>>> server discovery in here. :) But since the server does echo back the 
>>> configuration in its response, the client is discovering a few 
>>> things at run time about what it can and can't do with a particular 
>>> server. It's entirely possible that the client might get back a 
>>> configuration option that it can't use (say, it can't do 
>>> client_secret_jwt assertions but it can do
>>>
>>> From what I can see from this thread though there are two open 
>>> questions that Phil's raised:
>>>
>>>
>>>  1: Extensibility of token_endpoint_auth_method values, and where 
>>> potential values are listed (IANA? fully qualified URIs for things 
>>> not in the base spec?)
>>>
>>>  2: Plurality of token_endpoint_auth_method (could be left as a 
>>> string, made an array, or be a JSON-style optional plural: string 
>>> value if singular or array if plural)
>>>
>>>
>>>
>>> I think the first one should be addressed, but we just need to pick 
>>> the method. I'm personally in favor of the same method we used for 
>>> grant_type, which is short values in the spec and extensions as 
>>> fully qualified URIs. The second one could break existing 
>>> implementations (and other dependent specs), so if we change it, it 
>>> has to be for very good reason.
>>>
>>>  -- Justin
>>>
>>> On 04/24/2013 07:23 PM, John Bradley wrote:
>>>> In Connect there is a AS discovery before registration.
>>>>
>>>> The general pattern is the RP discovers the capabilities of the AS 
>>>> authentication methods and algorithms supported by the AS.
>>>> The client then picks the best options for it and registers them.
>>>>
>>>> It would in theory work of the client knowing nothing about the AS 
>>>> pushed it's capabilities at the AS as you are suggesting and let 
>>>> the AS pick.
>>>>
>>>> My general feeling is that discovery with the client picking the 
>>>> options works best.
>>>>
>>>> In many cases the client doesn't need to register parameters as 
>>>> they can be selected at run time once it knows what a server supports.
>>>> The token endpoint authentication method was a bit of a special 
>>>> case where even though it could be all dynamic and work, you do 
>>>> want to register a choice to prevent backwards compatibility attacks.
>>>>
>>>> I don't really want to complicate registration by trying to make it 
>>>> also cover AS discovery.
>>>>
>>>> John B.
>>>>
>>>> On 2013-04-24, at 7:55 PM, Phil Hunt <phil.hunt@oracle.com 
>>>> <mailto:phil.hunt@oracle.com>> wrote:
>>>>
>>>>> Right and if the client wants a method not supported then what?
>>>>>
>>>>> Why can't the client offer up a list of methods it is able to 
>>>>> support, say in order of preference?
>>>>>
>>>>> The text appears to indicate only one value may be passed.
>>>>>
>>>>> Given the way it is written. It seems better to just have the 
>>>>> server say the client must do authn method X in the response.
>>>>>
>>>>> Phil
>>>>>
>>>>> @independentid
>>>>> www.independentid.com <http://www.independentid.com/>
>>>>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 2013-04-24, at 3:41 PM, John Bradley wrote:
>>>>>
>>>>>> In Connect the AS may support a number of token endpoint 
>>>>>> authentication methods. The reason to allow a client to register 
>>>>>> using a particular one is to prevent downgrade attacks.
>>>>>>
>>>>>> If the client wants to always use an asymmetric signature you 
>>>>>> don't want to allow attackers to use weaker methods like http basic.
>>>>>>
>>>>>> So a server may support any number of methods, but it is 
>>>>>> reasonable for a client to specify which one it is going to use. 
>>>>>>   In a closed system that may not be that useful but in a open 
>>>>>> system where the AS has a looser relationship to the client it is 
>>>>>> important.
>>>>>>
>>>>>> John B.
>>>>>>
>>>>>> On 2013-04-24, at 7:30 PM, Phil Hunt <phil.hunt@oracle.com 
>>>>>> <mailto:phil.hunt@oracle.com>> wrote:
>>>>>>
>>>>>>> Hmmm… what was the objective or use case for having the client 
>>>>>>> being able to choose in the first place?
>>>>>>>
>>>>>>> It seems to me that the AS will make a decision based on many 
>>>>>>> factors. As you say, there isn't any other place that enumerates 
>>>>>>> the various [authn] methods a client can use to access the token 
>>>>>>> endpoint.  So, why do it?
>>>>>>>
>>>>>>> Phil
>>>>>>>
>>>>>>> @independentid
>>>>>>> www.independentid.com <http://www.independentid.com/>
>>>>>>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2013-04-24, at 2:07 PM, Justin Richer wrote:
>>>>>>>
>>>>>>>> Seems reasonable to me, can you suggest language to add in the 
>>>>>>>> capability? Would it require an IANA registry? Right now there 
>>>>>>>> isn't any other place that enumerates the various methods that 
>>>>>>>> a client can use to access the token endpoint.
>>>>>>>>
>>>>>>>>  -- Justin
>>>>>>>>
>>>>>>>> On 04/24/2013 04:17 PM, Phil Hunt wrote:
>>>>>>>>> For parameters to token_endpoint_auth_method, the spec has 
>>>>>>>>> defined "client_secret_jwt" and "private_key_jwt". Shouldn't 
>>>>>>>>> there be similar options of SAML?
>>>>>>>>>
>>>>>>>>> Shouldn't there be an extension point for other methods?
>>>>>>>>>
>>>>>>>>> Phil
>>>>>>>>>
>>>>>>>>> @independentid
>>>>>>>>> www.independentid.com <http://www.independentid.com/>
>>>>>>>>> phil.hunt@oracle.com <mailto:phil.hunt@oracle.com>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> OAuth@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>>
>>>>>
>>>>
>>>
>>