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

[Roman Danyliw via Datatracker <[e-mail]>]

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-positions/ 
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.

-- Section 8.5.  Add HKDF-SHA256 to the "LISP-SEC Authentication Data Key
   Derivation Function ID" registry


----------------------------------------------------------------------
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.

** 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)

** 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.

** 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.”

** Section 7.7.  Recommend adding that when DTLS is used it confirmed to
RFC7525, or even better would be draft-ietf-uta-rfc7525bis.

** Editorial
-- Section 6.2.  Typo. s/authetification/authentication/

-- Section 6.3.  Typo. s/Extentions/Extensions/