Subject: Re: [Rats] Some info model comments

From: "Smith, Ned" <[email-masked]>
Date: Thu, 1 Aug 2019 19:31:18 +0000

It appears the TPM, TUDA use case examples below could be categorized as either (IV), (V) or (VI)? 

From a different thread:
In summary, it seems reasonable for an IM that can talk about:
i)                    individual claims as unsigned expressions where the semantics are clear
ii)                   groupings of unsigned claims
iii)                 signed claims
iv)                 groupings of signed claims that are unsigned
v)                   groupings of signed claims that are signed (maybe expand to grouping of both signed and unsigned claims?)
vi)                 groupings of signed claims that are formatted differently from a parent or child grouping of signed claims

On 7/30/19, 8:07 AM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    It would be possible to take a TPM structure (that is the output of a 
    TPM command and typically includes a signature) and put it into an EAT 
    claim value.
    
    If there is a use case where a bundle of TPM structures other claims are 
    conveyed, signing the EAT could make sense in same cases, I think, 
    because it might add some (in this case still hypothetical) value.
    
    If remote attestation is based solely on already signed TPM structures, 
    maybe bundling them in an EAT still could be useful, but signing that 
    bundle would not add value, I think. Analogously, I am not convinced 
    that null ciphers, etc. are the bests approach here - and CWT need to 
    use COSE.
    
    That is why TUDA is working the other way around.
    
    If a TPM is used in TUDA, the native structure is decomposed down to its 
    values on the sender side, put into a very concise CBOR structure that 
    is far smaller than the native structure, is then conveyed, and then 
    canonically reconstructed as a valid signed TPM structure on the 
    receiver side.
    
    Additionally, any values that can be omitted because the receiver would 
    already know these values or could deterministically infer them in a 
    TUDA procedure are omitted in the conveyed CBOR structure - making it 
    even more compact/compressed.
    
    That is the reason why TUDA is not using EAT, if a TPM is involved. If a 
    TA in a TEE would provide the respective root-of-trust services, EAT 
    could be used in that TUDA flavor - and actually would be my first and 
    most obvious choice :)
    
    Viele Grüße,
    
    Henk

    On 7/26/19 5:18 PM, Carl Wallace wrote:
    > Seems you could define a claim carried in an EAT that encapsulated 
    > existing attestation types.
    > 
    > On Jul 26, 2019, at 8:09 AM, Laurence Lundblade <[email-masked] 
    > <mailto:[email-masked]>> wrote:
    > 
    >> Hi Ian,
    >>
    >> My TPM knowledge is limited, but I think it goes like this:
    >> *Payload / claims:* EAT and TPM are very different and incompatible
    >> *Signing format:* EAT and TPM are very different and incompatible
    >> *Proposed as part of remote attestation standard in RATS Work Group:* 
    >> identical
    >> *Transportable by YANG-described protocols like NetConf and COAP: 
    >> *near identical
    >> *Transportable in extensions of protocols like FIDO: *near identical
    >>
    >> I don’t think there’s any useful way to achieve much more 
    >> compatibility with the first two points, so I’m not sure what 
    >> “subtype” would mean if you are talking about data structures in some 
    >> formal or semi-formal way.
    >>
    >> Maybe you are suggesting that all the attestation tokens standardized 
    >> by RATS should be named an EAT?
    >>
    >> LL
    >>
    >>
    >>
    >>> On Jul 26, 2019, at 3:02 AM, Oliver, Ian (Nokia - FI/Espoo) 
    >>> <[email-masked] 
    >>> <mailto:[email-masked]>> wrote:
    >>>
    >>> I support this proposal. I too am a little confused that TPM 
    >>> attestation structures are treated differently from the proposed 
    >>> EAT-tyle.
    >>>
    >>> In our thinking, the TPM-constrainted attestation (TPM2_ATTEST, aka. 
    >>> TPM2 quote) is a subtype of a more generic EAT structure.
    >>>
    >>> At least this is how we see it
    >>>
    >>> Ian
    >>>
    >>> --
    >>> Dr. Ian Oliver
    >>> Cybersecurity Research
    >>> Distinguished Member of Technical Staff
    >>> Nokia Bell Labs
    >>> +358 50 483 6237
    >>>
    >>> ------------------------------------------------------------------------
    >>> *From:*Laurence Lundblade <[email-masked] 
    >>> <mailto:[email-masked]>>
    >>> *Sent:*26 July 2019 02:23
    >>> *To:[email-masked] <mailto:[email-masked]> <[email-masked] 
    >>> <mailto:[email-masked]>>
    >>> *Subject:*[Rats] Some info model comments
    >>> Here’s a characterization of RATS work. The non-blue boxes are where 
    >>> I believe RATS work is.
    >>>
    >>>
    >>> The proposed information model draft does two things that I think are 
    >>> problem.
    >>>
    >>>     First, it tries to span the orange and yellow boxes. These boxes
    >>>     are super different. I don’t think they should be mixed in one
    >>>     model. The yellow boxes are general claims about the entities.
    >>>     The orange box is inputs and outputs related to TPMs. For
    >>>     example, instructions to TPMs to do one type of attestation or
    >>>     another type.
    >>>
    >>>     Second, it cut the definition of a claim in two. Part of it would
    >>>     go in the information model and another part of it would go in
    >>>     the EAT draft or such. When you tweak the definition of a claim,
    >>>     say the location claim, you might have to update one document,
    >>>     the other, or both.
    >>>
    >>> I can think of ways to make use of info/data models in productive 
    >>> ways for RATs, but they would be different than the proposal. 
    >>> Something like this:
    >>>
    >>>     There would be one info model for claims and another for
    >>>     transport. Maybe a little fudging for the nonce, but it is simple
    >>>     and well understood.
    >>>
    >>>     The definition of a particular claim would be in only one
    >>>     document. It’s OK if there are common data types uses by claims
    >>>     are in a separate document (kind of like a .h file). 
    >>>
    >>>
    >>>
    >>> LL
    >>
    >> _______________________________________________
    >> RATS mailing list
    >> [email-masked] <mailto:[email-masked]>
    >> https://www.ietf.org/mailman/listinfo/rats
    > 
    > _______________________________________________
    > RATS mailing list
    > [email-masked]
    > https://www.ietf.org/mailman/listinfo/rats
    > 
    
    _______________________________________________
    RATS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/rats