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

Roman Danyliw <rdd@cert.org> Wed, 29 June 2022 20:35 UTC

Return-Path: <rdd@cert.org>
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 BA054C14792F; Wed, 29 Jun 2022 13:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=seicmu.onmicrosoft.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 qWktcOt8EKpv; Wed, 29 Jun 2022 13:35:07 -0700 (PDT)
Received: from USG02-BN3-obe.outbound.protection.office365.us (mail-bn3usg02on0138.outbound.protection.office365.us [23.103.208.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4EBC14F73D; Wed, 29 Jun 2022 13:35:06 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=MzRvK6xnwFIvBvz6ihmd/oN38wbS7LFU3D0pUaTdfaffsec7ubpgYmroKcYUY/0GRsr7OhAfL1mhztbUcWZ8kWY/Rcsxk9/bAA2O1RywJBuQU4gxZ+R/it3FTeHoLN5lOXDifPYXdBMzl2lbDJb0XChOyUF3nNmMJqM8mgnZmZ28Oez6tD3vIr7H6mZsL7fG4jUxSkOvhfT/wf/CDY7sFtkLqD4tlVEK3XxkXc1SNv03Gf039T3pq9zthH/g+qjltMgpmpyxSTomec6FmyxfexDk/4lMek1xbwmOdBcY2tvcnOnB+sf+EFO/gU/Jko+U2VbtQgyINBGcsauCFSDT+g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector5401; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=yYlTWqMNxVL7zsYRKfPQvvfumC8piL3Wm7ZnPASrOkE=; b=OjneoYpRTOug6PcVaZlX2WtQFETWTZCfPsO2C7w76FQCqmZlyoPoujU3ssVDEug7UVcfr2S1Sqqsje5BDOafyDzeS5WNOYNSKoAhlVZBUYwlKq9dq/nTO9L39FQPHBaWzDs6qq2/XXkNQai+Y5RB9N9gh8xl8wbL8iNeK3L/NmUhQuwqmypwn6ZTeZ3JxN80mRq68RdHlel9uXz8AhsaILNX6wBg+p8J64a5nRMKcIknq5jkHoQbreozaiVQVlRFcEs+2V1taO/dFNKcT//0yCnU6A2Sma586Am9zXs0VzzVaI6Gf1WS04A2EK270ekK0BfmiWie1yki7g24ucV08w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cert.org; dmarc=pass action=none header.from=cert.org; dkim=pass header.d=cert.org; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=seicmu.onmicrosoft.com; s=selector1-seicmu-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=yYlTWqMNxVL7zsYRKfPQvvfumC8piL3Wm7ZnPASrOkE=; b=YMgDeFfrhJhnd0QcnAbv8gsam5r6lBNSCBpTQ1ccO9/HZw60IC06/k6be9spfmvF1TlwsW4KrQmMi6bo+USo565F04tLSWFQkiknCnLaT8fVaap6fC9P+JbRMXm0hKz0qTPQ/pFZPXlTxYuiNfeO6VXr0xEsxK43ztGsgBudu2s=
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM (52.145.7.11) by BN2P110MB1044.NAMP110.PROD.OUTLOOK.COM (52.145.7.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.14; Wed, 29 Jun 2022 20:35:03 +0000
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::8d8:1199:53f0:8077]) by BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::8d8:1199:53f0:8077%2]) with mapi id 15.20.5353.024; Wed, 29 Jun 2022 20:35:03 +0000
From: Roman Danyliw <rdd@cert.org>
To: Luigi Iannone <ggx@gigix.net>
CC: The IESG <iesg@ietf.org>, "draft-ietf-lisp-sec@ietf.org" <draft-ietf-lisp-sec@ietf.org>, "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-lisp-sec-27: (with DISCUSS and COMMENT)
Thread-Index: AQHYi1pDC99zsUMgqEaIH3Qsjd10TK1mQ+QAgACUqNA=
Date: Wed, 29 Jun 2022 20:35:03 +0000
Message-ID: <BN2P110MB1107F5173EA81385F29690F2DCBB9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
References: <165646726541.26415.16934089318083861691@ietfa.amsl.com> <1C65D219-E665-4D19-B2B2-9D3AFF1392EA@gigix.net>
In-Reply-To: <1C65D219-E665-4D19-B2B2-9D3AFF1392EA@gigix.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cert.org;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f5215b96-33d1-4826-b3d9-08da5a0ed8bf
x-ms-traffictypediagnostic: BN2P110MB1044:EE_
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lej3iermVgGGbcN+ygbMEe9B13B8tyRXIb1N8O7cRrS+amNlQqvV1EfwlDDd60woUi7QCOb3AGB1BGRE4z9/tHODHc/q27nDEQoe30uparqFZ9uu0laJfHc0QIQc8HgE7RpqNtEhEnIUYl9QviwTabX5ttQz4cTxKhu+YtzQQsTdYE+no0J/DkxL/vekHX7cSpuM7nx5UWlM7hjBQ6PjYeE+mexUl940ReHX06Xkg3D6JyteBggIF8q1LVyoDKZOX8xCpG1ur20ey4qrsEwW5KmGbzBuUN8VFKD5sZlABmsigHjRxCWXuaoz35A80+IGrum/Vqc521iAUVO6n7qXiUNgjhuM01gwJzPF6wWW5Kg1jaMn517SPED2wSiHI5deq3dwGu/hB9Q8gtHafoT8e3mzXb5hbJxRGGBciOO9w/vp8Fvxkf5okbL4acMfsC8dmKoA34znlDSVJ8WehKEzOcZ/zR4Vdk7kAgZrlqzR3Rj/qh1RZG52gL3sFasYEog8YIFSAxr0qpw2VbmUfELpBnFc1g7ePWNkB38bLKsXvL3Bj0Ox/xiO6FopXff4+3RS4/Z75yBNRkpWAHnL1DH+h6Ijsybi7sgqus+wYJAJCNWY70RFbQ4vhsoycNfW05+7vv2nPWXefqntmsx/hWtQ3+H1bKA+uVIFVulzBcAilnzwgFb8k5fiVU37nrjrgxE6rr18dPSw7vSoEcEtZ+mr93I250EnDsmNBmQyu5zn82QeY4msOWmAjZlGs5G1eEbw
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230016)(366004)(4326008)(186003)(83380400001)(38100700002)(7696005)(8676002)(71200400001)(86362001)(2906002)(82960400001)(38070700005)(66476007)(8936002)(55016003)(66946007)(66556008)(122000001)(498600001)(53546011)(9686003)(6916009)(54906003)(33656002)(64756008)(966005)(76116006)(5660300002)(26005)(52536014)(6506007)(66446008); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: i7XcmpPYVIINv9TLR/5DsddQgC5wDYpj1m+kvPjgTnvXhacPC21RmznKocWv4BTstDSMNMScvZEg1b0+oK0ABAJdcILjZOXyNPLqinrFa6/jhn7kT1/EvnYX9++atgTA/XUUokf+GnIgvBTrmPbZEBiNY7lVzEVYJuhzCeCpCV4MInnkZ1YDkjPLtpHjLx/vXomn2u2/5UbsYNCcmVRMEmJUYpUTYns2ZauCZibxQ+eQz11cOZPdebGdceTa5lqyv8kpcn8LaAc7dO3SbHtc2fP0ZZeM6czttTIdpgtqo/toJOIMrsaQHAD88ec/aI/dckrHAP6NUQKacU+TjwyfD9JrAGE/YLDUyKjrfw5squMIXlugjeRBfm9BBT8wIITTp3PJC1JPxCiJQM5WU22zdAjQSTB5YlY1WwriKTtPaFc=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: cert.org
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: f5215b96-33d1-4826-b3d9-08da5a0ed8bf
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2022 20:35:03.8518 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN2P110MB1044
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/juVsJRdqd0JwlLxvpT8fCsC6gQ0>
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 20:35:08 -0000

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 <ggx@gigix.net>
> Sent: Wednesday, June 29, 2022 7:42 AM
> To: Roman Danyliw <rdd@cert.org>
> Cc: The IESG <iesg@ietf.org>rg>; draft-ietf-lisp-sec@ietf.org; lisp-chairs@ietf.org;
> lisp@ietf.org
> 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 <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-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.