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

From: Francisco Martin de la Fuente <[email-masked]>
Date: Tue, 2 Feb 2021 08:24:05 +0100

Dear members of the ACE working group,

I am pleased to be subscribed on this mailing list and follow the
activities of this WG.
We have been informed about the call for adoption of the draft (
https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-07)
We found it very interesting due to our actual works on the IoT CoAP based
projects.
We have been working on large scale Wifi networks for more than 14 years,
and we are very familiar with Telco Service providers integration.
We are now working on IoT services design for Telcos SP and we believe that
there are some interesting use cases on the integration of IoT protocols
with AAA platforms, very common on Telco integrations.
We think data accounting is a very interesting use case. Not exclusive from
other accounting methods and interesting on the security layer.
We believe it should be adopted.

Thanks,
Regards,

Francisco

Francisco Martín de la Fuente Magán
Director of Operations
+34 690618136
Skype: fmartin_fon
All information in this email is confidential <https://fon.com/legal/>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 2 Feb 2021 12:33:40 +0100

> Daniel Migault <[email-masked]> Thu, 21 January 2021 13:13 UTC
> 
> Hi,
> 
> The charter approval by the IESG is expected to be approved in the
> coming weeks. In the meanwhile, this email starts a call for adoption
> on work that has been included in the charter. Of course, adoption is
> contingent on the rechartering succeeding.
> 
> The document called for adoption is draft-marin-ace-wg-coap-eap
> available here: 
> https://tools.ietf.org/html/draft-marin-ace-wg-coap-eap-07
> 
> Please state your opinion on whether this work should not or should
> be adopted by the WG and express your motivation for such a
> statement. The call for adoption closes on February 4.
> 
> Yours, Daniel
> 
> 
> -- Daniel Migault Ericsson
> 

Hi,

This is my first post to this list.

We agreed internally that we at CEA support the adoption of this draft.

We have a few comments:

> ·        §3 “two different sequence _flow_” (typo: ‘s’ missing);
> 
> ·        §3 “_should_ be valid”: I do not like the feeling of
> uncertainty given by this lowercase ‘should’. What would be the
> restraints to this statement? Which key-deriving methods would not be
> acceptable?
> 
> ·        Page 5 “_on the contrary_, if DTLS”. I would replace « on
> the contrary » with “on the other hand” or “alternatively”… DTLS is
> not the opposite of OSCORE ;)
> 
> ·        PANA RFC is referenced but not quoted. I have to admit that
> my knowledge of IETF edition rules is now almost inexistent, so maybe
> it is acceptable to reference background RFCs that one does not
> actually quote in the text;
> 
> ·        You could find worthwhile to quote RFC6677, which seems (I
> may be wrong) relevant to the topic you address.

Yours,

Alexandre PETRESCU

---

From: Pedro Moreno-Sanchez <[email-masked]>
Date: Wed, 3 Feb 2021 17:28:59 +0100

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.