[Rats] Early AD Review of draft-ietf-rats-architecture-13

[Roman Danyliw <[e-mail]>]

Hi!

I was asked after IETF 111 to perform an early AD review of draft-ietf-rats-architecture-13.  I'm a little late, but below is my feedback:

** Section 1.  
   Conversely, systems that cannot be attested and verified to be in a
   good state can be taken out of service, or otherwise flagged for
   repair.

I was a bit surprised that the reduced trust/access motivation was not directly mentioned here given that it's the underlying use case of the two examples in the next paragraph and in Section 2.  I would have said something to the effect of:

NEW
Conversely, systems that cannot be attested and verified to be in a good state can be given reduced access or privileges, taken out of service, or otherwise flagged for repair.

** Section 2.1
   Network operators want a trustworthy report ... for purposes such as    inventory,
   audit, anomaly detection, record maintenance and/or trending reports
   (logging).

-- This seems like a list of unlike things - inventory and audit are activities.  Anomaly detection and trending reports are a technique for multiple purposes - is this better captured with a term like security operations?

-- What is "record maintenance"?  Isn't that the same as inventory or asset management?

** Section 2.7. Is the WG sure we need the last paragraph, "Other biometric authentication protocols ..." which cites various commercial services without citation.  Will that age well without references?  My recommendation would be to remove it.

** Section 3.1.  
   
There is no limit to or requirement on the types
   of hardware or software environments that can be used to implement an
   Attesting Environment, for example: Trusted Execution Environments
   (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules
   (TPMs) [TCGarch], or BIOS firmware.

To reinforce that software only solutions are acceptable too should 'software agent' or something to that effect be added to the following example list?

** Section 3.3.  Editorial. s/In consequence/Consequently,/

** Section 4.  The following terms appeared repeatedly in the document but were defined here: root of trust, target environment, and lead attester.  Should they be?

** Section 4.1. Relying Party.  Figure 1 says that the relying party also consume the "Appraisal Policy for Attestation Results" by that isn't noted here.

** Section 4.*.  Editorial.  
-- Section 4.1.  In the definition of relying party, what does the sentence fragment "Compare /relying party/ in [RFC4949]" mean?
-- Section 4.2.  Per the definition of "Claim", what does "Compare /claim/ in [RFC7519]" mean?
-- Section 4.3.  Per the definition of "Appraisal Policy for Attestation Results", what does "Compare /security policy/ in [RFC4949]" mean?

** Section 4.2.  Claim is the only definition that doesn't explicitly call out what "consumes" and "produces" it.

** Section 5. There is something foundational I am not following about this section.  The interactions described here do not conform behaviors described in the terminology in Section 4 or the high-level reference architecture of Figure 1.  I'm not sure how to reconcile this discrepancy.  

Minimally, these discrepancies are:

-- Figure 5.  Per Section 4, "Attestation Results" are not supposed to be consumed by the "Attester" and are supposed to come from the Verifier (not the Attester).

-- Figure 6, Evidence is being provided from the Attester to the Relying Party.  Relying part is providing evidence to the Verifier.

Additional sections in the document, e.g., Section 7.2, make use of this interactions too.

The introductory text states that "[t]he discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns."  I don't follow what is being illustrated in the context of RATS.  What is the takeaway for implementers or designers from this section?

** Section 5.1.
In this model, an Attester conveys Evidence to a Verifier, which
   compares the Evidence against its appraisal policy.  

Should the analogy be connected to the RATS architecture by saying the citizen is the Attester and the Evidence is ID (e.g., birth certificate) needed to present to get the passport issued.

** Section 5.1.  Per the paragraph, "Since the resource access protocol ...", I found this text an unexpected level of detail.  No earlier part of the document had previously discussed the existence of a serialization format or resource access protocol, let alone interoperability issues

** Section 7.1  I got a bit lost in the repeated use of the word trust as a verb, noun and adjective.  It seems like two properties should be described:
-
- (authenticity) Trusting that information came from a expected entity/role

-- (correctness) Having confidence in the veracity of the information being provided (e.g., the processes used by the verifier to process the evidence or compute ).

I'd recommend being clearer on what kind of trust is meant.

** Section 7.4.

   In a typical solution, a Verifier comes to trust an Attester
   indirectly by having an Endorser (such as a manufacturer) vouch for
   the Attester's ability to securely generate Evidence, in which case
   the Endorser's key material is stored in the Verifier's trust anchor
   store.

How does an Endorser "vouch" for something?

** Section 8.1
   Evidence is appraised by a Verifier to establish
   its relevance, compliance, and timeliness

What is meant by having to establish that evidence is relevant? Is the concern that the Attester would provide evidence that is not relevant?  Is than attack or attempt a subterfuge? 

** Section 8.1.
   Claims need to be
   collected in a manner that is reliable.

Can the intent of "reliable" be clarified here.

** Section 8.1.  In the spirit of inclusive terminology please use alternative phrasing for "man-in-the-middle attackers".

** Section 8.2.  This section is a subsection of Section 8 which seems to be scoped around "conceptual messages".  It isn't clear to me what "conceptual messages" or channel properties are being described here.

** Section 8.3.  It isn't clear to me what "conceptual messages" or channel properties are being described here.  This appears to be a restatement of the role of Reference Values already covered in Section 3.

** Section 8.4.

   Thus, Attestation Results often need to include detailed information
   about the Attester, for use by Relying Parties, much like physical
   passports and drivers licenses include personal information such as
   name and date of birth.  

I'm not convinced this analogy is helpful.  Yes, it conveys the need for detailed information but it also immediately suggests Attestation Results might include PII or privacy sensitive identifiers.

** Section 10.  I found the level of detail on this section on freshness out of place and inconsistent with the level of abstraction found in the rest of the test.  In most other section, generic interaction of roles, artifacts, their associated topologies, and high level security properties was noted.  This section delves into specific implementation choices.  In particular,  Is the WG sure that it needs all of the details of Section 10.3.  Even among all of the Section in 10.*, this stands out. It doesn't seem to provide enough detail to be create interoperability but goes beyond simply introducing the concept.  Section 12.3

** Section 11.  Is it possible for the Appraisal Policy for Evidence to also contain sensitive information?

** Section 11.
If
   confidentiality protection of the conceptual messages is omitted or
   unavailable, the protecting protocols that convey Evidence or
   Attestation Results are responsible for detailing what kinds of
   information are disclosed, and to whom they are exposed.

-- What is meant by "conceptional message" here?  


-- What does it mean that "the protecting protocols ... are responsible for detailing what kinds of information are disclosed?"
Is this text saying that if there isn't native object-level confidentiality protection in the Evidence and Attestation Results, the transport protocol should provide these protections?

-- Should the appraisal policies get similar protection?

** Section 11.  Typo. s/are disclosed/is disclosed/?

** Section 12.  I didn't come away from this section with a strong, consistent understanding of which interactions needs which security properties or what considerations are need for which roles.  Section 12.2 is at least clear on integrity, but it also makes vague allusions to other properties.  

-- Section 12.2  This section lists that there might be a need to support additional security properties and provides list (i.e., E2E encryption, DoS protection, authentication, etc.) .  What actionable guidance should be taken from this text?   How should one reason about those properties?

-- The overall Section 12 seems silent on:

o Endorsers and endorsements?
o Reference values?
o What is the implication of combining roles into a single entity as described in Section 3.4 and 6.  Does this lack of separation present any additional issues?
o Compositional devices per Section 3.3?

** Section 12.1.1
   An essential value-add provided by RATS is for the
   Relying Party to be able to trust the Attester even if the user or
   owner is not trusted.

Is it more accurate to say that an "A foundational security assumption of a RATS architecture is that a Relying Party is able to trust the Attester even if the user or owner is not trusted"

** Section 12.1.1.  Typo. s/Sometimes this is/Sometimes this/

** Section 12.1.2.  I didn't see any of the obvious text that regardless of whether the key is generated on or off device, high quality randomness is needed.

** Section 12.1.2.1.  Would it be more precise to say:

OLD
The degree of protection afforded to this key material can vary by
   device, based upon considerations as to a cost/benefit evaluation of
   the intended function of the device.  

NEW
The degree of protection afforded to this key material can vary by the intended function of the device and the specific practices of the device manufacturer or integrator.

** Section 12.1.2.1.  Editorial.

OLD
So, this is why, in general, ...

NEW
Commonly,

** Section 12.2.  Editorial.  The section title of "Integrity Protection" seems narrow given the content of this section.

** Section 12.2

Any solution that conveys information used for security purposes,
   whether such information is in the form of Evidence, Attestation
   Results, Endorsements, or appraisal policy ...

Should reference values be included?

** Section 12.2

   It is also important that the appraisal policy was itself obtained
   securely.  If an attacker can configure appraisal policies for a
   Relying Party or for a Verifier, then integrity of the process is
   compromised.

In addition to reconfiguration, wouldn't the ability to intercept either the appraisal policy for evidence or attestation results potentially provide the attacker insight into defensive mitigations?  This suggests that this policy might need confidentiality protection.

** Section 12.4.  Is there any read sensitivity for the trust anchor store?

** Section 12.4.  Since RFC5280 is being invoked here, is there an expectation that certificates in RATS would confirm to this profile?

Regards,
Roman