Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jul 5, 2021, at 10:43 AM, Eliot Lear wrote: > Is this something we should do here or in IOTOPS? I think EMU is the right area. Fixing EAP has impact outside of IoT. > I think it would be cool to develop at least something of a requirements doc. > And there are some tools out there, even at the EAP level. But They don't > all fit together well. I have a document I'll publish shortly. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
Is this something we should do here or in IOTOPS?
I think it would be cool to develop at least something of a requirements
doc. And there are some tools out there, even at the EAP level. But
They don't all fit together well.
Eliot
On 05.07.21 16:20, Carolin Baumgartner wrote:
On 7/3/21 1:57 PM, Alan DeKok wrote:
On Jul 3, 2021, at 7:47 AM, Eliot Lear wrote:
I don't think Tim could be blamed for holding the view that there is
a separation between specifications and how they are used. There's
good and bad to the practice. The good is that the spec can be used
in ways that the creators didn't intend, and thus perahsp there are
fewer unnecessary constraints.
On the other hand, not having a theory of operation section, as we
do have in a good number of our specs, leads to people really not
understanding when they are applicable, and perhaps more
importantly, when they are not.
People don't even understand how to use the specs as intended.
We're essentially telling people "EAP methods are applicable in these
situations, but good luck actually trying to get them deployed,
you're on your own".
I agree and out of experience everything that leaves just a little bit
room of interpretation ("you can do it this way or that way") ends up
in misinterpretions or gaps and causes good ideas to fail.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
OpenPGP_signature
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On 7/3/21 1:57 PM, Alan DeKok wrote:
On Jul 3, 2021, at 7:47 AM, Eliot Lear wrote:
I don't think Tim could be blamed for holding the view that there is a
separation between specifications and how they are used. There's good and bad
to the practice. The good is that the spec can be used in ways that the
creators didn't intend, and thus perahsp there are fewer unnecessary
constraints.
On the other hand, not having a theory of operation section, as we do have in a
good number of our specs, leads to people really not understanding when they
are applicable, and perhaps more importantly, when they are not.
People don't even understand how to use the specs as intended. We're essentially
telling people "EAP methods are applicable in these situations, but good luck
actually trying to get them deployed, you're on your own".
I agree and out of experience everything that leaves just a little bit
room of interpretation ("you can do it this way or that way") ends up in
misinterpretions or gaps and causes good ideas to fail.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jul 3, 2021, at 7:47 AM, Eliot Lear wrote: > I don't think Tim could be blamed for holding the view that there is a > separation between specifications and how they are used. There's good and bad > to the practice. The good is that the spec can be used in ways that the > creators didn't intend, and thus perahsp there are fewer unnecessary > constraints. > > On the other hand, not having a theory of operation section, as we do have in > a good number of our specs, leads to people really not understanding when > they are applicable, and perhaps more importantly, when they are not. People don't even understand how to use the specs as intended. We're essentially telling people "EAP methods are applicable in these situations, but good luck actually trying to get them deployed, you're on your own". Each vendor does randomly different things for UI / credential management / workflow / whatever. The end result is that the spec is largely theoretical. In practice, people do any number of hacks to get something to work. Because the specs don't help here. If people can't deploy a spec easily and securely, then I see that as a failure of the specification. For example, over the last 20+ years, the "Security Considerations" section of RFCs has grown in importance and content. This is a good thing. > All of this having been said, perhaps the best way to go forward is to have a > requirements discussion in terms of the sorts of operations we would like to > see as part of the authentication process – as opposed to elsewhere. > > I see tremendous opportunity here, to be honest. But it's a lot of work. I agree. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
Hi Alan, I don't think Tim could be blamed for holding the view that there is a separation between specifications and how they are used. There's good and bad to the practice. The good is that the spec can be used in ways that the creators didn't intend, and thus perahsp there are fewer unnecessary constraints. On the other hand, not having a theory of operation section, as we do have in a good number of our specs, leads to people really not understanding when they are applicable, and perhaps more importantly, when they are not. All of this having been said, perhaps the best way to go forward is to have a requirements discussion in terms of the sorts of operations we would like to see as part of the authentication process – as opposed to elsewhere. I see tremendous opportunity here, to be honest. But it's a lot of work. Eliot On 03.07.21 13:35, Alan DeKok wrote: We have specs with Security Considerations, and implementation guidelines. They're a lot more than just what bits go on the wire. In general, a BCP is too late in the process. Vendors have already implemented the base spec, so what's "current" is a random grab-bag of stuff decided on by product managers, or by junior engineers. I've seen many, many, sites unable to deploy the security they want, due to a wide range of limitations in products. IMHO, these are security issues, and should be treated as such in the base specification. There should be clear guidance given on a wide range of issues, such as security, implementation, UI, workflow, etc. Not having those guidelines is a large source of income for me. But it is endlessly frustrating for everyone involved. I would prefer to help people build useful systems, instead of having them pay me to paper over issues in multiple products. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu OpenPGP_signature Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jul 2, 2021, at 9:16 PM, Tim Cappalli wrote: > > >> The current specs define the base protocols, but leave pretty much > >> everything else undefined. > > That’s the job of a spec isn’t it? As far as I understand, deploying in the > real world / best practices should go in a BCP. We have specs with Security Considerations, and implementation guidelines. They're a lot more than just what bits go on the wire. In general, a BCP is too late in the process. Vendors have already implemented the base spec, so what's "current" is a random grab-bag of stuff decided on by product managers, or by junior engineers. I've seen many, many, sites unable to deploy the security they want, due to a wide range of limitations in products. IMHO, these are security issues, and should be treated as such in the base specification. There should be clear guidance given on a wide range of issues, such as security, implementation, UI, workflow, etc. Not having those guidelines is a large source of income for me. But it is endlessly frustrating for everyone involved. I would prefer to help people build useful systems, instead of having them pay me to paper over issues in multiple products. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
>> The current specs define the base protocols, but leave pretty much >> everything else undefined. That’s the job of a spec isn’t it? As far as I understand, deploying in the real world / best practices should go in a BCP. tim Sent from Mail for Windows 11 From: Alan DeKok<mailto:al...@deployingradius.com> Sent: Friday, July 2, 2021 3:02 PM To: Eliot Lear<mailto:l...@lear.ch> Cc: EMU WG<mailto:emu@ietf.org> Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03 On Jul 1, 2021, at 10:08 AM, Eliot Lear wrote: > > On 01.07.21 15:23, Alan DeKok wrote: >> TEAP is one solution, but I don't think everyone is going to move to TEAP >> overnight. It would be nice to have solutions for existing (and deployed) >> EAP methods. > > Perhaps I lost the plot, but what do you propose? Less of a proposal than trying to define some requirements. EAP isn't used in a vacuum. The current specs define the base protocols, but leave pretty much everything else undefined. This means that people deploying EAP have to invent and/or discover their own methods to deploy certificates, tie users to machines, tie machines to credentials, etc. It would be very nice to say "here's how EAP can be used in the real world". Alan DeKok. ___ Emu mailing list Emu@ietf.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=04%7C01%7Ctim.cappalli%40microsoft.com%7C6a74ce41b7c6443645c308d93d8be0d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637608493715426663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=3icw%2F1n6Q5WHXkLMYSDBGw%2BIerr7ZvgLlBYJRy%2FS%2BP8%3Dreserved=0 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jul 1, 2021, at 10:08 AM, Eliot Lear wrote: > > On 01.07.21 15:23, Alan DeKok wrote: >> TEAP is one solution, but I don't think everyone is going to move to TEAP >> overnight. It would be nice to have solutions for existing (and deployed) >> EAP methods. > > Perhaps I lost the plot, but what do you propose? Less of a proposal than trying to define some requirements. EAP isn't used in a vacuum. The current specs define the base protocols, but leave pretty much everything else undefined. This means that people deploying EAP have to invent and/or discover their own methods to deploy certificates, tie users to machines, tie machines to credentials, etc. It would be very nice to say "here's how EAP can be used in the real world". Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
Device identifiers, how certificates get provisioned, their contents, and where the keys are stored don’t seem in scope for this TLS-based EAP types spec. This seems like more of a BCP thing or a topic for MADINAS IMO. From: Eliot Lear<mailto:l...@lear.ch> Sent: Thursday, July 1, 2021 10:09 AM To: Alan DeKok<mailto:al...@deployingradius.com>; EMU WG<mailto:emu@ietf.org> Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03 Hi Alan, On 01.07.21 15:23, Alan DeKok wrote: >TEAP is one solution, but I don't think everyone is going to move to TEAP > overnight. It would be nice to have solutions for existing (and deployed) > EAP methods. Perhaps I lost the plot, but what do you propose? Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
Hi Alan, On 01.07.21 15:23, Alan DeKok wrote: TEAP is one solution, but I don't think everyone is going to move to TEAP overnight. It would be nice to have solutions for existing (and deployed) EAP methods. Perhaps I lost the plot, but what do you propose? Eliot OpenPGP_signature Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On 7/1/21 3:23 PM, Alan DeKok wrote: On Jun 30, 2021, at 9:52 AM, Eliot Lear wrote: I think we have to be a bit careful about using the term "TPM". What we care about are trust anchors, credentials, and operations on those. Those objects might be stored in TPMs, but it seems to me that the protocol does not need to be aware of that. Yes. Well. Yes, that is one dimension. A TPM can also allow for more automated proofs of trust. However if the issue is how to talk to a device to get a certificate installed, you will face the same challenges with or without TPM since the operating system sits inbetween. A TPM could also come with pre-installed device identity certificates. I am not sure that is happening a lot these days, so hm. best regards Carolin ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jun 30, 2021, at 9:52 AM, Eliot Lear wrote: > I think we have to be a bit careful about using the term "TPM". What we care > about are trust anchors, credentials, and operations on those. Those objects > might be stored in TPMs, but it seems to me that the protocol does not need > to be aware of that. Yes. > If we can be crisper on both the operations and the objects, I think we'll do > better. Some of that is on us with a TEAP update, but I think there's also a > discussion to be had about that. > > It's the T part of TEAP that is emphasized in the current work. The > operations and objects beyond that are underdeveloped. That has to be a lot > cleaner as we move forward. My concern is that we need a way for an administrator to identify a particular device. Either say "this particular phone", or "only this device has the given credentials." Both use-cases are similar, but not the same. Once credentials are provisioned, then protocols like EAP can work without knowing where the credentials come from, or where they are stored. But there's still a bootstrapping problem which remains unsolved. TEAP is one solution, but I don't think everyone is going to move to TEAP overnight. It would be nice to have solutions for existing (and deployed) EAP methods. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
Hi Alan Slight segue.. On 30.06.21 15:38, Alan DeKok wrote: If the answer is "use TPM", then that doesn't meet peoples existing needs. It will also take many years for it to become standardized, much less ubiquitous. As an example, here's an EAP / TPM paper from 2010: https://www.semanticscholar.org/paper/EAP-TPM-%3A-A-New-Authentication-Protocol-for-IEEE-.-Latze/6d755cf4d1ac1da25c8d02a2e5cba56212149d69 I think we have to be a bit careful about using the term "TPM". What we care about are trust anchors, credentials, and operations on those. Those objects might be stored in TPMs, but it seems to me that the protocol does not need to be aware of that. If we can be crisper on both the operations and the objects, I think we'll do better. Some of that is on us with a TEAP update, but I think there's also a discussion to be had about that. It's the T part of TEAP that is emphasized in the current work. The operations and objects beyond that are underdeveloped. That has to be a lot cleaner as we move forward. Eliot OpenPGP_signature Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jun 29, 2021, at 6:40 PM, Michael Richardson wrote: > I think that today, the answer is probably too bad because too complex. Yes. > But, I think that most phones can do "Enterprise" WPA, and so a certificate > can be loaded in to do EAP-TLS. ... somehow. :( Phone vendors are making this more difficult as time progresses. I've heard from MDM vendors who are largely giving up, as the APIs, limitations, and capabilities keep changing. Which is why I'm trying to find something which is useful, and which doesn't require massive new infrastructure. If the answer is "use TPM", then that doesn't meet peoples existing needs. It will also take many years for it to become standardized, much less ubiquitous. As an example, here's an EAP / TPM paper from 2010: https://www.semanticscholar.org/paper/EAP-TPM-%3A-A-New-Authentication-Protocol-for-IEEE-.-Latze/6d755cf4d1ac1da25c8d02a2e5cba56212149d69 So we've had this capability for a decade. But no one has found time / interest in moving forward with it. This makes me think that TPM is not really the best choice here. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
Alan DeKok wrote: > On Jun 28, 2021, at 8:50 PM, Michael Richardson wrote: >> To date, Enterprises with laptops and PCs have provisioned the IDevID into >> the TPM, themselves, at the same time the device is wiped and the golden >> image is installed. So, the TPM identity is actually known to them by construction. > And... if I have my own phone? Or if a university wishes to tie > devices to student accounts? So that they can limit (somewhat) abuses? > For now, the answer is "too bad". Or maybe "buy a MDM solution". I think that today, the answer is probably too bad because too complex. But, I think that most phones can do "Enterprise" WPA, and so a certificate can be loaded in to do EAP-TLS. > As someone who bought my own phone, I'm not going install some MDM > solution which lets my employer wipe my personal device. I would much > prefer to be able to prove (a) it's my device, and (b) it has a unique > device identifier. The simpler the method, the better. If I were a student, I would also not allow a university (or employer) MDM solution onto my phone, and I'm not actually sure that it directly helps; it just makes loading that certificate easier. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jun 28, 2021, at 8:50 PM, Michael Richardson wrote: > To date, Enterprises with laptops and PCs have provisioned the IDevID into > the TPM, themselves, at the same time the device is wiped and the golden > image is installed. So, the TPM identity is actually known to them by > construction. And... if I have my own phone? Or if a university wishes to tie devices to student accounts? So that they can limit (somewhat) abuses? For now, the answer is "too bad". Or maybe "buy a MDM solution". As someone who bought my own phone, I'm not going install some MDM solution which lets my employer wipe my personal device. I would much prefer to be able to prove (a) it's my device, and (b) it has a unique device identifier. The simpler the method, the better. > Smartphones do not get provisioned that way, but at the factory. > Ditto IoT devices, and routers that have IDevID. > RFC8995(BRSKI) can help, and Eliot has a proposal about how to run that over > TEAP. > There are other ways too, and most wind up with an LDevID deployed. That's good, but I suspect it will take a while to get implemented and/or popular. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
Alan DeKok wrote: >> If a strong hardware-bound identifier is required, the organization >> should use the TPM/SE for private key generation during >> provisioning/onboarding. > From my reading of TCG / TPM / etc. stuff, the private key describes a > *particular* device. Not a *known* device. i.e. the key is tied to a > device, so it's a unique token. But it's not an *identifying* token, in > that the administrator can tell which device is being provisioned. > There still needs to be a way for the administrator to know which > device is being used. Identifying a particular device is done via > physical examination in a secure network, or via some unique hardware > identifier. I might be missing something from the whole TPM > infrastructure, tho. To date, Enterprises with laptops and PCs have provisioned the IDevID into the TPM, themselves, at the same time the device is wiped and the golden image is installed. So, the TPM identity is actually known to them by construction. Smartphones do not get provisioned that way, but at the factory. Ditto IoT devices, and routers that have IDevID. RFC8995(BRSKI) can help, and Eliot has a proposal about how to run that over TEAP. There are other ways too, and most wind up with an LDevID deployed. MAC address randomization makes use of EAP-TLS methods that have unique IDevID as their client identifier much easier than WPA-PSK, where get nothing. I expect that is where things will go, but at this point, the major new "home" mechanism (CHIP/MATTER), seems stuck at sending WPA-PSKs out, despite actually having a mechanism to deploy LDevIDs to devices. As many of you know, TLS1.3 is a major win because the client certificate is not transmitted in the clear during the handshake. If the supplicant can validate the server certificate, then a Mallory-in-the-Middle (onpath) attack also does not get the identity. -- Michael Richardson. o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide signature.asc Description: PGP signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jun 28, 2021, at 4:05 PM, Tim Cappalli wrote: > Modern authorization is done using certificate properties as a lookup value. > Correlation of an individual piece of hardware to a certificate property > needs to be done during provisioning (which is the case in many deployments > today). And in the deployments where people don't do such provisioning? I would very much prefer to have a solution there. The solution right now is "intrusive MDM software". Not everyone can do (or afford) that. And MDM configuration is becoming more and more complex. Vendors randomly change APIs, UIs, and workflows. It's all a horrible bodge which is productive for no one. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
It has very little value as it can be easily changed on most platforms. Modern authorization is done using certificate properties as a lookup value. Correlation of an individual piece of hardware to a certificate property needs to be done during provisioning (which is the case in many deployments today). tim From: Alan DeKok<mailto:al...@deployingradius.com> Sent: Monday, June 28, 2021 4:00 PM To: Tim Cappalli<mailto:tim.cappa...@microsoft.com> Cc: oleg.pekar.2...@gmail.com<mailto:oleg.pekar.2...@gmail.com>; emu@ietf.org<mailto:emu@ietf.org> Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03 On Jun 28, 2021, at 2:20 PM, Tim Cappalli wrote: > The industry is moving away from any hardware identifier being sent off > device. I don’t think the physical MAC should ever be used as a device > identifier, even for channel binding. It's globally unique, which is a pretty useful identifier. > If a strong hardware-bound identifier is required, the organization should > use the TPM/SE for private key generation during provisioning/onboarding. From my reading of TCG / TPM / etc. stuff, the private key describes a *particular* device. Not a *known* device. i.e. the key is tied to a device, so it's a unique token. But it's not an *identifying* token, in that the administrator can tell which device is being provisioned. There still needs to be a way for the administrator to know which device is being used. Identifying a particular device is done via physical examination in a secure network, or via some unique hardware identifier. I might be missing something from the whole TPM infrastructure, tho. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jun 28, 2021, at 2:20 PM, Tim Cappalli wrote: > The industry is moving away from any hardware identifier being sent off > device. I don’t think the physical MAC should ever be used as a device > identifier, even for channel binding. It's globally unique, which is a pretty useful identifier. > If a strong hardware-bound identifier is required, the organization should > use the TPM/SE for private key generation during provisioning/onboarding. From my reading of TCG / TPM / etc. stuff, the private key describes a *particular* device. Not a *known* device. i.e. the key is tied to a device, so it's a unique token. But it's not an *identifying* token, in that the administrator can tell which device is being provisioned. There still needs to be a way for the administrator to know which device is being used. Identifying a particular device is done via physical examination in a secure network, or via some unique hardware identifier. I might be missing something from the whole TPM infrastructure, tho. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
On Jun 28, 2021, at 11:18 AM, Oleg Pekar wrote: > > Alan, agree on the MAC randomization problem. Is there any existing standard > or proposal for the network deployments where the Network Access Control > server needs to track the device with randomized MAC moving between intranet > SSIDs? Not that I know of. > About usage of physical MAC address - maybe some client systems will not have > access to the physical MAC rather than just to a randomized MAC. That is true. My goal here is not to make things perfect, but to be able to manage a device, when that's possible. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
The industry is moving away from any hardware identifier being sent off device. I don’t think the physical MAC should ever be used as a device identifier, even for channel binding. If a strong hardware-bound identifier is required, the organization should use the TPM/SE for private key generation during provisioning/onboarding. From: Oleg Pekar<mailto:oleg.pekar.2...@gmail.com> Sent: Monday, June 28, 2021 11:19 AM To: Alan DeKok<mailto:al...@deployingradius.com> Cc: EMU WG<mailto:emu@ietf.org> Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03 Alan, agree on the MAC randomization problem. Is there any existing standard or proposal for the network deployments where the Network Access Control server needs to track the device with randomized MAC moving between intranet SSIDs? About usage of physical MAC address - maybe some client systems will not have access to the physical MAC rather than just to a randomized MAC. Regards, Oleg On Mon, Jun 28, 2021 at 4:21 PM Alan DeKok mailto:al...@deployingradius.com>> wrote: One thing missing in the current document is how to address the modern issue of MAC address randomization. i.e. admins would like to ensure that only certain devices access the network. But with MAC address randomization, it's difficult to have a static device identifier. Even client certificates can be installed on multiple machines, if they're just sent to the user. Would it be worth adding a note that systems SHOULD implement RFC 6677 channel bindings to address this issue? And that the Calling-Station-Id inside of the channel bindings MUST be the actual physical MAC, and not the public / randomized MAC? I've seen this problem more and more in customer deployments. It's becoming a serious security issue. Alan DeKok. ___ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu=04%7C01%7Ctim.cappalli%40microsoft.com%7Ce5271f5f556b451a09bd08d93a4812ac%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637604903581345612%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=73wWIXCtD%2BLZz6IEsxzLgHDDUs0Jj64sdyHH56DSFWU%3D=0> ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03
Alan, agree on the MAC randomization problem. Is there any existing standard or proposal for the network deployments where the Network Access Control server needs to track the device with randomized MAC moving between intranet SSIDs? About usage of physical MAC address - maybe some client systems will not have access to the physical MAC rather than just to a randomized MAC. Regards, Oleg On Mon, Jun 28, 2021 at 4:21 PM Alan DeKok wrote: > One thing missing in the current document is how to address the modern > issue of MAC address randomization. > > i.e. admins would like to ensure that only certain devices access the > network. But with MAC address randomization, it's difficult to have a > static device identifier. Even client certificates can be installed on > multiple machines, if they're just sent to the user. > > Would it be worth adding a note that systems SHOULD implement RFC 6677 > channel bindings to address this issue? And that the Calling-Station-Id > inside of the channel bindings MUST be the actual physical MAC, and not the > public / randomized MAC? > > I've seen this problem more and more in customer deployments. It's > becoming a serious security issue. > > Alan DeKok. > > ___ > 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
[Emu] Question for draft-ietf-emu-tls-eap-types-03
One thing missing in the current document is how to address the modern issue of MAC address randomization. i.e. admins would like to ensure that only certain devices access the network. But with MAC address randomization, it's difficult to have a static device identifier. Even client certificates can be installed on multiple machines, if they're just sent to the user. Would it be worth adding a note that systems SHOULD implement RFC 6677 channel bindings to address this issue? And that the Calling-Station-Id inside of the channel bindings MUST be the actual physical MAC, and not the public / randomized MAC? I've seen this problem more and more in customer deployments. It's becoming a serious security issue. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
