Hello,
my name is Pedro Moreno-Sanchez. As this is my first post to this list, let me
give some background about myself. I am the main developer of PANATIKI
(https://www.mdpi.com/1424-8220/13/11/14888
<https://www.mdpi.com/1424-8220/13/11/14888>), a lightweight version of PANA as
EAP Lower Layer intended for constrained devices. Moreover, I have also
implemented the integration mechanism of PANA and PCP as described here
https://tools.ietf.org/html/draft-ohba-pcp-pana-04
<https://tools.ietf.org/html/draft-ohba-pcp-pana-04> and discussed in the
IETF84 PCP WG (https://www.ietf.org/proceedings/84/slides/slides-84-pcp-3.pdf
<https://www.ietf.org/proceedings/84/slides/slides-84-pcp-3.pdf>)
I have been recently informed about the call for adoption of the draft
(https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-07
<https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-07>)
and I am writing this email to express my opinion that I believe this document
should be adopted. I base this opinion in the following three points:
* I have analyzed the technical details of the draft. I attach my analysis at
the end of this email. I find the specification technically correct and the
rationale behind the architecture design well founded. Moreover, the
specification has taken special consideration on maintaining the requirements
of an EAP Lower Layer.
* EAP is the standard that has been successfully and widely used for
authentication in several other scenarios such as 802.1X. Therefore, IMHO
having EAP-based authentication in ACE is definitely interesting.
* From my experience as the main developer of PANATIKI, the approach of taking
a general purpose EAP Lower Layer like PANA (let alone a more complex one) and
“prune” it to make it compatible to constrained devices is a rather challenging
task and error prone. The design of CoAP as EAP Lower Layer in this document
not only has the advantages that (i) CoAP is already suitable for constrained
devices and (ii) it fulfills the requirements as EAP Lower Layer; but also the
fact that the design has been carefully thought with performance in mind and it
already contains the performance enhancements that we discovered while building
PANATIKI.
Best regards,
Pedro Moreno-Sanchez.
===========
======
* Architecture: I find the design of the architecture one of the most
interesting points and yet well-motivated ones. At a first glance, one would
imagine that EAP peer would be colocated with CoAP client whereas EAP
authentication would be colocated with CoAP server. However, indeed the fact
that EAP requests flow from the EAP authenticator highly motivates to co-locate
it with the CoAP client. Then the EAP peer and CoAP server will be naturally in
charge of processing incoming requests and create the corresponding responses.
Perhaps, the only aspect that I am not fully convinced about this architecture
is that it seems to be the case that the CoAP server needs to discover the CoAP
client to start the authentication in the first place. If this is the case, the
CoAP client would need to implement some kind of listening process where
“discovery requests” are sent, perhaps to a certain IP address and port that
need to be announced (and standardize?) before, etc. Moreover, I am wondering
whether such behavior/functionality is part of the standardize description of
CoAP in the first place. In any case, it would be interesting that authors
expand on how the CoAP Server discovers the CoAP client and what are the
possible modifications/consequences of the design of that part.
* Data protected with OSCORE (or DTLS) context: The OSCORE Context is used to
protect the exchanged data earlier than I was expecting. In particular, the EAP
Success message is already protected with the key material derived from the
authentication. This means that the EAP peer should have been able to derive
the MSK before the arrival of message 7 so that it is able to authenticate such
message. This situation leads to two questions: (i) Is the EAP success also
protected when an EAP Lower Layer other than CoAP is used?; and (ii) is it
possible that the EAP Success (and thus the corresponding ACK can be omitted)?
In particular, with regards to the latter question, it seems to me that after
message 6 in Figure 2, whenever the EAP peer receives a message that is
protected by the OSCORE context, the EAP peer knows that the authentication was
successful if it can successfully verify the authenticated incoming message. If
that is the case, then the message 6 can be used to send directly authenticated
application data instead of the EAP Success. In any case, it would be
interesting that the authors elaborate in this aspect of their design.
* Comments regarding the use case scenario (Section 5): I find this section
highly useful and enlightening to bring the proposed design and methodology to
a real world use case. I have identified two points that I believe can be
expanded by the authors to further improve this section. First, at the end of
this section, you mention that ACE framework can be used to let an
authenticated node A access information stored at another authenticated node B
assuming that both A and B have been successfully authenticated by a controller
C. As it is written now, it is unclear whether (a) the ACE framework also
defined how A and B are authenticated in the first place; or (b) the
authentication of A and B is considered out of the scope in the ACE framework
and hence the design of CoAP-EAP would be complementary there. I assume the
answer would be b, yet would be interesting to clarify it.
Second, you list a node D in the list of entities involved in the use case
scenario but it is never mentioned afterwards. I think adding a non-constrained
device like D in the description of your use case scenario is highly
interesting because allows to give answer to several interesting questions that
arise at this point: Given that D is non-constrained, one could imagine that D
could use an EAP Lower Layer other than CoAP, requiring thus that EAP
authenticator runs several EAP Lower layers. Is that a possibility? Or would
you require that all EAP peers within the same domain use the same lower layer?
Is it possible to use ACE across nodes that use a different EAP method and/or
EAP lower layer (e.g., nodes B and D in your case)?
* Seqnum option: Given the restrictions that you put over the CoAP exchange
(e.g., a single session, lockable steps, etc.), I was wondering whether it
would be possible that you get rid of this Seqnum option and use the token for
the purpose of ordering messages. While tokens are usually to distinguish
across sessions, given that you have a single session/process per EAP peer, it
might be possible that you use a different token for each request/response
exchange (similar to the message id approach that you also mention) in order to
order the messages. If this is possible, you might avoid the Seqnum in the
first place, which requires more bytes.
Other minor comments:
* Sequence number: The sequence number has been designed such that it is
initially drawn uniformly at random and then monotonically incremented by 1
after each request/response interaction. One could imagine that it is possible
that there exists situations where such sequence number overflows, that is, it
goes over the maximum number possible to represent with the number of bytes
assigned to it. I imagine that the solution then is to do rounding (i.e., go to
zero and continue from there), similar to what is done in other protocols. Yet,
it would be interesting that the authors specify this behavior.
* OSCORE vs DTLS_PSK: Throughout the document, you propose two different
security context, namely OSCORE and DTLS_PSK. While this is undoubtedly
beneficial for the interoperability of the proposed work, it would be
interesting if the authors could expand on: (i) the pros and cons for each of
the two approaches; and (ii) is there a set of basic yet mandatory guidelines
that one should follow to design its own security context (e.g., say based on
HIP) from the key material exported after the CoAP-EAP authentication?
* Section 6.1: You have not discussed how CoAP as EAP lower-layer handles
possible duplications of messages (if supported at all as it is not required
for lower layers).
* Section A.1: You mention that DTLS_PSK will have 16 bytes. Why is that? Is
this a strong requirement from DTLS itself? Otherwise, it seems to me a too
short key. In fact, you suggest that the key that needs to be derived within
the OSCORE security context should have 32 bytes instead.
Editorial comments:
- page 1: aganist a AAA —> against an AAA
- page 3: "can be used as a constrained link-layer independent EAP lower-layer”
—> This sentence is hard to parse. In particular, link-layer independent of
what?
- page 3: OSCORE is mentioned for the first time without any reference.
- page 10: perform an CoAP-EAP —> perform a CoAP-EAP
- page 14: suit —> suite
- page 15: you mention EMSK for the first time in the document without further
reference.
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
