Re: [Ace] CoAP-EAP draft
Christian Amsüss <christian@amsuess.com> Mon, 16 August 2021 14:40 UTC
Return-Path: <christian@amsuess.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB22B3A17B5; Mon, 16 Aug 2021 07:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ebnLpAdm7CoB; Mon, 16 Aug 2021 07:40:14 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBCE93A17B1; Mon, 16 Aug 2021 07:40:11 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id E4E9D40104; Mon, 16 Aug 2021 16:40:06 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id BFC2AD0; Mon, 16 Aug 2021 16:40:04 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:6a01:d988:4e55:c71b]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 3681C46; Mon, 16 Aug 2021 16:40:04 +0200 (CEST)
Received: (nullmailer pid 2872286 invoked by uid 1000); Mon, 16 Aug 2021 14:40:03 -0000
Date: Mon, 16 Aug 2021 16:40:03 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Dan Garcia Carrillo <garciadan@uniovi.es>
Cc: EMU WG <emu@ietf.org>, "ace@ietf.org" <ace@ietf.org>, Rafa Marin-Lopez <rafa@um.es>, core@ietf.org
Message-ID: <A4C71152-DA98-47B1-9BFC-136F59CAB68A@amsuess.com>
References: <0cfd2df3-9264-b6fd-e58b-a93a7d8fda5f@uniovi.es>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <0cfd2df3-9264-b6fd-e58b-a93a7d8fda5f@uniovi.es>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/RNFRrQyDLQsgRYvBTY6VHCwAXAg>
Subject: Re: [Ace] CoAP-EAP draft
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Aug 2021 14:40:19 -0000
Hello CoAP-EAP authors and involved groups, (CC'ing core@ as this is a review on CoAP usage), I've read the -03 draft and accumulated a few comments; largely in sequence of occurrence. Over all, the protocol has improved a lot since I've last had my eyes on it. Several comments below are about how prescriptive the message types are. I believe that this should be resolved towards generality, or else the usability of this protocol with generic CoAP components will be limited (or, worse, still implemented and then surprisingly incompatible). * Figure 1: For readers new to the topic of EAP, I think that it might be useful to extend this to cover also the EAP server or AAA infrastructure, if that can be covered without too much complication. Suggestion (without illusions of correctness): IoT device Controller +------------+ +------------+ | EAP peer/ | | EAP auth./ |+-----+[ AAA infra. ] | CoAP server|+------+| CoAP client|+-----+[ EAP server?] +------------+ CoAP +------------+ EAP? \_____ Scope of this document _____/ Figure 1: CoAP-EAP Architecture * `/.well-known/a`: [note: May be irrelevant, see next two items] If the designated experts don't go along with a very-short option (I'd kind of doubt you'd get anything shorter than `/.well-known/eap`) and if that puts you up against practical limits, using a short-hand option might be viable. So far there's no document for it and I've only pitched the idea briefly at an interim[1] (slides at [2]), but if push comes to shove and you need the compactness, let me know and that work can be expedited. [1]: https://datatracker.ietf.org/meeting/interim-2021-core-05/session/core [2]: https://datatracker.ietf.org/meeting/interim-2021-core-05/materials/slides-interim-2021-core-05-sessa-core-option-for-well-known-resources-00 * Discovering the Controller is described rather generically, but with CoAP discovery as an example. As long as CoAP discovery (as per RFC6690/7252) is used, that already produces a URI, which can contain any path the server picked. It has thus no need for a well-known path. Are there other discovery options envisioned that'd only result in a network address? Only for these, a well-known path would make sense. (And then it's up to the envisioned client complexity if one is warranted). For comparison, RD[3] explores some of the options. A path may be discovered using CoAP discovery as `?rt=core.rd*` right away from multicast. Or an address may be discovered using an IPv6 RA option, with CoAP discovery acting on that address. Only for cases of very simple endpoints, it also defines a `/.well-known/rd` name that can be used without CoAP discovery (and thus link parsing) happening beforehand. The same rationales may apply for EAP (the devices using the resource are mostly servers, otherwise, and send a very simple request to start things), but again that's only if the address was discovered through something that's not CoAP discovery already. [3]: https://www.ietf.org/archive/id/draft-ietf-core-resource-directory-28.html#name-rd-discovery-and-other-inte * For message 1, why does this need to go to a fixed resource? There has been previous communication in message 0 in which the resource could have been transported. Granted, it's not as easy as in messages 2-to-3 etc where the Location-* options are around, but the original message 0 POST could just as well contain the path in the payload. There are options as to how to do that precisely (just the URI reference in text form, or a RFC6690 link, or a CBOR list of path segments, or a CRI reference[4] -- if the latter were in WGLC already I'd recommend it wholeheartedly), but either of them would stay more true to the style of the other messages in that the earlier message informs the path choice of the next ones. An upside of this would be that it allows better behavior in presence of proxies (see later), even though it may be practical to not spec that out in full here. (But the path would be open for further specs, and they'd just need some setting down of paving stones). [4]: https://datatracker.ietf.org/doc/draft-ietf-core-href/ * (Bycatch of suggesting URIs): It may be worth mentioning that the NON's source address can easily be spoofed. Thus, any device on the network can trigger what the authenticator may think of as a device-triggered reauthentication, and the device may think of as an authenticator-triggered reauthentication (provided it works that way, see below when reauthentication is mentioned again). Even sending full URIs in message 0 would be no worse than the current source spoofing. Sending URI paths in message 0 would make this minimally better because the attacker would need to guess (or observe from the network) the CoAP server's path. * In 3.1 General flow, the message types are described in high detail. CoAP can generally be used with different transports (some of which don't even do NON/CON). Also, while I think it's reasonable to expect that a CoAP implementation can deal with requests coming in as either CON or NON, I'd expect that some don't offer all possible choices to applications. (A very constrained device may only send NON requests, or an implementation may decide autonomously whether to send piggy-backed or not). Can you clarify as to what of this is meant to be normative and what exemplary? My recommendation is to state that what is prescribed is the flow of requests and responses (which is what CoAP provides to the next layer), while notes on reliable transmission are recommendations for CoAP-over-UDP/DTLS. A similar statement, which I like a lot, is already in 3.2 on error handling. (I can serve examples of how subtle incompatibilities can develop but go unnoticed, but I'd only go through that if this is all really intended to be prescriptive). * The reuse of the empty token only works if the peers actually respond with piggy-backed responses, so that's where enforcing the above rules would give some benefit -- but at the cost of losing existing CoAP implementations that make no guarantees as to how the response will be sent as long as it's reliable. * Proxying: As it is right now, this protocol just barely works across proxies, and only if they support CoAP-EAP explicitly. (And while it may sound odd to even consider that, bear in mind that they are used in a very similar way in RFC9031). While it's a bit open whether all CoAP-based protocols should reasonably be expected to work across proxies or not, a remark (maybe before 3.1?) that "If CoAP proxies are used between EAP peer and EAP authenticator, they must be configured with knowledge of this specification, or the operations will fail after step 0." * 3.2.2: The use of RST is rather unusual here, for the same reasons as the prescriptive message types. A response of 5.03 (Service Unavailable) has roughly the same size, is available independent of transport, and on most libraries *way* easier to use, if they support sending an RST to a well-formed message at all. (Furthermore, the sender of the 5.03 can encode an estimate of the remaining unavailable time in the Max-Age option; not sure if that is of any help here). * 3.3.1: "received with the ACK", "sends piggybacked response" are, again, overly specific. "received in the last response" and "sends a response" could work as replacements even if message types are presecriptive. * 3.3.1: "after the maximum retransmission attempts, the CoAP client will remove the state from its side". So the device that's being kicked from the network can delay its own eviction for about a minute as long as it doesn't answer? * 3.3.2: Is reauthentication always triggered by the EAP peer, or can it also be triggered by the authenticator? If the latter, will the authenticator use /.well-known/a again, or POST something to the resource from where it'd DELETE in 3.3.1? * cryptosuites: What's the upgrade model of that hardcoded list? As it is now, it looks pretty static, so updates would be through updates of this document. The obvious alternative is an IANA registry with ranges, policies and the usual pros and cons. Then again, this is not the first nor last time AEAD algorithms with their parametrization and hash functions are assigned aggregate numbers (I-D.ietf-lake-edhoc comes to mind which has asymmetric algs in the mix too; probably others as well); can we deduplicate this with anything? (Possibly by bringing this up with COSE or OSCORE people). * OSCORE derivation: Is it cryptographically necessary to derive *both* a master secret and a master salt through KDF? (Sounds like a needless step to me, as both only go into KDF once more when the actual OSCORE parameters are derived). I *guess* there's a good reason why the MSK is not used as the OSCORE IKM right away and the CSO as OSCORE master salt, but it'd help to have at list a comment here on why that's needed. (It may be useful to compare this step to the HKDF steps in OSCORE; their info element is always a 5-element array with a 4th "type" element of "Key" or "IV"; other extractions might just hook in there with different type values, maybe, and save everyone an extra handling step). * OSCORE ID derivation: * Randomly assigned full-length ideas look like an odd choice. They are excessively long (nonce length - 6 is 7 for the MTI AES-CCM-16-64-128 and shorter for other current ones, but I doubt that keeping the IV *short* is necessarily a design criterion for future algorithms). What commonly happens here (eg. in the ACE-OSCORE profile, or in EDHOC) is that each party picks a recipient ID out of its pool of currently unused IDs. This makes for shorter keys, and allows the client to be sure that no two peers use the same context. Any chance something like that can still make it in? * If the parties happen to be assigned the same sender ID, bad things happen (identical key derivation, nonce reuse, nuclear meltdown). If the current pattern of KDF'ing IDs stands, this needs to be prevented explicitly. * The derivations of "OSCORE RECIPIENT ID" and "OSCORE SENDER ID" are confusing as they each need to happen on both sides, and the terms will match on one and need to be opposite on the other. (I couldn't even easily find which is intended to be which). My suggestion is to derive "OSCORE EAP PEER SENDER ID" and "OSCORE AUTHENTICATOR SENDER ID" instead. (Or preferably shorter strings). * Exmaples: Do you envision particular EAP protocols to be used in the given examples? Best regards Christian
- [Ace] CoAP-EAP draft Dan Garcia Carrillo
- Re: [Ace] CoAP-EAP draft Christian Amsüss
- Re: [Ace] CoAP-EAP draft Dan Garcia Carrillo
- Re: [Ace] CoAP-EAP draft Dan Garcia Carrillo
- Re: [Ace] CoAP-EAP draft Christian Amsüss
- Re: [Ace] CoAP-EAP draft Christian Amsüss