Subject: [Rats] Comments on YANG Module for Basic Challenge-Response-based Remote Attestation Procedures

From: Puru Kulkarni <[email-masked]>
Date: Tue, 27 Aug 2019 17:38:11 +0000

Hello RATS Working group,

I would like to submit the some comments on the RATS working group draft for
the YANG Module for Basic Challenge-Response-based Remote Attestation Procedures.

I feel that this module should be taken forward for adoption. Please find my comments
Below. They have been split up to correspond with sections of the document:

GENERAL COMMENTS
----------------
The IETF draft titled 'YANG Module for Basic Challenge-Response-based Remote
Attestation Procedures' should be moved forward for adoption. However, one
note is that Attestation is applicable only for TPM-enabled systems. Therefore,
this draft, for instance, does not cover attestation for Apple devices, which
do integrity measurements using the Apple T2 security chip. I feel that since
the attestation performed here is dependent on a TPM being present on the
device under attestation, it should contain the string 'TPM' in the title.

Additionally, there are multiple references that the module defined by this
draft requires a TPM 2.0. However, the defined module also has provisions for
performing remote attestation using a TPM 1.2. All references to 'TPM 2.0'
need to be changed to 'TPM 1.2 or TPM 2.0'

2. THE YANG MODULE FOR BASIC REMOTE ATTESTATION PROCEDURES
----------------------------------------------------------
The RPC named 'basic-trust-establishment' uses the 'tpm20-signature scheme',
this may not be compatible with an implementation of this module on devices
only having a TPM 1.2. Additionally, the output for this RPC uses the
'tpm20-attestation-key-identifier' which may also have the same problem.
Therefore, two new RPCs such as 'tpm12-trust-establishment' and
'tpm20-trust-establishment' may need to be created to prevent ambiguity during
implementation.

For the RPC named 'log-retrieval' the log should allow selecting the Canonical
Event Log (CEL) format. (I don't know if both TPM 1.2 and TPM 2.0 support CEL
format). A new grouping such as 'cannonical-event-log' may also be defined
(or introduced through a separate RFC) which can then be used in the output
container for the 'log-retrieval' RPC.

4. SECURITY CONSIDERATIONS
--------------------------
Security considerations should mention that the nonce exchanged in the RPC for
tpm*-challenge-response-attestation is intended for providing freshness, and
to prevent replay attacks.

Security considerations also need to mention that this YANG module is intended
to be used over NETCONF (RFC 6241), which is a clear-text protocol. If quote
information modelled according to the BRAT YANG module is served over cleartext
NETCONF, then it is opened up to a Message Modification Attack on the quote
in-transit. Additionally, if NETCONF over SSH is used, quote information may
be spoofed if the SSH key of the device under attestation is compromised such
as in the Asokan Attack (RFC 6813).
It must be noted that this module does not solve these problems.

I hope that this draft goes forward to implementation.

Regards,
Puru