[secdir] Secdir last call review of draft-ietf-lisp-sec-26
Alexey Melnikov <alexey.melnikov@isode.com> Wed, 08 June 2022 09:36 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4D8C159483; Wed, 8 Jun 2022 02:36:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVAGgZujv3BF; Wed, 8 Jun 2022 02:36:12 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 794CDC15D866; Wed, 8 Jun 2022 02:36:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1654680968; d=isode.com; s=june2016; i=@isode.com; bh=00NLA3yGGudJ9kQe8Bmb2t+LDbx9t6V2FGl01gY/YLg=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=PsV8PfV14PWAmz+89Qh9RVDt8Un0SYViMnUF+A8ceoQSnSVYDQ6pHHobVwA449dyFJRYRn dH3lDdVIOA+zFN5bp6cE+iPSjDsqlKMgA+yfsuULwVeGC0IPowQI7FcFCuaNNsaikhjRvw Sm8xDVEglLbdj+EM+xQfo9PlQalCW14=;
Received: from [192.168.1.222] (host31-49-219-36.range31-49.btcentralplus.com [31.49.219.36]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <YqBthwBhWF30@statler.isode.com>; Wed, 8 Jun 2022 10:36:07 +0100
Message-ID: <422b173b-64b2-679b-2929-609dbdf3eb58@isode.com>
Date: Wed, 08 Jun 2022 10:36:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0
To: "secdir@ietf.org" <secdir@ietf.org>
Cc: draft-ietf-lisp-sec.all@ietf.org
From: Alexey Melnikov <alexey.melnikov@isode.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------DDu3JSt44vKjP1vJ056Mmpiv"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/qlvyZrJ_7RZbeVzbTjakzit6MKU>
Subject: [secdir] Secdir last call review of draft-ietf-lisp-sec-26
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2022 09:36:16 -0000
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
- [secdir] Secdir last call review of draft-ietf-li… Alexey Melnikov
- Re: [secdir] Secdir last call review of draft-iet… Luigi Iannone
- Re: [secdir] Secdir last call review of draft-iet… Luigi Iannone
- Re: [secdir] Secdir last call review of draft-iet… Alexey Melnikov
- Re: [secdir] Secdir last call review of draft-iet… Alexey Melnikov
- Re: [secdir] Secdir last call review of draft-iet… Luigi Iannone
- Re: [secdir] Secdir last call review of draft-iet… Luigi Iannone
- Re: [secdir] Secdir last call review of draft-iet… Alexey Melnikov