|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
Date: Tue, 22 Sep 2020 17:00:19 -0700 From: Benjamin Kaduk <kaduk@mit.edu> To: Ken Hornstein <kenh@cmf.nrl.navy.mil> Message-ID: <20200923000019.GT89563@kduck.mit.edu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <202009222349.08MNn5b2020102@hedwig.cmf.nrl.navy.mil> Cc: krbdev@mit.edu Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: krbdev-bounces@mit.edu On Tue, Sep 22, 2020 at 07:49:05PM -0400, Ken Hornstein wrote: > >Just to acknowledge: this seems like a valid use case(*), but it would > >require a significant restructuring of the PKINIT server code (which > >contains a lot of technical debt as it is), so I wouldn't expect it to > >happen soon. Changing the certauth plugin API isn't a big problem; new > >methods could be added for async plugins. > > Yeah, when I dug into this I got a sense of the scope of the problem. > Certainly this is NOT easy, and I just wanted to float it as a trial > balloon in case someone else came up with this as a requirement. > > >For now, I'd suggest seeing if you can sync a copy of the cert deny list > >to each KDC, and check against it locally in the plugin module. > > Well, we do that today with our existing PKINIT server side plugin that > I am trying desperately to kill, and it works fine ... with the caveat > that we talk to an OCSP responder running locally on the KDC (like I > explained in my previous message). The problem is the total number of > CRL entries we have to deal with is more than 8 million, changes daily, > and most applications simply can't deal with that. My reading of the > PKINIT code is that it loads all of the CRLs into memory at startup and > doesn't reload them if they change (but I fully admit that I could > be reading that wrong, since it involves a lot of OpenSSL code). > > >(*) With the caveat that online OCSP checking hasn't been successful in > >the context browsers, because of the added latency and the bad user > >experience if the browser fails closed. And there isn't much security > >value if you fail open, because an attacker could potentially deny > >access to the OCSP server. In the context of PKINIT and a > >within-the-enterprise OCSP server, online checking might make more sense. > > It's not that I disagree with you here and we don't typically enable > OCSP checking on clients, but it is a requirement that we do client > certificate revocation checking on our servers and I can't really > ignore that. We have a custom OCSP server that can handle 8 million > CRL entries without a problem (it stores them in a Berkeley DB and can > handle updates and adding/removing CAs without issues), and from from > my perspective it makes sense to make the interface for CRL checking > via OCSP since that seems to be where the world is going and the OCSP > protocol is already handled well by OpenSSL and we can re-use our OCSP > server code with applications like Apache. > > Anyway, I understand where you are coming from and I knew this was going > to be a heavy lift; I don't need it in the short term since having a > co-located OCSP server on the KDC has been working fine, but if you ever > get around to adding async support the PKINIT plugin I'll definitely > make use of it. FWIW I think that OpenSSL 3.0 will make it a bit easier, with the "read stuff from disk" having been genericized/modularized and letting you "drop in" alternative implementations via "provider" modules, but of course OpenSSL 3.0 is not done yet... -Ben _______________________________________________ krbdev mailing list krbdev@mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev
|
|
|
|
|
|
|
|
|
|
|
|
| home | help | back | first | fref | pref | prev | next | nref | lref | last | post |