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

[Dan Garcia Carrillo <[e-mail]>]

Hi Michael,


El 21/01/2021 a las 16:26, Michael Richardson escribió:
> I reviewed the document before, and my concerns were not really answered.
>
> 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.

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

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

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

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"


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

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.


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

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


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

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.

>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
>
>
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>             Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace