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

[Vladimir Dzhuvinov <[e-mail]>]

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?

How does the cert registration actually take place?

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

-- 
Vladimir Dzhuvinov :: [e-mail]