Subject: [Ace] call for adoption for draft-marin-ace-wg-coap-eap

From: Daniel Migault <[email-masked]>
Date: Thu, 21 Jan 2021 08:13:08 -0500

Hi,

The charter approval by the IESG is expected to be approved in the coming
weeks. In the meanwhile, this email starts a call for adoption on work that
has been included in the charter. Of course, adoption is contingent on the
rechartering succeeding.

The document called for adoption is draft-marin-ace-wg-coap-eap available
here:
https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-07

Please state your opinion on whether this work should not or should be
adopted by the WG and express your motivation for such a statement. The
call for adoption closes on February 4.

Yours,
Daniel

-- 
Daniel Migault
Ericsson

---

From: Michael Richardson <[email-masked]>
Date: Thu, 21 Jan 2021 10:26:30 -0500

I reviewed the document before, and my concerns were not really answered.

I can not understand what the applicability is.

The document starts off with:

   The goal of this document is to describe an authentication service
   that uses the Extensible Authentication Protocol (EAP) [RFC3748].
   The authentication service is built on top of the Constrained
   Application Protocol (CoAP) [RFC7252] and ALLOWS AUTHENTICATING TWO
   CoAP endpoints by using EAP without the need of ADDITIONAL PROTOCOLS
   TO BOOTSTRAP A SECURITY ASSOCIATION BETWEEN THEM.

...
   The assumption is that the EAP method transported in CoAP MUST
   generate cryptographic material [RFC5247]

This implies use of one of the many EAP-TLS modes, some EAP PAKE
mode, or maybe, in theory some EAP-SIM/AKA mode.

1) TLS modes could just use TLS, or DTLS and omit the extra EAP
   bytes.  If saving those bytes are not important, then
   the use of PANA seems to do the same thing.

2) The EAP PAKE modes could just TLS with some PSK or PAKE
   authentication.

3) The EAP-SIM/AKA modes are not realistic, as they generally depend upon
   being able to talk to a database of SIM/AKA secrets.

So, which modes that generate cryptographic material are envisioned?

The document goes on to say:

   The CoAP client MAY contact
   with a backend AAA infrastructure to complete the EAP negotiation as
   described in the EAP specification [RFC3748].

which is a third party, when the intro told me that no third party was
required.  Even figure 1 show three parties.
And section 5 says there might be five parties, again including an AAA server.

I believe that this entire proposal goes against the ACE architecture,
and should not be adopted by this WG.
This work seems to duplicate the work in LAKE, as well as cTLS, while not
bringing any clear advantage over existing protocols.

If adopted, I don't review the document.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Mohit Sethi M <[email-masked]>
Date: Fri, 22 Jan 2021 14:36:59 +0000

Hi Michael,

I guess the question you are asking is: what is the benefit of adding the overhead of EAP. For EAP-TLS, you could directly use TLS. For EAP-pwd (which is a PAKE) one could use any PAKE without the EAP encapsulation overhead?

Is your concern only in the context of IoT or do you think in general we are better off using protocols directly without the EAP framework overhead?

--Mohit

On 1/21/21 5:26 PM, Michael Richardson wrote:

...

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]<mailto:[email-masked]>  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]><mailto:[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
Ace mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ace

---

From: Seitz Ludwig <[email-masked]>
Date: Fri, 22 Jan 2021 15:17:39 +0000

I’d like to second the question Mohit assumes Michael is asking:

What is the benefit, in the context of IoT, to add the overhead of EAP to say TLS?

/Ludwig

From: Ace <[email-masked]> On Behalf Of Mohit Sethi M
Sent: den 22 januari 2021 15:37
To: Michael Richardson <[email-masked]>; Ace Wg <[email-masked]>
Subject: [EXTERNAL] Re: [Ace] call for adoption for draft-marin-ace-wg-coap-eap

Hi Michael,

--Mohit

...

   authentication.

--

--

Ace mailing list

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Jan 2021 11:38:04 -0500

Mohit Sethi M <[email-masked]> wrote:
    > Is your concern only in the context of IoT or do you think in general
    > we are better off using protocols directly without the EAP framework
    > overhead?

EAP is designed to be used within a protocol, to interact with AAA
infrastructure.   Use within 802.1X, and IKEv2 has been great.
The purpose of which is to authenticate a relationship, and provide keying material.

This document claims to be useful between two peers, then goes on to
acknowledge that there are more entities involved.

1) If we aren't talking about IoT, why would we be talking about CoAP?

2) I haven't seen a use case for this yet.

3) If you are trying to produce keying material for OSCORE, and EDHOC is not
   to your liking, and you want *TLS* involved, then just use DTLS or ATLAS or cTLS.
   You can run your favourite EAP methods within TLS if you want to.

---

From: Dan Garcia Carrillo <[email-masked]>
Date: Fri, 22 Jan 2021 18:42:41 +0100

Hi Michael,

> I can not understand what the applicability is.

Did you check the last version of the use case?

The use case is a bit more ellaborate than the initial to give a more 
broad view of the concept and try to clarify doubts. If it is not clear 
we will review that part.

>     TO BOOTSTRAP A SECURITY ASSOCIATION BETWEEN THEM.

We can improve the text to better explain the goal with your comments.

> mode, or maybe, in theory some EAP-SIM/AKA mode.

We do not specify a particular EAP method to be used and that is one of 
the reasons for choosing EAP: "One of the advantages of the EAP 
architecture is its flexibility"

> So, which modes that generate cryptographic material are envisioned?

As commented above, we do not force a specific EAP method to be used, 
that is the key desing behind an EAP lower layer, to be agnostic to the 
EAP method in use. But to answer to your question, we will not use EAP 
methods that do not export key material such as EAP-MD5.

> And section 5 says there might be five parties, again including an AAA server.

The added parties are for the purpose of ellaborating the use case, but 
at the end they all map to the EAP architecture.

EAP is clear with this point. You have the option of using it in 
standalone or pass-through mode.

If you use it in standalone mode, the controller wil act as EAP 
authenticator/server, and there will be no need for contacting any AAA 
server.

In other words, the design of an EAP lower layer is not dependant on a 
AAA server.

This said, we can improve the abstract for example with this:

"This document describes an authentication service that uses EAP 
transported by means of CoAP messages with the following purposes:

    o  Authenticate a CoAP-enabled constrained device that enters a new 
security
       domain under the control of a CoAP-enabled Controller, providing 
flexible
       authentication with EAP.

    o  Bootstrap key material to protect CoAP messages exchanged between
       a constrained device and controller.

    o  Enable the establishment of a security association between them."

> If adopted, I don't review the document.

This is not correct. It does not go against the ACE architecture but it 
is a complement to it.

Our main contribution is the definition for a CoAP-based transport for 
EAP (Figure 1). We tried to explain the relationship with ACE in the use 
case section, but we will improve the text after your comments. In fact 
we have:

"In the second phase, when node A wants to talk with node B, it
contacts the controller C for authorization to access node B and
obtain all the required information to do that in a secure manner
(e.g. keys, tokens, authorization information, etc.).  It does NOT
require the usage of CoAP-EAP.  The details of this phase are out of
scope of this document, but ACE framework can be used for
this purpose [I-D.ietf-ace-oauth-authz]”

Therefore CoAP-EAP happens before and can be used to establish a secure 
relationship between the AS and the  constrained device in ACE-OAuth.

The most general  or broad use case we have in mind are constrained 
devices with:
- Different types of credentials and authentication mechanisms
- Can belong to different domains
- Want to join a domain under the control of a controller.

It turns out that CoAP-based EAP service allows you to generate key 
material (the MSK) to establish this secure association.

Having provided the initial key material that the ACE-OAuth framework 
requires:
  "... Client registration and provisioning of client credentials to the 
client is out of scope for this specification. "

What happens after that, is all about the ACE-OAuth framework.

Best Regards,

Dan.

> [email-masked]

---

From: Dan Garcia <[email-masked]>
Date: Fri, 22 Jan 2021 20:05:08 +0100

Hi Ludwig,

Basically, to bring the features that EAP has into IoT.

Such as:

- Well known protocol thas provides flexible authentication with 
diffrent methods and counting.

- It integrates well with AAA.

- It has a standard and very well known Key Management Framework.

With regards to the overhead EAP brings, it is a small price to pay 
having into account this benefits. In fact, our work is all about using 
CoAP so the EAP transport is lightweight and we think is worth the effort.

Best Regards,

Dan.

El 22/01/2021 a las 16:17, Seitz Ludwig escribió:
> *From:*Ace <[email-masked]> *On Behalf Of *Mohit Sethi M
> *Sent:* den 22 januari 2021 15:37
> *To:* Michael Richardson <[email-masked]>; Ace Wg <[email-masked]>
> *Subject:* [EXTERNAL] Re: [Ace] call for adoption for 
> draft-marin-ace-wg-coap-eap
>
> Hi Michael,
>
> I guess the question you are asking is: what is the benefit of adding 
> the overhead of EAP. For EAP-TLS, you could directly use TLS. For 
> EAP-pwd (which is a PAKE) one could use any PAKE without the EAP 
> encapsulation overhead?
>
>     ][email-masked]  <mailto:[email-masked]>   http://www.sandelman.ca/  <http://www.sandelman.ca/>         |   ruby on rails    [
>
>     --
>
>     Michael Richardson<[email-masked]>  <mailto:[email-masked]>    . o O ( IPv6 IøT consulting )
>
>     [email-masked]  <mailto:[email-masked]>
>
>     https://www.ietf.org/mailman/listinfo/ace  <https://www.ietf.org/mailman/listinfo/ace>
>
>

---

From: Dan Garcia Carrillo <[email-masked]>
Date: Fri, 22 Jan 2021 20:36:31 +0100

Hi Michael,

I hope the last email answered your questions.

Best Regards,

Dan.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 22 Jan 2021 19:29:28 -0500

Are you talking about this answer:

> - Well known protocol thas provides flexible authentication with diffrent methods and counting.

because it continues to not be answer.

These are all features of EAP.
How does EAP-over-CoAP benefit?

EAP can be used inside (D)TLS (and maybe even cTLS) without CoAP having to carry EAP.
I guess you want to be able to key OSCORE.
So, I would guess that this must involve not using EAP-TLS* (or TEAP, or
TTLS, etc.), so I think that reduces to some kind of EAP-PAKE situation,
or EAP-SIM/AKA.

Do both peer talk to the same AAA server?

In that case, then they must have already established a secure relationship
with the AAA server. (Because, radius demands it).
If you have that, then you can just use the ACE framework to get OSCORE keys,
treating the AAA server as the AS or RS.

If they don't talk to the same AAA server, then how are the AAA servers related?

---

From: Josh Howlett <[email-masked]>
Date: Tue, 26 Jan 2021 09:37:06 +0000

Hi,

I believe this document should be adopted.

  *   CoAP will benefit from a successful and highly extensible authentication framework that today supports many different forms of authentication, increasing the range of use cases that can be supported
  *   it will enable CoAP-based infrastructure to use existing deployed AAA systems for authentication, reducing the barrier to adoption of CoAP
  *   it will help deployers to align their CoAP and their other EAP-based infrastructures, such as IEEE 802.1X, helping them to leverage common business processes (e.g., identity proofing and credentialling). This could be particularly beneficial within certified environments (e.g., ISO27001).

Josh

Hi,

The charter approval by the IESG is expected to be approved in the coming weeks. In the meanwhile, this email starts a call for adoption on work that has been included in the charter. Of course, adoption is contingent on the rechartering succeeding.

The document called for adoption is draft-marin-ace-wg-coap-eap available here:
https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-07

Please state your opinion on whether this work should not or should be adopted by the WG and express your motivation for such a statement. The call for adoption closes on February 4.

Yours,
Daniel