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

[Pedro Moreno-Sanchez <[e-mail]>]

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.