Subject: [Emu] I-D Action: draft-ietf-emu-eaptlscert-02.txt

From: [email-masked]
Date: Mon, 16 Mar 2020 00:38:58 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

        Title           : Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods
        Authors         : Mohit Sethi
                          John Mattsson
                          Sean Turner
	Filename        : draft-ietf-emu-eaptlscert-02.txt
	Pages           : 12
	Date            : 2020-03-16

Abstract:
   EAP-TLS and other TLS-based EAP methods are widely deployed and used
   for network access authentication.  Large certificates and long
   certificate chains combined with authenticators that drop an EAP
   session after only 40 - 50 round-trips is a major deployment problem.
   This memo looks at the this problem in detail and describes the
   potential solutions available.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eaptlscert-02
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-02

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Mar 2020 12:57:51 -0400

Hi, I didn't know about this document, and I've just read it.

Some questions:

1) "RADIUS can generally transport only about 4000 octets of EAP in a single
   message."

   Can you explain this?  Radius over UDP would have fragment a 4000 octet
   message, so why is the number 4000?  That's three fragments.  Is the
   loss amount beyond this too high?  Or is it that common implementations
   just don't support larger sizes?

   RFC6613 radius over TCP would not seem to have that limitation, but
   I won't be surprised if it is less common. I've certainly used it
   as it solves the the NAT and Radius key problem. (Alan?)

2) the problem appears is documented to occur at 60Kbyte chain size.
   With 6 intermediate certificates in the chain, that provides for
   10KByte for each certificate, which seems rather generous to me.
   I am not objecting to solving the problem as stated, but I want to
   understand what the goals really are.

   The advice in section 4.1 is good.  Are full postal addresses in
   intermediate CAs really the culprit here?

3) section 4.2.2, about caching certificates from a previous TLS session
   is interesting.  I'm unfamiliar with rfc7924, does it use a session
   resumption ticket, or will any previous connection do?
   (It seems that a session resumption process is not required?)
   This might provide motivation Alan's question about why/how one
   might resume an HTTPS TLS session over EAP-TLS.

I was surprised to get to the end of the document without any suggestions
about sending certificates by reference rather than value.
This is the method that we have adopted on draft-selander-ace-ake-authz.
We considered using the mathmesh UDF mechanism, but found a way that could
instead send only the location while actually encrypting the ID as a privacy
enhancement.
I don't think such a thing would be desireable, and TLS 1.3 provides other
equivalent privacy enhancements, but I want to suggest you consider a new
certificate container which contains a reference.  IKEv2 already has that.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 Mar 2020 17:45:27 -0400

>   just don't support larger sizes?

  RFC 2865 says that the maximum RADIUS packet size is 4K octets.  Given some overhead for the packet header and other attributes, a reasonable limit for EAP is 4000 octets.

>   as it solves the the NAT and Radius key problem. (Alan?)

  RFC 6613 doesn't solve the 4K limit.  That's solved by RFC 7930.  I'm not aware of any products supporting that, tho.

>   intermediate CAs really the culprit here?

  It's the bloat of "meh, put everything into the certificate".

  The problem is that when certificate chains fail, the admins don't tell people.  They *might* ask a question on a public mailing list... or not.  But they won't share *what* they did to bloat the certificate chain.

  I've seen people run into this in the real world.  And then express great surprise when told "No, you can't really have 60K+ certificate chains.  This isn't HTTP."

  The advice here is necessarily vague, because we don't know exactly what the admins are doing.

>   might resume an HTTPS TLS session over EAP-TLS.

  TLS 1.3 makes it easier to cache the certificates.  But you may have to exchange them at least once, which makes bootstrapping difficult.

> about sending certificates by reference rather than value.

  Does TLS 1.3 support that?  I haven't looked in detail, TBH.

> certificate container which contains a reference.  IKEv2 already has that.

  Changing that may be very, very, difficult.

  Alan DeKok.