Re: [Rats] RATS Architecture Document Review

[Henk Birkholz <[e-mail]>]

Hi Kathleen,

thank you very much for the timely feedback! I'll create an editorial 
branch in github next week and will transplant your comments into the 
issue tracker so they can be addressed in the same branch.

Viele Grüße,

Henk

On 26.02.21 23:23, Kathleen Moriarty wrote:
> Greetings!
> 
> I reviewed the RATS Architecture document with the intent of progressing 
> this to last call soon as the document shepherd.  The document has come 
> a long way since my first and second detailed reviews, thank you all 
> very much for all the work that has been put into this document!
> 
> Here is my current set of comments, which do not include the Appendix.  
> I will have to read that in the next few days.
> 
> This should be quick to get through as text is suggested in most cases, 
> it may appear long, but really is not.
> 
> IETF RATS Architecture Review
> 
> Abstract:
> The abstract limits remote attestation to network protocols and 
> assessing peers.  A major use for it will be posture assessment, which 
> could be a management station that collects and verifies the evidence.  
> Let's work this into the abstract so that the solution is not viewed as 
> constrained as the abstract suggests.  How about:
> 
> OLD:
>   In network protocol exchanges it is often the case that one entity
>     requires believable evidence about the operational state of a remote
>     peer.  Such evidence is typically conveyed as claims about the peer's
>     software and hardware platform, and is subsequently appraised in
>     order to assess the peer's trustworthiness.  The process of
>     generating and appraising this kind of evidence is known as remote
>     attestation.  This document describes an architecture for remote
>     attestation procedures that generate, convey, and appraise evidence
>     about a peer's operational state.
> 
> NEW:
>     It is often the case that one entity
>     requires believable evidence about the operational state of a remote
>     peer.  Such evidence is typically conveyed as claims about the peer's
>     software and hardware platform, and is subsequently appraised in
>     order to assess the peer's trustworthiness.  The process of
>     generating and appraising this kind of evidence is known as remote
>     attestation.  This document describes an architecture for remote
>     attestation procedures that generate, convey, and appraise evidence
>     about a peer's operational state.
> 
> Introduction:
> NIT: RATS is provided as an acronym and used, but then the text reverts 
> back to the expanded text.  Choose how you'd like to do this an be 
> consistent.
> 
> Section 2.1:
> NIT:
> Network operators is too limited as others want this information as 
> well.  Suggest changing
> S/Network operators/Organizations/
> OLD:
> Network operators want a trustworthy report that includes identity
>     and version information about the hardware and software on the
>     machines attached to their network, for purposes such as inventory,
>     audit, anomaly detection, record maintenance and/or trending reports
>     (logging).
> NEW:
> Organizations want a trustworthy report that includes identity
>     and version information about the hardware and software on the
>     machines attached to their network, for purposes such as inventory,
>     audit, anomaly detection, record maintenance and/or trending reports
>     (logging).
> OLD:
> The network operator may also want a policy by which full
>     access is only granted to devices that meet some definition of
>     hygiene, and so wants to get Claims about such information and verify
>     its validity.
> NEW:
> An operator may also want a policy by which full
>     access is only granted to devices that meet some definition of
>     hygiene, and so wants to get Claims about such information and verify
>     its validity.
> 
> If this should be more generally readable, then removing the network 
> focus here would help a general reader who might be concerned with 
> lateral movement between applications rather than "access to the 
> network".  We no longer advise a mushy core (e.g. zero trust 
> architecture), so I suggest the following word changes:
> 
> OLD:
> Remote attestation is desired to prevent vulnerable or
>     compromised devices from getting access to the network and
>     potentially harming others.
> NEW:
> Remote attestation is desired to prevent vulnerable or
>     compromised devices from gaining further access and
>     potentially harming others.
> 
> Section 11:
> NIT:
> Remove the closing paren in the second paragraph as there is no opening 
> parentheses.
> "Many claims in Attestation Evidence and Attestation Results are
>     potentially Personally Identifying Information) depending"
> 
> The privacy section should also include a requirement for transport 
> security protections via TLS, cTLS, DTLS, EDHOC/OSCOAP, IPsec to ensure 
> only the intended party can access the content (unless that intended 
> party has been compromised).
> 
> Section 12.1.1:
> It might be worth calling out that this process could all occur on a 
> single system.  It reads as if that's the case for this section and 
> you'll have an IESG with diverse backgrounds reading this.
> 
> This seems to be conflating use cases for cryptography:
> "Cryptography can also be used to support confidentiality, but keys
>     that are used to then provision attestation keys must somehow have
>     been provisioned securely beforehand (a recursive problem)."
> It would be good to separate out encryption for transport and 
> cryptographic protections for attestation at the object level or even 
> the attestation keys for signing processes.  It would be important to 
> have this read well.
> You could mention transport level encryption, then a discussion on 
> attestation keys and options for advanced provisioning (by hand is 
> certainly an option for secure systems or mention the burn in process 
> for TPMs by the manufacturer as an example.
> Perhaps include an example of how attestation keys might be provisioned 
> to a TEE for use cases where the TEE is the attester.
> 
> Section 12.2
> Integrity protections should mention digital signatures over the 
> evidence for the attestation.  It may be obvious to the authors, but not 
> to all readers.  This should come before the other mentioned 
> protections.  The first sentence should be split in two to make this 
> possible and to shorten the sentence.
> OLD:
>   Any solution that conveys information used for security purposes,
>     whether such information is in the form of Evidence, Attestation
>     Results, Endorsements, or appraisal policy must support end-to-end
>     integrity protection and replay attack prevention, and often also
>     needs to support additional security properties, including:
> NEW:
>   Any solution that conveys information used for security purposes,
>     whether such information is in the form of Evidence, Attestation
>     Results, Endorsements, or appraisal policy must support end-to-end
>     integrity protection and replay attack prevention.  Cryptographic 
> digital
> signatures provide integrity protection, enabling verification that the 
> data has not been altered since it was signed.  Solutions often
>     need to support additional security properties, including:
> 
> A leap is made to the following paragraph and the reader will have 
> trouble figuring out why it's there.  Tie the following to an 
> explanation of how one might know this information on whether the RoT is 
> mutable or not and explain the cryptographic keys and functions are 
> stored/performed in the RoT, digital signatures are applied within the 
> RoT.  This will explain the relevance to the integrity section.
> 
> "   To assess the security provided by a particular appraisal policy, it
>     is important to understand the strength of the root of trust, e.g.,
>     whether it is mutable software, or firmware that is read-only after
>     boot, or immutable hardware/ROM.
> 
>     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."
> 
> 12.3:
> Make sure the text on transport encryption is added and fuller 
> explanations on when you may or may not need transport encryption.  It 
> can be in the other section where I pointed this out and then put a 
> reference to it from this text:
>    "To mitigate this threat, the transport should be at least integrity
>     protected and provide origin authentication."
> 
> In a coherent section, discuss the physical security options, use cases 
> within a single system, protected and physically isolated networks, and 
> then any other use case requiring transport encryption.
> 
> -- 
> 
> Best regards,
> Kathleen
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>