Joseph Salowey <j...@salowey.net> wrote:
> On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear
<lear=40cisco....@dmarc.ietf.org>
> wrote:
>> +1. How does anyone even do OCSP without having first gotten onto the
>> network?
> [Joe] THat is what OCSP stapling is supposed to solve since the OCSP
> messages are sent in the TLS handshake. I believe there are some EAP-TLS
> implementations that support OCSP, but I am not sure if it is actually
> deployed.
I think that it should say, if you do OCSP, then you must staple.
But, the intro suggests that revocation checking is mandatory with TLS 1.3.
(I didn't double check if that's MUST, SHOULD, or what)
Since CRLs won't be fresh and can't be retrieved until online, then it seems
that OCSP is needed if one is going to revocation checking.
What I read in section 5.4 is that servers have to support OCSP stapling
requests. I see a tiny bit of wiggle room as to whether the peer actually
must USE it :-)
Maybe that wiggle room can be made official for Hannes.
The document currently says: (1.0)
Privacy is mandatory and achieved without any additional round-trips,
revocation checking is mandatory and simplified with OCSP stapling,
and:
5.4. Certificate Revocation
This section updates Section 5.4 of [RFC5216].
While certificates may have long validity periods, there are a number
of reasons (e.g. key compromise, CA compromise, privilege withdrawn,
etc.) why client, server, or sub-CA certificates have to be revoked
before their expiry date. Revocation of the EAP server's certificate
is complicated by the fact that the EAP peer may not have Internet
connectivity until authentication completes.
EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate
Status Requests (OCSP stapling) as specified in [RFC6066] and
Section 4.4.2.1 of [RFC8446]. When EAP-TLS is used with TLS 1.3, the
peer and server MUST use Certificate Status Requests [RFC6066] for
the server's certificate chain and the EAP peer MUST treat a
CertificateEntry (except the trust anchor) without a valid
CertificateStatus extension as invalid and abort the handshake with
an appropriate alert. When EAP-TLS is used with TLS 1.3, the server
MUST check the revocation status of the certificates in the client's
certificate chain.
The OCSP status handling in TLS 1.3 is different from earlier
versions of TLS, see Section 4.4.2.1 of [RFC8446]. In TLS 1.3 the
OCSP information is carried in the CertificateEntry containing the
associated certificate instead of a separate CertificateStatus
message as in [RFC4366]. This enables sending OCSP information for
all certificates in the certificate chain.
>> Eliot
>>
>> On 21 Oct 2020, at 11:02, Hannes Tschofenig <hannes.tschofe...@arm.com>
>> wrote:
>>
>> Hi all,
>>
>> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and
I
>> believe this is a problem for implementations. This extra burden is IMHO
>> unjustified. For the type of deployments where EAP is used there is no
need
>> for a mandatory certificate revocation checking with OCSP.
>>
>> Having it optional, like the use of many other TLS extensions, is fine
for
>> me. FWIW even TLS 1.3, which is used in a more generic environment, does
>> not mandate the use of OCSP stapling.
>>
>> This requirement will make the problem described in
>> draft-ietf-emu-eaptlscert worse. I am sure the authors are aware of this
>> fact since they are also co-authors of draft-ietf-emu-eaptlscert.
>>
>> Ciao
>> Hannes
>> IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy
the
>> information in any medium. Thank you.
>> _______________________________________________
>> Emu mailing list
>> Emu@ietf.org
>> https://www.ietf.org/mailman/listinfo/emu
>>
>>
>> _______________________________________________
>> Emu mailing list
>> Emu@ietf.org
>> https://www.ietf.org/mailman/listinfo/emu
>>
> ----------------------------------------------------
> Alternatives:
> ----------------------------------------------------
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
--
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
