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

Luigi Iannone <ggx@gigix.net> Wed, 29 June 2022 11:42 UTC

Return-Path: <ggx@gigix.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7300C15C7CC for <lisp@ietfa.amsl.com>; Wed, 29 Jun 2022 04:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gigix-net.20210112.gappssmtp.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 j5v5p2XFOXxO for <lisp@ietfa.amsl.com>; Wed, 29 Jun 2022 04:42:29 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FB17C159529 for <lisp@ietf.org>; Wed, 29 Jun 2022 04:42:28 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id i25so16522213wrc.13 for <lisp@ietf.org>; Wed, 29 Jun 2022 04:42:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gigix-net.20210112.gappssmtp.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SqYWIfBC98aq1wJSiEQVbwI2KwFfkpF9wKpC5uC4gd8=; b=hCZn73Fg7OCb5UCPQu7NPh7ccyJrd0QuZCXXWglVEbiOQqAF+QQgcw/IP9A4ofdpHB nLLDVrjK5vpDp1Yla0eLbGMSphRbTSecOWmYsHScbtuHQZcUfqrbgEPFoINZId3DPHJQ OYZUUkUGjz9vcWkYqHBwqVtiMgTJUvMqeL/HB9iJh6VmFux/qafEmYtxsOfxBzRi8mnD q50/cewAxKmdDuh40/YEQEEYOYc5SE6445scKEjmHGx3SrVChwkm5rH6rrbtlayx0wQa hg23HLMeC/43T+Y2FO9iZNac9oHclKuZ25NnjUwrZd7OEFUlH8gHsGMq9DEUEgtRCQAj d9sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SqYWIfBC98aq1wJSiEQVbwI2KwFfkpF9wKpC5uC4gd8=; b=8MEBHU0TZ2R8UtWA4QbbFEpqcb1Q3XCxWaoToyHsKQJdo0j+yEusRFMwFXSLMtqhDk 63S7wtDqOhfWSm+SHAT4Vqa5tzgAhXsCTUESuo8YMW+YHSuDisllJLd/nSEURtNjdfIL GCvJATFJOHM+e3eDeLrLL1u2QCLOddgZI6H6ti61rgu8eyn+oRb2wfVhPSf2VqS+dEAB eqgEPEfUn4PIbNbws/0eNU26fimMBhkejxoarLMsD25Q8B3XzdCD8RlrbuksUqQEChzl A8OBQKKNcmnfdCb3SkpuyD28+roDbd+VRCjEoY5AYv2n+4DTwLRjWQh7BcPUCiRlQe+H ofOQ==
X-Gm-Message-State: AJIora/ZXE2696gPDzl/lUssKTTarzi63niZ/dSYumBhCx1yrvMkWbqo PtireMrPGnIULU6w/3mZHXFewg==
X-Google-Smtp-Source: AGRyM1tykb828YkZjS/7J7VmcsOcEwd7a2Uto1t0g2g7PJObyma6Ssp/V3ZR8isz8vySsG0LuXkZ0A==
X-Received: by 2002:a05:6000:1f81:b0:21b:a1b5:776 with SMTP id bw1-20020a0560001f8100b0021ba1b50776mr2563973wrb.201.1656502947195; Wed, 29 Jun 2022 04:42:27 -0700 (PDT)
Received: from smtpclient.apple ([37.170.18.203]) by smtp.gmail.com with ESMTPSA id i8-20020a5d5588000000b002102f2fac37sm16356386wrv.51.2022.06.29.04.42.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Jun 2022 04:42:26 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Luigi Iannone <ggx@gigix.net>
In-Reply-To: <165646726541.26415.16934089318083861691@ietfa.amsl.com>
Date: Wed, 29 Jun 2022 13:42:24 +0200
Cc: The IESG <iesg@ietf.org>, draft-ietf-lisp-sec@ietf.org, lisp-chairs@ietf.org, lisp@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1C65D219-E665-4D19-B2B2-9D3AFF1392EA@gigix.net>
References: <165646726541.26415.16934089318083861691@ietfa.amsl.com>
To: Roman Danyliw <rdd@cert.org>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/5G4G-fPOc8TZovoXU2-xNeEGCPU>
Subject: Re: [lisp] Roman Danyliw's Discuss on draft-ietf-lisp-sec-27: (with DISCUSS and COMMENT)
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2022 11:42:30 -0000

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 <noreply@ietf.org> 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-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.

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.