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 [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
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
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
