[Rats] Comments on draft-birkholz-rats-architecture-01

[Giridhar Mandyam <[e-mail]>]

Please note that these comments are not meant as a response to any call-for-adoption of this document.

Thanks to the editors for preparing this document.  It was an interesting read.  That being said, I had some brief and initial follow-up.  After I conduct a more detailed review, I may send more follow-up comments/questions.


  1.  This document [1] is listed as "Standards Track" and is not listed as "Informational" .  I am wondering what that means in practice, as I would assume a standards track document would address areas where interoperability is required.  I am having trouble identifying where in the document there is any actual specification that affects interoperability (e.g. protocol requirements between the actors defined in Sec. 4).  So what is the intention behind requiring this document to be standards track?  Does it mean that if I set up a remote attestation solution that does not follow the architecture defined in Section 2, then I am doing it wrong?
  2.  Subsequently, I compared this document to another security architecture document on standards track in the IETF, namely the RTCWeb sec. arch. draft [2],  Note that there are several areas crucial to WebRTC interoperability that are defined in [2], particularly in the usage of the SDP identity attribute (also defined in this document - see [3] for the IANA registry reference).  As a result, there are several 'MUST' requirements in this document.
     *   In contrast, [1] has zero "MUST" or even "SHOULD" requirements.  So what is being defined here that is standards track?  Could this instead be an informative document that is not standards track, like the Use Cases?
  3.  The term "appraise" is used in the document without defining the role of an appraiser and the target of appraisal.  This is unfortunate and is not consistent with previously-published work on attestation.  For instance, [4] offers the following definitions:  "An appraiser is a party, generally a computer on a network, making a decision about some other party or parties. A target is a party about which an appraiser needs to make such a decision."  The authors go on to comment, "We refer to the decision-making party as an appraiser rather than a verifier to emphasize that the decision-making process is a matter of evaluating the target against the appraiser's internal standards, rather than proving the target's correctness."
     *   I contrast this with [1], where appraisal seems to be the sole responsibility of the verifier.  Forcing appraisal to be part of verification means that all attestation appraisals will be tied into verification.  Therefore it can be assumed that a successful verification is required for appraisal, when in many cases it is not.
  4.  Sec. 4.1.1:  Attester Duties.  Amongst them, "Acquisition or collections of assertions about itself".  What constitutes 'itself' in this case?
     *   Note another terminology definition in [4]:  "Attestation is the activity of making a claim to an appraiser about the properties of a target by supplying evidence which supports that claim. An attester is a party performing this activity. An appraiser's decision-making process based on attested information is appraisal."

                                                               i.      There is no requirement that attester and target be the same in this definition, while [1] seems to require that the attester can only make claims about 'itself'.

     *   Note that if the attester and target have to be one and the same, then this excludes certain architectures that may be required for limited-resource devices that are simply unable to make claims about themselves.  For instance, in [5] (apologies in advance for being self-referential), an architecture is described wherein an IoT gateway constructions attestations on behalf of attached devices for a relying party based on network observations.
  1.  Sec. 3.1.  The role of the verifier in appraisal.  Note that [4] goes on to state that "A given target may wish to provide different information to different appraisers depending on the current trust relationships it has with those parties." The definition of the verifier does not cover multiple appraisers.
     *   An individual relying party may actually execute different levels of appraisal, depending on the type of authorization it wants to provide.  An example could be an RP that allows access to its service for a successfully-verified attestation where all claims are as expected, but requires step-up authentication for a successfully-verified attestation where certain claims do not meet the appraisal criteria (e.g. target's SW version is not at the tip, target's location is outside a permissible geofence).
  2.  Sec. 3.1.  Authentication Checker.  I tried to determine whether an Authentication Checker can fulfil the role of an appraiser, but I don't see how this is possible.
     *   "The consumer ... that assesses the trustworthiness or other trust relationships of the information consumed via trusted third parties or external trust authorities ...".  This sentence seems to restrict assessment as being only based on information provided only by external or 3rd-parties.  If the RP and the manufacturer of the target are one and the same, this seems to be unnecessary.

                                                               i.      Note that in my reading of [4], no such restriction is proposed.  However, this paper focuses on the TPM-model for attestation and therefore in its examples tends to assume the use of external CA's.

  1.  Privacy:  The role of privacy considerations in an attestation architecture should ideally be addressed.  There is a mention of a privacy CA in the definition of Authentication Checker, but the use of a privacy CA is only one option and is often undesirable for many service providers.
     *   FIDO defined the role of a "none" attestation statement [6], to allow RP's to avoid undesired exposure to information that could be used for device fingerprinting, user tracking, etc.  Any reference architecture should be able to accommodate a none attestation as a means of preserving privacy.
  2.  There is no definition of attestation delegation or definition of an attestation proxy as an actor or architectural component in the current draft.  I contrast this to [7], where Section 5.4 clearly defines these concepts and demonstrates their usage in the context integrating trusted 3rd-parties in attestation verification and appraisal.
     *   This kind of operational model may be depicted in the example of Section 6.1.  If so, why not use the terms-of-art such as 'attestation proxy' or 'attestation delegation'?
     *   The use of attestation proxies may be addressed in Section. 7.1 ("lying endpoint"), but it is not clear how an RP distinguishes between a lying endpoint and a trusted system.

                                                               i.      I interpret the guidance in Section 7.2 to actually discourage the use of attestation proxies:  "Remote Attestation argues that a systems's integrity characteristics should not be  believed until rationale for believability is presented to the relying party seeking to interact with the system."  This means that the RP must have access to all aspects of the 'rationale' and cannot simply consume a 'yes/no' indication from a trusted 3rd-party.

  1.  Has this document been compared to the TEEP reference architecture [8]?    I have done a very superficial comparison, but I expect that if the group adopts [1] then the TEEP architecture will evolve to be consistent with the RAts architecture.
     *   Note that the status of the TEEP arch. draft is "Informational".  Maybe the RAts architecture should be as well.
     *   Sec. 7.1 of [8] specifically requires signature non-repudiation.  I could not find an equivalent requirement in [1].  Is there a reason why non-repudiation is not required for the RAts architecture?

                                                               i.      If such a requirement is in [1] but is worded differently from [8], please point me to it.

     *   Sec. 5.3 of [8] states "... the TEEP Broker provides connections from the TEE and the Client App to one or more TAMs.  The selection of which TAM to communicate with is dependent on information from the Client App and is directly related to the TA."

                                                               i.      Since the TEEP Broker plays a critical role in conveyance of the attestation information to the correct TAM, it seems to me that there should be a similar entity defined in the attestation target of the RAts architecture that would determine how and to which endpoint the attestation is conveyed.

[1] https://www.ietf.org/id/draft-birkholz-rats-architecture-01.txt.
[2] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20.
[3] https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml.
[4] Coker, George et al.  "Principles of Remote Attestation."  International Journal on Information Security.  Vol. 10.  No .2.  2011.  pp. 63-81.
[5] Mandyam, G.  IEEE/ACM International Conference on Communications Systems and Networks (COMSNETS).  January 2017.  https://ieeexplore.ieee.org/abstract/document/7945438.
[6] https://www.w3.org/TR/webauthn/#none-attestation.
[7] J. Guttman et al.  ""Attestation:  Evidence and Trust".  MITRE Technical Report MTR080072.  March 2008.  https://www.mitre.org/sites/default/files/pdf/07_0186.pdf.
[8] https://datatracker.ietf.org/doc/draft-ietf-teep-architecture/.

-Giri Mandyam, Qualcomm