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.
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.
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. 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.
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.
Do we need to write an Operational Considerations document here?
> For many devices the manufacturers will be unable to predict whether a
> device will or will not have direct access to anything. It specific to
> deployment circumstances. Also, running an OCSP server is something
> that will be very new for many enterprises.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
