Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues

John Bradley <ve7jtb@ve7jtb.com> Thu, 05 March 2015 11:54 UTC

Return-Path: <ve7jtb@ve7jtb.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701B01B2C36 for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 03:54:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrno0TGZEfMz for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 03:54:54 -0800 (PST)
Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6B451A1B4C for <oauth@ietf.org>; Thu, 5 Mar 2015 03:54:53 -0800 (PST)
Received: by wevl61 with SMTP id l61so15480204wev.0 for <oauth@ietf.org>; Thu, 05 Mar 2015 03:54:52 -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=MXW0lPAr0zOYi9Kuk5Z2eDFGiJyGxLfNxcXR5MHnknw=; b=Ik8xGevfNgeYn9Tssg6J1rNY+BaDchnYOBVSpCUZlo/A0qWGJJSoUZL3/BOd0wrBLp bJDBgWmwwqVfRjPWu1C/FPE/8BcxqPMhlt9ay1N0snFnRherR4iFYcv84tZb0OvVEyJX 278dOkuFo7eI60sIsUCJAI3ihsBcJSJbjddj+SI4am/wF6YGk6+3rCyVyS7KaL3cOqAI 7BUHHRc4eQK1ZkCNj4he9o3LYFrB7JRM66RT0GaSHHi6OTp5/7ZqsDfsYZNrhWOF3RkS PLezlXax3qkRnBXGBhdhFeLTaVhY4j8BETLLPMhB3XPHM342rBvfwJ94NzKIVnKIBZmc UxpA==
X-Gm-Message-State: ALoCoQm6Ekjtnp1i8JsO7c9ninDpnpyiS9rqj5Ze/Q4y8cTthxfIzFrffVD8yHpzErPeLKhEr32y
X-Received: by 10.194.62.167 with SMTP id z7mr18075499wjr.106.1425556492708; Thu, 05 Mar 2015 03:54:52 -0800 (PST)
Received: from [10.6.0.209] ([95.211.146.166]) by mx.google.com with ESMTPSA id bd1sm8656196wib.13.2015.03.05.03.54.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 03:54:51 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_4510CBE6-ED69-46F3-B22F-C97E758CEFC9"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <54F83F32.3040305@gmx.net>
Date: Thu, 5 Mar 2015 12:54:39 +0100
Message-Id: <FE8540FB-5CF6-4B1F-9C07-21638865AB17@ve7jtb.com>
References: <54F81ADA.3000203@gmx.net> <0B09DB9C-CB26-448D-AE4B-F50E37C2560A@ve7jtb.com> <54F83F32.3040305@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/64u9uzmuGJsHkHSp2mgIfMVKeDM>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-pop-key-distribution-01 and Open Issues
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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, 05 Mar 2015 11:54:56 -0000

For signing authentication requests you include the keyid in the JWT, and the AS looks in the JWKS to find the correct key if there is more than one.

I don't think that is a problem

What we probably need to do is pass a keyid in the request if there is more than one signing key registered for the client.

John B.

> On Mar 5, 2015, at 12:34 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> 
> Hi John,
> 
> 
> On 03/05/2015 10:27 AM, John Bradley wrote:
>> inline
>>> On Mar 5, 2015, at 9:59 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>> 
>>> Hi all,
>>> 
>>> I refreshed the PoP key distribution document. No changes to the
>>> content of the document.
>>> 
>>> The document contains two questions, namely
>>> 
>>> QUESTION: A benefit of asymmetric cryptography is to allow clients to
>>>  request a PoP token for use with multiple resource servers.  The
>>>  downside of that approach is linkability since different resource
>>>  servers will be able to link individual requests to the same client.
>>>  (The same is true if the a single public key is linked with PoP
>>>  tokens used with different resource servers.)  Nevertheless, to
>>>  support the functionality the audience parameter could carry an array
>>>  of values.  Is this desirable?
>>> 
>>> 
>>> Hannes: My view is that we do not want to introduce likability into
>>> OAuth via the use of these keys. As such, different keys for different
>>> origins.
>>> 
>>> 
>> John:  Having an array increases complexity and decreases privacy by allowing RS to link.
>> 
>> Audiance should be a single value.  That requires separate keys for symmetric, or asymmetric keys provisioned by the AS.
>> 
>> For asymmetric keys provisioned by the client it would be up to the client to decide if using the same key for multiple RS makes sense.  
>> 
>> It might be that there is a single key provisioned by a MSM in the tpm that they want to use for all the connections as that is the most secure, and are not concerned with correlation as all the RS are internal to a single enterprise.
>> 
> 
> OK.
> 
>> 
>> 
>>> QUESTION: Should we register the token_type and alg parameters for use
>>> with the dynamic client registration protocol?
>>> 
>>> Hannes: I believe we should register these two parameters into the
>>> dynamic client registration protocol since that allows us to configure
>>> the values for the client rather than exchanging them with every message.
>>> 
>> John:  Yes I had assumed that that was a no brainer.
>> The other question on registering is if we should allow the client to preregister a public key as well.
>> In some situations the client may want to always use the same key and making them push it each time is a waste of bandwidth.
> The dynamic client registration already supports the feature of
> uploading a public key to the authorization server and hence the missing
> feature to support that case is to allow the client to refer to that key
> somehow. I assume that the public key uploaded by the dynamic client
> registration protocol is referenced using a URI. The question is just
> what that URI would be.
> 
> Unfortunately, the Dynamic Client Registration spec is silent about how
> to reference the public key uploaded via the jwks parameter. Did we just
> found a bug in the spec?
> 
> Ciao
> Hannes
> 
> 
>> 
>> John B.
>>> Feedback appreciated before the submission deadline.
>>> 
>>> Ciao
>>> Hannes
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth