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 <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
