Hi Hannes > On 24 Mar 2020, at 10:08, Hannes Tschofenig <hannes.tschofe...@arm.com> 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 <l...@cisco.com> > Sent: Tuesday, March 24, 2020 10:02 AM > 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 > > 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.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
