> On 26 Oct 2020, at 15:19, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Signed PGP part > > Eliot Lear <lear=40cisco....@dmarc.ietf.org> wrote: >>> The EAP server is expected to frequently request a OCSP response from >>> the OCSP responder (a server typically run by the certificate >>> issuer). The OCSP response is then added to the Servers Certificate >>> message as long as it is valid. Before the OCSP response is close to >>> expiring, the EAP server requests a new OCSP response from the OCSP >>> responder. > >> Right. What this is saying is that a local deployment MUST run an OCSP >> responder. If that OCSP responder is unavailable, then what? Now >> imagine we are discussing critical infrastructure where the responder >> is not in the same room, and there are network connectivity problems. >> The device joining the network needs local access and that is it. Does >> that mean it should not use EAP-TLS? Or are we saying that they MUST >> use naked public keys? > > No. There are several steps before we get to raw public keys. > > The first is that the duration of the Staples could be lengthed to accomodate > anticipated down time for the (now) critical OCSP responder. > A second part is that perhaps staples could be provisioned in advance for the > server to cover for planned maintenance periods. I don't imagine this is in > any protocol, but could be added.
But to what end? We don’t even know if these devices can reasonably deal with any secure notion of time. Even checking cert expiry is a bit questionable in some cases, especially if the cert has been seen before, and the device is of someone critical value. And it’s not clear what the value is with a lengthy expiry. > > The second is, I think, that the EAP server (Authentication Server), would run > an OCSP responder locally so that it can mint it's own staples. > AFAIK, each certificate can point to a different OCSP signer. Does anyone actually do that? > While this degenerate case of Authentication Server + OCSP Signer on the same > machine is kinda dumb from a overall security point of view, it's still > better than raw public keys. Yes. Let’s think about who OCSP is protecting in this case. It’s protecting the client from the Authentication Server, in theory. > If the OCSP signer is moved to some TPM then > there is a win. Not all TPMs can provide the performance required to handle > the server certificate, but resigning an OCSP Staple once every ten minutes > or something shouldn't be a problem. If this is the case, then a public key could be moved into the the TPM just as easily. > > The third is, I think, that the EAP server runs an entirely self-contained > private CA. The OCSP responder is now clearly an integral part of the local > system. Again, what threat are we protecting against? Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
