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

[Jim Manico <[e-mail]>]

> 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?

Ah, good point. I hear you now.  I personally like the idea of "one cert
per service" so I can selectively manage each access separately, but I
understand where you are coming from and it makes sense.

Thanks for taking the time to respectfully explain your perspective and
provide me with a little education. :)

ALOHA,

Jim Manico


On 11/3/16 12:32 PM, Justin Richer wrote:
> 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 <[e-mail]
>> <mailto:[e-mail]>> 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
>> [phone]
>>
>> On Nov 3, 2016, at 8:51 AM, Justin Richer <[e-mail]
>> <mailto:[e-mail]>> 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
>>>> [phone]
>>>>
>>>> On Nov 3, 2016, at 8:41 AM, Justin Richer <[e-mail]
>>>> <mailto:[e-mail]>> 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
>>>>>> <[e-mail] <mailto:[e-mail]>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>

-- 
Jim Manico
Manicode Security
https://www.manicode.com