Re: [lisp] Roman Danyliw's Discuss on draft-ietf-lisp-sec-27: (with DISCUSS and COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Luigi!

Thanks for the quick response.  To your direct question, yes, the proposed edits described below address my feedback.

Roman

> -----Original Message-----
> From: Luigi Iannone <[e-mail]>
> Sent: Wednesday, June 29, 2022 7:42 AM
> To: Roman Danyliw <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: Roman Danyliw's Discuss on draft-ietf-lisp-sec-27: (with DISCUSS
> and COMMENT)
> 
> Hi Roman,
> 
> Thank you very much for your review.
> 
> A few proposed changes  inline.
> 
> > On 29 Jun 2022, at 03:47, Roman Danyliw via Datatracker <[e-mail]>
> wrote:
> >
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-lisp-sec-27: Discuss
> >
> > 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/about/groups/iesg/statements/handling-ballot-posi
> > tions/ for more information about how to handle DISCUSS and COMMENT
> > positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-lisp-sec/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > ** Since originally scheduled for the telechat in version -26, thank
> > you for adding the following text about preferring HMAC-SHA256 for new
> > deployments in
> > -27:
> >
> >   The HMAC
> >   function AUTH-HMAC-SHA-256-128 [RFC6234] MUST be supported in LISP-
> >   SEC implementations.  LISP-SEC deployments SHOULD use AUTH-HMAC-
> SHA-
> >   256-128 HMAC function, unless older implementations using AUTH-HMAC-
> >   SHA-1-96 are present in the same deployment [RFC2104].
> >
> > Could this same approach be applied for the algorithms set by KDF ID.
> > Specifically:
> >
> > -- Section 6.9 says:
> >
> >   The key derivation function
> >   HKDF-SHA1-128 [RFC5869] MUST be supported.
> > ...
> >  However, since HKDF-SHA1-128 is mandatory to implement, the process
> >   will eventually converge.
> >
> > Could it say something to the effect of:
> >
> > The key derivation function HKDF-SHA256 MUST be supported in LISP-SEC
> > implementations.  LISP-SEC deployments SHOULD use the HKDF-SHA256
> HKDF
> > function, unless older implementations using HKDF-SHA1-128 are present
> > in the same deployment.
> >
> > However, since HKDF-SHA1-128 and HKDF-SHA256 are supported, the
> > process will eventually converge.
> 
> Yes, good idea. THe text makes sense and makes LISP-Sec even more robust.
> 
> 
> >
> > -- Section 8.5.  Add HKDF-SHA256 to the "LISP-SEC Authentication Data Key
> >   Derivation Function ID" registry
> >
> 
> Yep.
> 
> 
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Thank you to Alexey Melnikov for the SECDIR review.
> >
> > ** Section 4.
> >   In this
> >   way the ETR can maliciously redirect traffic directed to a large
> >   number of hosts.
> >
> > Does the number of impact host matter so much as the generic ability
> > to redirect traffic?  I’m imagining that a “surgical” or targeted
> > attack might be equally interesting – for example, if there was a
> > particular services on a given prefix that an attacker wanted to redirect.
> 
> You are right. It works both ways.
> The text can simply state: “… the ETR can maliciously redirect traffic."
> 
> 
> >
> > ** Section 5.
> >
> >   Those trust relationships are used to securely
> >   distribute, as described in Section 8.4, ...
> >
> > Is Section 8.4, really the right reference here?
> >
> > ** Section 6.5
> >   Implementations of this specification MUST support OTK Wrapping ID
> >   AES-KEY-WRAP-128+HKDF-SHA256 that specifies the use of the HKDF-
> >   SHA256 Key Derivation Function specified in [RFC4868]
> >
> > RFC4868 doesn’t define a HKDF with SHA256.  Do you mean RFC5869?  Same
> > issue in Section 8.4 (IANA table)
> 
> Will be replaced.
> 
> >
> > ** Section 6.5
> >   4.  The per-message encryption key is computed as:
> >
> >       *  per-msg-key = KDF( nonce + s + PSK[Key ID] )
> >       where the nonce is the value in the Nonce field of the Map-
> >       Request, 's' is the string "OTK-Key-Wrap", and the operation'+'
> >       just indicates string concatenation.
> >
> > HKDFs typically take one more input, L, the output size.  Since this
> > is tied to a particular key wrap the options are more constrained.
> > AES-KEY-WRAP-128 can have both a 128-bit and 192-bit KEK, please
> > explicitly state the expected output size.
> 
> 
> 128 bits is the expected output size.
> 
> >
> > ** Section 7.4
> >
> >   As an example, in certain closed and controlled deployments, it is
> >   possible that the threat associated with an on-path attacker between
> >   the xTR and the Mapping System is very low, and after careful
> >   consideration it may be decided to allow a NULL key wrapping
> >   algorithm while carrying the OTKs between the xTR and the Mapping
> >   System.
> 
> 
> >
> > Wouldn’t this violate:
> > -- Section 6.4, “ITR-OTK confidentiality and integrity protection MUST
> > be provided in the path between the ITR and the Map-Resolver”
> >
> > -- Section 6.4, “If the NULL-KEY-WRAP-128 algorithm (see Section 8.4)
> > is selected and no other encryption mechanism (e.g.  DTLS) is enabled,
> > in the path between the ITR and the Map-Resolver, the Map-Request MUST
> > be dropped and an appropriate log action SHOULD be taken”
> >
> > -- Section 6.5, “MS-OTK confidentiality and integrity protection MUST be
> > provided in    the path between the Map-Server and the ETR.”
> >
> 
> Yes it would. The text in section 7.4 needs to be changed, actually dropping
> altogether the paragraph you are citing.
> 
> 
> > ** Section 7.7.  Recommend adding that when DTLS is used it confirmed
> > to RFC7525, or even better would be draft-ietf-uta-rfc7525bis.
> 
> Will be updated
> 
> >
> > ** Editorial
> > -- Section 6.2.  Typo. s/authetification/authentication/
> >
> > -- Section 6.3.  Typo. s/Extentions/Extensions/
> >
> >
> >
> 
> Thanks will be fixed.
> 
> Do the above proposed changes address your comments?
> 
> Ciao
> 
> L.