Re: [OAUTH-WG] Dynamic Client Registration in trusted federation

George Fletcher <gffletch@aol.com> Fri, 01 June 2018 14:28 UTC

Return-Path: <gffletch@aol.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 F112712D883 for <oauth@ietfa.amsl.com>; Fri, 1 Jun 2018 07:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
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 Fls5yxc5jI4h for <oauth@ietfa.amsl.com>; Fri, 1 Jun 2018 07:28:10 -0700 (PDT)
Received: from sonic304-11.consmr.mail.bf2.yahoo.com (sonic304-11.consmr.mail.bf2.yahoo.com [74.6.128.34]) (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 B9DDC12D880 for <oauth@ietf.org>; Fri, 1 Jun 2018 07:28:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1527863289; bh=kFpmhxbbeu3XqTsEneQ3AGnoTYJfp82N5ytqFuNatwM=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=IaS5kvDQDY76wlBqTYfhZZfeI/rC8ISeE/FQ6MwJs8tC6IYYeGJ867jjU33Y9T7hWR9K1s+QkWtYKTC/DluCQApyIVvIl3nI4CP5ShC1fzDfHswpws2Q12f66X2j5/wjM/4o1q2JyngzfmJKR95U13g5j1Z3gaFs68mZmTcZ0wdzK+Ca2UxoHjJrkddJ4D62wEQHNPy8l/CBkQYFBoRcXt8n+SRM5uviUVqqQYN2ZcA+BOUkjI/OFirg7BQcdxbit7BQraPE4Xxo70nu14UUrkLPk9JbB+Gxz4aLrOTNAe1ZUWNSRCEQIS6m/0u/cM0DtCyf/iiGCtLOtmrvBCr2qw==
X-YMail-OSG: AHrHtFIVM1ktIaVPWVxaMBO56Tg.Hsx.2EudRLMsTDVGndm8_nz0jND7ksJE27A zM5pIrRnFYgZsqq.JtpR3_l0fV4zY93CTV4zK4Ia6u4aRV3f2jq7sod6IwBCCS3LnNdnUOL69HBT jk.WpOOcSqpz0FwonWuHsYXD43MeHIGtc3iAsVbMYcGIOAAT5hwUwwkcPvFAU_ULRZ_D_rTg3d9o jX8gOjSUKB.LcyZS8ZGlCnUq1fmFypLHkKJs_UnZOiFbV1lQSpHQVBXCYU7cPZ1tHmXLD8WQwWnn yZCHJNWA9zK3yZwRJvEZNBcd1NzrhCvQwuemhKHFcjUPEcR_xopsOKup9FCX8EiM6uHS6an4CFtZ 343j0sjzy2yfRJOsBn7dmlPRDd6ZBJ1_5uO3VHckZJEFyRNjjLQUGjlX75O6sad9C6_HoY9eZm_9 f0umH2QMkhFUOsVhWkalK3rCqldJVE.aES6rgzdblWerVy1doFv.IBAWgv.99Zbh5idvxhOy9odQ ywzIVrIdHETwa42xTWaJcHkWgulqaiJ7mNn3L9P.lIRmrTWY9ZyVEZASA_yE7cbzXV0dIRwJFZnf vNGIB9Qkcvg_.3EwaheMaHpRV1UP1sFKP6uejN8gN.CjBkTYQsjEYETHdOE59hryG.eM27WIpQ7s KIojHWHjhkuk_frkexkgJc2UH
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Fri, 1 Jun 2018 14:28:09 +0000
Received: from nat-wireless-users3.cfw-a-gci.net.dulles.office.oath (EHLO [172.130.136.180]) ([184.165.3.238]) by smtp406.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID be9f83e131f62a7f99dc67841202658b; Fri, 01 Jun 2018 14:28:06 +0000 (UTC)
To: Matt Pryor - UKRI STFC <Matt.Pryor@stfc.ac.uk>, "oauth@ietf.org" <oauth@ietf.org>
References: <59B07252-0FEA-433F-9DD7-F3C5A5B8CF66@stfc.ac.uk>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <f341cfcd-812e-3efc-dbc4-dfb047ad00b8@aol.com>
Date: Fri, 1 Jun 2018 10:28:05 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <59B07252-0FEA-433F-9DD7-F3C5A5B8CF66@stfc.ac.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/rMSYgc_cNOWiwhvbJsL1-Yu-ppM>
Subject: Re: [OAUTH-WG] Dynamic Client Registration in trusted federation
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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 Jun 2018 14:28:13 -0000

Given that you have a federation, could not the federation issue the 
signed software-statement to each of the relying parties (existing or 
old) and the AS will trust the dynamic client registration if and only 
if the signed software-statement is signed by the federation. This fits 
more closely with the trust framework model.

Thanks,
George

On 6/1/18 9:57 AM, Matt Pryor - UKRI STFC wrote:
> Hi,
>
> I am working on a use case of OAuth 2.0 in a federation and am after some advice about bootstrapping trust.
>
> Each site in the federation has an OAuth 2.0 authorization server and an OAuth 2.0 relying party. The relying party at each site needs to be registered with all the authorization servers in the federation. We want to automate as much of this process as possible, but restrict client registration to trusted members of the federation. We also want to make onboarding a new federation member as easy as possible.
>
> This seems an ideal use case for the Dynamic Client Registration Protocol (RFC 7591). The RFC permits the client registration endpoint to require a pre-existing token in order to register a new client which gives us our security (only trusted federation members can register a client).
>
> The challenge seems to be in bootstrapping the initial trust. It seems cumbersome to require that a new federation member must manually obtain a token from each authorization server before registering - they may as well manually register their client. I'd be interested to know if anyone has any ideas for a solution other than securely distributing a shared secret to new federation members.
>
> One possible option is to piggy-back on the legacy authn/z we already have - users can obtain an X509 certificate from their home idp, which is then trusted by all the other sites. We can then obtain SAML assertions about their permissions based on that certificate. We could use this mechanism to maintain a list of trusted admins, requiring authentication with an X509 certificate with the correct SAML assertion for the client registration endpoint. However, we are hoping to retire the X509 support in the short-to-medium term, so I'm also looking for solutions that do not use it. I'm also not sure how the use of X509 certificates would fit in with an RFC-compliant implementation of the Dynamic Client Registration Protocol.
>
> Thanks in advance for your help,
> Matt
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>