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 <jric...@mit.edu
<mailto:jric...@mit.edu>> 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 <j...@manicode.com
<mailto:j...@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 <tel:%2B1%20%28808%29%20652-3805>
On Nov 3, 2016, at 8:51 AM, Justin Richer <jric...@mit.edu
<mailto:jric...@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 <tel:%2B1%20%28808%29%20652-3805>
On Nov 3, 2016, at 8:41 AM, Justin Richer <jric...@mit.edu
<mailto:jric...@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
<sam...@erdtman.se <mailto:sam...@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>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
