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

Roman Danyliw <rdd@cert.org> Wed, 13 July 2022 21:01 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 ED8F4C16ED0E; Wed, 13 Jul 2022 14:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, 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 j-gpxomolOgg; Wed, 13 Jul 2022 14:01:28 -0700 (PDT)
Received: from USG02-BN3-obe.outbound.protection.office365.us (mail-bn3usg02on0107.outbound.protection.office365.us [23.103.208.107]) (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 59BF0C1A649B; Wed, 13 Jul 2022 14:00:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector5401; d=microsoft.com; cv=none; b=u/CW1mygGbnyoO0RxI5bi2E14DGFZMcsn8iRIBSaX2bTl9wu8BDeSodu8MJnY9QqfHuQDfPEtb4vCthMeZLvKZ2MnUUvAVMYYz+cSFgXioytFltG5zzc1WcZ4J1TDZ24h8kta+KWMJR8iuJSzh44Y5hzg2l4V9UeQOrpip2+7+ZMJ1lJRuaVCY/e6o6ImWdmk/R/BNGWQFEI9584iQ6retl3YYYuK9souFKE/I8XpLReH0ciZn3skfsLklkoVqbt1Gr8Ax9B+RQ29C4kEiBCrXJpZ8b2ylcT+3WkjwvnXLyL2YIv95eo62a4T0JS2c9SBxdwN8NcRJFGIqB1KJqCSg==
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=zla5TV0SYJ4ium11qAsyFwQhQOZSkCgIE2kDIeI8n/I=; b=xYD3YCOC28/R+kLeOug83ihtwo1vOciQ3zAdBn1pVtVd8ta2qHzIytgbpvRSLij98IMzzr+CA5XwijU++g1Z75hNNoEKJYbZx0whavKsRWGBUF04AE4z0P52Bcq9D8io2Yf/5PwHBdXe6bzV8DojsXtdv+f+ejyhO5BHKyNVD4mPfzBE6FJlD2DITLR0mqUNAzmsIlhSCF4kcBXNWCZjHvwApEI1Z81uGL+eRL+IUBKauzOQtzF1pIbmqVKZcnI9pxbGZHgeLF9oNbnBPPXmwG49dYO0O0Ycydkx+EfOAgoiW4WbMT/QGjthE6agM+rblho8f9ORqN1VVkXIeiJn3g==
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=zla5TV0SYJ4ium11qAsyFwQhQOZSkCgIE2kDIeI8n/I=; b=dckwwZ0aHGJoHUIWOv1ioju6oMEBMbUTESo1bWRGVBA3o3x/55HXp2AvIEXhGwHJGIC7d+a+4O1jD7qUJlrcrAMB72PSZRRD4Ye9IdMNRg/3Gce2IoMuXj8kfy/4MsMrF0dOQBjALovPK15zzJcF2kIls9gstibVWeE2TUb1soc=
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:168::11) by BN2P110MB0962.NAMP110.PROD.OUTLOOK.COM (2001:489a:200:16a::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5417.26; Wed, 13 Jul 2022 21:00:06 +0000
Received: from BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::61c5:afc3:7804:7d27]) by BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM ([fe80::61c5:afc3:7804:7d27%3]) with mapi id 15.20.5417.026; Wed, 13 Jul 2022 21:00:06 +0000
From: Roman Danyliw <rdd@cert.org>
To: Roman Danyliw <rdd@cert.org>, 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+QAgACUqNCAFgecMA==
Date: Wed, 13 Jul 2022 21:00:06 +0000
Message-ID: <BN2P110MB1107DF2133B490893C2FC3EADC899@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
References: <165646726541.26415.16934089318083861691@ietfa.amsl.com> <1C65D219-E665-4D19-B2B2-9D3AFF1392EA@gigix.net> <BN2P110MB1107F5173EA81385F29690F2DCBB9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
In-Reply-To: <BN2P110MB1107F5173EA81385F29690F2DCBB9@BN2P110MB1107.NAMP110.PROD.OUTLOOK.COM>
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: 41c0000b-a915-4aeb-ac41-08da6512aa01
x-ms-traffictypediagnostic: BN2P110MB0962:EE_
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: ihuNijzv8fs34ALCgCEkxq/as9HK2IX47eE/bxXVcgRMKgGF5xq8WxZcmtATpJ2wZ2PxQ5csM4/dw1TR+Pjis40taI5nguMnUwUBWj0nlVME7vyqNl02EGagQwyJbVNVF5OMFtjic/4xh82cPwB/esAmQid23hRN0tWZJMJH87o9fJloBwg3nLD7yyfmIqr7On7/TtK0/ZMdIvdsn1qpWrERSb85Y0u2TLWnGpEgUpWYm2TuQ94xk/vLVvfkORm3SBJ8L4YNdEN5hRCgJHRyv4KbeqsCqDaOF1W+yM+q23B4lU9nkMNkGmBR1Gkr0oYmEzEQgjugK0L+FgZ8nyAl30KqzDedBrUVAauf/6edIxoaR9TUpMTl1wMF++nMPukGPLJZMxI+j6dGptDVKQaIHvIhyg/+qKBtq8UkmrfOHStfLshIhNH7xaJuHQOwz4IdlGljRvMk930xVWPnY4oWglZwgWdn5UBKj3CGqQoMlDOPoGZHycRshO6j2Kb9ZPLTKHxzyq/Ntm38nvK2qxEgsdrcfcIy1FmAnuYKYgMWfl5CXisw6DISqTT2geWIYBP9lynuE1vGEGc4jErzC+cVMZdEe5xMuejeaRJT3cS75apZE/x/aZrXG3RXu34k5VngHUpgdLOsFcQFcKDD3Zb4FkEhXVGg4EwoIOC5MGQY7lR+GeEpVaDbmn1rJ/SKx60Z21sKqZOWeek+lOE03JvsD/Cx4swoUqckrxUMWoVanX3DzEJjrduvIxybkKR7snd7
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)(186003)(53546011)(52536014)(82960400001)(5660300002)(498600001)(71200400001)(55016003)(8936002)(7696005)(83380400001)(6506007)(66946007)(33656002)(76116006)(122000001)(38100700002)(54906003)(966005)(66556008)(64756008)(66476007)(2906002)(38070700005)(66446008)(9686003)(26005)(4326008)(86362001)(110136005)(8676002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: ojCjnp51fzxIX6jn5L+UC2lACFhk1Lz6RHb6qwr4VNLiCNo5li6QUSotVbja1WTe8RVduKIHsdb63pMP0UPJbXtWUnL/zKnTDACwM/XEiBxDOq50bafnoz7yKvrMu9khWkSfzTiZ71ISF0Lr+rjfPb8gEpL8zQRPu8bnO/TkKm0VoI4rIa7yJj2VVJdsngyaz/M3M8jY+0tDeC8x9CG/6zoAprP9XnQmCERo3buhf0igvghhWGjNyLVxeaHNvYBzSMAsznzRWIVuB750BkSzkZXa5gxAf2t/4/EzI2OKY1wexHT39tcyfCJbWUtheQmW5fARdYSKht/8ZRRq4pPxxZB7HjTGiyd5HALG42FbDtf+pWxEOOZeQC7K/fK00Skpcyk7tp1UYdauGUtMa2qfQvP+8iqSw9VrTJMXPF1Z358=
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: 41c0000b-a915-4aeb-ac41-08da6512aa01
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2022 21:00:06.2086 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 95a9dce2-04f2-4043-995d-1ec3861911c6
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN2P110MB0962
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/RD4USbWX_7BnXIuderEUIOVkn3I>
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, 13 Jul 2022 21:01:32 -0000

Hi Luigi!

Thanks for publishing -28/-29.  It addresses my feedback per our discussion below.  I've cleared my ballot.

Roman

> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of Roman Danyliw
> Sent: Wednesday, June 29, 2022 4:35 PM
> To: Luigi Iannone <ggx@gigix.net>
> 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 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-po
> > > si 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.