Re: [lisp] Virtual meeting

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 31 March 2020 23:59 UTC

Return-Path: <jmh@joelhalpern.com>
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 91C063A0F43 for <lisp@ietfa.amsl.com>; Tue, 31 Mar 2020 16:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k87f6i_xps1i for <lisp@ietfa.amsl.com>; Tue, 31 Mar 2020 16:59:14 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 66FE73A0F01 for <lisp@ietf.org>; Tue, 31 Mar 2020 16:58:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 48sRB76wrhz6GHFr; Tue, 31 Mar 2020 16:58:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1585699135; bh=6cFZrfKXufrV547puJvKvcb43pzs3VCwYHZEY7EkvY0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CoHduyKTbwxz7rpO4dJomh2LFNElNK9y+J9QZSqZNYKG5U9NLN6uctzc9xOMkkt3O D1akXWXqG+1TI9GIME81/AoLITUiFMbf+0cSOu5Y98i670C1HX0/YmRuyJJo/j0kpK pkWUrUDV0xe9KoAZZNaJpIN2Fzgli7CbmaOWdc3k=
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 48sRB70pcgz6GHFq; Tue, 31 Mar 2020 16:58:55 -0700 (PDT)
To: Dino Farinacci <farinacci@gmail.com>
Cc: "Alberto Rodriguez Natal (natal)" <natal=40cisco.com@dmarc.ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
References: <bf751274-3d10-4675-40ff-0876b968ec58@joelhalpern.com> <EB8728FF-8299-4915-81C0-7A414E1A1735@gmail.com> <b2bf2e7c-9535-e6b2-51ff-dc922c875fb7@joelhalpern.com> <F0929D9F-2726-48AF-90E0-9242A5898F4C@gmail.com> <e995cd58-3504-c7b4-a970-f55550e3829b@joelhalpern.com> <0310FDA2-6AE2-472B-82A7-D38039F64DDB@cisco.com> <293fbb16-75c4-bb79-e183-eaf781b696e3@joelhalpern.com> <613F569E-6FCF-4363-A60A-CB14C6459FE2@cisco.com> <8e654897-26f6-e4c2-db74-e5a15155e04b@joelhalpern.com> <D4231D6A-A0EC-484D-BE3A-C3E31476178B@gmail.com> <e87119cf-443e-753a-1c87-0c2ae197a61a@joelhalpern.com> <9C98131B-A82E-43DE-B1F4-417018EF2C10@gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <245a8fc4-c937-887d-bf30-6070fb6a7dc6@joelhalpern.com>
Date: Tue, 31 Mar 2020 19:58:55 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <9C98131B-A82E-43DE-B1F4-417018EF2C10@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/bFj8G0A_znpLK-QYHWTO7A_Mgvk>
Subject: Re: [lisp] Virtual meeting
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 31 Mar 2020 23:59:22 -0000

We could reuse the OTK directly.  My actual inclination would be for the 
MR to send back (via the ETR) some data which, when combined with the 
OTK, produced a separate key for use with the notify messages.  Clearly, 
the MR would have to store whatever security key we want it to use as 
long as the subscription persisted.

Yours,
Joel

On 3/31/2020 7:27 PM, Dino Farinacci wrote:
>> I may have missed something, but I think that in the case of the first notify, it does actually start at the Itr.
>>   Specifically, it starts with an ItR sending a subscribe request.  The MS responds to that with a notify.  What I am suggesting is that (when security is desired) the Itr includes the same kind of information in its subscribe that goes into lisp-sec.  And that the reply, instead of going directly from the MS back to the ITR goes through the ETR so that the rest of the lisp-sec procedures can be applied.
> 
> Yes, and in that Subscribe-Request you can include an OTK. But that one-time-key would be used more than one time. To send the Map-Notify to reply with the RLOC-set to the ITR as well as acknowledger from the Map-Server that subscription has been accepted. But then the one-time-key would have to be *stored* in the Map-Server and then used later when the RLOC-set changes to send an unsolicited Map-Notify. So the one-time-key would be “two time” and we would set a precedent to make it no longer ephemeral. In previous cases, the OTK was not stored anywhere.
> 
>> I would then use that as a bootstrap, putting necessary secrets to create the key information so that the MS can sign and the ITR can verify future notifies that go directly from the MS to the ITR.
> 
> If the working group believes that the OTK should be stored and then used again, then both the Map-Server and ITR would have to store it. In the original case, the ITR stores the OTK only until the time a Map-Reply or Map-Notify is received. But the Map-Server would have to store it indefinintely (per ITR that subscribes).
> 
> Dino
> 
>>
>> Yours,
>> Joel
>>
>> On 3/31/2020 1:33 PM, Dino Farinacci wrote:
>>>> thinking about Alberto's request, and reading the document, I wondered if the security could be improved by sending the first notify back via the ETR, and coupling it to LISP-SEC to protect the information and provide needed keys for further messages? It seems like we do need a way to protect the notifications, and requiring associations from every ITR to every MS who may provide notifications seems impossible.
>>> You can’t use LISP-SEC because the transactional nature of it starts with an ITR and a one-time-key, that is used to signed Map-Replies returning to it.
>>> For Map-Notify messages send from Map-Server via ETR, there would be no ITR one-time-key. And if the Map-Server used its own one-time-key, the ITR couldn’t derive it. Note with LISP-SEC the map-server one-time-key is derived from the ITR’s one-time-key in the Map-Request.
>>> Dino
>