ADMA
what is ADMA vs QDMA? (ethernet vs wifi)?
ADMA
what is ADMA vs QDMA? (ethernet vs wifi)?
Raven
An old code name for this product maybe?
The device must fetch the Trusted Component Binary in another connection after receiving an Update message
So the device must reveal eis location to the Trusted Binary server.
Hence, depending on the freshness mechanism in use, the TAM may need to store data (e.g., a nonce) for some time.
This also suggests that for mobile devices that it may be hours to days before before right things are installed if they require unmetered WIFI to get the right pieces. The mobile device might change IP addresses and even geographies. Specifically, someone with a mobile device in some localities may find they have to change to their roaming SIM card in order to appear in their "home" country.
Since the word "key" is mainly used in its other meaning, as a cryptographic key, this specification uses the term "label" for this usage as a map key.
Is this something that EAT should say?
While the TEEP protocol does not require use of EAT, use of EAT is encouraged and Section 4.3
Need to list alternatives and reasons not to use EAT.
Example 1: Having one SUIT Manifest pointing to a URI of a Trusted Component Binary
I don't like them being called examples.
when
and when not?
When an Entity Attestation Token is used
... and when EAT is not used?
(RFC-editor: upon RFC publication, replace URI above with "https://www.rfc-editor.org/info/rfcXXXX" where XXXX is the RFC number of this document.) It MUST be present if the attestation-payload parameter is present and the format is not an EAT in CWT format with the profile defined below in Section 5.
If we revise this document rfcXXXX-bis, then what will the absense of the payload format mean?
The TAM SHOULD set an expiration time for each token and MUST ignore any messages with expired tokens. The TAM MUST expire the token value after receiving the first response containing the token value and ignore any subsequent messages that have the same token value.
I guess this is a defense against replays. I guess this document hasn't told me if it's over HTTP or carrier pigeon yet.
This is an issue that can be solved by tooling.
rewrite sentence
Whether to re-use the standardized manifest format that was used during the initial firmware retrieval process or whether it is better to use a different format for the secure boot- specific meta-data depends on the system design.
Whether to re-use the standardized manifest format that was used during the initial firmware retrieval process or whether it is better to use a different format for the secure boot- specific meta-data depends on the system design, but it is a local decision.
It is likely that one of the CPUs will be considered a master, and will direct the other CPU to do the upgrade.
It is likely that one of the CPUs will be considered the primary, and will direct the other CPU to do the upgrade.
Another configuration consists of a similar architecture to the previous, with a single CPU. However, this CPU supports a security partitioning scheme that allows memory (in addition to other things) to be divided into secure and normal mode.
Another configuration with a single CPU is similiar to the previous section, however, this CPU supports a security...
turns
turned
contain
containing
trick phone companies
Again, the phone companies are trying to blame their customers for their own failure to authenticate properly.
identity theft
I hate this term. Banks use it to blame the victims for their failure to authenticate people properly. I wish we had another term.
? suit-manifest-mud => SUIT_Digest
So, shouldn't that be: ? suit-manifest-mud => SUIT-Digest / bstr .cbor SUIT_MUD_container
To enable this, we add a MUD url to SUIT along with a subject-key identifier, according to [RFC7093], mechanism 4 (the keyIdentifier is composed of the hash of the DER encoding of the SubjectPublicKeyInfo value).
It's ugly that we have cool COSE signed SUIT manifests referencing multi-decade old CMS objects. Let's make sure we can step forward by anticipating that we might sign MUD files with something more modern as well?
At the time of onboarding, devices report their manifest in use to the MUD manager.
That's really cool. How does that work? DHCP? LLDP? BRSKI? EAP-NOOB?
A certificate created for use with network access authentication is typically not signed by the entity that wrote the software and configured the device, which leads to conflation of local network access rights with rights to assert all network access requirements.
This needs to be expanded. It conflates IDevID, LDevID, and ignores enrollment steps, be they BRSKI-TEEP, EAP-NOOB, or other mechanisms.
unprotected
s/unprotected/unprotected and can be easily changed in transit/
trust the device to report a correct URL
s//trust that a correct URL is transmitted, and is not modified in transit/
functionality
s/functionality/privileges/
IEEE 802.1X whereby the URL to the MUD file would be contained in the certificate used in an EAP method.
using the MUD extension in a certificate based system, such as IEEE 802.1X using a certificate-based EAP method, or a BRSKI based enrollment system.
than
that
MAY not be able
MAY not be able -> MAY be unable
A Replicator MAY not offer a Point for every interface available on the system.
This sentence is confusing, please rewrite.
This sentence is confusing.
another definition of bootstrapping
maybe we can make up yet-another-term?
If these conditions are not met, or if it cannot validate the chain of trust to a known trust anchor, the MUD manager MUST cease processing the MUD file until an administrator has given approval.
What's the point of the signature if the MUD URL arrives by DHCPv4, LLDP.
o permissive a set of rules in the otherwise-legitimate MUD File. A manufacturer SHOULD employ secure development best practices to take reasonable steps to insure that their devices behave correctly at least up to the point that they are shipped and that their web services follow all BCPs.
Pinning of the signing key? (With TOFU)?
The MUD URI is a very visible and important part of MUD that is best done correctly from the start, for once it is embedded in an IoT device,
I guess this might be more subtle as advice.
If a device manufacturer chooses to update a MUD-enabled device's firmware, the manufacturer may update the MUD URI to a new one.
Okay. Good advice, I think.
the
then
From a security standpoint, it is better to have several URIs with more granular security profiles than it is to have a very few URIs with "catch-all" (and thus more open) security profiles.
This argues for having every firmware update and every SKU of every product have a unique MUD URI. These can be 301 redirects to a common file, until that file changes.
available
accessible ?
The service which returns the MUD file will not be responsible for any security policy enforcement, as that is the job of the network which contains the devices themselves
It's curious to need to say this. There is clearly some confusion somewhere, and I wonder if teasing out what the misconception was, would be useful.
(i.e., there is no per-serial-number version of the MUD URI)
But, is there a per-firmware MUD URI?
IPv6 AD
What's AD? Address Discovery? Do you mean Router Solicitation?
(the switch to which the bulb in connected, for example)
Light bulbs don't really connect to switches, they run on WiFi (often, historically), or 802.15.4 (newer). I think it would be better to use a different example of something that actually does connect to a switch.
If that request has a MUD URI in it, equipment in the network (not necessarily the DHCP server) can use that URI to retrieve the device's MUD file from the MUD file server.
This is very IPv4 specific. LLNs do not have DHCPv4 servers. I guess we should define a way to carry a MUD URL in an RPL DAO?
retrieval
the manufacturer will delegate the MUD file serving function to a third party. They may also delegate the MUD file creation/managed to another party.
How does one get the logs from the recursive DNS servers that trump-email.com was talking to?
I am concerned that the experiment time of one year may not be long enough to socialize this out to non-IETF insiders.