Re: [Emu] [Ace] New Version Notification for draft-ietf-ace-wg-coap-eap-04.txt
gt; message containing a cipher suite, the exchange of cipher suites between > EAP authenticator and EAP peer cannot be verified. For example, a > man-in-the-middle could replace cipher suites in either message which would > not be noticed if the protocol is ended after step 2. > > > > [authors] That’s right. However, after your comments, we believe this > could be improved. The reason is that by default we can assume that at > least cipher suite 0. AES-CCM-16-64-128, SHA-256 is implemented in both > entities. As such, if the controller includes option 0 in the list of > cipher suites, the controller will not receive a bad request since at least > the IoT device can select cipher suite 0 and therefore the authentication > will follow until the end cipher suite negotiation can be verified. We > think it is simpler and we can get rid of a bad request. Does it sound > reasonable? > > [GS] Sounds OK to me. > > > > > > > > ___ > Ace mailing list > a...@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Daniel Migault Ericsson ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] New Version Notification for draft-ietf-ace-wg-coap-eap-04.txt
cessful before EAP-SUCCES. > > > > - In section 3.3. it might be good to state that "Reauthentication" might > be needed to rekey MSK/EMSK and to increase protection against key leakage. > > > > (An important mitigation of pervasive monitoring is to force attackers to > do dynamic key exfiltration instead of static key exfiltration. Dynamic key > exfiltration increases the risk of discovery for the attacker [RFC7624]. > While OSCORE will soon be augmented with a rekeying mechanism with forward > secrecy, attackers can still get away with doing static key exfiltration. > This is similar to TLS 1.3 with KeyUpdate, after leakage of > application_traffic_secret_N, a passive attacker can passively eavesdrop on > all future application data sent on the connection including application > data encrypted with application_traffic_secret_N+1, > application_traffic_secret_N+2, etc.) > > > > - "4. The values from 65000 to 65535 are reserved for experimentation" > > > >what does "The values" refer to? Lifetime? In that case it would fit > better under 3. > > > > - In addition to AES-CCM-16-64-128, only ciphersuites only cipher suites > with AES-GCM is included. My feeling was that most IoT people are more > interested in ChaCha20-Poly1305 than AES-GCM. I don't have a strong > personal opinion. > > > > - "which is considered fresh key material" > > > >“considered fresh”? Maybe "uniformally random"? > > > > - With normal use of DTLS, Appendix A violates “The CoAP-EAP operation is > intended to be compatible with the use of intermediary entities between the > IoT device and the Controller”. This limitation should be clearly stated. > > > > - Probably good if the labels have “CoAP-EAP” in all the labels to > guarantee that they do not collide with anything else. > > > > Cheers, > > John > > > > *From: *Emu on behalf of Dan Garcia Carrillo < > garcia...@uniovi.es> > *Date: *Monday, 25 October 2021 at 13:27 > *To: *a...@ietf.org , EMU WG > *Subject: *Re: [Emu] New Version Notification for > draft-ietf-ace-wg-coap-eap-04.txt > > Dear ACE and EMU WG, > > We have submitted a new version of the draft (draft-ietf-ace-wg-coap-eap) > > This version provides information on the different comments, from the > reviews and interim meetings. > > Best Regards. > > > El 10/25/2021 a las 1:23 PM, internet-dra...@ietf.org escribió: > > A new version of I-D, draft-ietf-ace-wg-coap-eap-04.txt > > has been successfully submitted by Dan Garcia-Carrillo and posted to the > > IETF repository. > > > > Name: draft-ietf-ace-wg-coap-eap > > Revision: 04 > > Title:EAP-based Authentication Service for CoAP > > Document date:2021-10-25 > > Group:ace > > Pages:29 > > URL: > https://www.ietf.org/archive/id/draft-ietf-ace-wg-coap-eap-04.txt > > Status: > https://datatracker.ietf.org/doc/draft-ietf-ace-wg-coap-eap/ > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-ietf-ace-wg-coap-eap > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-wg-coap-eap-04 > > > > Abstract: > > This document specifies an authentication service that uses the > > Extensible Authentication Protocol (EAP) transported employing > > Constrained Application Protocol (CoAP) messages. As such, it > > defines an EAP lower layer based on CoAP called CoAP-EAP. One of the > > primer goals is to authenticate a CoAP-enabled IoT device (EAP peer) > > that intends to join a security domain managed by a Controller (EAP > > authenticator). Secondly, it allows deriving key material to protect > > CoAP messages exchanged between them based on Object Security for > > Constrained RESTful Environments (OSCORE), enabling the establishment > > of a security association between them. > > > > > > > > > > > The IETF Secretariat > > > > > > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > ___ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > -- Daniel Migault Ericsson ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] [Ace] Proposed charter for ACE (EAP over CoAP?)
CCing emu, core It seems ACE to me that ACE could be home for such a document. I am wondering if emu core or any other WG believe there is a better place for it. Regarding ACE I am wondering what is the WG opinion about adding this item to the ACE charter. Yours, Daniel From: Ace on behalf of Dan Garcia Sent: Thursday, December 3, 2020 6:10 AM To: a...@ietf.org Subject: [Ace] Proposed charter for ACE (EAP over CoAP?) Dear all: Regarding the new charter, since ACE is considering the definition of CoAP transport for CMPv2 (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00), we were wondering whethere it could also consider specifying EAP (Extensible Authentication Protocol) over CoAP. In this sense, we proposed this some time ago and we have implementations about this. https://datatracker.ietf.org/doc/html/draft-marin-ace-wg-coap-eap-06 https://www.mdpi.com/1424-8220/16/3/358 https://www.mdpi.com/1424-8220/17/11/2646 The usage of CoAP can provide a very light and link-layer independent (we even tested in LoRa networks) EAP lower-layer (transport for EAP) suitable for IoT enviroment. We believe this would be really useful since EAP provides flexibility for the authentication and it is a well-known protocol. Therefore, we would like to propose the following modification to the charter: "The Working Group will examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols, such as EST and CMPv2, as well as a transport for authentication protocols such as EAP, and standardize them as needed." This modification does not necessarily mean the adoption of our draft. After all, we completely understand that this would happen only if there is an interest in the WG. Nevertheless, we would like to avoid that the charter is a barrier later if there is interest in the WG to work in this transport of EAP over CoAP: Any opinion about this? Best Regards. El 18/11/2020 a las 8:08, Daniel Migault escribió: Hi, Please find the proposed charter we agreed on during the interim meeting. If you would like to propose any change, please use the following URL by November 25: https://docs.google.com/document/d/1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY/edit?usp=sharing<https://protect2.fireeye.com/v1/url?k=f9dc6551-a6475d83-f9dc25ca-866132fe445e-9c25a5c257a23470=1=03ce3af5-6990-40e0-b2b5-255ac5f5dfe0=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1RtxUSvUeBdZWoQkjSj2c3DtR8DuBwPM2BnBXhoDiptY%2Fedit%3Fusp%3Dsharing> Yours, Daniel The Authentication and Authorization for Constrained Environments (ace) WG has defined a standardized solution framework for authentication and authorization to enable authorized access to resources identified by a URI and hosted on a resource server in constrained environments. The access to the resource is mediated by an authorization server, which is not considered to be constrained. Profiles of this framework for application to security protocols commonly used in constrained environments, including CoAP+DTLS and CoAP+OSCORE, have also been standardized. The Working Group is charged with maintenance of the framework and existing profiles thereof, and may undertake work to specify profiles of the framework for additional secure communications protocols and for additional support services providing authorized access to crypto keys (that are not necessarily limited to constrained endpoints, though the focus remains on deployment in ecosystems with a substantial portion of constrained devices). In addition to the ongoing maintenance work, the Working Group will extend the framework as needed for applicability to group communications, with initial focus on (D)TLS and (Group) OSCORE as the underlying group communication security protocols. The Working Group will standardize procedures for requesting and distributing group keying material using the ACE framework as well as appropriated management interfaces. The Working Group will standardize a format for expressing authorization information for a given authenticated principal as received from an authorization manager. The Working Group will examine how to use Constrained Application Protocol (CoAP) as a transport medium for certificate enrollment protocols, such as EST and CMPv2, and standardize as needed. On Tue, Nov 17, 2020 at 6:47 PM Benjamin Kaduk mailto:ka...@mit.edu>> wrote: Thanks for updating the draft charter at [1], Daniel! I note that Michael raised the question of whether some other group might also be interested in working on CMP-over-coap, so the IESG will be sure to discuss that if CMP is still in the draft ACE charter when it goes to the IESG for review. -Ben On Tue, Nov 17, 2020 at 06:16:48PM -0500, Daniel Migault wrote: > Thank you all for the feed backs. For the purpose of driving the charter > discussion at the IETf 10
[Emu] draft-aura-eap-noob-07 review
Hi, I have reviewed the eap-noob document and believe it is ready for adoption. I have made a series of comments that are mostly editorial and some clarifying questions. I am happy to review the document further. Yours, Daniel [...] Abstract Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. This EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have a minimal user interface and no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB channel between the peer device and authentication server. A nit. There are double spaces, so maybe :%s/ / /gc may be needed. I believe that *minimal* should be expanded here as it might be an important characteristic of the object. Typically the ability to communicate an URL to the end user, is a characteristic that is not generic to all devices at least maybe not the bulb or temperature network. I would be good that from the abstract the reader knows if this methods apply or not. 1. Introduction This document describes a method for registration, authentication and key derivation for network-connected ubiquitous computing devices, such as consumer and enterprise appliances that are part of the Internet of Things (IoT). These devices may be off-the-shelf hardware that is sold and distributed without any prior registration or credential-provisioning process. Thus, the device registration in a server database, ownership of the device, and the authentication credentials for both network access and application-level security must all be established at the time of the device deployment. Furthermore, many such devices have only limited user interfaces that could be used for their configuration. Often, the interfaces are limited to either only input (e.g. camera) or output (e.g. display screen). The device configuration is made more challenging by the fact that the devices may exist in large numbers and may have to be deployed or re-configured nimbly based on user needs. More specifically, the devices may have the following characteristics: o no pre-established relation with a specific server or user, I understand this characteristic as requiring that devices must be completely new. I have the impression that the characteristic concerns more the state of the device then the device itself. Does the text means that such characteristics are not necessary or that these characteristic if existing will make the registration impossible. Typically, I imagine the following scenarios. I have a registered screen from in a server in my company. I am taking that screen to the University that organises a workshop. Can the screen work with two different accounts/registration on different servers ? Do I have to necessarily factory reset the screen ? Do I have to redo the registration procedure when I bring the screen back to my company ? Am I going to possibly register the screen I bought on second-hand-gatan ? o no pre-provisioned device identifier or authentication credentials, I do have the same questions as above. o limited user interface and configuration capabilities. I am finding limited too vague to understand if my device is a candidate for this registration. Many proprietary OOB configuration methods exits for specific IoT devices. The goal of this specification is to provide an open standard and a generic protocol for bootstrapping the security of network-connected appliances, such as displays, printers, speakers, Aura & Sethi Expires May 1, 2020 [Page 3] Internet-Draft EAP-NOOBOctober 2019 and cameras. The security bootstrapping in this specification makes use of a user-assisted out-of-band (OOB) channel. The device authentication relies on user having physical access to the device, and the of the key exchange security is based on the assumption that attackers are not able to observe or modify the messages conveyed through the OOB channel. We follow the common approach taken in pairing protocols: performing a Diffie-Hellman key exchange over the insecure network and authenticating the established key with the help of the OOB channel in order to prevent impersonation and man-in-the- middle (MitM) attacks. The solution presented here is intended for devices that have either an input or output interface, such as a camera, microphone, display screen, speakers or blinking LED light, which is able to send or receive dynamically generated messages of tens of bytes in length. I believe that this characteristics should be mentioned earlier as it characterizes the devices. The
