[Cryptography] Mutually authenticated TLS

Nico Williams nico at cryptonector.com
Thu Mar 8 18:25:00 EST 2018


On Thu, Mar 08, 2018 at 09:34:45PM +0100, Florian Weimer wrote:
> * Kevin W. Wall:
> 
> > 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".
> 
> A real downside is that encoding the access privileges in the
> certificate means that you need to reissue the certificate if
> privileges change.

In this case there's no problem because the necessary authorization data
is small, being just an OU in the DN.

> Red Hat does this approach for subscription certificates in the
> entitlement PKI:
> 
> <https://access.redhat.com/documentation/en-us/red_hat_subscription_management/1/html/rhsm/structure-of-ent-certificates>
> 
> Others can comment how smoothly this works out in practice.

Active Directory does this for Kerberos, but not PKI.  With PKI the
"PAC" is downloaded as needed, whereas with Kerberos it is included in
the ticket.

Does it work?  Yes.  Are there issues?  Definitely:

a) You won't have new grants until you get a new TGT and new service
   tickets -- whatever.  Windows does this periodically anyways.

   This will happen with the other approach too, since you want to cache
   the PAC anyways (so you don't refetch it too often; in some contexts
   that could happen way too frequently as you'll see below), but you're
   likely to have a much shorter TTL for fetched PACs than for Kerberos
   tickets.

b) Ticket bloat due to PACs is a serious issue.

   You see HTTP/Negotiate with huge headers for users who have many
   Windows group memberships.  This sometimes necessitates increasing
   header size limits on servers (ugh).

   Non-cookie-using apps will send an AP-REQ on *every* HTTP request, so
   this is tremendously wasteful.  Horrible.

On the other hand, having to fetch a PAC on the server side makes
authentication blocking when you need to fetch a new PAC.  This is not
exactly desirable...  It really is very nice that accepting Kerberos
authentication does not block...

One really does need to address (b).  The obvious thing to do is to use
cookies...  And, of course, TLS (which was needed anyways).  And
preferably also channel binding one way or another.  (Another thing to
do would be to have the acceptor return a new ticket to be used in
subsequent authentications, but this would require standards work.)

> In theory, it allows localized ACLs checks (without looking up the
> certificate in a database) and very good partition tolerance,
> especially if you do not need perfect certificate revocation checks.

Yes.  Especially if certificates are fresh.

Speaking of fresh certs, I think we should just converge on fresh certs
and to hell with OCSP and CRLs.  This necessitates an online CA to
re-issue certs often, but so what.

Nico
-- 


More information about the cryptography mailing list