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>; 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>; 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.
- [lisp] Roman Danyliw's Discuss on draft-ietf-lisp… Roman Danyliw via Datatracker
- Re: [lisp] Roman Danyliw's Discuss on draft-ietf-… Luigi Iannone
- Re: [lisp] Roman Danyliw's Discuss on draft-ietf-… Roman Danyliw
- Re: [lisp] Roman Danyliw's Discuss on draft-ietf-… Roman Danyliw