Hi Alan Thanks a lot for your comments. I guess you understand that I am always a bit nervous when the results of non-public conversations dictate the problem space. I have seen it often enough that people have made their measurements wrong, had wrong configuration, or had simply misunderstood concepts.
It sounds like we need a "myth-busting" document. Of course, it isn't certain whether the decision makers will indeed read RFCs but it would be worthwhile a try. Also it appears that the authors could do something really actionable here, namely to update the hostap code to update the roundtrip limit. Ciao Hannes PS: Why aren't you a co-author on this document? You know more about this than anyone else. -----Original Message----- From: Alan DeKok <al...@deployingradius.com> Sent: Tuesday, March 24, 2020 3:08 PM To: Hannes Tschofenig <hannes.tschofe...@arm.com> Cc: Michael Richardson <mcr+i...@sandelman.ca>; emu@ietf.org Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt On Mar 24, 2020, at 4:00 AM, Hannes Tschofenig <hannes.tschofe...@arm.com> wrote: > Having seen this statement from Michael I have reviewed the document. Two > generic observations about the draft: > > 1) Many statements are made about deployments and no references are provided. > To improve quality of the write-up I would strongly suggest to add such > references, as you would have to do with an academic publication as well. The issue is that deployment issues are usually discussed privately. One public link is this: http://freeradius.1045715.n5.nabble.com/Free-Radius-problem-with-sending-large-certificate-chains-using-EAP-TLS-td2780319.html >> TLS certificates are often relatively large, and the certificate >> chains are often long. > > I think this statement is in general incorrect. You could say that in > deployment X certificates have size X and the chain is Y long. Maybe "can be large" and "can be long". It's difficult to get quantitative numbers here. I didn't instrument my software to send statistics back to a central collector. :( > >> Also, >> from deployment experience, EAP peers typically have longer >> certificate chains than servers. > > I would like a reference to be included here. Theoretically, it makes > no sense to have a certificate chain for an EAP peer to have a longer > certificate chain than a server given a EAP peer talks to one EAP server. The peer often has a client certificate. So it's chain can be one longer than the server in some cases. > In network access authentication it is not only about authentication but the > most important part is authorization. Hence, you pretty much always have a > one-to-one relationship between the EAP peer and the EAP server. There are no > good reasons to have complex CA hierarchies here. Please tell that to corporations. :( I can't count how many times I've had to tell people "the technology doesn't support that", when they explain their business requirements. It is often difficult to get people to understand that their preferred process / methods are simply impossible to implement in the real world. >> This is because EAP peers often >> follow organizational hierarchies and tend to have many intermediate >> certificates. Thus, EAP-TLS authentication usually involve >> significantly more octets than when TLS is used as part of HTTPS. > > I think it would make sense to explain this organizational hierarchy > aspect in a bit more detail. I'm not sure what else could be said here. >> The EAP fragment size >> in typical deployments is just 1020 - 1500 octets. > > Reference for the 1500 octets. Ethernet maximum packet size... >> For example, many EAP authenticator (access point) implementations >> will drop an EAP session if it has not finished after >> 40 - 50 round-trips. > > Is there a reference that could be included? References to hostap source code. >> However, deployment >> experience has shown that these jumbo frames are not always >> implemented correctly. > > Add a reference here. Private communication. :( i.e. I've mediated calls between multiple large companies all pointing the finger at each other when things don't work. The solution was to point out that one particular networking box was simply dropping jumbo EAPoL frames. Names will not be used here. >> RADIUS can generally transport only about 4000 octets of EAP in a >> single message. > > How was this number constructed? 4K RADIUS maximum packet size. Minus 20 bytes for the RADIUS header overhead, 18 for Message-Authenticator, and <hand waving> for whatever other random things the AP vendor includes in packets. > I am also wondering what you are trying to say here with this > sentence. Are you saying that you have seen deployments for network access > authentication that have up to 6 intermediate CA certificates in the chain? Yes. >> This means that if the chain is >> larger than ~ 60 kB, EAP-TLS authentication cannot complete >> successfully in most deployments. > > Regarding the 60 kB certificate chain: Should this be an indication to > someone deploying the technology for access network authentication that > something has gone wrong? An indication that *what* has gone wrong? Nothing in any of the current specs indicates that a 60KB certificate chain would be a problem. I suspect few AP / OS vendors discuss that in their documentation, too. > Is this someone you have observed or is this just a theoretical statement? I > hope it is the latter. It's observed. >> 4.2.2. Caching Certificates > > There seems to be the misconception that TLS Cached Info requires a full > exchange to work. > It is the other way around: If you pre-distribute certificates > upfront then there is no need to exchange the certs again. You could just > send the fingerprints right away. > > A spec, however, has to also cover the bootstrapping problem. Sure. This should be explained. >> 4.2.5. Using Fewer Intermediate Certificates > >> The EAP peer certificate chain does not have to mirror the >> organizational hierarchy. For successful EAP-TLS authentication, >> certificate chains should not contain more than 2-4 intermediate >> certificates. > > I would make a stronger statement here. There is absolutely no reason > for the certificate chain to mirror the organizational structure. Tell that to the people who love hierarchies. > I also don't understand why you would need a hierarchy of 4 intermediate CAs. "My boss says it's our corporate process. Why don't the specs support it?" Alan DeKok. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
