Re: [Suit] AD Review of draft-ietf-suit-mud-04

[Roman Danyliw <[e-mail]>]

Hi Hannes!

> -----Original Message-----
> From: Suit <[e-mail]> On Behalf Of Hannes Tschofenig
> Sent: Saturday, September 23, 2023 3:24 PM
> To: Roman Danyliw <[e-mail]>; [e-mail]
> Subject: Re: [Suit] AD Review of draft-ietf-suit-mud-04
> 
> Hi Roman,
> 
> 
> thanks for the extra feedback. Responses inline:
> 
> 
> Am 23.09.2023 um 00:41 schrieb Roman Danyliw:
> > Hi Hannes!
> >
> > Thanks so much for publishing -05.  My remaining line of feedback is around
> my original questions about Section 3 –- the normative guidance around the
> workflow.  The new text in Section 3 on the steps in the workflow are much
> clearer, and I very much appreciated the pro/con write-up of the design in
> Section 4.  Not many specifications will write-up the cons.
> >
> > If I read things correctly, the Section 3 workflow is trying to mirror a new
> MUD conveyance approach like DHCP or LLDP.  What I’m grappling with is how
> interoperable is this attestation step as currently scoped?  EAT is cited
> normatively, but there are no other normative details on how this attestation
> should occur.
> >
> > Are there any requirements other than an “EAT token with a manifest claim is
> somehow passed”?
> >
> > Is there any guidance on conveyance?  For example, EAP is mentioned (as an
> example).  Is there a pointer on how an EAT can be carried by an EAP method?
> 
> Currently, this attestation step is not interoperable. While there is the need to
> convey an EAT token in an EAP method exchange, I haven't seen such an EAP
> method yet.
> 
> Theoretically, one could argue that the work in <draft-fossati-tls-attestation>
> could be applied to an EAP-TLS-based method but nobody has done this work
> yet.

If we both agree that the current guidance is not interoperable, then it isn't clear how it can be normatively required.  As written, it seems underspecified.  I'm assert that it is "normatively required" because [I-D.ietf-rats-eat] is cited normatively.

Would it be acceptable to the WG to suggest a workflow using attestation but not normatively describe?  For example:

OLD
   The intended workflow is as follows:

   *  At the time of onboarding, devices report their manifest in use to
      the MUD Manager via attestation evidence in the Entity Attestation
      Token (EAT) [I-D.ietf-rats-eat].

      -  Among other claims, the device will report its software
         digest(s), and the manifest URI in the EAT "manifests" claim to
         the MUD Manager.  This approach assumes that attestation
         evidence includes a link to the SUIT manifest via the
         "manifests" claim (see Section 4.2.15 of [I-D.ietf-rats-eat])
         and that this evidence can be carried in either a network
         access authentication protocol (for eample an EAP method) or
         some onboarding protocol like FIDO Device Onboard (FDO).

NEW (rough text)
   The intended workflow is as follows, and assumes an attestation mechanism between the device and the MUD Manager:

   *  At the time of onboarding, devices report their manifest in use to the MUD Manager via some form of attestation evidence and a conveyance protocol.  The normative specification of these mechanisms is out of scope for this document. 
.
      -  An example of an attestation evidence format is the Entity Attestation Token (EAT) [I-D.ietf-rats-eat].  Among other claims, the device could report its software digest(s), and the manifest URI in the EAT "manifests" claim to the MUD Manager.  This approach assumes that attestation evidence includes a link to the SUIT manifest via the "manifests" claim (see Section 4.2.15 of [I-D.ietf-rats-eat]) and that this evidence can be carried in either a network access authentication protocol (for eample an EAP method) or some onboarding protocol like FIDO Device Onboard (FDO).
 
Regards,
Roman


> >
> > Related to what “attestation” means, is the subsequent text in Section 4:
> “The device does not report the MUD URL, so the device cannot tamper with
> the MUD URL.”  I took that to mean that there is a distinction being made
> between TEE and a REE; and the “device” here is the REE. Is that intended
> interpretation?
> 
> I think the text needs a picture. There is the underlying assumption with the
> use of attestation technology that some low-level software/hardware is able to
> collect measurements from about its environment. When that software
> generates the attestation evidence for use with remote attestation then it
> includes information about the manifest. When using the SUIT manifest, the
> attester will hopefully verify also the firmware the SUIT manifest describes.
> 
> 
> >
> > If accurate, I recommend explicitly clarifying this.  Section 1.1 of draft-ietf-
> rats-eat-21 seems to lay out uses of EAT which are not TEE based.  A quick scan
> of draft-ietf-suit-architecture found definitions for TEE and REE, but (with using
> a keyword search only) REE is never used after it is defined, and TEE is used
> once in Section 6 without direct guidance on use.
> 
> 
> The RATS architecture does not say where some of the functionality is
> implemented. The attester-functionality needs to be provided by some low-
> level software, which would be close to a TEE in the TEEP terminology.
> 
> 
> To summarize, this document is something you could describe as more forward
> looking than the other SUIT items.
> 
> 
> Ciao
> Hannes
> 
> 
> >
> > Thanks,
> > Roman
> >
> >> -----Original Message-----
> >> From: Suit <[e-mail]> On Behalf Of Hannes Tschofenig
> >> Sent: Sunday, September 10, 2023 10:59 AM
> >> To: Roman Danyliw <[e-mail]>; [e-mail]
> >> Subject: Re: [Suit] AD Review of draft-ietf-suit-mud-04
> >>
> >> Hi Roman,
> >>
> >>
> >> those are great review comments.
> >>
> >>
> >> I have started to address them, see
> >> https://github.com/bremoran/suit-mud/pull/5
> >>
> >>
> >> You have certainly discovered the weakness of this proposal. It
> >> relies on a number of technologies to be in place before it can
> >> actually be deployed. When those conditions are met, there are
> >> security and operational benefits. I made this more clear in the write-up.
> >>
> >>
> >> Ciao
> >>
> >> Hannes
> >>
> >>
> >> PS: Only the MUD URL is included in the manifest and not the MUD file
> itself.
> >> Your reading of the CDDL was correct.
> >>
> >>
> >> Am 09.09.2023 um 22:18 schrieb Roman Danyliw:
> >>> Hi!
> >>>
> >>> I performed an AD review of draft-ietf-suit-mud-04.  Thanks for this
> >> document.  Below is my feedback.
> >>> ** Section 1 and 6 assert that a MUD file can be included by
> >>> reference or
> >> value.  How does one include a MUD file by value?  Excuse my
> >> familiarity with CDDL but my read of SUIT_MUD_container is that is
> >> contains only a URL and associate SKI.  All of the other CDDL in
> >> Section 5 by my read is about integrating the SUIT_MUD_container data
> >> structure so it can be as a manifest member or be severable.
> >>> ** Section 3.  I was confused on how to read this section.  I was
> >>> expecting this document to primarily discuss how to embed MUD
> >>> information into a SUIT manifest.  However, this section seems to
> >>> define attestation behavior and functionality on the end-point that
> >>> is outside the SUIT workflow and more rigorous than required in the
> >>> core SUIT manifest document.  Is this section normative or just an
> example?
> >>> [I-D.ietf-rats-eat] being cited normatively here suggests the
> >>> section is also normative.  If this is an example, please make that
> >>> clearer and don’t make EAT a normative reference.  If not, then
> >>> please be more specification about these attestation mechanisms
> >>> (more below)
> >>>
> >>> ** Section 3.
> >>>
> >>>      *  At the time of onboarding, devices report their manifest in use to
> >>>         the MUD manager via attestation evidence.
> >>>
> >>> Can a pointer please be provided on the normative mechanism for
> >>> sharing
> >> attestation evidence with the MUD manager?  I ask because RFC8520
> >> doesn’t mention attestation as an activity done by the MUD manager.
> >>>      *  If the SUIT_MUD_container, see Section 5, has been severed, the
> >>>         MUD manager can use the suit-reference-uri to retrieve the
> >>>         complete SUIT manifest.
> >>>
> >>> What happens if suit-reference-uri is not included?  If my reading
> >>> of draft-
> >> ietf-suit-manifest-22 is correct, this field is optional.
> >>>      *  Each time a device is updated, rebooted, or otherwise
> >>>         substantially changed, it will execute an attestation.
> >>>
> >>> Is this new requirement on any device including this MUD extension?
> >>>
> >>>         -  Among other claims in the Entity Attestation Token (EAT)
> >>>            [I-D.ietf-rats-eat], the device will report its software
> >>>            digest(s), configuration digest(s), manifest URI, and manifest
> >>>            digest to the MUD manager.
> >>>
> >>> What is the profile of the EAT claims needed?  How is it conveying
> >>> this EAT
> >> token?
> >>>      *  If the MUD manager does not already have a full copy of the
> >>>         manifest, it can be acquired using the reference URI.
> >>>
> >>> When the manifest was retrieved in step #2 is was verified in step
> >>> #3.  Here,
> >> there is no explicit language about verification.
> >>>      *  Once a full copy of the manifest is provided, the MUD manager can
> >>>         verify the device attestation report
> >>>
> >>> Wouldn’t the device have to emit the device attestation report?
> >>>
> >>> ** Section 5.  To be clear, suit-mud-ski is the subject key
> >>> identifier for the key
> >> used in the MUD signature file described in Section 13.2 of RFC8520?
> >> If so, editorial, I would have benefited from an explicit statement to that
> effect.
> >>> ** Section 6.  Do any Security Considerations from suit-manifest or
> >>> MUD
> >> apply here?
> >>> ** Reference
> >>>
> >>> --  [I-D.isobe-cose-key-thumbprint] is now adopted by the WG and is
> >>> draft-
> >> ietf-cose-key-thumbprint.  Please replace it.
> >>> -- feedback from idnits:
> >>>     == Unused Reference: 'RFC7093' is defined on line 288, but no explicit
> >>>        reference was found in the text
> >>>
> >>>     ** Downref: Normative reference to an Informational RFC: RFC
> >>> 7093
> >>>
> >>> Please drop it.
> >>>
> >>> Regards,
> >>> Roman
> >>> _______________________________________________
> >>> Suit mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/suit
> >> _______________________________________________
> >> Suit mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/suit
> > _______________________________________________
> > Suit mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/suit
> 
> _______________________________________________
> Suit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/suit