Hi Eliot, I consider the enterprise and the university case as a roaming model. From an EAP method point of view there is IMHO little difference between the roaming and the non-roaming case: the EAP exchange always runs between the EAP peer on the device and the EAP server.
The IoT case is different because it falls more in the category of home WiFi usage. This doesn’t really use EAP in my understanding. Ciao Hannes From: Eliot Lear <[email protected]> Sent: Tuesday, March 24, 2020 10:24 AM To: Hannes Tschofenig <[email protected]> Cc: Michael Richardson <[email protected]>; [email protected] Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt Hi Hannes On 24 Mar 2020, at 10:08, Hannes Tschofenig <[email protected]<mailto:[email protected]>> wrote: Hi Eliot You bring up a good point, namely the deployment environment. Are we are talking about an IoT, an enterprise deployment environment or something else? Clearly there will be differences. Reading through the text my impression was that this is about an enterprise (or university) deployment environment. I might, however, be on the wrong track here. Since we’re talking about EAP, I can think of a few cases: * Classic enterprise/university case, IoT or not. I was ASSUMING IoT because my brain goes to IOT, but I don’t think it has to be so. * There is also a wifi roaming device model, where EAP might be used in various service provider or federated environments a’la Eduroam or similar. Today this is NOT a big IoT space, but soon? The one place this is not a big deal at the moment is in the home, as WPA-Personal/PAE is the norm. One additional question is how big the impact is between wired and wireless. Obviously with the former you worry less about interference and drops. Eliot Having the references to where deployment problems with large certificates/certificate chains occur would shine light on this aspect. Ciao Hannes From: Eliot Lear <[email protected]<mailto:[email protected]>> Sent: Tuesday, March 24, 2020 10:02 AM To: Hannes Tschofenig <[email protected]<mailto:[email protected]>> Cc: Michael Richardson <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt Good morning Hannes 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. 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. Not sure I entirely understand you. A few places are promoting new roots for manufacturers. And so the initial chain for a peer might look like CA-Root->CA-Intermediate->Mfg Root->Mfg Intermediate->Device. I think it may be possible to remove one of the intermediates, but probably not both. It seems to me that this is an onboarding problem, and the best way to reduce the cert chain size on a day to day basis would be to swap out for an operational cert where the trust anchor is within the enterprise. That means you get one of those Big Fat transactions and then things settle down, and that transaction may be handled specially anyway. One comment I have in the draft relates to this text: o Extensions are necessary to comply with [RFC5280], but the vast majority are optional. Include only those that are necessary to operate. This statement is just a little too general. It very much depends WHICH certificate we are discussing. If it is a manufacturer certificate, as long as you can roll to an enterprise cert, then who cares? If it is an enterprise certificate, then we have to look more closely. So for instance, as Hannes mentions, authorization is a big issue. Some of that can be done outside of the certificate using ACE or similar, but some may need to be present in the cert. What we would rather not have is people working the SAN to introduce authorization attributes. Eliot 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. 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 [email protected] https://www.ietf.org/mailman/listinfo/emu
