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

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Fri, 13 Sep 2019 01:10:10 +0000

Hi Puru,

Many thanks for the review and suggestions. 

Please find comments inline @Shwetha

On 8/27/19, 11:08 PM, "RATS on behalf of Puru Kulkarni" <[email-masked] on behalf of puruk=[email-masked]> wrote:

    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'

[Shwetha] https://github.com/ietf-rats/draft-birkholz-rats-basic-yang-module/issues
#5,#6 are raised to track and resolve this.

    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.
[Shwetha] 
Basic trust establishment is to fetch the public certificate chain and public keys for attestation and device identity.
We can explore if it is possible to have basic-trust-establishment to be independent of TPM version, as this will be the first operation between attestor and attestee before challenge response based RPC can be triggered. 
#7 is created to track this
    
    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.

[Shwetha] log-type extended to support Canonical Event log and new grouping can be added.
#8 is created.
    
    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.
    
[Shwetha] Couple of questions :
1 . Why do you suggest restricting it to NETCONF? I believe this yang module could be used over RESTCONF or any other transport that is used for carrying yang modelled data.
2. For carrying this data over NETCONF per RFC6241 section 2.2 NETCONF transport MUST provide message integrity, confidentiality and replay protection. So the concern about clear-text hence message modification attack on the quote if NETCONF is used is not valid.

I would prefer to defer the security consideration to be same as whatever transport is used.
But we can update the Security consideration section to select a transport of the yang modelled data over a transport that provides data integrity, confidentiality, and replay protection to avoid spoofing of quote information.
#9 created to track this

Thanks again for the detailed review.

Shwetha

    I hope that this draft goes forward to implementation.
    
    Regards,
    Puru
    
    _______________________________________________
    RATS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/rats