Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS

"Phil Hunt (IDM)" <phil.hunt@oracle.com> Mon, 08 February 2016 17:52 UTC

Return-Path: <phil.hunt@oracle.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 5DA391B2FF0; Mon, 8 Feb 2016 09:52:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 k3MkoX8D94qy; Mon, 8 Feb 2016 09:52:30 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4ECF1B3030; Mon, 8 Feb 2016 09:52:30 -0800 (PST)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u18HqQQt005764 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Feb 2016 17:52:27 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u18HqQmU017059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 Feb 2016 17:52:26 GMT
Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u18HqNIt032765; Mon, 8 Feb 2016 17:52:24 GMT
Received: from [192.168.1.23] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 08 Feb 2016 09:52:23 -0800
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (13D15)
In-Reply-To: <82E817C1-B95F-4E08-A7BC-E11164FFDD61@ve7jtb.com>
Date: Mon, 08 Feb 2016 09:52:21 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <F7B783CB-8D02-4D0A-8E18-82F619CDCBD1@oracle.com>
References: <56B31FEB.4010204@sics.se> <16330.1454596303@obiwan.sandelman.ca> <56B36703.8060305@sics.se> <36D7AE64-51CB-4437-AC28-9F912CD6B0D9@ve7jtb.com> <56B45DA7.6040408@sics.se> <82E817C1-B95F-4E08-A7BC-E11164FFDD61@ve7jtb.com>
To: John Bradley <ve7jtb@ve7jtb.com>
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/NMxLr0ruHYZHGMp0uVXhImiGAEI>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, oauth@ietf.org, ace@ietf.org
Subject: Re: [OAUTH-WG] [Ace] Questions about OAuth and DTLS
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: <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: Mon, 08 Feb 2016 17:52:37 -0000

There is a more general problem in PaaS deployment about how RA and AS infrastructure discover and coordinate with each other. For the most part this hasn't been necessary since usually the AS and RS are controlled by the same admins. But in PaaS/IaaS the requirements vary widely. 

How does an RS indicate to an AS what tokens it is able to support (directly or indirectly via a security module). And then subsequently for the as and rs to let the client know?

We need to broaden discovery to cover all the scenarios so that automated and secure config of AS/RS/Tkn/Reg/RS entities works. 

Phil

> On Feb 8, 2016, at 07:04, John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
> The RS is going to have to advertise what presentment mechanisms it supports.
> 
> We don’t have that yet.   I suspect that it might be part of OAuth Discovery.  Currently that mostly cover AS discovery, but for the RS I could see doing a head on the resource and getting back a link to a JSON document that would contain meta-data about the RS.
> 
> The standard OAuth answer to this question is the client would get it from the service documentation, but that is not really scalable.
> 
> 
>> On Feb 5, 2016, at 5:30 AM, Ludwig Seitz <ludwig@sics.se> wrote:
>> 
>> On 02/04/2016 05:14 PM, John Bradley wrote:
>>> In https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution
>>> 
>>> The proof key is included in the access token or provided out of band.
>>> 
>>> The proof mechanism to the RS is what would determine if the key type needs to match DTLS .
>>> If the proof is DTLS then they would need to match.
>> 
>> Thank you John, this leads me to another question (maybe I just missed it in the PoP drafts): Who decides what the proof mechanism should be? How is the proof mechanism signaled to the client (the client may support several proof mechanisms)?
>> 
>> /Ludwig
>> 
>> 
>> -- 
>> Ludwig Seitz, PhD
>> SICS Swedish ICT AB
>> Ideon Science Park
>> Building Beta 2
>> Scheelevägen 17
>> SE-223 70 Lund
>> 
>> Phone +46(0)70 349 9251
>> http://www.sics.se
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth