Re: [Suit] [Last-Call] Opsdir last call review of draft-ietf-suit-mud-06
Behcet Sarikaya <sarikaya2012@gmail.com> Tue, 26 December 2023 17:00 UTC
Return-Path: <sarikaya2012@gmail.com>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F211EC14F699; Tue, 26 Dec 2023 09:00:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.854
X-Spam-Level:
X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, 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 (2048-bit key) header.d=gmail.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 SDn8E2yD5zdb; Tue, 26 Dec 2023 09:00:21 -0800 (PST)
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E2E0C14F69B; Tue, 26 Dec 2023 09:00:21 -0800 (PST)
Received: by mail-vs1-xe2c.google.com with SMTP id ada2fe7eead31-466f713c6baso204094137.1; Tue, 26 Dec 2023 09:00:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1703610020; x=1704214820; darn=ietf.org; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=YwrzsYKuM+4TxaVvJnVm7QjjdUlHTTg30ISAuYeo4t8=; b=K7hFDKbk3x4qDdO8ViMF7zL7BlUpgkGrRGGqVEzKM01x9GhnYG5vpTdED2WSCJ6IZ/ ghHiRgdZRsHwOPD/GdyeiF2tVorJVTVqlaGUVl06d2Bg2lpyvZzsRFD4ysZsHB+qk6m5 d23n54GFM0QcoQKKoZeE98NGxbItdcxcmtrfQ4QQfJt4HFE7gR7y1XhKGZj0Rnrf/O73 2mu244WngtawLp70exZ8/zh1JUJlwfQ3R72bDO3yOxI9WyQ5A1afJFcJB/X7umCozLpZ cOmFhSLvoPg5fM6Aj0ikq5UxczOtwexp5yAQTkmCYlfKRDNKnnN3g06oek8abF4eLbNS dZww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703610020; x=1704214820; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YwrzsYKuM+4TxaVvJnVm7QjjdUlHTTg30ISAuYeo4t8=; b=iif6tTTOX/2geDSn5ImS9Cg1AKjnPa6sU71Tw7jNuMUyLF9mAvLBi7UgIFBkqUJEZR SqeJVK4Kl8SngL3KR9k0YTa9xivKwBWCjFcu67VBVxwLNxqJgsSrwjYZjpQGpjOS3T5R a3lYLX0MDTLmZxYBcRxgeU3CLATwH+6H8VJZzy0nzbdwyqTDGtXzcNua402X8KnaVdcc M0tM4hzPc9W7+uDHc2kZYgpqlHQrr8d0LQJ7gK9mb3JNajT3n5dNOp4GcbYuCh8VdqxM FDYGCbfPYkRQ7jLwgRUNmxuUU1/I2kolgf8H15TQVHvOI76sm/D7VCUmDi2aFjamfA38 jX2A==
X-Gm-Message-State: AOJu0YyhHHx+CJqdubg571Masjs2r87/IWmbqWP9dQAwNpyKNVH30GEp zgWOUEUXXcNYKqT/LLUyUZXBZkO6kXMchk8naWY=
X-Google-Smtp-Source: AGHT+IEfJNBm3jltB8jqn5m+zv3F9n5kAewgG1kPPU0A+RGSavc+aCX3z1eZm4arKwltEiNlhdWcNNaVnUIDdCkxK0E=
X-Received: by 2002:a05:6102:cc6:b0:467:200b:ae3 with SMTP id g6-20020a0561020cc600b00467200b0ae3mr464503vst.33.1703610019993; Tue, 26 Dec 2023 09:00:19 -0800 (PST)
MIME-Version: 1.0
References: <170170315182.17411.11522235103450951717@ietfa.amsl.com> <e92a87df-5554-4dda-b5aa-47155f3c4614@gmx.net> <ef80cde4-027a-463d-8b6b-21df80fa9d8e@lear.ch> <aca7f406-ba0e-4f66-ae27-1e34d97cc28c@gmx.net> <983b4f20-fc7c-44ac-943f-100253653d4e@lear.ch>
In-Reply-To: <983b4f20-fc7c-44ac-943f-100253653d4e@lear.ch>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Tue, 26 Dec 2023 11:00:08 -0600
Message-ID: <CAC8QAcc2FsRCvhTk1x3JxOaCDNUABY0kHeZAiMSnm0_xfadGQQ@mail.gmail.com>
To: Eliot Lear <lear@lear.ch>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, Susan Hares <shares@ndzh.com>, ops-dir@ietf.org, draft-ietf-suit-mud.all@ietf.org, last-call@ietf.org, suit@ietf.org
Content-Type: multipart/alternative; boundary="00000000000013dddd060d6c9ec9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/H-Yxbwkj996Ci_ax9yc9bLHkzXg>
Subject: Re: [Suit] [Last-Call] Opsdir last call review of draft-ietf-suit-mud-06
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Dec 2023 17:00:25 -0000
Folks, It seems like Ref -07 of suit-mud draft is out. I read it, it resolves my issues. I think, maybe the takeaway from Sue's review is what Eliot said: We don't have a YANG model for the MUD manager itself with operational state. I think that might be a possible next step. Regards, Behcet On Thu, Dec 21, 2023 at 5:50 AM Eliot Lear <lear@lear.ch> wrote: > We don't have a YANG model for the MUD manager itself with operational > state. I think that might be a possible next step. > On 21.12.2023 12:06, Hannes Tschofenig wrote: > > Hi Eliot, > > > thanks for the quick response. > > > That's good to hear but I haven't read how any error cases are reported to > some central device management system to take some actions. > > Is that functionality documented somewhere as well? For example, some YANG > modules for use with Netconf? > > > Ciao > > Hannes > > > Am 21.12.2023 um 11:35 schrieb Eliot Lear: > > Hi Hannes and thanks Sue > > The MUD Manager always has the responsibility to "consider the source" and > then to consider the context. The information provided in MUD files *can > *be used to automate access control to their associated devices. I think > this is pretty well covered in RFC 8520, but I am starting to think about > an update to that document. > > Eliot > On 21.12.2023 11:08, Hannes Tschofenig wrote: > > Hi Susan, > > thanks for your detailed review. > > You are correct that this document does not address operational aspects of > the MUD Manager and this is certainly something the OPSAWG working group > should address since this document is a tiny extension to the already > existing MUD RFC. Along these lines you are also correct that the document > does not define any mechanism for the MUD Manager to notify the operator > about any error situations with the processing of MUD files and/or SUIT > manifests. I will reach out to Eliot and the OPSAWG working group to think > about standardization work in this direction. > > I have updated the draft to better explain how the different URIs are > passed around. I also added a figure to illustrate it graphically. > Attestation Evidence, which is used to convey information about the MUD > URL, also allows the network to double-check the firmware/software (and > other properties of the device). We didn't go into any details about how > Evidence is processed because this is part of different documents, like the > RATS architecture RFC. I hope the updated text clarified these aspects. > > Regarding the CDDL I had a chat with Brendan and we will make an update. > > Ciao > Hannes > > > Am 04.12.2023 um 16:19 schrieb Susan Hares via Datatracker: > > Reviewer: Susan Hares > Review result: Has Issues > > Overall comment: > Qualifications: I am not an expert on SUIT implementations or an operator > of > networks using SUIT. Therefore, my issues may be covered by some general > security considerations in a document I am not aware of. > > General comments to authors: This feature is clearly described in this > document. Brendan and Hannes did an excellent job of writing the document. > > Security/Operational Issues: > > The security of MUD URLs may move the attacks from individual devices to > the > MUD Manager. (Instead of a single lemming going over the cliff, a MUD > manager > may send many lemmings over the cliff). This document does not seem to > consider > the operational issues in the MUD Manager or provide mechanisms on how to > check > for these attacks (e.g. Yang modules with operational state). > > 1. An Attack on the MUD Manager can shut down or subvert the entire > network. > > It is not clear how the operator knows an attack on the MUD Manager is > happening > or occurred. If the MUD Manager pulls in broken SUIT manifests and > then pulls in broken software/firmware based on the SUIT manifests > how does the operator know? In other words what device watches > that the MUD Manager is not subverted via a management protocol? > > I do not see any operational state in the MUD Yang module [RFC8620 section > 2.1] > It would seem natural to have some operational state in the MUD Manager > reports > manifest state. Yang's notif protocols could report any manifest state > change > (over secure TLS connections) to a centralized security server. > > 2. For secure URLs transmitted by 802.1X with certificates, > Why are these not a "double-check" on the validity of the software? > > Again, it would seem natural to utilize these secure certificates as > "double-checks" on the MUD Manager being "in-sync" with the devices. > > 3. As a less secure double-check on being "in-sync", is the reporting of > MUD URL sent via MUD Devices via DHCP or LLDAP that is not what is in > the > manifest. > > These reporting features are useful in transition scenarios as well as > detecting attacks on the MUD manager. > > Editorial nits: > > 1. section 1, last paragraph, sentence 2 > > Old text: /can get/ > New text: /has/ > > English grammar > > 2. Just for my sanity, would you check the following text is correct > > $$SUIT_severable-members-extensions //= ( > suit-manifest-mud => bstr .cbor SUIT_MUD_container > ) > It appears you are looking to define a CBOR Type for the > the SUIT_MOD_container is defined in the text. > > What I think I'm missing is the .cbor value for SUIT. > It looks correct, but I could not derive this from > draft-ietf-suit-manifest-24: > > SUIT_Severable_Manifest_Members = ( > ? suit-payload-fetch => bstr .cbor SUIT_Command_Sequence, > ? suit-install => bstr .cbor SUIT_Command_Sequence, > ? suit-text => bstr .cbor SUIT_Text_Map, > * $$SUIT_severable-members-extensions, > ) > > And your IANA definitions of: > > IANA is requested to add a new value to the SUIT envelope elements > registry > created with [I-D.ietf-suit-manifest]: Label: TBD2 [[Value allocated from > the > standards action address range]] > > Name: Manufacturer Usage Description (MUD) > Reference: [[TBD: This document]] > > Again, this may be due to my incomplete understanding. > This is why this is a NIT rather than an Issue. > > > > > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call >
- [Suit] Opsdir last call review of draft-ietf-suit… Susan Hares via Datatracker
- Re: [Suit] Opsdir last call review of draft-ietf-… Hannes Tschofenig
- Re: [Suit] Opsdir last call review of draft-ietf-… Hannes Tschofenig
- Re: [Suit] Opsdir last call review of draft-ietf-… Eliot Lear
- Re: [Suit] Opsdir last call review of draft-ietf-… Eliot Lear
- Re: [Suit] [Last-Call] Opsdir last call review of… Behcet Sarikaya
- Re: [Suit] [Last-Call] Opsdir last call review of… Hannes Tschofenig