Subject: [Emu] EAP-TLS 1.3 - TLS extensions and mechanisms

From: John Mattsson <[email-masked]>
Date: Wed, 14 Nov 2018 14:04:29 +0000

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 <[email-masked]>
Date: Wednesday, 14 November 2018 at 13:50
To: "[email-masked]" <[email-masked]>
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: "[email-masked]" <[email-masked]>
Date: Wednesday, 14 November 2018 at 13:20
To: Mohit Sethi <[email-masked]>, John Mattsson <[email-masked]>
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

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Nov 2018 09:32:29 -0500

> "The use of Certificate Status Requests to determine the current status of the EAP server's certificate is RECOMMENDED."

  I think that's good.

> 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...

  I don't see major issues with it.

> - Fragmentation due to large certificates

  I would tend to agree.

  The only caveat is that RFC 7924 requires the completion of a full certificate exchange before caching can take place.  This requirement means that the handshake may not, in fact, complete, unless some other mechanism enables it.  The alternative is for the full handshake to work in one location, and then when a user moves locations and the certs change, it becomes impossible to authenticate.

  For some systems, the cached certificates can be pre-provisioned.  That means the full handshake is always avoided.

> 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 crypto…

  That concern can be mitigated by requiring a short lifetime for certs cached due to partial handshakes.  e.g. minutes, not days.  And, ensuring that the total number of certificates cached per site is limited to a small number, like 16.

> 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 l…

  My larger worry is that underlying SSL implementations may not support caching of certs from dropped handshakes.  It may be hard to add features to SSL libraries which are used only by EAP-TLS.

  Alan DeKok.

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 14 Nov 2018 14:56:34 +0000

I would be very hesitant to mandate RFC 7924. Most EAP-TLS 
implementations use existing TLS libraries rather than implementing 
their own TLS stack. And many popular TLS libraries don't provide 
support for RFC 7924. Please look at : 
https://github.com/openssl/openssl/issues/5040 for example.

Using RFC 7924 even for dropped handshakes requires wider community 
review and should stay in draft-ms-emu-eaptlscert. We should try to keep 
the two drafts in sync but independent. For me, shipping 
draft-ietf-emu-eap-tls13 within a reasonable time (say within 6 months) 
is more critical.

+1 on making OCSP stapling mandatory.

--Mohit

On 11/14/18 4:04 PM, John Mattsson wrote:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Wed, 14 Nov 2018 10:51:47 -0500

On Nov 14, 2018, at 9:04 AM, John Mattsson <[email-masked]> wrote:
> 
> Hi all,
> 
> I think the draft is now in quite good shape. It would be good to get some reviews. 

  A quick review, mostly NITs:

   Weaknesses found in previous versions of TLS, as well as new
   requirements for security, privacy, and reduced latency has led to

  I think this should be "... have led to ..."

   As stated in [RFC5216], the TLS cipher suite shall not be used to
   protect application data.  This applies also for early application
   data.  When EAP-TLS is used with TLS 1.3, early application data
   SHALL NOT be used.

 I'm not sure what section of RFC5216 says that the application data isn't protected.  Perhaps this could be clarified?

  Section 2.1.3:

   .. higher.  The two paragraphs below replaces the corresponding

 "replace", not "replaces"

  Section 2.1.5:

   Including ContentType and ProtocolVersion a single TLS record may be
   up to 16387 octets in length.  Some EAP implementations and access
   networks may limit the number of EAP packet exchanges that can be
   handled.  To avoid fragmentation, it is RECOMMENDED to keep the sizes
   of client, server, and trust anchor certificates small and the length
   of the certificate chains short.

  The subsequent text talks about modifying the certificate formats (ECC vs RSA) in order to shrink the certs.  It may be useful here to discuss other methods, too.

  e.g. adding full addresses, contact information, etc. into every certificate can increase the cert sizes by hundreds of bytes.  Admins should investigate ways to identify certificates (especially intermediate ones) via something *other* than using the certificate as a database.  Also, using many many intermediate certs should be discouraged.  While the structure of the cert chain may mirror management structure in a company, technical limitations may mandate a different structure for certificate chains.  In practice 2-3 intermediate certificates should be enough for most purposes.  It may be better to have  a wider "fan  out" of certificate dependencies, instead of a deeper chain of certs.

  Alan DeKok.