[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Cryptography] Mutually authenticated TLS
- From: "Kevin W. Wall" <kevin.w.wall AT gmail.com>
- Subject: [Cryptography] Mutually authenticated TLS
- Date: Mon, 5 Mar 2018 18:50:49 -0500
- Arc-authentication-results: i=1; mx.google.com; dkim=neutral (body hash did not verify) email@example.com header.s=20161025 header.b=TPSi6F5Q; spf=pass (google.com: best guess record for domain of cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com designates 18.104.22.168 as permitted sender) smtp.mailfrom=cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.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:list-subscribe:list-help :list-post:list-archive:list-unsubscribe:list-id:precedence:subject :to:message-id:date:from:mime-version:dkim-signature:delivered-to :arc-authentication-results; bh=5X0x9uoDviDCVngmr2zR2cjAks+ACwDYlWrNb4BFCw0=; b=xVkO6GAxY3pUppKC/Rmlc7/p05e+iTAp4VDsUaaKdDVqarujT/zUSv7sNlmo62kWmR Q6+pWsyHAN4MI+1n9G33+DgLnXyJpt/a3aPlSr7j7tyZNabhKupTaJwxgZqp/58W+3ow 1BcbI4FHBdknFF+j9M4RloaBuRNko0wBPKY7px32qE3gChJG5VqAiyszN/EXkZU0jPlK BES0oZ941kf4GmrM+KH9cYMoqYmeKOdCd2u6xWQvHcsxA8uea4EUQM7ifA/1MswFY1Ac XHNMMHHtBYnM/HTy0E90dDEPHPUakjoEC/NHXQMRmwMqaLOEuw0DgnUvshJ9qTvxm20C a89A==
- Arc-seal: i=1; a=rsa-sha256; t=1520302035; cv=none; d=google.com; s=arc-20160816; b=pryF2gy9t838OBXPRf/SCpQ9DNGAWKl4mXepMd6PUAzFvzQEmQg68nF3x61BA0D4+e QJ5LS7SXaOPIdsg44NqFGHjTLw2gKqMmM/rmr2RC2HXxd3prk4t8luD93qvnhnff6Noo VXBqOZS4KxTWj4/uWl3JUH/yOJ8LXfbxb4h4rfWVcEObU0hPwvP4zNz7BPI4kJ2gT8PB cOSAdxJfsKF1vZWMAuI1SW0PqPBsi3y8tcMxLR6T1gGKadw4FkH6PGdoDjS9qInjKf0i 60Vcpje38CPEFxpOUTiStbIdDa5JJ8/Hucx5bYEVw3FIQGDbKuzeRc3VafCvD4m6Snmp wq2A==
- List-archive: <http://www.metzdowd.com/pipermail/cryptography/>
- Sender: "cryptography" <cryptography-bounces+ben=bentasker.co.uk AT metzdowd.com>
- To: Cryptography Mailing List <cryptography AT metzdowd.com>
[Moderator: Sorry if this is slightly OT. I think it is tangentially
related to cryptography, but if a moderator rejects it, I'll
understand. But people here a a lot more clueful than those on Stack
Overflow, so I'm hoping it is allowed.]
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. (There are validating the entire cert chain and have
an internal CA that has to issue the cert.) 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.
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). 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
allowed. (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".
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?
Blog: http://off-the-wall-security.blogspot.com/ | Twitter: @KevinWWall
NSA: All your crypto bit are belong to us.
The cryptography mailing list
cryptography AT metzdowd.com