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

[Dan Garcia <[e-mail]>]

Hi Michael,

El 23/01/2021 a las 1:29, Michael Richardson escribió:
> Dan Garcia Carrillo<[e-mail]>  wrote:
>      > I hope the last email answered your questions.
>
> Are you talking about this answer:
>
>> - 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.
> because it continues to not be answer.
>
> These are all features of EAP.

Sure. But as proponents of an EAP-based solution in IoT, it is important 
to show its benefits, which is what we do first in the I-D.

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

Regarding this question, in our I-D, we design an EAP lower-layer (see 
RFC 3748) based on CoAP. We assume that CoAP is a lightweight protocol 
that is adapted for constrained devices. Therefore a CoAP-based EAP 
lower layer will inherit these features, unless CoAP is not lightweight 
enough or it its not suited for IoT, which is not the case. Another 
assumption is that constrained devices will ship with a CoAP 
implementation too.

So, if you transport EAP, you need to design an EAP lower-layer. It is 
not just transport EAP over anything. RFC3748 defines this in Section 3. 
Moreover, regarding your suggestion, the EAP specification specifies the 
requirements for an EAP lower layer:

Section 3.1 Lower Layer requirements

"Lower layer security.  EAP does not require lower layers to
provide security services such as per-packet confidentiality,
authentication, integrity, and replay protection.  However, where
these security services are available, EAP methods supporting Key
Derivation (see Section 7.2.1) can be used to provide dynamic
keying material.  This makes it possible to bind the EAP authentication
to subsequent data and protect against data
modification, spoofing, or replay.  See
Section 7.1 for details."

You need define an EAP lower-layer following the requirements in section 
3.1 RFC3748.

This is precisely how CoAP-EAP is designed.

In fact, I was wondering how it can be lighter to establish a DTLS 
connection and then transport EAP in order to key OSCORE (that sounds 
too heavy in my opinion), for example, than using CoAP.

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

Actually, the Controller (where the EAP authenticator is placed) will 
have a secure relationship with a next hop AAA server but it does not 
have to be the AAA server where the EAP server is located.

If you check Fig 1. in RFC 5247 the AAA part is just refering to a AAA 
infraesturcture, which may be formed by several AAA “hops” until 
connecting with AAA server that has the EAP server. But that is 
something already working nowdays, as you may know.

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

I do not understand what does “treating the AAA server as the AS or RS” 
mean? Are you going to use AAA protocols with them? which entity is 
acting AAA client? where is the EAP server placed?

Nevertheless, that is not our target. In our mind, CoAP-EAP happens 
before the ACE framework but it is complementary to ACE. The reason 
is that CoAP-EAP can be used as “client registration” but using EAP. As 
you know, ACE-OAuth leaves open the client registration:

"Client registration and provisioning of client credentials to the
    client is out of scope for this specification."

For the ACE case, with CoAP-EAP, we can establish some key material 
between the client (constrained device) and AS.
> If they don't talk to the same AAA server, then how are the AAA servers related?
This is also part of the basics of AAA: they belong to a federation. We 
use this everyday in eduroam, for example.

Based on EAP peer identity (represented as a Network Access Identifier) 
helps to “route” the EAP packets to the AAA/EAP server. However, that is 
something that AAA infraestructures already support, so nothing new 
there. We do not see any problem either.

Best Regards.

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