Subject: Re: [Rats] Minimizing the Attestation Results objects which can represent overall Attester trustworthiness

From: "Smith, Ned" <[email-masked]>
Date: Fri, 3 Sep 2021 21:59:35 +0000

> If there is consensus over a set of ‘standard’ APE statements then mapping them to an integer field is a
> fine way to represent it and seems to align semantically with what Thomas F. is describing. But otherwise, > the AR should include the profile(s) and APE statements as context for the quad/pent-state result.
> <eric3> I would say the text above attempts to standardize the results of some APE statements.  And it might be interesting for people who want to design the > APE languages to assert how they are constructed and referenced between Verifier and Relying Party.  Are you good with this interpretation?
+1

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thursday, August 26, 2021 at 9:18 AM
To: "Smith, Ned" <[email-masked]>, Laurence Lundblade <[email-masked]>, Thomas Fossati <[email-masked]>
Cc: rats <[email-masked]>, vincent r scarlata <[email-masked]>, Henk Berkholz <[email-masked]>, Thomas Hardjono <[email-masked]>
Subject: RE: [Rats] Minimizing the Attestation Results objects which can represent overall Attester trustworthiness

Hi Ned, see inline  <eric3>

From: Smith, Ned, August 25, 2021 7:46 PM
See inline <nms2>

From: "Eric Voit (evoit)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 25, 2021 at 12:49 PM
To: "Smith, Ned" <[email-masked]<mailto:[email-masked]>>, Laurence Lundblade <[email-masked]<mailto:[email-masked]>>, Thomas Fossati <[email-masked]<mailto:[email-masked]>>
Cc: rats <[email-masked]<mailto:[email-masked]>>, vincent r scarlata <[email-masked]<mailto:[email-masked]>>, Henk Berkholz <[email-masked]<mailto:[email-masked]>>, Thomas Hardjono <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Rats] Minimizing the Attestation Results objects which can represent overall Attester trustworthiness

Hi Ned,

Thanks for this.  Some thoughts in-line...

From: Smith, Ned, August 25, 2021 2:12 PM
A few observations about Attestation Results are summarized here.

  1.  AR standards should make it easy for simple results. If Boolean is too simple, then something close like true, false and inconclusive.
<eric2> This makes sense, you and Thomas have shown good reasons to move away from Boolean.

Building from your tri-state suggestion, what do you think about general Trustworthiness Claims which are given a value indicating:

  *   Trustworthy: The Verifier affirms the Attester support for this aspect of trustworthiness  (instead of True)
  *   Warning: The Verifier warns about this aspect of trustworthiness (expands on Inconclusive)
  *   Contraindicated: The Verifier does not support this aspect of trustworthiness (instead of False)
  *   None: There simply is no claim asserted. (is a special case of Inconclusive)
<nms2> An error state might make sense which always implies ‘None’
<eric3> Makes sense, will add.

  1.  Some RPs are auditors and care about voluminous details for forensic purposes. The ARs might also include all of the Claims asserted by Attester / Attesting Environments, Endorsers and the Verifier. Possibly it makes sense to archive these results and pass a pointer to the archive to a RP?
<eric2> I agree we need to support Relying Parties that wants simplicity, as well as Verifiers, Auditing RPs, and more robust RPs that want details.   Thomas suggested doing this with a signed 8 bit integer.   The integer meaning would be the same across any encoding type.  And the integer space could be broken down something like the following:

  *   Trustworthy:   Values 1-31: Each value provides a single standards enumerated reason for affirming the Trustworthiness Claim, values -1 to -32 can indicate a non-standard reason for affirming.
  *   Warning:   Values 32-63: A standards enumerated reason for the warning, values -33 to -64: a non-standard reason for the warning.
  *   Contraindicated:  Values 64-127: A standards enumerated reason for the contraindication,  values -65 to -128: a non-standard reason for the contraindication.
  *   None: Value 0, which is interpreted identically to the Trustworthiness Claim not being present.
<eric3> will make Error value = -1

<nms2> The profile context is also needed. Profiles can indicate which Appraisal Policies for Evidence (APE) are to be applied. An APE might be broken into several statements. The warning / contradicted states might justify listing the APE statements that were not satisfied. APE statements could be OIDs or UUIDs or actual policy expressions.
<eric3> I can see that for some use cases the Relying Party might take a different action based on what Verifier APE was performed.  Before things get that evolved, the Relying Party might only take action based Verifier assigned result value for one or more Trustworthiness Claims (with the instance of the APE included as supplemental Evidence.)

The integer result code ranges Thomas F. proposed seem like a form of APE statements that are commonly understood and standardized.
<eric3> I don't think they are intended to explicitly/directly reference an APE instance.  But instead the resulting output/finding of a specific APE could be one of these code values.  (And per above, an identifier for the APE which was executed could reference this code could be added as supplemental evidence within the AR.)

I don’t know that it satisfies “non-standard” or Owner defined results however as these will require some form of additional contextualization. If the profile is identified as part of the Attestation Results, then this goes a long way toward contextualizing the APE statements. APE statements have to be fairly concretely defined and the output is likely tri/multi-state as well. The Verifier can easily have a built in ‘all-or-nothing’ policy for ‘Trustworthy’ and ‘None’ (i.e., where all APE statements are accepted or none are) while ‘Warning’ and ‘Contraindicated’ will be cases where some of the APE statements were satisfied while others were not. Note: It would be possible to put a fine point on ‘contraindicated’ as APE statements that satisfied a deny condition.
<eric3> This makes sense to me.

If there is consensus over a set of ‘standard’ APE statements then mapping them to an integer field is a fine way to represent it and seems to align semantically with what Thomas F. is describing. But otherwise, the AR should include the profile(s) and APE statements as context for the quad/pent-state result.
<eric3> I would say the text above attempts to standardize the results of some APE statements.  And it might be interesting for people who want to design the APE languages to assert how they are constructed and referenced between Verifier and Relying Party.  Are you good with this interpretation?

/Eric3

The benefits of such a scheme include:

  *   A simple RP can have a Policy for Attestation Results which is as simple as: "Only allow connectivity where the set of provided Trustworthiness Claim values are 'Trustworthy' ".
  *   A more robust RP can work from a specific reason encoded in the value ranges above.
  *   An auditing RP gets standard values, and each value can then act as a hook for extended details which might be includes in the Attestation Results.

     *   It may be helpful to partition claims according to who is speaking (Attester, Endorser, Verifier).
<eric2> Agree.   At this point the draft has just aimed at Verifier Claims.  Certainly we need provenance provably understood for all elements in the AR.

     *   Attester can assert Claims as Evidence (that should be compared with Reference Values. It can also assert Claims that it makes on its own authority (as a trustworthy entity).
<eric2> Agree.  And these Claims would be even more believable when the Verifier vouches for general aspects of the Attester :-).

  1.  Verifiers can assert Claims that are meaningful to RPs that involve some form of inference beyond (2) but less than (1). These Claims likely are use-case / RP specific. Maybe it doesn’t make sense to define appropriate extension points rather than drive for definitions right now?
<eric2> Ok.  But if we start from Thomas F's thinking, we might have a workable approach for both.  Pending any objections/suggestions, look for a draft-voit-rats-attestation-results revision shortly which makes an attempt at both.

See also comments in green <nms> below.

From: RATS <[email-masked]<mailto:[email-masked]>> on behalf of "Eric Voit (evoit)" <evoit=[email-masked]<mailto:evoit=[email-masked]>>
Date: Tuesday, August 17, 2021 at 8:14 AM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>, Thomas Fossati <[email-masked]<mailto:[email-masked]>>
Cc: rats <[email-masked]<mailto:[email-masked]>>, vincent r scarlata <[email-masked]<mailto:[email-masked]>>, Henk Berkholz <[email-masked]<mailto:[email-masked]>>, Thomas Hardjono <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Minimizing the Attestation Results objects which can represent overall Attester trustworthiness

Hi Laurence,

From: Laurence Lundblade, August 17, 2021 1:28 AM
Hi Eric,

Really glad we’re having a discussion on attestation results now.
<eric> Yes, this is good and necessary.

Kind of a coincidence we both focused on it at 111.
<eric> Actually, core of the Verifier generated AR is the " trustworthiness-level" of draft-voit-rats-trusted-path-routing-00  (Feb 2020   :-).   At the interim, I would love to show off some production code.  We didn't have time for it in IETF 111.

On Aug 10, 2021, at 2:00 PM, Eric Voit (evoit) <evoit=[email-masked]<mailto:evoit=[email-masked]>> wrote:

Hi Laurence,

During the RATS IETF 111 sessions, we both shared views of how to encode Attestation Results (AR).   From the perspective of draft-voit-rats-attestation-results, the AR in scope are Verifier generated claims* about trustworthiness of the Attester itself.   Some examples of such claims include:

  *   the Verifier asserts that the Attester has only known good software loaded
  *   the Verifier asserts Attester's configuration doesn't expose security holes
We are now beginning to standardize these Verifier generated claims (and associated AR object definitions).   We need to do this with the stated objective of maximally simplifying the interworking of different types of Attesters, Verifiers, and Relying Parties.  That maximal simplification is essential as we diverse group of RATS roles and developers spanning different industries.  And to accomplish this, I suggest we adopt the following set of design principles:

  1.  We should only have a small number of Verifier trustworthiness claims standardized at this time.  Reason: a plethora of similar trustworthiness claims will result in divergent choices made between different Verifiers.  This would place a lot of complexity in the Relying Party as it would be up to the RP (and its policy language) to enable normalization across rich incompatible Verifier object definitions.
<nms> +1

  1.  Any objects from (1) which we do standardize should only include specific enumerated states that could viably result in a different action from the applied Policy for Attestation Results.   Reason: by explicitly disallowing the standardization of any enumerated states which cannot easily be connected to a use case, we avoid forcing implementers making incompatible guesses on what could happen.  This will eliminate many types of errors.
<nms> +1 with a preference for AR structures that focus first on Ned’s (1) and (2) with extension points for (3) above.
<eric2> Agree.

  1.  Verifier and RP developers need explicit definitions of *each* state in order to accomplish the goals of (1) and (2).  Without such guidance, the Verifier will send plenty of raw info, as it relieves the Verifier of making the hard decisions.  Of course, this raw info will be mostly non-interpretable and therefore non-actionable by the RP.
<nms> This could be understood in terms of Ned’s (2) and (3) above. Maybe helpful to avoid conflation.

  1.  We do need extensibility for this type of Verifier generated claim.  But Verifier generated claims should be worked in the WG and managed via the RFC process, rather than being in a separately maintained Attester Claims list.  This will keep a tight lid on extensions which must be considered by the RP's policy language.
<nms> +1 If the AR structure comprehends which Claims are appraised and accepted, appraised and not accepted, inconclusive, inferred (created by the Verifier) or passed through, then RPs will have the proper context for doing auditing / cross-checking appraisals.

I assume these claims would be in the CWT and JWT registry like other claims and that they have no special status in those registries. We’re not creating a new registry for these, nor are we going to modify the CWT or JWT registries so they can have special status, right?
<eric> I believe the claims can go into the registry without any special status.  As the claims will need to be encoded in other contexts such as YANG and EAP/TLS  the authoritative object definitions should be defined in drafts/RFCs which then get imported to the necessary registries.

I also assume we should clarify that EAT profiles apply to attestation results and/or evidence and that is the mechanism used to keep a handle on the number of claims in attestation results.
<eric> As long as the WG has a firm hand on specific standardized claim definitions, and there is space for vendor defined claims, I am good.
<nms> I don’t think Claims should be stereotyped as Evidence, Endorsement, AR etc… They should focus on describing an informational content. Who (attestation role) asserts the Claim is what makes it Evidence, Endorsement or AR. Since vendors often invent new things, it is appropriate for them to name them too. The RATS Arch refers to Target and Attesting ‘Environments’ which can be named things. Claims can (and should) describe environments in addition to trustworthiness properties of those environments.
<eric2> Works for me.

I would like to add this important design principle:

(5) Cover the full range of use cases, device types and security levels. Use cases may include letting a device on the network, a financial transaction, a biometric authentication and more. Device types may include complex mobile phones, simple IoT sensors, laptops and network equipment. Security levels may range from EAL 5 certified secure element, to a TEE, to entirely simple minimal devices with no special security properties.
<eric> Works for me.   Each device will need to specify which claims are realistically supportable based on the underlying hardware.
<nms> Profiles seem appropriate for this objective.

These design principles are important to keep the number of Verifier generated claims low, and to retain the complexity in the Verifier rather than the RP.   We followed these design principles in draft-voit-rats-attestation-results.   Consequently, the next version of draft-voit-rats-attestation-results will include a total of 9 Verifier generated Trustworthiness Claims supporting a total of 18 enumerated states.   18 enumerated states feels like an easily digestible number for the developers of RP policy language :-).

I think there may be more than one model for constructing attestation results.  Your draft is one. Another might be based on machine learning, in which case the RP just wants every data item possible. I think a single  “trust me” boolean is OK for some use cases. Maybe the boolean is implied because attestation results were generated.
<eric> For a couple years Boolean seemed sufficient to me.   However just a month ago Thomas Fossati convinced me that a boolean was not as flexible as a signed integer, and various integer values other than "1" can be used to express standard and non-standardized failure reason codes.  A new draft should be posted by the Attestation Results authors on this in ~1 week.
<nms> tri-state result is a simple but not too simple expression. E.g. (a) accepted claims, (b) not accepted claims and (c) inconclusive / ignored claims. A profile can define which claims MUST be in (a) and MAY be in (b) or (c).
<eric2> Yes, the new proposal above is based on tri-state :-).

This also fans out by submodule for complex devices, even with draft-voit-rats-attestation-results (there is no inheritance with submodules).
<eric> Routers can get very complex, with multiple control/supervisory cards and dozens of line cards.  Each have their own Attesting Environments.   My experience is that as the Attester gets more complex, the interfacing Relying Party device depends more-and-more on a single summary result for the device before deciding whether to trust.   From there, specific claims from submodules might be useful, but at least in the Routing/Switching world I haven't seen that yet beyond specific hardware protected identities.   (Note: the Verifier developers have always wanted to provide voluminous details on how smart they are.  But the Relying Party has consistently said that it is up the Verifier to make these hard decisions.  And it is the Relying Party which gets to choose if they use the Attestation concept at all.)
<nms> the concept of claims inheritance should be better defined / explained. Transitive trust could be described as a form of ‘inheritance’. There is pretty good math on transitive trust properties and notation for describing sequences of transitivity. Most often trust is all or nothing in normal circumstances.
<eric2> This does seem a meaningful space for submissions.  The need is certainly highlighted in draft-ietf-rats-architecture, Figure 4.

I am hoping we can connect this thinking to your swresult object from your IETF 111 slides.   Looking at your slide on the swresult claim, *each* software measurement could include a large array of results.  I believe this unbounds the complexity of the RP policy language.  Effectively, the Evidence to the Relying Party may often be richer than that originally sent by the Verifier.  In what scenarios do you see Relying Party applying such a rich language?   And at least from the perspective of deciding whether Attester itself is trustworthy, do you see ways for just a few Verifier generated claims to expose key trustworthiness attributes and states evaluated for the Attester?

Swresults was intended as a flexible way to report what ever SW measurement results need to be reported. It is intended to cover all possible cases. I would expect many use cases to use very little of it. Many, hopefully, most could be very simple using it.

Swresults also can be in attestation evidence when one subsystem like a TEE can measure and evaluate another subsystem.
<nms> Agree. Once a node is determined to be trustworthy (via attestation or otherwise) it can make new Claims that are acceptable without Reference Values. We don’t have terminology for this in RATS Arch (I think), but the closest to this is AR and Endorsements but we don’t say that an Attester (Attesting Env) can assert AR or Endorsements. I think it’s a gap in the arch but others may disagree.
<eric2> Agree it is a gap.  What you are talking about above is the interplay of specific instances or classes of claims.  Only now are we even in a position to have that conceptual discussion.

/Eric2

I’m not sure the principles above should be applied to swresults as I think it is for a different model for reporting attestation results. Open to discussion on this.

Swresults is kind of a first proposal. Would appreciate lots of discussion around it. Seems to me that we’re just getting started on this topic.

<eric> I will be interested in where this goes, as I see it as a way of potentially documenting supporting evidence beyond the Trustworthiness Vector.  I moved Thomas F to the 'to' as I know he has been thinking about this as well.

I know this is a complex question which might only be worked in an upcoming interim.

Probably more than just one interim :-)

<eric> Agree.

Eric

LL

But I figured I would start the dialog now.

Thanks,
Eric

* Note from above: these Verifier generated claims are not the same thing as a Verifier ratifying specific claims generated within the Attester (such as UEID, location, software manifest, etc.)   Many of your AR definitions within the swresult appear aimed at this context.  So there might not be an explicit overlap between our drafts.

Eric Voit
Principal Engineer
.:|:.:|:. Cisco Systems, Inc.

_______________________________________________
RATS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 20 Sep 2021 10:17:28 -0700

I have a lot of catch up to do on this thread and such, just one comment here.

Eric, you listed a bunch of principles for the design of attestation results upon which we have agreed.

> On Aug 25, 2021, at 4:46 PM, Smith, Ned <[email-masked]> wrote:
> 
> I am hoping we can connect this thinking to your swresult object from your IETF 111 slides.   Looking at your slide on the swresult claim, *each* software measurement could include a large array of results.  I believe this unbounds the complexity of the RP policy language.  Effectively, the Evidence to the Relying Party may often be richer than that originally sent by the Verifier.  In what scenarios do you see Relying Party applying such a rich language? ...

My thought is that swresults, in its simplest form, meets all those requirements.  For example an EAT profile could say:

- For Acme devices, the verification system is always “Acme verify"
- For this device, the SW measurements covers everything so the verification-object is always “all”
- The results reported must always be “fully-verified” or “verification-failed”
- No nesting of swresults is allowed

[
    [
        “Acme verify”,
        “all”,
        “fully-verified”
    ]
]

Effectively this is pretty much a boolean yes/no result, the simplest possible and simpler than 18 states.

Note that swresults is for both attestation evidence and attestation results. For attestation evidence, the TEE in a phone might measure a lot of different things.

I’m not up to speed on your attestation results draft (the 18 states aren’t intuitive to me (yet)), so I don’t have to much more to say here. My thought in the design of swresults was to allow both the most simple expressions and to be able to scale to more complexity. Like most things in EAT, CWT, JWT, COSE, JOSE… there are tons of options to accommodate lots of use cases and we have to rely on a profile to narrow down.

I do not have strong opinions on this yet. Swresults is an initial proposal.

LL