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. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
