Re: [Emu] I-D Action: draft-ietf-emu-eaptlscert-02.txt
On Mar 16, 2020, at 12:57 PM, Michael Richardson wrote: > 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? 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. > 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?) RFC 6613 doesn't solve the 4K limit. That's solved by RFC 7930. I'm not aware of any products supporting that, tho. > 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? 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. > 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. TLS 1.3 makes it easier to cache the certificates. But you may have to exchange them at least once, which makes bootstrapping difficult. > I was surprised to get to the end of the document without any suggestions > about sending certificates by reference rather than value. Does TLS 1.3 support that? I haven't looked in detail, TBH. > 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. Changing that may be very, very, difficult. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-eaptlscert-02.txt
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 , Sandelman Software Works -= IPv6 IoT consulting =- signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] I-D Action: draft-ietf-emu-eaptlscert-02.txt
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/ ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
