Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Justin Richer <jricher@mit.edu> Thu, 03 November 2016 16:32 UTC

Return-Path: <jricher@mit.edu>
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 09810129505 for <oauth@ietfa.amsl.com>; Thu, 3 Nov 2016 09:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.697
X-Spam-Level:
X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 Y0g165ILPFsN for <oauth@ietfa.amsl.com>; Thu, 3 Nov 2016 09:32:51 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 4E209129658 for <oauth@ietf.org>; Thu, 3 Nov 2016 09:32:50 -0700 (PDT)
X-AuditID: 1209190e-d3fff70000002f99-45-581b66b0729f
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 82.23.12185.0B66B185; Thu, 3 Nov 2016 12:32:49 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id uA3GWmDK017679; Thu, 3 Nov 2016 12:32:48 -0400
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uA3GWjXn025847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Nov 2016 12:32:46 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_8ECDA5C2-45FD-47E9-BC4D-0F17EBD3CF76"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <B6AF115B-A0FB-47B1-851B-9BC198D3E36A@manicode.com>
Date: Thu, 03 Nov 2016 12:32:45 -0400
Message-Id: <67189330-9FC0-4A10-815D-9EA5047BA3EF@mit.edu>
References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <CA+k3eCQaWm+O8VMNGGJG41j=dW2vqa4n6QZgKmVM9=d0HxgnCA@mail.gmail.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <CAF2hCbYn5_qBTmYkeJVCtJ-0=zWdRcFfu+0cHHb4ygo6as_V6w@mail.gmail.com> <CA+k3eCRXss-4_Cxmi41YAcXHh0VKeHogGT=xNkAo1mU6e5WG1w@mail.gmail.com> <CAF2hCbaEi4ntDwbWpTJ4-7_uwunK5WhpsoVLKds87r_s4K7n1w@mail.gmail.com> <CA+k3eCRq=P=0wqBx7O3C--fJYTEsuP1WH+1of53_oWb=bxfssw@mail.gmail.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> <9D3DD1DC-1432-4CB9-9122-F47CB87ABD58@manicode.com> <55855cf4-e683-95b4-38e0-788f402c8cd2@mit.edu> <B6AF115B-A0FB-47B1-851B-9BC198D3E36A@manicode.com>
To: Jim Manico <jim@manicode.com>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsUixCmqrLsxTTrCYNdjbovV/28yWrzYf5Dd 4uTbV2wWn28dZrX4v/QUkwOrx4t/exg9liz5yeTxfGc/k0fjjAeMHnePXmQJYI3isklJzcks Sy3St0vgyji6bR5LwY25jBW9O/axNzD+Kehi5OSQEDCRmPVpGxOILSTQxiQx+3JMFyMXkL2B UWLzlzY2COcBk8Te7dtZuhg5OJgFEiTef+IGaeAV0JPYtP4tWLMwUPjMq3Ywm01AVWL6mhYw m1PAQeL6u+csIDaLgIpE38KT7CA2s8AdRontt2Ig5lhJzNj8CGpXF5vEgfetYA0iAooSB/Y0 MUFcKivx5OQilgmM/LMQzpiF5IxZYGO1JZYtfM0MYWtK7O9ezoIpriHR+W0i6wJGtlWMsim5 Vbq5iZk5xanJusXJiXl5qUW6xnq5mSV6qSmlmxjBUSHJt4NxUoP3IUYBDkYlHl4HH+kIIdbE suLK3EOMkhxMSqK8i2OAQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4NyUC5XhTEiurUovyYVLS HCxK4rz/3b6GCwmkJ5akZqemFqQWwWRlODiUJHgVgNEvJFiUmp5akZaZU4KQZuLgBBnOAzS8 IxVkeHFBYm5xZjpE/hSjopQ47xOQhABIIqM0D64XlLQS3h42fcUoDvSKMC83yAoeYMKD634F NJgJaLB5kgTI4JJEhJRUA2OXw7qJ1+YYpCgnXJ7hsepz5o/k/1MuVv6+/H5Pl3n+O9sXibvt DRsFxbwfvGDND9M3PFZQ/Hjv0dkMiel9kn3OM3i27dubcpBD+ETRoqCJwXuz13L7/9XY/Cbl 9Z33pZUMi0qKeF4v5N1g9kD36Sv3cveMzddTb7XvMCtcwZbF3p3y/t/6oJVKLMUZiYZazEXF iQB4ZDzpNQMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/PhDm4pFvZxvR3Vu4SUCg7HNvrYY>
Cc: Nat Sakimura via Openid-specs-fapi <openid-specs-fapi@lists.openid.net>, "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 03 Nov 2016 16:32:55 -0000

Jim,

In those circumstances, are the clients generally calling multiple different services? Or just one? For those that call multiple services, are they using multiple (different) client certificates?

I’m not saying the client would issue its own cert in all cases — much more common is what I’ve seen, with clients being assigned a certificate from a trusted CA, and then services that the client talks to being told to trust that CA and also assign the CN/DN of the cert a set of privileges. What I *haven’t* seen is a client being issued multiple certificates to talk to multiple systems. That latter case is common enough in the OAuth world that I wouldn’t want us to paint ourselves in a corner.

 — Justin

> On Nov 3, 2016, at 10:31 AM, Jim Manico <jim@manicode.com> wrote:
> 
> Thanks Justin. I use several security intel services and they all have different cert delivery mechanisms for mutual TLS. It's •rare• for services to let clients choose certs, they are usually assigned to users by each service from my experience.
> 
> Aloha,
> --
> Jim Manico
> @Manicode
> Secure Coding Education
> +1 (808) 652-3805
> 
> On Nov 3, 2016, at 8:51 AM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
> 
>> Yes, I elided the certificate issuance process. The point remains the same: you're not going to be submitting a CSR to the same party you're getting your client_id from, usually. If the draft assumes that, then it's incredibly limiting.
>> 
>> 
>> Do people really use separate TLS client certs for separate connections in the wild? I've personally never seen that. What I've seen is that a piece of software gets its certificate that it uses to make whatever connections it needs to make.
>> 
>> 
>>  -- Justin
>> 
>> On 11/3/2016 8:48 AM, Jim Manico wrote:
>>> Just to be clear, the relationship should more like...
>>> 
>>> AS issues public key to clients, or client sends public key to AS. The authorities job is NOT to give the client the public key, but to sign the public key for authenticity. It's bad practice to accept the full cert (pub key+signature) from an authority. If an authority is creating your public key, they are also creating your private key.... bad.
>>> 
>>> > The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id. 
>>> 
>>> This seems like a bad idea. I suggest a separate key/signature for each service.
>>> --
>>> Jim Manico
>>> @Manicode
>>> Secure Coding Education
>>> +1 (808) 652-3805
>>> 
>>> On Nov 3, 2016, at 8:41 AM, Justin Richer <jricher@mit.edu <mailto:jricher@mit.edu>> wrote:
>>> 
>>>> I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id. 
>>>> Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today. 
>>>> I do think that more examples and guidance are warranted, though, to help AS developers.
>>>> 
>>>>  -- Justin
>>>> 
>>>> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>>>>> 
>>>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se <mailto:samuel@erdtman.se>> wrote:
>>>>> 
>>>>> I agree it is written so that the connection to the certificate is implicitly required but I think it would be better if it was explicit written since the lack of a connection would result in a potential security hole.
>>>>> 
>>>>> That's fair. I agree it can be made more explicit and that it be good to do so. 
>>>>> 
>>>>>  
>>>>> When it comes to the client_id I think subject common name or maybe subject serial numbers will be the common location, and I think an example would be valuable.
>>>>>  
>>>>> 
>>>>> In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly common. 
>>>>> 
>>>>> I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward. 
>>>>> 
>>>>>  
>>>>> 
>>>>> I´m not saying it is a bad Idea just that I would prefer if it was not a MUST. 
>>>>> With very limited addition of code it is just as easy to get the certificate attribute for client id as it is to get it from the HTTP request data (at least in java). I also think that with the requirement to match the incoming certificate in some way one has to read out the certificate that was used to establish the connection to do some kind of matching.
>>>>> 
>>>>> 
>>>>> Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus. 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>