Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
Hi Ryan, This topic seems like a good one to just get on the phone and sort through, but I have one question: On 8 Jan 2020, at 09:11, Ryan Sleevi mailto:ryan-i...@sleevi.com>> wrote: However, if using the same set or CAs that popular OSes use for TLS, it does mean that these CAs, and their customers, will still be subject to the same agility requirements, and limited to the same profile as TLS. Because of this, there’s ample reason to split further into the dedicated hierarchy and dedicated EKU. Is there an example of a non-EAP use where splitting into a new hierarchy has actually succeeded? Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
Thanks, Ryan. After I sent the note I thought about document signing. Our SUDI model at Cisco I view as somewhat different, but may be closer to apt to EAP anyway, so worth discussing. Eliot On 8 Jan 2020, at 12:26, Ryan Sleevi mailto:ryan-i...@sleevi.com>> wrote: On Wed, Jan 8, 2020 at 5:00 AM Eliot Lear (elear) mailto:el...@cisco.com>> wrote: Hi Ryan, This topic seems like a good one to just get on the phone and sort through, but I have one question: On 8 Jan 2020, at 09:11, Ryan Sleevi mailto:ryan-i...@sleevi.com>> wrote: However, if using the same set or CAs that popular OSes use for TLS, it does mean that these CAs, and their customers, will still be subject to the same agility requirements, and limited to the same profile as TLS. Because of this, there’s ample reason to split further into the dedicated hierarchy and dedicated EKU. Is there an example of a non-EAP use where splitting into a new hierarchy has actually succeeded? Document signing generally fits there, in that there are a number of CAs that only offer document signing/identity proofing without overlapping. As would, say, Cisco’s device/firmware signing model or the PKIs in use in the financial services/ATM markets. Relevant to EAP would be the aforementioned Passpoint model, which uses new and distinct CAs for that. There are definitely flaws with that (e.g. wanting said CAs to work with browsers), but there are parts of it that do work. There’s no technical reason to require the use of the same roots/same hierarchy, and ample and adequate reason to distinguish: both from the perspective of a root store maintainer (ensuring certificates comply with policies) and as a certificate consumer (minimizing risk of misissuance, ala Flame) ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)
Hi Michael, > > Owen, do we have a need to recognize that a device needs to perform > onboarding again after a movement? > > i.e. device A enrolls on network 1, gets an LDevID usable on network 1, > uses that with EAP-FOOBAR. > > device A then is moved to network 2, it tries to use same LDevID, > receives an error and then recognizes that it needs to perform another > enrollment. > I think that is up to the device manufacturer and relates to a number of factors, such as whether the device is mobile, whether it has a reset button, the nature of the device, privacy considerations, whether there are federated capabilities on the device, etc. > What is that error, and is it recognizeable? Do we need a new error > code to distinguish from "I reject you" from "I reject you but, you > could try enrolling with BRSKI-TEAP" I think that can already be detected in the draft based on the action request frames. Eliot > > > (hoping re-installed laptop works) > > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] BRSKI-TEAP vs regular connection (was Re: EAP questions ...)
> On 15 Jan 2020, at 16:10, Michael Richardson wrote: > > > Eliot Lear (elear) wrote: >>> Owen, do we have a need to recognize that a device needs to perform >>> onboarding again after a movement? >>> >>> i.e. device A enrolls on network 1, gets an LDevID usable on network >>> 1, uses that with EAP-FOOBAR. >>> >>> device A then is moved to network 2, it tries to use same LDevID, >>> receives an error and then recognizes that it needs to perform another >>> enrollment. > >> I think that is up to the device manufacturer and relates to a number >> of factors, such as whether the device is mobile, whether it has a >> reset button, the nature of the device, privacy considerations, whether >> there are federated capabilities on the device, etc. > > I can see that some of these are important to the device. > The device may have reasons why it would like to enroll again, but I think > the question is more about when the network recognizes that it does not need > to enroll again. > An example would be a device which was originally enrolled with BRSKI-TEAP, > but is then provided with roaming credentials (EDU-ROAM). > > How would it know it was on network 2? Ah. I misread your note the first time. The example of 2 is precisely eduroam, and this becomes a matter of configuration. We were talking about this at one point, and there is a need to configure a realm as part of all of this. That is something that could be easily be included in TEAP but isn’t there today. It could also be included in DPP in the configuration frame. > >>> What is that error, and is it recognizeable? Do we need a new error >>> code to distinguish from "I reject you" from "I reject you but, you >>> could try enrolling with BRSKI-TEAP" > >> I think that can already be detected in the draft based on the action >> request frames. > > To clear, it would be doing TEAP (or EAP-TLS) to connect to the network, > because it is already enrolled. If there are BRSKI-specific responses > defined in TEAP, then I'm surprised. That is what draft-lear-eap-teap-brski is really about. Eliot > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic
On 8 Jan 2020, at 17:29, Ryan Sleevi mailto:ryan-i...@sleevi.com>> wrote: The CA must revoke if the certificate is misused; that's required by contract. The CA defines what misuse means. A number of CAs define misuse as "used for purposes other than TLS web server" Ergo, obtaining and using certificates with EAP means these certificates are at risk of revocation. Ok not for nothing but this is getting silly. If a CA actually revoked a cert for someone using it for EAP, would they also have to revoke for someone using it for SMTP, XMPP, and IMAP? Has that ever happened? Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
