ietf-rats-wg / architecture Goto Github PK

Ned suggests that the term Measure be added to connect the Attested Environment and Attesting Environment.
There may be multiple Attested Environments that can measured by a single Attesting Environment (such as when there is a TPM, SGX, DICE).

Section 7.1 should start out with something more like "Evidence is made up of claims and usually signed by the attester"n (not signed by the device). It should say claims are being standardized. Should say "Evidence is always evaluated by a Verifier"

Based on https://mailarchive.ietf.org/arch/msg/rats/2rwmcm7pQICXN8lzlX21lEkb9Is/

OLD:

One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates to be applied.

NEW:

One significant problem is malware that holds a device hostage and does not allow it to reboot to prevent updates from being applied. Remote attestation aids in the verification process that may occur locally as well as it is less likely that the policy or verification processes have also been compromised if hosted on a separate system.

Early on, we need to explain what the composite evidence is.

Based on https://mailarchive.ietf.org/arch/msg/rats/2rwmcm7pQICXN8lzlX21lEkb9Is/

Appraisal Policy for Attestation Result: A set of rules that direct
how a Relying Party uses the Attestation Results regarding an
Attester generated by the Verifiers. Compare /security policy/ in
[RFC4949]

Kathleen's comment: I don't think direct is the right word. If this is so you can make judgments on relying party decisions, the policy is more of a statement on the decision process than how they are directed, which could be more subjective. The verifier here reads as if they generate the policy, but are verifying against a set policy.

Proposed:

A set of rules for a Relying Party to verify attestation results.

What should the label on the outer box be: Device or Composite Device or Attester or ...?

The architecture draft should say that known-good reference values can be either a part of an endorsement or part of an appraisal policy or both.

Based on https://mailarchive.ietf.org/arch/msg/rats/2rwmcm7pQICXN8lzlX21lEkb9Is/

Evidence: A set of information about an Attester that is to be appraised by a Verifier

Kathleen's comment: For evidence, should this definition be more about what evidence is rather than about the roles involved? The attester may not be the same component or system that attests to the evidence as well. Evidence could be measurement data, telemetry (e.g. counters on a system interface - YANG or SNMP), results of a policy comparison to configuration data).

Perhaps:

Evidence: Information about or originating from a system/firmware/software that may include configuration data, measurements, telemetry, or inferences.

Based on https://mailarchive.ietf.org/arch/msg/rats/2rwmcm7pQICXN8lzlX21lEkb9Is/

Attester: An entity whose attributes must be appraised in order to
determine whether the entity is considered trustworthy, such as
when deciding whether the entity is authorized to perform some
operation

Attester:
An entity (typically a device), whose Evidence must be appraised in order to infer the extent to which the Attester is considered trustworthy, such as when deciding whether it is authorized to perform some operation

Kathleen's comment: The 'definition' seems to get into role recommendations rather than being a definition. Shouldn't this stick to what an attester is/does?

Perhaps:

attester - entity who puts forth data that may include configuration or static system information, evidence, or claims. The evidence may be digitally signed.

Here's some possible text.

Endorser
The primary function of an Endorser is to endorse an Attester so that a Verifier can know to trust that Attester. The Endorser does this by creating an Endorsement and conveying it securely to the Verifier. The primary basis for a Verifier trusting an Attester is the Endorsement.

There is thus an existential relationship between Attesters and Endorsers. An Attester with no Endorsement is not worth very much since there is no good basis by which a Verifier can trust it so every Attester needs an Endorser. The Endorser’s primary function is to endorse Attesters so an Endorser doesn’t have anything to do without some Attesters to endorse.

A Verify cannot do its job without Endorsements. It must have an Endorsement for each Attester from which it received Attestation Evidence. Without this, the Attester is not trusted and there is no basis for trusting the Evidence it produces.

There is a trust triangle between the Endorser, Attester and Verifier. The Endorser tells the Verifier that an Attester is trustworthy.

Endorsement
Ultimately an Endorsement must be realized as some input bytes to a Verifier and they must be conveyed securely from the Endorser to the Verifier. RATS architecture does not impose any limit or restriction on the formats of these bytes or the conveyance mechanism. In practice they are expected to vary quite widely.

In most cases the Endorsement will include the key material that is used to verify signatures on the Evidence. Since the Evidence will contain a nonce, this signature verification serves to authenticate the attester. The Endorsement may also contain information about the Attester such as its type, version, manufacturer and such.

In one example, the Endorser and the Verifier are the same legal organization, so secure conveyance is entirely an internal issue for the organization. It may consist of one employee copying a set of public keys from computer in the company to another.

In another example, the Endorsement may take the form of a PKI hierarchy. The Endorser conveys a root certificate to the Verifier. The Endorser also creates per-attester certificates under that root. Those per-attester certificates are programmed into Attesters. The Attester sends them to the Verifier attached to the Evidence. There may be several levels of certificates in the PKI hierarchy. The Verifier walks the certificate chain to determine trust. Note in the case the abstract notion of Endorsement comes to the Verifier in two parts, one in an out-of-band secure conveyance or a root certificate and the other as the signed (self-securing) certificates from the Attester.

Unendorsed Attesters
The use of unendorsed Attesters is discouraged because there is no good basis for establishing trust in them. An unendorsed Attester may still have a signing key and produce signed evidence. A Verifier may choose to have some trust in the Evidence they produce by assuming they are trusted on first use (TOFU), building up trust over time after seeing a lot of presumably good attestation evidence, or because it is fed into a machine learning algorithm that correlates to known fraud. Rats architecture include any facilities, details or designs for this mode of use and explicitly considers it insecure.

Based on https://mailarchive.ietf.org/arch/msg/rats/2rwmcm7pQICXN8lzlX21lEkb9Is/

Kathleen's comment: Did you consider the more commonly used, "hygiene"?

Section 4.2 / 4.3 are conceptually similar hence should follow similar conventions for naming. If section 4.3 is about "Composite Device(s)" as it relates to attestation then section 4.2 is about "Layered Device(s)" as it relates to attestation. Section names should be similar. (Artifact of having different authors maybe?)
Figure 2 caption is "Layered Attester" while Figure 3 is "Conceptual Data Flow for a Composite Device".
It would make more sense for the section heading for 4.2 to be "Layered Device" or "Layered Device Attestation" (and "Composite Device Attestation") and figure 2 to be "Conceptual Data Flow for a Layered Device"

To be defined

See comments in #6

this term gets re-introduced here, without any annotation.
The appraisal policy are the rules on how to test the evidence.
Here, "Attestation" is the creation of the evidence
Often people use the term "Attestation" to refer to the whole process.
Suggestion that we should define this term somewhere, but maybe "Remote Attestation"?

@mcr
FIDO has NONE-Attestation-Type, where there is no assessment. TCG would call this Implicit Attestation. https://www.w3.org/TR/webauthn/#none-attestation

@mcr
Let's take this to the WG, and maybe we can not get consensus on this term.

@mcr
Charter says: "Remote
attestation procedures (RATS) enable relying parties to establish a level of
confidence in the trustworthiness of remote system components through the
creation of attestation evidence by remote system components and a processing
chain towards the relying party."

Since the resource access protocol between the Attester and Relying
Party includes an Attestation Result, in this model the details of
that protocol constrain the serialization format of the Attestation
Result. The format of the Evidence on the other hand is only
constrained by the Attester-Verifier attestation protocol. "So..."

Thomas suggests:

The current paragraph looks wrong to me. When it says:

[...] solely on the appraising entity, e.g., the Verifier (for Evidence),
or the Relying Party (for Attestation Results),`
should instead say:

[...] solely on the remote attestation protocol initiator, e.g., the
Relying Party (for Evidence or Attestation Results) and the Attester
(for Attestation Results).

The introduction section uses the phrase "role compositions and data flows" then mentions "Passport Model" as an example of a role composition.
In section 4.3 on Composite Device the second to last section describes "combinations of roles" using an example involving a Composite Device.

I think the architecture should have crisper understanding of two concepts a) "topological models" (as defined by the section 5 heading that describes Passport, BKC and Hybrid; b) "role composition" which ought to refer to the "combining of roles" by a given entity.

The terms "role composition" and "combining of roles" are too similar for them to have different meanings and "role composition" as an alias for "topological models" is unnecessary.

I suggest pulling the second to the last paragraph in section 4.3 into a new section 4.4 titled "Role Composition" that has a paragraph defining role composition conceptually followed by the paragraph taken from section 4.3.

Suggested Text for section 4.4:
RATS roles are implemented by entities (e.g., devices). A simple realization of the architecture associates a single role to a single entity; for example, the topological models described in section 5.1 and 5.2 follow this convention. However, entities may host multiple roles as a way to accommodate more sophisticated use cases and deployment scenarios. An entity that both connects to a wide-area network and to a system bus may play both Attester and Verifier roles. As a system bus entity, a Verifier consumes Evidence from other devices connected to the system bus that implement an Attester role. As a wide-area network connected entity, it may implement an Attester role. The entity, as a system bus Verifier, may choose to fully isolate its role as a wide-area network Attester. Alternatively, attestation results might reflect an aggregation of system bus operational state claims in the form of Evidence.

For example, in the Composite Device scenario, the lead Attester...
<paste remainder of paragraph from section 4.3>

Additionally, the introduction section should change "role composition" terminology to "topological models" as it references Passport.

For the sake of interoperability prefer some serialization formats over others. I would propose preference for CWT and JWT for Evidence and JWT for Results. This is only a preference not an exclusion of other serialization formats.

+-------------+            +-------------+               +-------------+
|             |----------->|             |-------------->|             |
|   Attester  |  Evidence  |   Verifier  |  Attestation  |   Relying   |
|             |            |             |     Result    |    Party    |
+-------------+            +-------------+               +-------------+
                           Compare Evidence              Compare Attestation
                           against Appraisal             Result against
                           Policy                        Appraisal Policy

In both the passport and background-check models, the Attester communicates directly with the Relying Party to access some resources. But in some cases, the Attester doesn't need to access resources from the Relying Party.
Assume that the Attester is a network device (router, switch, etc.), and the Relying Party is the network management system (NMS) of the network operator. In such a case, the NMS monitors the health of the device by retrieving the Attestation Result of the device from a Verifier. If the device fails the attestation process, the NMS can take countermeasures like quarantining it. So the figure above depicts this situation.

The more accurate text should be compliance or non-compliance.
And whatever the attestation result is, the attester should always present the attestation result to the relying party, I think.

new text from #82 requires some new Security Considerations text.

Section 3.1 of the draft says:

FIXME from Henk: Measurements at early stages of
Layered Attestation are NOT evidence yet.
This text does not cover that yet

This fixme needs to be fixed somehow.

PR #88 and PR #91 merged text that I had, and continue to have, problems with.

A summary of the problems follows:

1. It includes events (CC, RP) that are not used in any checks in the text. I had pointed this out before when the PR was generated, but the PR was merged without addressing this comment.
2. The section about using timestamps with synchronized clocks was removed and replaced with a section that talks about a different mechanism (handles) that is not in any RFC or WG document. I believe that such replacement is inappropriate. If the WG adopts a document that talks about a handle distribution mechanism, then a section can be added. Or if there is a standard from another org that can be referenced then it's fine to add one in that case too. But I think it should not replace the section discussing the well known technique of synchronized clocks (e.g., using secure NTP, or PTP (IEEE 1588-2002) or whatever other standard mechanism).
3. time(HD) is problematic as phrased since all the other events are times as seen by a single entity, whereas time(HD) does not clearly say whose perspective (i.e., whose clock) it is from... is it the distributor's? Text is unclear.
4. It talks about nonces in a timestamp section, which I think causes confusion since there's already a separately section about nonces and this section is labeled to be scoped to timestamps. Addressing #2 might address this naturally, if it uses a different section title.
5. There are some editorial typos, such as capital "The" in the middle of a sentence, etc.
6. I have no idea what "delta(time(HD),time(EG))distribution-interval" is supposed to mean. Normally I would expect an equality for any condition to be evaluated, but I have no idea what this check is.
7. time(HD) and time(EG) are according to different clocks (if my guess about point 3 above is right) and so the delta is not directly comparable. I'm not sure how point 6 accounts for this.
8. The phrase "A nonce not predictable to an Attester (recentness & uniqueness) is sent to an Attester" has "(recentness & uniqueness)" which doesn't read well (sounds like bad grammar) to me, and is not explained.

Kathleen's review part 2

Further privacy considerations:

• Remote attestation also provides a way to profile systems as well as the user behind that system.
• If attestation results go higher in the stack to include containers and applications, it could reveal even more about a system or user.
• The scope of access needs to be emphasized, including the administrators access to data (or restrictions).
• If there is a way to make inferences about attestations from their processing, that should be noted as well.

It seems to me the statement applies for both models (passport model and BC model).

Kathleen's review part 2

The following text is a little confusing, in particular, the last sentence:

"An execution environment may not, by default, be capable of claims collection for a given Target Environment. Attesting Environments are designed specifically with claims collection in mind."

If the attesting environment is a place, TEEs and other processors were not necessarily designed with claims in mind.  If you can help to explain an attesting environment better, I can help to phrase it more clearly to convey the intended set of points as I think there are several.

Taking into account the recent trends in terminology used in draft text & PR, I am proposing to add Entity and Sub-Entity to the terminology section. We do not need to over-specify here. Hence, only mentioning Composite Device and Components as an examplew for each of the terms in the definition text could be enough.

Are there any objections to this proposal? If not, we could create a PR and address it in next week's meeting.

Based on https://mailarchive.ietf.org/arch/msg/rats/2rwmcm7pQICXN8lzlX21lEkb9Is/

Kathleen's comment: Is the following definition necessary?

Verifier Owner: An entity, such as an administrator, that is
authorized to configure Appraisal Policy for Evidence in a
Verifier

Based on https://mailarchive.ietf.org/arch/msg/rats/2rwmcm7pQICXN8lzlX21lEkb9Is/

This typically works by having some protected environment in the
device attest to some manufacturer service. If remote attestation
succeeds, then the manufacturer service releases either the model, or
a key to decrypt a model the Attester already has in encrypted form,
to the requester.

Attester: A device desiring to run an ML model to do inferencing

Relying Party: A server or service holding ML models it desires to
protect

Kathleen's comment: I think it would help to talk about inferences in the written description. For the attester, if it's the whole system as opposed to a component, then then definition makes sense. I'm wondering if it is crisper when narrowed. RoT captures inferences of the ML modeling used as evidence. Does the relying party hold the ML model or knowledge of expected inferences? I'm happy to propose alternative text once I have more information to more fully understand the use case.

There may be a class of claims having to do with how RATS Roles convey RATS messages. This was first observed in the Composite Device where Evidence from a sub-device/sub-component 'transits' another attesting environment (aka lead Attester).

Another pattern seems to be emerging around the various message flow models (passport, bk check, hybrid(s)) where Evidence and Attestation Results are expected to transit different entities from those implied by the Roles architecture.

Should the architecture assert a preference for 'transited' claims as a way to flexibly attest these flows?

Concern over whether a Relying Party is allowed to check Evidence (which isn't envisaged by the Roles arch) is easily addressed by asserting that the entity hosting the Relying Party may also host a Verifier whose sole purpose is to Verify 'transited' claims and enforce an expected message flow model such as Passport, hybrid...

The architecture would take this approach rather than assert that implementations should invent various combinations of Evidence, AR and Endorsement with semantically important nesting conventions.

Not sure where in the doc this type of section should go. Could be sprinkled with sections that define models and complex devices or dealt with in a separate section.

Section 6 "Two Types of Environments of an Attester" gives the introduction to these terms, but they are used back in section 4.1 "Composite Attester".

Something needs to change either move section 6 up, or section 4.1 down.

When working #40, we realized that the Relying Party might be able to see the contents of the Evidence, or it might be possible to encrypt from Attester to Verifier.
We need to document what it means for there to be an arrow from box 1 to box 2.

Attestation Result is far more than compliance/non-compliance for many / most use cases. Attestation Results may contain lots claims that are passed through from the device (e.g., GPS location). I would also expect information from the Endorsement to be passed through, particularly in the case where the Verifier is an aggregator. Implied claims would also show up in the Attestation Result.

The current Section 4.2 text details a hypothetical example aimed at providing clarity of a presumably more abstract concept. However, the concept (illustrated by figure 2) hasn't been explained.

Suggested wording:
Attestation involving a layered device involves multiple Attesting Environments that collect claims from multiple Target Environments. Attestation "layering" exists when the Target Environment contains an Attesting Environment that collects claims for the next layer Target Environment. Layering forms a cascade of target and attesting environments starting with an anchor Attesting Environment (i.e., Figure 2 - Attesting Environment A) and ending with a leaf Target Environment (i.e., Figure 2 - Target Environment C). The leaf environment isn't expected to encapsulate an Attesting Environment. Any number of layered environments (i.e., Figure 2 - Target Environment B / Attesting Environment B) could exist between the anchor and leaf. A hardware execution environment establishes trust in the anchor Attesting Environment (see Section 4.1).

A Verifier relies on Endorsements for insight regarding trustworthiness of the anchor Attesting Environment. Verifiers may require Endorsements for all the environments. Each Attesting Environment generates Evidence for its respective Target Environment (i.e., Figure 2 - Layered Evidence for B and C).

Layering of Evidence means the first layer Attesting Environment (i.e., Figure 2 - Attesting Environment A) integrity protects Evidence B and the next layer Attesting Environment (i.e., Figure 2 - Attesting Environment B) integrity protects Evidence C.

Note:
I stopped short of describing use of keys for integrity protection, whether or not the same or different keys can be used or where the keys are stored / protected. By inference, the attesting environments either have them locally or can use them by keyID or some other way. I also stopped short of describing how the Verifier disambiguates Evidence B from Evidence C or how each evidence instance is attributed to its proper attesting environment. If it is important to describe this then maybe more words are needed?

I think the remainder of the section could more efficiently describe the BIOS / PC boot use case relying more on the terminology in Figure 2 to describe a mapping from the abstraction in Figure 2 to an example implementation.

Kathleen's review part 2

Since ROLIE [RFC8322] has been added to SCAP2.0, it would be good to list that as an option since a lot of time and effort went into how to secure the exchange of formatted data for that protocol.

In the 2nd paragraph of the Trust Model section, the third sentence is impossible for me to make sense of. Which trust relationships are addressed here and why should an Endorser consume Evidence - even in the case that a Verifier "acts" (also not the best choice of words) as an Attester?

Current Trust Model section states:

"a Verifier might be configured to implicitly trust firmware or even software (e.g., a hypervisor). That is, it might evaluate the trustworthiness of an application component, or operating system component or service, under the assumption that information provided about it by the lower-layer hypervisor or firmware is true. "

Would like to refine for the use of unsigned and potentially-unendorsed tokens. If the attestation token is received over a trusted link, e.g. one that the verifier has set up with the device that is anchored in an an RoT (e.g. cellular communications link), then the verifier may implicitly trust the information sent without the evidence itself being signed.

I don't think so, since it's just the RoTS and RoTR, but not the RoTM.
Opinions?

<this section can include content from Serialization Formats and Conceptual Messages sections from
draft-thaler-rats-architecture, and Role Messages content from draft-birkholz-rats-architecture>

otherwise, the section 4.1 including a lot of content about attester, attesting enviroment and target enviroment are not easy to understand.
Or, at least, have some general introduction or reference to section 6 about what is relation between them.

https://mailarchive.ietf.org/arch/msg/rats/huQUUnk96jS2Av4uO4pVBs_iMVs/

Eric and Dave will convert HTML table to pull request.

TEEP and others needs to know what kind of SLA RATS can provide.

To establish trust in a Verifier, Section 7 states that a Relying Party may require "information" about the Verifier:

Or, for a stronger level of security, the Relying Party might require that the Verifier itself provide information about itself that the Relying Party can use to assess the trustworthiness of the Verifier before accepting its Attestation Results

Section 7 states that an Endorser or Verifier Owner may establish trust in a Verifier by treating it as an Attester:

The Endorser and Verifier Owner may need to trust the Verifier before giving the Endorsement and Appraisal Policy to it. Such trust can also be established directly or indirectly, implicitly or explicitly. One explicit way to establish such trust may be the Verifier first acts as an Attester and creates Evidence about itself to be consumed by the Endorser and/or Verifier Owner as the Relying Parties. If it is accepted as trustworthy, then they can provide Endorsements and Appraisal Policies that enable it to act as a Verifier.

Topic 1: spec content. Why the differing levels of specifics? Is it intentional that the methods to establish trust is different for { Endorser, Verified Owner } and the Relying Party? I believe that the Relying Party may require Evidence from the Verifier to trust it, in fact, this is precisely how the Microsoft Azure Attestation Service (a Verifier) has been designed and implemented.

Topic 2: conceptual dataflow diagram. The conceptual dataflow diagram in the architecture spec does not currently reflect that the Verifier may also be an Attester and then share Evidence with the Endorser, Verifier Owner and Relying Party. Should it be updated? Or have a 2nd more complex diagram?

Topic 3: EAT. If accurate, I'd like to see a clear acknowledgement that the Verifier may need to act as an Attester for the Relying Party since I'd like to then see specifically how the IETF EAT specification covers this circumstance. In other words, for an EAT that represents an AttestationResult, would the Evidence for the Verifier be embedded or discovered? If embedded, how are submods distinguished for the Verifier's Evidence versus the AttestationResult's embedded claims, including nested EAT's?

This is for section 7.2 on Attester, 7.4 on Verifier and 7.5 the Endorser/Manufacturer.

The main trust flow for all of attestation is that the Verifier has a direct trust relationship with the Endorser/Manufacturer but not the Attester. The Endorser/Manufacturer supplies Input (e.g., an Endorsement containing key material) to the Verifier that allows the Verifier to come to trust the Attester.

In just about every use of attestation, there is no direct trust of the Attester by the Verifier. The Verifier doesn't directly trust the Attester's HW or SW as suggested by the text in 7.4. This text seems incorrect on one of the most fundamental attestation concepts.

Section 7.2 and 7.5 don't even discuss the primary transitive trust flow. They only address the secondary trust flow on confidentiality and privacy. While confidentiality and privacy are important they are not the primary reason that the Attester and Endorser exist.

"(via Internal Links or Network Connections)" is ambiguous.

Is it Internal (Links or Network Connections) or
(Internal Links) or (Network Connections)