Hi Michael,
El 23/01/2021 a las 1:29, Michael Richardson escribió:
Dan Garcia Carrillo<[email protected]> 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<[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
