Last Call Review of draft-ietf-lisp-sec-26
review-ietf-lisp-sec-26-secdir-lc-melnikov-2022-06-08-00

Reviewer: Alexey Melnikov
Review result: Has Nits

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The security aspect of LISP is addressed not only in this draft but also in
draft-ietf-lisp-rfc6833bis and in RFC7835. If I understood correctly, LISP-SEC
builds on top of draft-ietf-lisp-rfc6833bis and it addresses a part of the
threats mentioned in RFC7835. From my reading of the document it seems to
address threats specified in Section 4 of this draft.

I have a few questions about the document, which might or might not result in
any change:

1) Use of SHA-1 versa SHA-256 in various places:

6.  LISP-SEC Control Messages Details

    These specifications use Keyed-Hashing for Message Authentication
    (HMAC) in various places (as described in the following).  The HMAC
    function AUTH-HMAC-SHA-1-96 [RFC2104] MUST be supported in LISP-SEC
    implementations.

6.5.  Encrypting and Decrypting an OTK

    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] to derive a
    per-message encryption key (per-msg-key), as well as the AES-KEY-
    WRAP-128 Key Wrap algorithm used to encrypt a 128-bit OTK, according
    to [RFC3394].

6.9.  ITR Processing: Receiving a Map-Reply

    The key derivation function HKDF-SHA1-128 [RFC5869] MUST be
    supported.  Without consistent configuration of involved entities,
    extra delays may be experienced.  However, since HKDF-SHA1-128 is
    mandatory to implement, the process will eventually converge.

Use of SHA-1 is generally not recommended these days, so I would like to
understand why you chose to use it. Are there some backward compatibility
issues or concerns about size of some fields? Also implementing just SHA-256
everywhere will make implementations simpler.

As a side note, this is what I found in draft-ietf-lisp-rfc6833bis:

    2.  Implementations SHOULD use the 'HMAC-SHA256-128+HKDF-SHA256' as
        the Algorithm ID (Section 12.5) in Map-Register message
        (Section 5.6), and MUST NOT use 'None' or 'HMAC-SHA-1-96-None' as
        Algorithm ID (Section 12.5) in the Map-Register message
        (Section 5.6)

       1:  The KDF algorithm is identified by the field 'Algorithm ID'
           according to the table in Section 12.5.  Implementations of
           this specification MUST implement HMAC-SHA-256-128 [RFC4868]
           and SHOULD implement HMAC-SHA-256-128+HKDF-SHA256 [RFC5869] .

    To publish an authoritative EID-to-RLOC mapping with a Map-Server
    using the Map-Register message, an ETR includes authentication data
    that is a MAC of the entire message using a key derived from the pre-
    shared secret.  An implementation SHOULD support HMAC-SHA256-
    128+HKDF-SHA256 [RFC5869].

There are some possible inconsistencies between this draft and
draft-ietf-lisp-rfc6833bis.

2) In Section 7.7:
7.7.  Message Privacy

    DTLS [RFC9147] SHOULD be used to provide communication privacy and to
    prevent eavesdropping, tampering, or message forgery to the messages
    exchanged between the ITR, Map-Resolver, Map-Server, and ETR, unless
    the OTK is encrypted in another way, e.g. using a pre-shared secret.

Is this talking abou OTK key wrapping? If yes, then this sounds a bit
misleading, considering that AES-KEY-WRAP-128+HKDF-SHA256 is "MUST implement".

Best Regards,
Alexey