[Ace] Secdir last call review of draft-ietf-ace-wg-coap-eap-09

Deb Cooley via Datatracker <noreply@ietf.org> Tue, 23 January 2024 12:07 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ace@ietf.org
Delivered-To: ace@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F33C14F6FB; Tue, 23 Jan 2024 04:07:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Deb Cooley via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: ace@ietf.org, draft-ietf-ace-wg-coap-eap.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.3.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <170601163753.46347.3725201997179804291@ietfa.amsl.com>
Reply-To: Deb Cooley <debcooley1@gmail.com>
Date: Tue, 23 Jan 2024 04:07:17 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/1RHl52wyHa_ycHmCrXIcDaGtEf8>
Subject: [Ace] Secdir last call review of draft-ietf-ace-wg-coap-eap-09
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 23 Jan 2024 12:07:17 -0000

Reviewer: Deb Cooley
Review result: Has Nits

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Document: draft-ietf-ace-wg-coap-eap-09
Reviewer: Deb Cooley
Review Date: 2024-01-23

The summary of the review is 'Has Nits'.

0.  All of my early review comments have been addressed.  TY

1.  Section 5.1, last paragraph:  The MSK can be assumed to be 'fresh key
material', but do all EAP methods yield 'strong cryptographic key' by Section
3.3 of RFC 5869?  If some EAP methods do not yield strong keys, then either the
KDF Extract should be used, or those methods should not be allowed.  (I did not
look this up, so telling me that you all checked is a fine answer)

2.  Section 5.2:  It would be useful to have an actual example of the info part
of the KDF. How is CS constructed - spaces, commas? Are there spaces between CS
and the string?