Re: [Rats] Call for adoption (after draft rename) for Yang module draft

[Henk Birkholz <[e-mail]>]

Hi Laurence,

maybe I lack the required background knowledge about YANG here. My 
question is the following: Is it in-scope for a YANG modules (which 
typically have a well-defined semantic scope for each statement) to 
convey opaque EATs via a single statement. Or is it necessary to create 
YANG statements for each well-defined EAT Claim?

Viele Grüße,

Henk

On 12.11.19 05:16, Laurence Lundblade wrote:
> What is most important for me is that the YANG document allow for EAT 
> tokens as that seems like an important upgrade path / alternative given 
> that EATs are much more capable.
> 
> But flip it around. In RATS maybe it should be possible for TPM-based 
> attestations to go anywhere an EAT goes. You should be able move TPM 
> attestations around by HTTP, or in TLS extension points or maybe even as 
> an IMAP extension just like you can with EAT. To some degree FIDO has 
> done it. It has a pluggable attestation architecture that allows several 
> formats including TPM-based, Android SafetyNet (which is not Android key 
> store) and some FIDO-specific schemes that are more EAT like.
> 
> That seems like it takes you to a clear demarcation between:
> 
>   * Self-securing signed attestation token
>   * Token conveyance protocol
> 
> 
> This seems very good in concept. We often separate like this in protocol 
> design.
> 
> Then one way to look at the RATS work is in three:
> 
>  1. EAT Attestation Token
>  2. TPM Token (that can be carried by HTTP and almost any conceivable
>     protocol extension)
>  3. A very specific YANG-based conveyance protocol for routers because
>     that’s how routers like it and it is important for the RATS work
>     group constituency.
> 
> 
> Maybe we’ll find another specific conveyance protocol we’ll want to 
> address, but in general we don’t have to. All the web app, IoS app and 
> Android app frameworks will be OK just like they are today for things 
> like Android KeyStore.
> 
> If you look at it this way, 1) then EAT is fine as, 2) we need to define 
> a new "TPM Token" format that is sort of an alternative to EAT, and 3) 
> the YANG module has to be tweaked so it is a carrier of EATs and TPM 
> Tokens. (I’m probably glossing over some of the complexity with YANG and 
> TPMs).
> 
> TPM Token would not be a general claims carrier like EAT. TPM HW is 
> super locked down and limited and TPM Token would just do what TPMs can 
> do. Probably the “claims" amount to a few PCRs. Since the TPM signing 
> format is fixed, the TPM Token signing format would be fixed. TPM Token 
> is sort of a serialization of the output of a TPM. (It can’t be directly 
> COSE as TPM’s can’t do RFC 8152 section 4.4, the COSE-specific creation 
> of the to-be-signed bytes, when signing; probably similarly not JOSE). 
> Since TPM Token is simple, will never change and won’t have extensions 
> we don’t need all the weight of CDDL or YANG or such and can maybe go 
> directly to JSON, XML or CBOR.
> 
> LL
> 
> 
> 
> 
>> On Nov 11, 2019, at 4:56 PM, Smith, Ned <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> YANG I already being used to describe attestation flows and 
>> attestation related data. So the reason why is it is already deployed.
>>
>> YANG has been used as an IM language but more commonly as a DML.
>>
>> When trying to talk about attestation "Claims" it helps if we're 
>> speaking the same language.
>>
>> On 11/11/19, 13:33 PM, "RATS on behalf of Schönwälder, Jürgen" 
>> <[e-mail] <mailto:[e-mail]> on behalf of 
>> [e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>    Hi,
>>
>>    we commonly call YANG a data modeling language and not an information
>>    modeling language. Can someone explain why you want to use YANG?
>>
>>    /js
>>
>>    On Mon, Nov 11, 2019 at 09:27:09PM +0000, Smith, Ned wrote:
>>> You’re saying YANG fills a gap that is similar to what OpenAPI/RAML 
>>> fills?
>>>
>>> It could be doing more than this as well, such as defining claims (as 
>>> was suggested in a previous email by I think Michael). If RATS 
>>> determined that the way to specify a Claim in the information model 
>>> was via CDDL (only) and there is a YANG expression of it, then that 
>>> implies a CDDL to YANG mapping is required. (Is that reasonable?).
>>>
>>> Or RATS says that it is reasonable to use either/both CDDL and YANG 
>>> for Claims expressions. This suggests there are CDDL and YANG 
>>> mappings to whatever are the target DMLs (JOSE, COSE, DER, something 
>>> else?). Does YANG support DML mappings to JOSE, COSE and DER or just 
>>> to YANG? Does CDDL support mappings to DER and YANG (something else)?
>>>
>>> Ideally CDDL can be mapped to other information modelling languages 
>>> (e.g. YANG) so that only one normative expression needs to be 
>>> canonized. However, that implies extra work on behalf of the YANG 
>>> drafts to come up with the CDDL equivalent. Maybe that is unnecessary 
>>> extra work for consistency sake? That would force the conversations 
>>> around whether ‘time’ and ‘ticks’ are the same information model 
>>> expression (for example).
>>>
>>> -Ned
>>>
>>> On 11/11/19, 11:52 AM, "RATS on behalf of Laurence Lundblade" 
>>> <[e-mail] 
>>> <mailto:[e-mail]><mailto:[e-mail]> on 
>>> behalf of [e-mail] 
>>> <mailto:[e-mail]><mailto:[e-mail]>> wrote:
>>>
>>> One more note on this. It seems wrong-headed to try express claims in 
>>> YANG. To do that we’d need to invent a YANG signing standard (YOSE?). 
>>> Seems like YANG should be thought of as RPC / conveyance / transport 
>>> here, not as a way to format a signed attestation token.
>>>
>>> LL
>>>
>>>
>>>
>>> On Nov 11, 2019, at 11:47 AM, Laurence Lundblade 
>>> <[e-mail] 
>>> <mailto:[e-mail]><mailto:[e-mail]>> wrote:
>>>
>>> On Nov 10, 2019, at 9:20 PM, Michael Richardson 
>>> <[e-mail] 
>>> <mailto:[e-mail]><mailto:[e-mail]>> wrote:
>>>
>>>
>>> I think the value add to the larger RATS effort of adding EAT support
>>> to this YANG protocol is really high. It a core thing to do that helps
>>> bring together the two attestation worlds and make the TPM and EAT
>>> work here less like ships in the night.
>>>
>>> Can you explain what it would mean to add EAT support for a YANG module?
>>>
>>> The EAT is an opaque chunk of data in YANG. I’m not a YANG expert, 
>>> but maybe like this:
>>>
>>> Server                               Device
>>> GetAttestationTypes —>
>>>                                <- TYPE_TPM, TYPE_CWT /* bit flags */
>>>
>>> GetAttestation(TYPE_CWT , nonce) —>
>>>                                <— CWT Token /* a full signed token */
>>>
>>> I assume YANG can carry opaque binary data of moderate size.
>>>
>>> The yang module information model would have an element for a nonce 
>>> and for an opaque EAT. It would not describe any internals of the 
>>> EAT. The information model for the EAT is separate in the EAT document.
>>>
>>> LL
>>>
>>>
>>>
>>>
>>
>>> _______________________________________________
>>> RATS mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/rats
>>
>>
>>    --
>>    Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>    Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>    Fax:   [phone]         <https://www.jacobs-university.de/>
>>    _______________________________________________
>>    RATS mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rats
>>
>>
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>