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

[Sergey Beryozkin <[e-mail]>]

On 10/11/16 21:57, Sergey Beryozkin wrote:
> On 10/11/16 20:10, Vladimir Dzhuvinov wrote:
>>
>>
>> On 03/11/16 19:11, Sergey Beryozkin wrote:
>>> Hi
>>>
>>> In our implementation we support the following scenario:
>>> - the client registers its public certificate during the client
>>> registration
>>
>> Did you extend the standard client reg API for this purpose?
> No. Should there be an option in the client reg API ?
>>
>> How does the cert registration actually take place?
> The encoded certificate is an optional property of the Client class
> which is part of the larger OAuth2 model. The clients are registered out
> of band - the assumption that the product integrating our model will let
> the admins upload a certificate associated with a given client,
> alongside all the other information one would typically allocate at a
> client registration time via some UI page.
> In a particular integration instance I'm aware of no such option to
> upload the certs is offered yet
>
> Sergey
>>
>>>
>>> - next, mutual/two-way TLS is used, so AccessTokenService tries to
>>> figure out the client_id. At the moment it assumes the client_id is
>>> (Java) X509Certificate.getSubjectX500Principal().getName().
>>>
>>> Next it retrieves a client with this name and compares the TLS
>>> client/peer certificate against the pre-registered one.
>>>
>>> I think it may be interesting to explore further if client_id can
>>> become optional based on what Samuel said.
>>>
>>> For example, indeed I can see how I can update our code to have a
>>> mapping between some of client certificate's properties and a client
>>> id stored within a Client registration.
>>>
>>> The question is how to find a given Client registration effectively
>>> given only a certificate, without an optional client_id. One would
>>> need to have a map between these client certificate attribute and
>>> client_id or Clients.
>>>
>>> Cheers, Sergey
>>>
>>>
>>>
>>> On 03/11/16 16:48, Samuel Erdtman wrote:
>>>> I can see your point, maybe the client_id will not be in the
>>>> certificate.
>>>> If I had an AS I would select to trust one or several CAs and then
>>>> create certificate mappings between certificate serial number (or some
>>>> other unique attribute in the certificate) and client_id. If I were to
>>>> bind a specific certificate to a client_id I lose the flexibility of
>>>> the
>>>> PKI (maybe what you want).
>>>>
>>>> I think multiple certificates might not be a uncommon situation
>>>> especially if you call ASs from different organizations because they
>>>> will trust different CAs.
>>>>
>>>> //Samuel
>>>>
>>>>
>>>> On Thu, Nov 3, 2016 at 5:32 PM, Justin Richer <[e-mail]
>>>> <mailto:[e-mail]>> 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] <tel:%2B1%20%28808%29%20652-3805>
>>>>>
>>>>>     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] <tel:%2B1%20%28808%29%20652-3805>
>>>>>>>
>>>>>>>     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] <mailto:[e-mail]>
>>>>>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>>     <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>>>
>>>>>>>>     _______________________________________________
>>>>>>>>     OAuth mailing list
>>>>>>>>     [e-mail] <mailto:[e-mail]>
>>>>>>>>     https://www.ietf.org/mailman/listinfo/oauth
>>>>>>>>     <https://www.ietf.org/mailman/listinfo/oauth>
>>>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>


-- 
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/