Re: [Iot-directorate] Iotdir telechat review of draft-ietf-emu-rfc5448bis-07

["Eric Vyncke (evyncke)" <[e-mail]>]

Belated thank you Russ for the review, my ballot will take this into account.

-éric

-----Original Message-----
From: Iot-directorate <[e-mail]> on behalf of Russ Housley via Datatracker <[e-mail]>
Reply-To: Russ Housley <[e-mail]>
Date: Tuesday, 24 March 2020 at 21:33
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/iot-directorate