Re: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE

"Fries, Steffen" <steffen.fries@siemens.com> Thu, 04 March 2021 07:08 UTC

Return-Path: <steffen.fries@siemens.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565E03A147A for <anima@ietfa.amsl.com>; Wed, 3 Mar 2021 23:08:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 vBxmTG5dSVjd for <anima@ietfa.amsl.com>; Wed, 3 Mar 2021 23:08:49 -0800 (PST)
Received: from gw-eagle1.siemens.com (gw-eagle1.siemens.com [194.138.20.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32C933A1479 for <anima@ietf.org>; Wed, 3 Mar 2021 23:08:49 -0800 (PST)
Received: from mail1.dc4ca.siemens.de (mail1.dc4ca.siemens.de [139.25.224.78]) by gw-eagle1.siemens.com (Postfix) with ESMTPS id 24F5F4F0016; Thu, 4 Mar 2021 08:08:44 +0100 (CET)
Received: from DEMCHDC89XA.ad011.siemens.net (demchdc89xa.ad011.siemens.net [139.25.226.103]) by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id B836918CF5B90; Thu, 4 Mar 2021 08:08:43 +0100 (CET)
Received: from DEMCHDC89XA.ad011.siemens.net (139.25.226.103) by DEMCHDC89XA.ad011.siemens.net (139.25.226.103) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Thu, 4 Mar 2021 08:08:43 +0100
Received: from DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) by DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) with mapi id 15.01.2106.013; Thu, 4 Mar 2021 08:08:43 +0100
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "anima@ietf.org" <anima@ietf.org>
CC: "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>, =?utf-8?B?Q2hyaXN0aWFuIEFtc8O8c3M=?= <christian@amsuess.com>
Thread-Topic: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE
Thread-Index: AQHXCI4aI3KJbNx1uESz0kmGFFYTuKpwu3rggAIYgYCAAKFesA==
Date: Thu, 4 Mar 2021 07:08:42 +0000
Message-ID: <3a5b5c8bbe5d477f9b69cf8acbb4636d@siemens.com>
References: <161393206518.11813.1416988663631870171@ietfa.amsl.com> <23305.1613938428@localhost> <bb9ac3341495461aa19f9a32c123afa5@siemens.com> <1300.1614809819@localhost>
In-Reply-To: <1300.1614809819@localhost>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-03-04T07:08:40Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=bb2f2bc7-c85a-4d36-87db-600cdebb7a53; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: [139.21.146.182]
x-tm-as-product-ver: SMEX-14.0.0.1158-8.6.1012-26008.005
x-tm-as-result: No-10--27.460500-8.000000
x-tmase-matchedrid: grK+ChACArzdDS6etHbe2wFP3zQ/z11d0bm0QnK23OYK3Ma88LL+bt3Q prxGuiIh4GDT9PuL9Z6f6eu+NowNgf8nv9x3PStadH9kusomMxcZcLrAZ/XZFTMvozJIQnRWIQX VF2qsdV1h2fnHe1cilwO2c6ovBmDph40R7G5gclz0eK/d+mnNvdtQoXKm4JivMhko6oynp7bdYV rFVbszaNRGf5c57+FFUNzM39IykFjIW6O1WInIUAPF8/7D3WUe8GhZM9HP2b46LZngKEXBdc6gB dMBUo41YjNWMNi9SZo4ijYc5twsTv6X154lAoxD7H0prhByuzjX8DucA0mWtcOC5QFrchIlv/9o vxpTvIAfyMkN7e89Axszr5/QcdMSV4tMYEJxbKDeEtMuS1eIWw/sueJZRd3ZHZJmvOZBmBEAXOn qjVuo8wg2kgWdt3qayqat6b4pc9054m3Nc0twG4P1KYKlSmjQuKlcYh5MR8RbfP6Rn++qeZIU5V RwhxxfBthzL1hCXp5efevuRniZm9/3V/OM7Vjge/d6+ieb/6q9a7L3aaqeU8LRNemq17EipWOBf K9L1z90A3EYPb/xOPoyx2o9QKI6OtZjV93JWoyzE1I26BnC6MRI9S5UU3PpU8KO1ajdBDwfkDOl TQgzYbnoQlc940JDINVMCwGUhxf0IaDcAWFEqZmLngkC75apthfZltvQe7LW4Mz461fsHAL3rpy OT0zYOBy9qYAHlxFOhVUhwURBiAUY+Xt/b/3h8Qk1Q6ghyPET6F/I3FhqMDKVTrGMDe/DEJBSu9 U3+s9jyv+d0Z0OxYoL26yYoYgd585VzGMOFzABi3kqJOK62QtuKBGekqUpIG4YlbCDECtruV6hT 84yE/IxdJB3PGL0
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
x-tmase-result: 10--27.460500-8.000000
x-tmase-version: SMEX-14.0.0.1158-8.6.1012-26008.005
x-tm-snts-smtp: 3CF0205411EC97BD35C4371F485C53C62BB10BC2E38A87D57D668CFFC77581062000:8
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/58yCxUh7swbgVJe3BvkTxFOYnlw>
Subject: Re: [Anima] draft-ietf-acme-star-delegation-05.txt and BRSKI-AE
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Mar 2021 07:08:51 -0000

> From: Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>     > Sorry for the late response.
>     >> We have struggled with brski-ae to deal with how the pledge can pin a
>     >> thing from the pledge-agent to prove proximity.
> 
>     > Based on some further discussion, we have to decide, how the proximity
>     > is handled in BRSKI-AE. The motivation for now was to have it to avoid
>     > DoS attacks on the pledge.
> 
> Understood.
> Christian Amsuss has done some work with CoAP over the websocket version of
> BTLE/NFC (Please correct me here).  The idea being that we could do EDHOC or
> some such over that link.  That wouldn't be an IPv6 link.
> 
> A reason for this interest is that this interface is available to one-page WEB apps
> on a smartphone via Javascript, while mucking around with IPv6 over BTLE or
> changing wifi access points is a serious pain on smartphones.
> 
> This provides a fair bit of physical proximity, which I think can mitigate the DOS
> attack concern.  Really, we need to do some experiments here with some kind
> of spike solution.
> 
> EDHOC, running over CoAP, should be relatively happy with the store-and-
> forward mechanism that BRSKI-AE would like.
Wouldn't this still require that the pledge is able to verify the certificate of the pledge-agent during the first contact? The pledge authentication at the pledge-agent is probably easier, if we assume the pledge-agent knows the signing certificate of the pledge manufacturer. We run into a similar issue with the discussion when using TLS. The pledge (acting as server in PUSH) itself does not have a certificate the has the correct subjectAltName (and the key usages) to perform the verification on the pledge-agent side. Also, the Pledge would not be able to authenticate the pledge-agent until it receives the voucher.

> 
>     > If we assume that the likelihood for DoS
>     > attacks is higher on the registrar side, it is important to protect the
>     > registrars endpoints.
> 
> I think that we can handle attacks on this side.
Yes, that is why we though to utilize the same endpoints (via https)


>     >> It feels that something like either Delegated STAR could work well.
>     >> Or, if not that, and we are using TLS, then draft-ietf-tls-subcerts-10
>     >> Failing that, we need to create some kind of JWT, or CWT artifact
>     >> which the Registrar uses to bless the pledge-agent.
> 
>     > Currently, the proposal would be to utilize an LDevID between the
>     > pledge-agent and the registrar. It can be provided either by a separate
>     > BRSKI run to the pledge-agent or manually.
> 
> Agreed, that's what I had in mind as well.
> 
>     > connecting or a pledge-agent based on the utilized certificate (IDevID
>     > or LDevID). I would like to discuss the trust relations in the next
>     > design team meeting.
> 
> Awesome!
> 
>     >> I find the PULL/PUSH terminology confusing.  I recognize that the
>     >> directionality that is implied by the PULL/PUSH is based upon, I
>     >> thought, whether the RFC8366 voucher is retrieved by the pledge, or
>     >> provided to the pledge.  But, in section 5.1, I think that it's called
>     >> PULL because the communication with the RA?
> 
>     > The naming PULL and PUSH was motivated by the pledge behavior, that it
>     > either PULLs information from the registrar or that it is pushed with
>     > the information from the pledge-agent. From a naming perspective we
>     > already introduced some further names like pledge(-callee) in the PUSH
>     > case, as the pledge is acting as a server while in the PULL case the
>     > pledge acts as a client.  So one option would be to state pledge-client
>     > (UC1) and pledge-server (UC2). Would you have further suggestions for a
>     > naming? We could also discuss this in the next design team meeting.
> 
> I suggest we refer to it as "pledge-initiated onboarding" (PULL), or "registrar (or
> pledge-agent) initiated onboarding".
A further alternative may be pledge-client or pledge server.

> Also, it is a Pledge-Agent, or is it really a Registrar-Agent?
> 
> (In real-estate: we have seller's agent or buyer's agent...)
Yes, this is some point I already put on the slides to have a change in terminology. We discussed this and the agent is actually acting rather as a registrar agent, specifically in the case were it has an LDevID.

Best regards
Steffen

> 
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide