Re: [Ace] WGLC for draft-ietf-ace-wg-coap-eap-02

Carsten Bormann <> Sun, 20 June 2021 11:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D341F3A1176 for <>; Sun, 20 Jun 2021 04:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.922
X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_BLOCKED=0.001, SPF_FAIL=0.919, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id urtqjXJvqM0w for <>; Sun, 20 Jun 2021 04:50:37 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:32::19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5152F3A1172 for <>; Sun, 20 Jun 2021 04:50:37 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4G79vs6CWVz2xHk; Sun, 20 Jun 2021 13:50:33 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Carsten Bormann <>
In-Reply-To: <>
Date: Sun, 20 Jun 2021 13:50:33 +0200
Cc: Loganaden Velvindron <>, "" <>
X-Mao-Original-Outgoing-Id: 645882633.405894-142a7a9022a1e484d6adcc2ed45e76d6
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Mohit Sethi M <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [Ace] WGLC for draft-ietf-ace-wg-coap-eap-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 20 Jun 2021 11:50:41 -0000

Hi Mohit,

great review!

There are a few places where I think you might be overcompensating, or where we actually have found good solutions previously that could be applied here.

> "The URI of the CoAP-EAP service CAN be set to "/b"? First, 
> "CAN" is capitalized but it is not in the list of keywords defined by 
> RFC 2119/RFC 8174.

Right.  As per BCP190, “/b” should really be qualified as an example (and it would be weird to choose an example that cannot actually be used, so that choice implies that it “can” be used).
for an example how this can be worded (this uses “/rd” for its examples).

Note that the resource directory also defines /.well-known/rd, to aid clients to operate on it *before* discovery has been completed.  Here this is different from the lookup interface that is shown to be under “/rd” in the examples.

I have no idea whether EAP over CoAP needs such a well-known path; that depends on whether the discovery that leads to operating on this resource provides a full URI (in which case the server can freely choose the path, no need for a well-known one) or just the IP address (in which case the client needs to be able to construct a URI from just that IP address).

> Add a reference to RFC 8174 in section 1.1. Besides, you already use 
> "MAY"/"MUST" in section 1. For example, the text says: "The CoAP client 
> MAY contact with a backend AAA infrastructure to complete the EAP 
> negotiation as described in the EAP specification [RFC3748]" but "MAY" 
> is defined as a keyword only later?

I don’t think this is a problem for a brief section that precedes the terminology.

> "The assumption is that" -> instead just say EAP methods used in this 
> specification MUST generate key.". Standards specifications don't make 
> assumptions and rather dictate what implementations/deployments should do.

I would be careful with restating a MUST from a base standard.  Sometimes semantic differences creep in, and this creates a special flavor of the base standard, even if that is not intended.  Here, it is probably best to factually state that EAP methods generate a key.  Or, if that is meant, that this specification MUST NOT be used with EAP methods that do not generate a key.

> I don't fully understand the logic behind having separate resources for 
> each request.

The idea is to separate protocol runs.  Allowing the attacker to confuse the parties about their protocol runs is one of the leading sources of vulnerabilities.

> I read Christian Amsüss's CoAP FAQ on this. It helped a 
> bit but I am not sure why this is needed since RFC 3748 says: "EAP 
> provides its own support for duplicate elimination and retransmission."?

Well, EAP over CoAP replaces that part of EAP, so indeed the functionality needs to be provided here.

> Why can't you send the identity already in the first POST message from 
> the device. AFAIK, a separate Identity request and response is not 
> necessary. You'll save on one round trip? This will also help the 
> authenticator to decide already on the first message if it should 
> continue or not (depending on the domain name in the NAI)?

I think that reducing round-trips may be a valid way to optimize EAP, but I’m not sure that what you propose is always possible.

> Section 3.3: casuistics -> interesting choice of words. At least I had 
> to lookup the meaning.

It is best to avoid words that most people have to look up…

> MSG-ID -> Not used in RFC 7252 so I recommend that you should not use it 
> either. Also, perhaps adding a bit more context would not hurt. For 
> example, Message Id in CoAP is used for....... In CoAP-EAP, the Message 
> Id can be used for ..... You have also used MSGID (vs. MSG-ID) in the 
> document.

The message-id is not available at the service interface of CoAP.  But it may be useful to say that CoAP itself will make use of message-IDs to do deduplication etc.

> IANA Considerations section only says TBD.?? I would have thought that 
> it would be complete before issuing the working group last call?

Indeed!  It is important to see what registries/extension points EAP-CoAP uses and what it provides.

Grüße, Carsten