On Mar 16, 2020, at 12:57 PM, Michael Richardson <mcr+i...@sandelman.ca> 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
