Re: [Mud] [Iot-onboarding] Some new stuff for mudmaker.org

Eliot Lear <lear@cisco.com> Thu, 26 March 2020 09:28 UTC

Return-Path: <lear@cisco.com>
X-Original-To: mud@ietfa.amsl.com
Delivered-To: mud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 329EC3A0C01; Thu, 26 Mar 2020 02:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Dngp6lCWy1Oc; Thu, 26 Mar 2020 02:28:10 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 191383A0AB4; Thu, 26 Mar 2020 02:28:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3264; q=dns/txt; s=iport; t=1585214890; x=1586424490; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=8xJy6N5Ud6iSzTn/6lJYqshoPFP7DNFoXmE8KpB3BVU=; b=OflU7VYk3m2PZwKiaxkaq4uKh0ZPmGINkN5/szWzxrzDtC8qA4Pz9Scz Ze5sIiXmjwfv3GIfQrQWAGf8ezj1Y7DOqDCGv+oqn/35Oc9QSTlRwR44s cBHQOjmQaJ4WJmMU8QIKws2GVfCEnyxhqvaSGtLXjvzpP/ylztBja8j7a s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AqAwBGdXxe/xbLJq1mHAEBAQEBBwEBEQEEBAEBgXuDFVUgEiqEGokCh2eTYYgLCgEBAQwBARsUBAEBhEQCglA4EwIDAQELAQEFAQEBAgEFBG2FVgyFZAYjVhALBD4CAlcHgzgBgnytBXWBMoVLhRiBOIxJggCBEScMFIJNPodcMoIsBI4SokOCRoJWhQmPKh2DTotZjDiEX4oymEGDNAIEBgUCFYFpIoFYMxoIGxVlAYJBCTUSGA2ObYg3hUJAAzCPJQEB
X-IronPort-AV: E=Sophos; i="5.72,307,1580774400"; d="scan'208,217"; a="24713183"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2020 09:28:07 +0000
Received: from [10.61.243.68] ([10.61.243.68]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 02Q9S6tJ019739 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 26 Mar 2020 09:28:07 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <05087541-ADBC-4B1B-BF2B-891B653DB3B1@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_964BD98B-0CBA-412C-986C-19C26995BF32"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 26 Mar 2020 10:28:06 +0100
In-Reply-To: <4450F7B2-D9F2-4480-93D7-2DF2B062D83D@cisco.com>
Cc: Carsten Bormann <cabo@tzi.org>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: iot-onboarding@ietf.org, mud@ietf.org
References: <0DE46278-4708-42B6-8DFF-A8BC67B23F7E@cisco.com> <CAHiu4JPqXd2emEFCRK2dq0L6OFOcr-UdNkhJ2W+Cx5TUCLrprA@mail.gmail.com> <17397.1585086427@localhost> <CAHiu4JNfWBBMZV0bO41Emdo4GO2EFmicw+E=np_Xey_xG4JsKA@mail.gmail.com> <A19C04FE-3A50-4466-84D4-521C575C43C0@cisco.com> <27885.1585179569@localhost> <4450F7B2-D9F2-4480-93D7-2DF2B062D83D@cisco.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-Outbound-SMTP-Client: 10.61.243.68, [10.61.243.68]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/VbOt93rsGdwaMIQ2ISrVinekQIA>
Subject: Re: [Mud] [Iot-onboarding] Some new stuff for mudmaker.org
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2020 09:28:23 -0000

So there’s one aspect that my early draft glosses over.  Great.  You have a URL, whatever it is.  The manufacturer is likely to want to authenticate you.  What’s the tooling flow?  I think it’s something like this:

MUD URL picked up by mud manager
Mud manager retrieves mud file, dispatches URL of the SBOM to an SBOM consumer of some form that we’ll just call an SBOM manager for the moment.
SBOM manager resolves URL first time.
It has no token to use.  
User must register.  Requires a browser interaction of some form, presumably with OAUTH.  Perfectly reasonable when the SBOM lives in the cloud.  OR
Token is received out of band for this service, either from the device itself, or from the manufacturer service if one is registered through that (requires browser interaction).
There is a token. Authenticate with that and retrieve.

I am thinking that when a token is received out of band for access to a resource, that is a generic exchange that goes well beyond this use case.  Carsten, Hannes, do you have views on any of this?

Eliot