Subject: [Rats] Attestation Results for Secure Interactions

From: Nicolae Paladi <[email-masked]>
Date: Thu, 12 Aug 2021 12:10:54 +0200

Hi,

I would like to ask the list - or specifically the authors & contributors of draft-voit-rats-attestation-results-01 <https://datatracker.ietf.org/doc/draft-voit-rats-attestation-results/> if there is a GitHub repo for this document? I would like to open some issues (and otherwise help improve the document).

Two issues:
 1. Non-repudiable identity:

"   Additionally, each set of AR Augmented Evidence must be provably and
   non-reputably bound to the identity of the original Attesting
   Environment which was evaluated by the Verifier.  This will be
   accomplished via two items.  First the Verifier signed Attestation
   Results MUST include sufficient Identity Evidence to ensure that this
   Attesting Environment signature refers to the same Attesting
   Environment appraised by the Verifier.  Second, an Attesting
   Environment signature which includes the Verifier signature of the
   Attestation Results MUST also be included.
"
As it looks right now, the second item ("an Attesting Environment signature which includes the Verifier signature") is only possible in the passport-model, since to include the Verifier signature, the Attesting Environment must sign _after_ the Verifier. That is not compatible with the background-check model. Is that the intent?

2. In §2.2.1 Attester and Attesting Environment, the document mentions three general categories of Attesters: (1) HSM-based, (2) process-based and (3) VM-based. This looks neat, but where do you add solutions like IBM PEF, which uses both a TPM and firmware extensions + an additional virtualisation element (ultravisor) to protect the execution environment of the VM. My main concern is to avoid an artificial classification that will cause trouble down the line.

Full disclosure: I am in no way related to IBM but I do care about being able to consume attestation results from a broad range of platforms.

Best regards,
Nicolae

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 12 Aug 2021 12:41:45 +0200

Hi Nicolae,

yes there is!

> https://github.com/ietf-rats/draft-voit-rats-attestation-results

Please find more comments in-line.

On 12.08.21 12:10, Nicolae Paladi wrote:
> Hi,
> 
> I would like to ask the list - or specifically the authors & 
> contributors of draft-voit-rats-attestation-results-01 
> <https://datatracker.ietf.org/doc/draft-voit-rats-attestation-results/> if 
> there is a GitHub repo for this document? I would like to open some 
> issues (and otherwise help improve the document).
> 
> 
> Two issues:
> As it looks right now, the second item ("an Attesting Environment 
> signature which includes the Verifier signature") is only possible in 
> the passport-model, since to include the Verifier signature, the 
> Attesting Environment must sign _after_ the Verifier. That is not 
> compatible with the background-check model. Is that the intent?

It is true that we started with a focus on the passport model and that 
was already noticed by Dave Thaler during one of the RATS sessions at 
the latest IETF meeting. That said, a lopsided focus on the passport 
model is not the actual intend here and we have to remediate that as 
feasible as possible.

> 
> 
> 2. In §2.2.1 Attester and Attesting Environment, the document mentions 
> three general categories of Attesters: (1) HSM-based, (2) process-based 
> and (3) VM-based. This looks neat, but where do you add solutions like 
> IBM PEF, which uses both a TPM and firmware extensions + an additional 
> virtualisation element (ultravisor) to protect the execution environment 
> of the VM. My main concern is to avoid an artificial classification that 
> will cause trouble down the line.

The reason for classification here is to make digesting the 
Trustworthiness Vector defined in our document as simple as possible for 
a Relying Party. To support this goal, we intend to avoid confusion of a 
Relying Party on how to react to such an Attestation Result. One of the 
means how we try to avoid such confusion is that "artificial 
classification". Its intent definitely is not to restrict the 
applicability of the Trustworthiness Claims - rather it is intended to 
ensure that for Relying Parties their meaning is simple and clear based 
on the capability sets of the Attester's various Attesting Environments. 
These groups/classifications are a first step towards that unambiguous 
clarity. I think it is quite possible to fall under more than one 
category. If that is the case, the only hard requirement here is that 
the resulting Trustworthiness Vector still makes sense to all Relying 
Parties and does not burden them with too complex requirements on 
Appraisal Policy for Attestation Result (yes, that is a bit of a 
mouth-full) overhead - which, if not available or to resource intensive 
to process, would leave a Relying Party none the wiser.

> 
> Full disclosure: I am in no way related to IBM but I do care about being 
> able to consume attestation results from a broad range of platforms.
> 
> Best regards,
> Nicolae
> 

Viele Grüße,

Henk

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 12 Aug 2021 13:30:54 +0000

Hi Nicolae,
Hi Henk,

Some more thoughts in-line...

> From: Henk Birkholz, August 12, 2021 6:42 AM
> 
> Hi Nicolae,
> 
> yes there is!
> 
> > <https://datatracker.ietf.org/doc/draft-voit-rats-attestation-results/
> > > if there is a GitHub repo for this document? I would like to open
> > some issues (and otherwise help improve the document).
> >
> >
> > Two issues:
> It is true that we started with a focus on the passport model and that was
> already noticed by Dave Thaler during one of the RATS sessions at the latest IETF
> meeting. That said, a lopsided focus on the passport model is not the actual
> intend here and we have to remediate that as feasible as possible.

As Dave T pointed out during the IETF 111 session, Figure 1 articulates a Hybrid model.   Both passport and hybrid viewpoints are required to deliver all the benefits articulated.

As we remediate the draft per Henk's note above, it is worth thinking about why we need to intertwine/entangle the Attester signature with the Verifier signature.  This is to prove both the freshness of the AR, and to prove the AR Augmented Evidence is actually coming from the *same* AR.  Such an intertwining/entanglement is not necessary when just the standard background-check is used, because the Relying Party can see the freshness of the independently delivered Evidence and AR. 

> > three general categories of Attesters: (1) HSM-based, (2)
> > process-based and (3) VM-based. This looks neat, but where do you add
> > solutions like IBM PEF, which uses both a TPM and firmware extensions
> > + an additional virtualisation element (ultravisor) to protect the
> > execution environment of the VM. My main concern is to avoid an
> > artificial classification that will cause trouble down the line.
> 
> The reason for classification here is to make digesting the Trustworthiness
> Vector defined in our document as simple as possible for a Relying Party. To
> support this goal, we intend to avoid confusion of a Relying Party on how to
> react to such an Attestation Result. One of the means how we try to avoid such
> confusion is that "artificial classification". Its intent definitely is not to restrict
> the applicability of the Trustworthiness Claims - rather it is intended to ensure
> that for Relying Parties their meaning is simple and clear based on the capability
> sets of the Attester's various Attesting Environments.
> These groups/classifications are a first step towards that unambiguous clarity. I
> think it is quite possible to fall under more than one category. If that is the case,
> the only hard requirement here is that the resulting Trustworthiness Vector still
> makes sense to all Relying Parties and does not burden them with too complex
> requirements on Appraisal Policy for Attestation Result (yes, that is a bit of a
> mouth-full) overhead - which, if not available or to resource intensive to
> process, would leave a Relying Party none the wiser.

Additionally the three classifications are in an Appendix.   This is done because we don't want to assert any normative text regarding potential future combinations/classifications.   If others in the WG want to assert new interpretations for the Appendices, that would be great.

Eric

> > Full disclosure: I am in no way related to IBM but I do care about
> > being able to consume attestation results from a broad range of platforms.
> >
> > Best regards,
> > Nicolae
> >
> 
> Viele Grüße,
> 
> Henk
> 
> >
> >