Benjamin Kaduk has entered the following ballot position for
draft-ietf-emu-rfc5448bis-07: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/
--
COMMENT:
--
I mostly only read the diff and skimmed the rest.
Section 1
The rest of this specification is structured as follows. Section 3
defines the EAP-AKA' method. Section 4 adds support to EAP-AKA to
prevent bidding down attacks from EAP-AKA'. Section 5 specifies
requirements regarding the use of peer identities, including how EAP-
AKA' identifiers are used in 5G context. Section 6 specifies what
I'm not sure if it's "EAP-AKA' identifiers being used in 5G context" or
"5G identifiers being used in an EAP-AKA' context" -- which way does the
causality go?
Section 4
Note that we assume (Section 7) that EAP-AKA' is always stronger than
EAP-AKA. As a result, there is no need to prevent bidding "down"
attacks in the other direction, i.e., attackers forcing the endpoints
to use EAP-AKA'.
I'd prefer to say something like "we do not provide" rather than "there
is no need".
Section 5.2
I agree with the IoTdir reviewer's concerns about over-stating the need
for a secure PRNG in pseudonym generation.
Section 5.3.1
In all other cases, the following applies:
The identity used in the key derivation formula MUST be exactly
the one sent in EAP-AKA' AT_IDENTITY attribute, if one was sent,
regardless of the kind of identity that it may have been. If no
AT_IDENTITY was sent, the identity MUST be the exactly the one
sent in the generic EAP Identity exchange, if one was made.
Again, the identity MUST be used exactly as sent.
If no identity was communicated inside EAP, then the identity is
the one communicated outside EAP in link layer messaging.
In this case, the used identity MUST be the identity most recently
communicated by the peer to the network, again regardless of what
type of identity it may have been.
Just to check: there's a strong message sequencing, so that there cannot
be ambiguity between peers about the "most recently communicated"
identity?
Section 5.3.1.1
23415099...@nai.5gc.mnc015.mcc234.3gppnetwork.org
Should this be using an example domain name instead of 3gppnetwork.org?
(I think "no", but have to check.)
Section 5.3.2.1
For the null-scheme:
type0.rid678.schid0.userid09@nai.5gc.mnc015.
mcc234.3gppnetwork.org
For the Profile protection scheme:
type0.rid678.schid1.hnkey27.ecckey.
cip.mac@nai.5gc.
mnc015.mcc234.3gppnetwork.org
[ditto]
Section 6
The EAP-AKA' Session-Id is the concatenation of the EAP Type Code
(0x32, one byte) with the contents of the RAND field from the AT_RAND
attribute, followed by the contents of the AUTN field in the AT_AUTN
attribute:
Session-Id = 0x32 || RAND || AUTN
When using fast re-authentication, the EAP-AKA' Session-Id is the
concatenation of the EAP Type Code (0x32) with the contents of the
[...]
nit: the second paragraph contradicts the first, since the first one
does not disclaim that it's only for "regular authentication"
(non-fast-reauthentication).
Section 7
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.
Could we mention that we are not agile with respect to the use of
SHA256/HMAC-SHA256?
Section 7.2
Basin et al [Basin2018] have performed formal analysis and concluded
that the AKA protocol would have benefited from additional security
requirements, such as key confirmation.
This feels a bit like a teaser -- what would be gained/prevented by
using key confirmation? Is there a path towards performing key
confirmation in the future?
Section 7.3
As described Section 7.2, after the publication of RFC 5448, new
nit: "As described in"
In particular, it is crucial that manufacturers limit access to the
secret information and the cards only to necessary systems and
personnel. It is also crucial that secure mechanisms be used to
communicate the secrets between the manufacturer and the operator
that adopts those cards for
