[Rats] draft-ietf-rats-reference-interaction-models

[Daniel Migault <[e-mail]>]

Hi,

I reviewed reference-interaction-models and have a few comments /
questions. For this one I think - and hope - I am on time to provide
comments.

Yours,
Daniel

section Introduction

There are some markdowm notations I am not sure are intended: __term__

section 4

I am reading 'MUST' while I am not concerned by such language for an
informational document, I had to remove it and it appeared that lowering
the case can bring some language confusions. Maybe chairs and AD can
clarify what their recommendation is to the co-authors.

It seems to me that authentication and authentic are different concepts --
at least as far as I see them. I see authentic as not altered by its
origin, while I see authentication associating an identity to the origin.
In other words, authentication does tell you who this piece of information
is from as opposed to this information is trusted.

I think the paragraph should better distinguish between authentication and
integrity especially in a context of authenticated encryption.
Typically I am wondering in which case do we have integrity without
authentication ? I interpret a HMAC as using material agreed during an
authenticated negotiation and so consider it as something related to
authentication, but I might be missing the point.

One small comment, this architecture considers Evidence rather than
Attestation Evidence. I suggest to remain aligned with that unless there is
a reason not to do so. I also saw this in EAT in case there is a need to
uniformize the terminology.

This might be more a question to clarify my thoughts. Related to the RoT of
TPM, it seems to me Endorsement is the CA that signs the attestation keys (
and other keys) of the TPM. But I think we heavily rely on the BIOS being
securely carried to the TPM PCR 0. I see this as a part of the RoT but not
as a part of the Endorsement. If I am missing something, I appreciate you
clarify this to me.

section 5

 Attestation Evidence Authenticity:  Attestation Evidence MUST be
      authentic.

I think authentic is unclear to me.... but that might be just me. I would
like to understand why authenticity cannot be replaced by authentication.

section 6

I think the statement there is dangerous. The way I interpret it is that a
handle may have additional properties than freshness.

 A Verifier can also use a Handle as an indicator for authenticity
      or attestation provenance, as only Attesters and Verifiers that
      are intended to exchange Evidence should have knowledge of the
      corresponding Handles.  Examples include Nonces or signed
      timestamps.

section 6

=> may be interpreted as information being sent from Attester to Verifier,
which is not the case. This is just a comment.

section 7

I have the impression I am missing the difference between Uni-Directional
Remote Attestation and Streaming Remote Attestation. Typically, in both
cases we have a continuous stream of attestations and since delta are being
provided, it matters the verifier receives all packets and I expect that a
transport channel TCP or HTTP is set between the Verifier and the
 Attester. In other words, there is a session and a specific dedicated
channel between the Attester and the Verifier - as opposed to something
being broadcast.
Obviously I do not expect a boot sequence to be sent over and over, as a
result, I am wondering what use case we have for such a stream of
attestation.

The main difference I see between Uni-Directional Remote Attestation and
Stream Remote Attestation is that in one case the Handle Distributor
initiates the attestation while in the other case, this is the Verifier
directly. If that were the case, I would probably think that Unidirectional
is a Stream Remote Attestation with an additional token that provides a
third party handle. At that point it is a bit unclear to me why we are
considering them as two different approaches and I suspect I am missing
something.



-- 
Daniel Migault
Ericsson