Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

From: Alan DeKok <[email-masked]>
Date: Thu, 1 Jul 2021 09:23:50 -0400

On Jun 30, 2021, at 9:52 AM, Eliot Lear <[email-masked]> 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.

---

From: Carolin Baumgartner <[email-masked]>
Date: Thu, 1 Jul 2021 16:01:18 +0200

>> 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…
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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 1 Jul 2021 16:08:26 +0200

Hi Alan,

>    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

---

From: Tim Cappalli <[email-masked]>
Date: Thu, 1 Jul 2021 14:38:04 +0000

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:[email-masked]>
Sent: Thursday, July 1, 2021 10:09 AM
To: Alan DeKok<mailto:[email-masked]>; EMU WG<mailto:[email-masked]>
Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

Hi Alan,

Eliot

---

From: Alan DeKok <[email-masked]>
Date: Fri, 2 Jul 2021 15:01:35 -0400

> 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.

---

From: Tim Cappalli <[email-masked]>
Date: Sat, 3 Jul 2021 01:16:33 +0000

>> 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:[email-masked]>
Sent: Friday, July 2, 2021 3:02 PM
To: Eliot Lear<mailto:[email-masked]>
Cc: EMU WG<mailto:[email-masked]>
Subject: Re: [Emu] Question for draft-ietf-emu-tls-eap-types-03

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu&amp;data=04%7C01%7Ctim.cappalli%40microsoft.com%7C6a74ce41b7c6443645c308d93d8be0d2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637608493715426663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=3icw%2F1n6Q5WHXkLMYSDBGw%2BIerr7ZvgLlBYJRy%2FS%2BP8%3D&amp;reserved=0

---

From: Alan DeKok <[email-masked]>
Date: Sat, 3 Jul 2021 07:35:52 -0400

> 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.

---

From: Eliot Lear <[email-masked]>
Date: Sat, 3 Jul 2021 13:47:28 +0200

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:
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Alan DeKok <[email-masked]>
Date: Sat, 3 Jul 2021 07:57:57 -0400

On Jul 3, 2021, at 7:47 AM, Eliot Lear <[email-masked]> 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 agree.

  Alan DeKok.

---

From: Carolin Baumgartner <[email-masked]>
Date: Mon, 5 Jul 2021 16:20:13 +0200

>    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 deploye…
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.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 5 Jul 2021 16:43:27 +0200

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:
>>> 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".
> room of interpretation ("you can do it this way or that way") ends up 
> in misinterpretions or gaps and causes good ideas to fail.
>

---

From: Alan DeKok <[email-masked]>
Date: Mon, 5 Jul 2021 10:52:58 -0400

> 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.