I think mandatory support and use of stapling is a great idea. There have been
so many changes across platforms the past few years w.r.t. status checks during
an EAP exchange which has caused significant admin and end user headache. This
solves that by making it consistent while adding the security value of
revocation checks for the server identity.
Mandating support for the Cached Information Extension also seems like a good
idea given the uptick of EAP-TLS usage and larger chains. I'd definitely be
interested in hearing the TLS WGs opinion on this before being comfortable with
mandating use.
tim
On 11/14/18, 9:04 AM, "Emu on behalf of John Mattsson" <emu-boun...@ietf.org
on behalf of john.matts...@ericsson.com> wrote:
Hi all,
I think the draft is now in quite good shape. It would be good to get some
reviews. One thing that I would like to discuss is what the draft should say
about various extensions and mechanisms. In particular:
- Revocation
------------------------------------------------------
RFC 5216 says:
"EAP-TLS peer and server implementations MUST support the use of
Certificate Revocation Lists (CRLs)"
"EAP-TLS peer and server implementations SHOULD also support the Online
Certificate Status Protocol (OCSP)"
"EAP-TLS peers and servers SHOULD implement Certificate Status Request
messages"
draft-ietf-emu-eap-tls13-03 adds:
"The use of Certificate Status Requests to determine the current status of
the EAP server's certificate is RECOMMENDED."
For EAP-TLS where the peer often does not have internet connection OCSP
stapling is often by far the most appropriate mechanism. Is it time to make
Certificate Status Requests (OCSP stapling) mandatory to implement for EAP-TLS
with TLS 1.3?
My view would be yes, OSCP stapling is solving a lot of issues with
revocation, especially for EAP-TLS. I think OCSP stapling should be mandatory
to support and maybe also mandatory to use...
What is the working group's opinion about revocation mechanisms?
- Fragmentation due to large certificates
------------------------------------------------------
draft-ietf-emu-eap-tls13-03 says:
"EAP-TLS peers and servers SHOULD support and use the Cached Information
Extension as specified in [RFC7924]."
draft-ms-emu-eaptlscert-01 says:
"The extension however necessitates a successful full handshake before any
caching. This extension can be useful when, for example, when a successful
authentication between an EAP peer and EAP server has occurred in the home
network."
As fragmentation of large certificates is a large problem in EAP-TLS
deployments, would it make sense to mandate support and or use of RFC 7924 when
TLS 1.3 is used?
Also, in IETF 102 we discussed cached information and the possibility for
the client to cache the server's certificate from a dropped handshake. I though
more about this and I cannot see any cryptographic problems with the client
caching the server's certificate from a dropped handshake. The client can
verify the certificate anyway, but the server may not have time to prove
possession of the private key before the handshake is dropped. Getting
certificates out-of-band is common in many cases. The only problem I can see is
that an attacker could try to fill the peer's memory storage by sending
certificates to the client, but this does not give any amplification and could
easily be mitigated by the client only caching a single or very few
certificates.
As fragmentation of large certificates is a large problem in EAP-TLS, my
view would be that we should specify that the peer can cache certificates from
a dropped handshake. With this change is it likely almost always possible to do
EAP-TLS even if the authenticator drops the connection after 40-50 packages. If
we decide to do this, we should tell the TLS working group that we are planning
this and ask for their view.
(Note that the whole Fragmentation section in draft-ietf-emu-eap-tls13
should be updated when draft-ms-emu-eaptlscert gets adopted by the WG).
/John
-----Original Message-----
From: John Mattsson <john.matts...@ericsson.com>
Date: Wednesday, 14 November 2018 at 13:50
To: "emu@ietf.org" <emu@ietf.org>
Subject: FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
Hi,
We have updated the draft according to the discussion and conclusions at
IETF 103.
- New figure showing the message flow for EAP-TLS client rejection of
NewSessionTicket
- The draft did not mention that TLS has both warning and fatal alerts. We
changed "TLS Alert Message" to " TLS Fatal Alert" and added a few sentences
that describe the difference.
"Figures 4, 5, 6, and 7 illustrate message flows in several cases
where the EAP peer or EAP server sends a TLS fatal alert message.
TLS warning alerts generally mean that the connection can continue
normally and does not change the message flow. Note that the party
receiving a TLS warning alert may choose to terminate the connection
by sending a TLS fatal alert, which may add an extra round-trip, see
[RFC8446]."
- Made it mandatory to always conceal the username in the Identity
Response. This led to smaller changes in several places.
-- Text were updated to reflect this is mandatory
-- Changed "Identity (MyID)" to "Identity (Anonymous NAI)" in all figures
-- Removed the "privacy" figure as that is no longer needed. Instead the
section refer to Figure 1.
- Added "and all Post-Handshake messages have been sent" to page 3. The new
sentence reads:
"After the TLS handshake has completed and all Post-Handshake messages
have been sent, the EAP server sends EAP-Success."
- Several editorials.
Cheers,
John
-----Original Message-----
From: "internet-dra...@ietf.org" <internet-dra...@ietf.org>
Date: Wednesday, 14 November 2018 at 13:20
To: Mohit Sethi <mo...@piuha.net>, John Mattsson
<john.matts...@ericsson.com>
Subject: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
A new version of I-D, draft-ietf-emu-eap-tls13-03.txt
has been successfully submitted by John Mattsson and posted to the
IETF repository.
Name: draft-ietf-emu-eap-tls13
Revision: 03
Title: Using EAP-TLS with TLS 1.3
Document date: 2018-11-14
Group: emu
Pages: 22
URL:
https://www.ietf.org/internet-drafts/draft-ietf-emu-eap-tls13-03.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
Htmlized: https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-03
Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-03
Abstract:
This document specifies the use of EAP-TLS with TLS 1.3 while
remaining backwards compatible with existing implementations of EAP-
TLS. TLS 1.3 provides significantly improved security, privacy, and
reduced latency when compared to earlier versions of TLS. EAP-TLS
with TLS 1.3 provides significantly improved protection against
pervasive monitoring by mandating use of privacy. This document
updates RFC 5216.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________
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
