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 234150999999...@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.userid0999999999@nai.5gc.mnc015. mcc234.3gppnetwork.org For the Profile <A> protection scheme: type0.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key>. cip<encryption of 0999999999>.mac<MAC tag value>@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 their customers. No recommendation for encryption at rest? Beyond these operational considerations, there are also technical means to improve resistance to these attacks. One approach is to provide Perfect Forwards Secrecy (PFS). This would prevent any passive attacks merely based on the long-term secrets and observation of traffic. Such a mechanism can be defined as a backwards- compatible extension of EAP-AKA', and is pursued separately from this specification [I-D.ietf-emu-aka-pfs]. Alternatively, EAP-AKA' authentication can be run inside a PFS-capable tunneled authentication method. In any case, the use of some PFS-capable mechanism is recommended. My preference would be to drop the "Perfect" and also discuss forward secrecy with respect to specific event(s). See also the discussion at https://mailarchive.ietf.org/arch/msg/saag/81XWrBZiLNoPg7kfnAdaxIB8da8/ Section 7.4 The server receives the EAP transaction from a given access network, and verifies that the claim from the access network corresponds to the name that this access network should be using. It becomes impossible for an access network to claim over AAA that it is another access network. In addition, if the peer checks that the information it has received locally over the network-access link layer matches with the information the server has given it via EAP-AKA', it becomes impossible for the access network to tell one story to the AAA network and another one to the peer. These checks prevent some Why is this an "if" the peer checks -- shouldn't it be mandatory? Appendix 9.2 It looks like the only place we reference [FIPS.180-1] and [FIPS.180-2] is in the note saying that we updated the references to them :) _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
