Belated thank you Russ for the review, my ballot will take this into account.
-éric
-----Original Message-----
From: Iot-directorate <iot-directorate-boun...@ietf.org> on behalf of Russ
Housley via Datatracker <nore...@ietf.org>
Reply-To: Russ Housley <hous...@vigilsec.com>
Date: Tuesday, 24 March 2020 at 21:33
To: "iot-director...@ietf.org" <iot-director...@ietf.org>
Cc: "last-c...@ietf.org" <last-c...@ietf.org>,
"draft-ietf-emu-rfc5448bis....@ietf.org"
<draft-ietf-emu-rfc5448bis....@ietf.org>, "emu@ietf.org" <emu@ietf.org>
Subject: [Iot-directorate] Iotdir telechat review of
draft-ietf-emu-rfc5448bis-07
Reviewer: Russ Housley
Review result: Ready with Issues
I reviewed this document as part of the IoT Directorate's effort to
IoT-related IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the Internet Area Directors.
Document authors, document editors, and WG chairs should treat these
comments just like any other IETF Last Call comments.
Document: draft-ietf-emu-rfc5448bis-07
Reviewer: Russ Housley
Review Date: 2020-03-24
IETF LC End Date: 2020-01-29
IESG Telechat date: 2020-04-09
A review from the IoT Directorate was requested on 2020-03-23, which is
after the IETF Last Call ended. I assume that the Internet ADs want
this review to help inform them during IESG Evaluation.
Note: I did not review the Appendices.
Summary: Ready with Issues
Major Concerns:
Section 5.2 says:
The pseudonym usernames and fast re-authentication identities MUST be
generated in a cryptographically secure way so that that it is
computationally infeasible for an attacker to differentiate two
identities belonging to the same user from two identities belonging
to different users. This can be achieved, for instance, by using
random or pseudo-random identifiers such as random byte strings or
ciphertexts. See also [RFC4086] for guidance on random number
generation.
It is not clear to me that a random number generator is needed to hide
the identities. For example, a hash of a configured secret value and a
counter are probably good enough. There are clearly other ways to do it
too, and some of them need a random number generator. Because of the
way this is worded, it is not clear not me that my proposed solution
would meet the MUST statement. I do not think we want to make this
harder than necessary.
Section 7 says:
In general, it is expected that the current negotiation
capabilities in EAP-AKA' are sufficient for some types of
extensions and cryptographic agility, including adding Perfect
Forward Secrecy ([I-D.ietf-emu-aka-pfs]) and perhaps others. But
as with how EAP-AKA' itself came about, some larger changes may
require a new EAP method type.
I do not think it it appropriate to claim cryptographic agility when
SHA-256 and HMAC-SHA-256 are hardwired. It would be better to say that
a new EAP method will be defined to change the algorithms (as was done
to make EAP-AKA' in the first place).
Minor Concerns:
Section 1 includes the summary of changes from RFC 5448. However, it
does not mention the addition of Sections 3.5 and 4.1. Please add them.
Section 3.1 says:
Only the server sends the AT_KDF_INPUT attribute. The value is sent
as specified in [TS-3GPP.24.302] for both non-3GPP access networks
for 5G access networks.
There are some missing words here. I am not really sure what is
intended, so I cannot offer a fix.
Section 5.3.1 says:
Again, the identity MUST be used exactly as sent.
Please delete! Saying it twice does not make it a stronger MUST.
Section 7.2: s/encrypt all payload traffic after encryption/
/encrypt all payload traffic after authentication/
Nits:
Section 1: s/ non-goal of this draft/ non-goal of this memo/
There is a misalignment in the bottom box in Figure 1. This is
surprising because the figure is otherwise identical to the one in
RFC 5448.
In Section 3.5: The introduction to the numbered columns is simply
"In addition:". For clarity, I think it would be better to say
something like:
The numbered columns indicate the quantity of the attribute
within the message as follows:
Section 5.1: s/(see Section 5.3.2 and Section 5.3.2.1./
/(see Section 5.3.2 and Section 5.3.2.1)./
Section 5.3: s/as defined in this RFC/as defined in Section 5.1/
I suggest the following structure for Section 5.3.1:
5.3.1. Key Derivation
5.3.1.1 Format of the SUPI
5.3.1.2 Format of the other identities
Section 6: s/Peer-Id is null string/Peer-Id is the null string/
Section 7.2: s/recommendations from Section 5.2 need to be
followed to avoid this.
Section 7.2: s/following the recommendations in Section 5.2
mitigate this concern./
--
Iot-directorate mailing list
iot-director...@ietf.org
https://www.ietf.org/mailman/listinfo/iot-directorate
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
