Draft: draft-ietf-rats-architecture

Commentary: Coalesce a bunch of small edits suggested in our WGLC review [ 1 ] [ 1 ]
Mailing list commentary: Hi , all , This is our WGLC review of draft - ietf - rats - architecture-07 . Summary : The document is in fairly good shape and nearly ready to be shipped . A big thank you to all the people involved ! A few top - level points : 1 ) The split between Endorsements and Reference Values is not completely ironed out yet . Endorsements are not super clearly defined . This seems to be the only non - trivial missing piece . 2 ) The appendix on Handles needs some work to better clarify the concepts and simplify the flow . 3 ) It 'd be great to do something around Terminology and use cases . has proposed rationale for restructuring as well as text to address the identified issues in PR#164 [ 1 ] . We 'd be happy to help working on that until it can be merged . [ 1 ] 4 ) The prose is at times a bit prolix and could be streamlined , especially in places where style tends to obscure the information content . Detailed comments and editorial suggestions : [ Abstract ] Maybe define the term " attestation " before using it in the phrase " such remote attestation procedures " [ 1 . Introduction ] OLD This documents defines NEW This document defines OLD to enable implementers in order to choose appropriate solutions to compose NEW to enable implementers to choose appropriate solutions to compose OLD for Attestation Results : A set of rules that direct how a Relying Party uses the Attestation Results regarding an Attester generated by the Verifiers . ) for Attestation Results : A set of rules that directs how a Relying Party uses the Attestation Results generated by a Verifier . or , if the Attester has to be mentioned : NEW(b ) for Attestation Results : A set of rules that directs how a Relying Party uses the Attestation Results generated by a Verifier in response to appraisal of Evidence from an Attester . OLD [ ... ] integrity of an Attester 's various capabilities such as Claims collections and Evidence signing NEW [ ... ] integrity of an Attester 's ability to collect Claims and sign Evidence . OLD Relying Party : A role performed by an entity that depends on the validity of information about an Attester , for purposes of reliably applying application specific actions . NEW Relying Party : A role performed by an entity that depends on the trustworthiness of information about an Attester , for purposes of taking application specific decisions . [ 3.1 . Network Endpoint Assessment ] OLD [ ... ] version of information of the hardware and software NEW [ ... ] version information about the hardware and software In the sentence " [ ... ] record maintenance and/or trending reports ( logging ) " , it 's not clear what " trending reports " have to do with " logging " ? The para : Typically , solutions start with a specific component ( called a " root of trust " ) that provides device identity and protected storage for measurements . The system components perform a series of measurements is probably not a very accurate description of what happens with measured boot , i.e. , that the measurer itself has to be part of the RoT. It ca n't be a generic component whose measurements are ( blindly ? ) signed by the RoT. OLD the hardware , firmware , BIOS , software , etc . that is running . NEW the hardware , firmware , BIOS , software , etc . that is present . ( Using " present " because hardware is not strictly " running " . ) OLD Relying Party : A network infrastructure device such as a router , switch , or access point NEW Relying Party : A network infrastructure device such as a router , switch , or access point , responsible for admission of the device into the network . [ 3.2 . Confidential Machine Learning ( ML ) Model Protection ] OLD This typically works by having some protected environment in the device go through a remote attestation with some manufacturer service that can assess its trustworthiness . NEW This typically works by having the ML application request attestation evidence from the device and engage with the manufacturer to assess the trustworthiness of said evidence . [ 3.3 . Confidential Data Retrieval ] The para : An assessment of system state is made against a set of policies to evaluate the state of a system using attestations for the system requesting data . is not exactly crystal clear . What about : As part of attestation procedure , an assessment is made against a set of policies to evaluate the state of the system which is requesting the confidential data . [ 3.4 . Critical Infrastructure Control ] This section could be expanded to include the case where the roles are swapped : the sensor that provides critical input into a controller needs to provide evidence of its trustworthiness before the controller can comfortably act upon its stimulus ( e.g. , opening a valve . ) [ 3.5 . Trusted Execution Environment ( TEE ) Provisioning ] Maybe an information reference to TEEP could be here ? [ 3.6 . Hardware Watchdog ] There seems to be some confusion here : initially it is said that the " Relying Party is the watchdog timer in the TPM . " Subsequently , the Relying Party is defined as " A remote server that will securely grant the Attester [ ... ] " . So , what is it ? [ 3.7 . FIDO ] The definition of Relying Party : Any web site , mobile application back end or service that does biometric authentication . seems slightly inaccurate : the web site does n't do biometric auth . The authenticator binds biometric to crypto material so that the web site can deal with usual crypto auth . [ 4 . Architectural Overview ] In Figure 1 there should be a mention to the Reference Value Provider . OLD pppraisal policy to make application - specific decisions such as NEW appraisal policy to make application - specific decisions such as [ 4.2 . ] This seems to skip the relationship with the Reference Value Provider now that 's been split from the role , and also seems to muddle the distinction between Ref - Values and Endorsements ( i.e. , Ref - Values could be a subset of the information carried in an Endorsement . ) [ 4.3 . Two Types of Environments of an Attester ] OLD Other examples may exist , and the examples discussed could even be combined into even more complex implementations . NEW Other examples may exist . Besides , the examples discussed could be combined into even more complex implementations . OLD [ ... ] taking measurements on code or memory and so on of the Target Environment . NEW [ ... ] taking measurements on code , memory or other security related objects of the Target Environment " An execution environment [ ... ] " is introduced without a definition . It might be not self - evident . Is this an alias for TEE ? Or something else ? The content of this para : By definition , the Attester role creates Evidence . An Attester may consist of one or more nested or staged environments , adding complexity to the architectural structure . The unifying component is the root of trust and the nested , staged , or chained attestation Evidence produced . The nested or chained structure includes Claims , collected by the Attester to aid in the assurance or believability of the attestation Evidence . is a slightly confusing . What do we really want to say ? Also , " nested " , " staged " , " chained " : let 's pick one and stick with it ;-) OLD Figure 3 depicts an example of a device that includes ( A ) a BIOS stored in read - only memory in this example , ( B ) an updatable [ ... ] NEW The device in Figure 3 includes ( A ) a BIOS stored in read - only memory , ( B ) an updatable [ ... ] OLD Therefore , these Claims have to be measured securely . NEW Therefore , the relevant Claims have to be measured securely . This para : In general , the number of layers may vary by device or implementation , and an Attesting Environment might even have multiple Target Environments introduces the capitalised " Attesting Environment " and " Target Environment " . Do they deserve their own entry in the Terminology section ? [ 4.5 . Composite Device ] WRT the trust model of a composite device : it looks like the lead attester needs to be trusted to collect the most fresh evidence from the other slots ? Is this discussed anywhere ? In this para : After collecting the Evidence of other Attesters , this inside Verifier uses Endorsements and appraisal policies Should n't Endorsements be Ref - Values instead ? [ 5 . Topological Models ] The three sentences " There are multiple [ ... ] " , " This section includes [ ... ] " and " This is not intended [ ... ] " are slightly vague . It does n't seem to me that their information content is enough to justify them being independent sentences . Maybe they should be combined ? [ 5.1 . Should this section have a forward ref to the freshness section , or otherwise discuss the freshness of the attestation results ? This para : There are three ways in which the process may fail . First , the Verifier may refuse to issue the Attestation Result due to some error in processing , or some missing input to the Verifier . The second way in which the process may fail is when the Attestation Result is examined by the Relying Party , and based upon the appraisal policy , the result does not pass the policy . The third way is when the Verifier is unreachable . not sure why is this relevant ? [ 5.2 . Background - Check Model ] The para : Hence , the ability to let the Relying Party obtain an Attestation Result [ ... ] seems to reshuffle the content of the preceding one . The two can be combined / streamlined . [ 5.3 . Combinations ] It is also worth pointing out that the choice of model is generally up to the Relying Party I ' m not sure it " is up to the RP " , rather it " depends on the RP " because it 's typically not a choice of the RP but of the use case / protocol flow in which the RP operates . [ 6 . Roles and Entities ] This sentence : An entity in the RATS architecture includes at least one of the roles defined in this document . creates a bit of cognitive dissonance : in the Terminology section the Endorser , Ref - val Provider , RP Owner and Verifier Owner are defined as " entities " , however , they do n't include any of the roles ( Verifier , RP , Attester ) . In the sentence : Alternative channels to convey conceptual messages [ ... ] maybe insert a forward reference to Section 8 ( conceptual messages ) . OLD As a system bus entity , [ ... ] NEW As a system bus - connected entity , [ ... ] [ 7.1 . Relying Party ] OLD The scope of this document is scenarios for which a Relying Party [ ... ] NEW This document covers scenarios for which a Relying Party [ ... ] [ 7.2 . OLD The Verifier might share this information with other authorized parties , according to rules that it controls . NEW The Verifier might share this information with other authorized parties , according to some predefined rules . OLD In some cases where Evidence contains sensitive information , an Attester might even require that a Verifier first go through a TLS authentication or a remote attestation procedure with it before the Attester will send the sensitive Evidence . NEW When Evidence contains sensitive information , an Attester typically requires that a Verifier authenticates itself ( e.g. , at TLS session establishment ) , and might even require a remote attestation before the Attester sends the sensitive Evidence . [ 7.4 . OLD is critical to the secure operation an Attestation system , NEW is critical to the secure operation of an Attestation system , [ 8.2 . Endorsements ] This section does n't provide a clear and concise definition of what is meant by Endorsement . Instead it goes in depth discussing the rather tangent topic of access authorisation based on one kind of Endorsement . I suggest this section is re - shaped to discuss : What is an endorsement conceptually ; Why we need to make it a first class object distinct from ref - values and other inputs to the verifier ; A few instances of Endorsements ; One example usage in the attestation workflow [ 8.3 . ] OLD may be a Boolean simply indicating compliance or non - compliance with a Verifier 's appraisal policy , or a rich set of Claims about the Attester NEW may carry a boolean value indicating compliance or non - compliance with a Verifier 's appraisal policy , or a richer set of Claims about the Attester This para : In some cases , it may even indicate that the Evidence itself can not be authenticated as being correct What does " authenticated as being correct " mean ? I suggest dropping the paragraph altogether . OLD The simplest such policy might be to simply authorize any party supplying a compliant Attestation Result NEW The simplest such policy might be to authorize any party supplying a compliant Attestation Result But taking a step back , the whole para : The simplest such policy might be to simply authorize any party supplying a compliant Attestation Result signed by a trusted Verifier . A more complex policy might also entail comparing information provided in the result against   , or applying more complex logic on such information . does not seem to provide useful information , so maybe another option is to drop it altogether . OLD Thus , Attestation Results often need to include detailed information NEW Thus , may need to include detailed information In the sentence : Finally , whereas Evidence is signed by the device ( or indirectly by a manufacturer , if are used ) , [ ... ] I ' m not sure what " or indirectly by a manufacturer , if are used " means ? Is it that Endorsement has the very tight meaning of the " certificate of the device signing key signed by the manufacturer " ? If so , can we make this explicit in the Endorsements section ? [ 9 . Claims Encoding Formats ] This sentence : To enable remote attestation to be to existing protocols , enabling a higher level of assurance against malware for example , it is important that information needed for appraising the Attester be usable with existing protocols that have constraints around what formats they can transport . it 's quite hard to digest . But more generally , the motivating use case ( OPC UA ) is slightly convoluted , and I ' m wondering whether it is really needed ? But assuming it were , the exposition needs to be improved to present a clear and compelling case . [ 12.1.1 . On - Device Attester and Key Protection ] OLD [ ... ] a dedicated chip a TEE or such that [ ... ] NEW [ ... ] a dedicated chip , a TEE or such that [ ... ] [ 12.2 . Integrity Protection ] 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 , NEW Any solution that conveys information used for security purposes , whether such information is in the form of Evidence , Attestation Results , Endorsements , Reference Values or appraisal policy , must support end - to - end integrity protection and replay attack prevention , [ 16.3 . Example 3 : Handle - based I have a bunch of nits on this but I think the whole section lacks clarity and conciseness . I 'd be happy to help with a makeover . cheers !
Paragraph (version A):
Network operators want a trustworthy report that includes identity
and version of information of 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).  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.  Remote attestation is desired to prevent vulnerable or
compromised devices from getting access to the network and
potentially harming others.
Paragraph (version B):
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).  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.  Remote attestation is desired to prevent vulnerable or
compromised devices from getting access to the network and
potentially harming others.
Paragraph (version A):
Typically, solutions start with a specific component (called a "root
of trust") that provides device identity and protected storage for
measurements.  The system components perform a series of measurements
that may be signed by the root of trust, considered as Evidence about
the hardware, firmware, BIOS, software, etc. that is running.
Paragraph (version B):
Typically, solutions start with a specific component (called a "root
of trust") that provides device identity and protected storage for
measurements.  The system components perform a series of measurements
that may be signed by the root of trust, considered as Evidence about
the hardware, firmware, BIOS, software, etc. that is present.
Paragraph (version A):
This is a generalization of the ML model use case above, where the
data can be any highly confidential data, such as health data about
customers, payroll data about employees, future business plans, etc.
An assessment of system state is made against a set of policies to
evaluate the state of a system using attestations for the system
requesting data.  Attestation is desired to prevent leaking data to
compromised devices.
Paragraph (version B):
This is a generalization of the ML model use case above, where the
data can be any highly confidential data, such as health data about
customers, payroll data about employees, future business plans, etc.
As part of the attestation procedure, an assessment is made against a
set of policies to evaluate the state of the system that is
requesting the confidential data.  Attestation is desired to prevent
leaking data to compromised devices.
Paragraph (version A):
An Attester consists of at least one Attesting Environment and at
least one Target Environment.  In some implementations, the Attesting
and Target Environments might be combined.  Other implementations
might have multiple Attesting and Target Environments, such as in the
examples described in more detail in layered-attestation and
compositedevice.  Other examples may exist, and the examples
discussed could even be combined into even more complex
implementations.
Paragraph (version A):
Claims are collected from Target Environments, as shown in twotypes-
env.  That is, Attesting Environments collect the values and the
information to be represented in Claims, by reading system registers
and variables, calling into subsystems, taking measurements on code
or memory and so on of the Target Environment.  Attesting
Environments then format the claims appropriately, and typically use
key material and cryptographic functions, such as signing or cipher
algorithms, to create Evidence.  There is no limit to or requirement
on the places that an Attesting Environment can exist, but they
typically are in Trusted Execution Environments (TEE), embedded
Secure Elements (eSE), and BIOS firmware.  An execution environment
may not, by default, be capable of claims collection for a given
Target Environment.  Execution environments that are designed to be
capable of claims collection are referred to in this document as
Attesting Environments.
Paragraph (version B):
An Attester consists of at least one Attesting Environment and at
least one Target Environment.  In some implementations, the Attesting
and Target Environments might be combined.  Other implementations
might have multiple Attesting and Target Environments, such as in the
examples described in more detail in layered-attestation and
compositedevice.  Other examples may exist.  Besides, the examples
discussed could be combined into even more complex implementations.
Paragraph (version B):
Claims are collected from Target Environments, as shown in twotypes-
env.  That is, Attesting Environments collect the values and the
information to be represented in Claims, by reading system registers
and variables, calling into subsystems, taking measurements on code,
memory, or other security related assets of the Target Environment.
Attesting Environments then format the claims appropriately, and
typically use key material and cryptographic functions, such as
signing or cipher algorithms, to create Evidence.  There is no limit
to or requirement on the places that an Attesting Environment can
exist, but they typically are in Trusted Execution Environments
(TEE), embedded Secure Elements (eSE), and BIOS firmware.  An
execution environment may not, by default, be capable of claims
collection for a given Target Environment.  Execution environments
that are designed to be capable of claims collection are referred to
in this document as Attesting Environments.
Paragraph (version A):
layered depicts an example of a device that includes (A) a BIOS
stored in read-only memory in this example, (B) an updatable
bootloader, and (C) an operating system kernel.
Paragraph (version A):
Attesting Environment A, the read-only BIOS in this example, has to
ensure the integrity of the bootloader (Target Environment B).  There
are potentially multiple kernels to boot, and the decision is up to
the bootloader.  Only a bootloader with intact integrity will make an
appropriate decision.  Therefore, these Claims have to be measured
securely.  At this stage of the boot-cycle of the device, the Claims
collected typically cannot be composed into Evidence.
Paragraph (version B):
The device illustrated in layered includes (A) a BIOS stored in read-
only memory, (B) an updatable bootloader, and (C) an operating system
kernel.
Paragraph (version B):
Attesting Environment A, the read-only BIOS in this example, has to
ensure the integrity of the bootloader (Target Environment B).  There
are potentially multiple kernels to boot, and the decision is up to
the bootloader.  Only a bootloader with intact integrity will make an
appropriate decision.  Therefore, the Claims relating to the
integrity of the bootloader have to be measured securely.  At this
stage of the boot-cycle of the device, the Claims collected typically
cannot be composed into Evidence.
Paragraph (version A):
For example, an entity that both connects to a wide-area network and
to a system bus is taking on both the Attester and Verifier roles.
As a system bus entity, a Verifier consumes Evidence from other
devices connected to the system bus that implement Attester roles.
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.
Paragraph (version B):
For example, an entity that both connects to a wide-area network and
to a system bus is taking on both the Attester and Verifier roles.
As a system bus-connected entity, a Verifier consumes Evidence from
other devices connected to the system bus that implement Attester
roles.  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.
Paragraph (version A):
The scope of this document is scenarios for which a Relying Party
trusts a Verifier that can appraise the trustworthiness of
information about an Attester.  Such trust might come by the Relying
Party trusting the Verifier (or its public key) directly, or might
come by trusting an entity (e.g., a Certificate Authority) that is in
the Verifier's certificate chain.
Paragraph (version B):
This document covers scenarios for which a Relying Party trusts a
Verifier that can appraise the trustworthiness of information about
an Attester.  Such trust might come by the Relying Party trusting the
Verifier (or its public key) directly, or might come by trusting an
entity (e.g., a Certificate Authority) that is in the Verifier's
certificate chain.
Paragraph (version A):
In some scenarios, Evidence might contain sensitive information such
as Personally Identifiable Information.  Thus, an Attester must trust
entities to which it conveys Evidence, to not reveal sensitive data
to unauthorized parties.  The Verifier might share this information
with other authorized parties, according to rules that it controls.
In the background-check model, this Evidence may also be revealed to
Relying Party(s).
Paragraph (version A):
In some cases where Evidence contains sensitive information, an
Attester might even require that a Verifier first go through a TLS
authentication or a remote attestation procedure with it before the
Attester will send the sensitive Evidence.  This can be done by
having the Attester first act as a Verifier/Relying Party, and the
Verifier act as its own Attester, as discussed above.
Paragraph (version B):
In some scenarios, Evidence might contain sensitive information such
as Personally Identifiable Information (PII) or system identifiable
information.  Thus, an Attester must trust entities to which it
conveys Evidence, to not reveal sensitive data to unauthorized
parties.  The Verifier might share this information with other
authorized parties, according to a governing policy that address the
handling of sensitive information (potentially included in Appraisal
Policies for Evidence).  In the background-check model, this Evidence
may also be revealed to Relying Party(s).
Paragraph (version B):
When Evidence contains sensitive information, an Attester typically
requires that a Verifier authenticates itself (e.g., at TLS session
establishment) and might even request a remote attestation before the
Attester sends the sensitive Evidence.  This can be done by having
the Attester first act as a Verifier/Relying Party, and the Verifier
act as its own Attester, as discussed above.
Paragraph (version A):
The Verifier is provided with an appropriate trust anchor, or
provided with a database of public keys (rather than certificates),
or even carefully secured lists of symmetric keys.  The nature of how
the Verifier manages to validate the signatures produced by the
Attester is critical to the secure operation an Attestation system,
but is not the subject of standardization within this architecture.
Paragraph (version B):
The Verifier is provided with an appropriate trust anchor, or
provided with a database of public keys (rather than certificates),
or even carefully secured lists of symmetric keys.  The nature of how
the Verifier manages to validate the signatures produced by the
Attester is critical to the secure operation of an Attestation
system, but is not the subject of standardization within this
architecture.
Paragraph (version A):
Attestation Results may be a Boolean simply indicating compliance or
non-compliance with a Verifier's appraisal policy, or a rich set of
Claims about the Attester, against which the Relying Party applies
its Appraisal Policy for Attestation Results.
Paragraph (version B):
Attestation Results may carry a boolean value indicating compliance
or non-compliance with a Verifier's appraisal policy, or may carry a
richer set of Claims about the Attester, against which the Relying
Party applies its Appraisal Policy for Attestation Results.
Paragraph (version A):
The security of conveyed information may be applied at different
layers, whether by a conveyance protocol, or an information encoding
format.  This architecture expects attestation messages (i.e.,
Evidence, Attestation Results, Endorsements and Policies) are end-to-
end protected based on the role interaction context.  For example, if
an Attester produces Evidence that is relayed through some other
entity that doesn't implement the Attester or the intended Verifier
roles, then the relaying entity should not expect to have access to
the Evidence.
Paragraph (version B):
The security of conveyed information may be applied at different
layers, whether by a conveyance protocol, or an information encoding
format.  This architecture expects attestation messages (i.e.,
Evidence, Attestation Results, Endorsements, Reference Values, and
Policies) are end-to-end protected based on the role interaction
context.  For example, if an Attester produces Evidence that is
relayed through some other entity that doesn't implement the Attester
or the intended Verifier roles, then the relaying entity should not
expect to have access to the Evidence.
Paragraph (version A):
Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica
Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade,
Paul Rowe, Hannes Tschofenig, Frank Xia, and David Wooten.
Paragraph (version B):
Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica
Fitzgerald-McKay, Diego Lopez, Laurence Lundblade, Paul Rowe, Hannes
Tschofenig, Frank Xia, and David Wooten.