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

[Sergey Beryozkin <[e-mail]>]

Hi

In our implementation we support the following scenario:
- the client registers its public certificate during the client registration

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


-- 
Sergey Beryozkin

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