[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Cryptography] Mutually authenticated TLS
- From: Viktor Dukhovni <cryptography AT dukhovni.org>
- Subject: Re: [Cryptography] Mutually authenticated TLS
- Date: Mon, 5 Mar 2018 21:22:59 -0500
- Arc-authentication-results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com designates 22.214.171.124 as permitted sender) smtp.mailfrom=cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:content-transfer-encoding:reply-to:list-subscribe :list-help:list-post:list-archive:list-unsubscribe:list-id :precedence:subject:to:references:message-id:date:in-reply-to:from :mime-version:delivered-to:arc-authentication-results; bh=PW3FbZ/KKlivG2ZbQrC2S/h3JmL+LwRNgKAbvcZsg/4=; b=R0DquRQhENLRPurCuMRWS1nbdrovNgRx3HgXXN0BP8iFnxo+PMcK71nSw2Eioj/nst LXtf2o4QolUbeqGdc6EbCQJJlD9dobarFhAV8Q43O8trRPDQHuaaWSRTYCt/ZUI0fgXI /8f95bPrxw4V22zhDYUGoauer51OzujZThIxjkGm31bPjIJA0lopWpFwM8nfKqCLfHxm Ul09BBnNWGZpDnQriLUDjXFRqyyvEKkdsyyu9sPRLyORPRZcjGdkCZ3dvt2++wmLi0t1 S27cb6v9hi0Czk8oNHSd48QivgISjItl7SEX/jInWNhIT3oOy2OQaqFt+1LC+lVbQaRf bI4w==
- Arc-seal: i=1; a=rsa-sha256; t=1520303392; cv=none; d=google.com; s=arc-20160816; b=SkUQTLXQdjGoFXkKuTjLsw8TRihdxh7h6qjOKwX7JpCMWifz2glvc5/4clXwh/hxvb 0xbX+LZDmY5J/lgUsgHbYv88Mb2zAvJrg5s2yA2/p0IpCumN417n718BU2h7I4Sm7eRH GPVRz1y3r8GGMwWNqE7FSO37xgxiMQm5zVCCO1V5BYt9CaobWWbiScv8JFzJ4DSwZ2Nl GlCFBnYezDkLfEDIXatpC1cQxYiR/+7PcxW15Z/YiC2kRBk/eIyIfPY5VjJunONVsCBz FAJfaV0uawnby8Tzy8fHw+bpfEI4mz2XvU3YHfKcI5hpu85cHT62eeS6m0SuXZygJDhl zpZg==
- List-archive: <http://www.metzdowd.com/pipermail/cryptography/>
- Reply-to: cryptography AT metzdowd.com
- Sender: "cryptography" <cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com>
- To: cryptography AT metzdowd.com
> On Mar 5, 2018, at 6:50 PM, Kevin W. Wall <kevin.w.wall AT gmail.com> wrote:
> I'm working with someone who is issuing X.509 client-side certificates
> used for authenticating against a REST-base web service.
> That person is says that the server code for the web service is only
> checking for a specific OU in the client cert's DN to do the
> authentication. (They're are validating the entire cert chain and have
> an internal CA that has to issue the cert.)
If the internal CA in question only grants certificates for names in
this OU to clients authorized to use the application in question, and
if revocation is considered not important (e.g. short-lived certs), or
CRLs are being checked. Then there's nothing wrong with this approach.
> I tried to explain that
> ideally, the entire client cert or at least it's public key should be
> used for the authentication process, but short of that, at least use
> the full, canonicalized DN.
TLS makes sure that the public key in the certificate signs the client
key exchange. So the key is always checked. The CA binds the key to
the OU. So this is all fine. The full DN has little authentication
value if all clients get the same access level. It might be useful
in an audit trail, but is not necessarily needed for access control.
> I find it rather odd that if they are going to use only a portion of
> the DN, that they wouldn't at least use the CN rather than some OU and
> explained my concern about having two different DNs with the same OU
> (which is supposed to represent a specific client application invoking
> the web service).
Since the server was not looking to communicate with a specific client,
but rather *some* client started communicating with the server, there's
little to be gained by checking the "CN" (against what exactly?) if all
possible "CN" values get the same access.
> E.g., one DN containing OU=abc,OU=applName and the
> other containing only OU=applName and otherwise the same. Because the
> server is only looking if the DN contains 'OU=applName', then the
> [supposedly unauthorized] cert with the DN containing
> 'OU=abc,OU=applName' could be used to authenticate as well, even
> though only the one with a single 'OU-applName' was intended to be
But the access control token is the "OU"...
> (Fortunately, the intermediate CA is manually vetting all
> requests and there's a very small number of clients certs issues so
> they claim they would catch this by their manual vetting process, but
> still it leaves me feeling a bit uneasy.)
> They are telling me that what *they* are doing is "standard practice"
> and what I was proposing (to minimally at least check the full,
> canonicalized DN) as "an acceptable compromise under some conditions,
> but should be avoided".
You're asking them to implement a more fine-grained access check in
the application, but they're comfortable doing that in the CA, and
either don't have a revocation requirement, or process CRLs.
> So I was just wondering, is anyone aware of any standards documents
> such as RFCs or some widely cited "best practices" document that I can
> refer them to?
The RFCs are out of scope here. Access control decisions are up to
the verifier. The certificate is valid, what part of it they choose
to base access control on is up to them.
The cryptography mailing list
cryptography AT metzdowd.com