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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Tue, 12 November 2019 08:28 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD981120169 for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 00:28:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UydEtNZroo93 for <rats@ietfa.amsl.com>; Tue, 12 Nov 2019 00:28:24 -0800 (PST)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57217120046 for <rats@ietf.org>; Tue, 12 Nov 2019 00:28:24 -0800 (PST)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xAC8SL64021151 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 12 Nov 2019 09:28:22 +0100
Received: from [134.102.157.164] (134.102.157.164) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Tue, 12 Nov 2019 09:28:16 +0100
To: Laurence Lundblade <lgl@island-resort.com>, "Smith, Ned" <ned.smith@intel.com>
CC: Michael Richardson <mcr+ietf@sandelman.ca>, =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <J.Schoenwaelder@jacobs-university.de>, "rats@ietf.org" <rats@ietf.org>
References: <8B173958-FC2A-4D1D-A81C-F324AB632CD7@cisco.com> <147F9159-6055-4E55-ABDC-43DFE3498BF1@island-resort.com> <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com> <1C8A1884-A37D-45E3-8C11-2FC5A083B245@island-resort.com> <ba12a686-1b34-21a3-388c-bbe01c01a408@sandelman.ca> <4A83CDF5-D29F-4279-8B03-E9D23299EB53@island-resort.com> <0C6940B0-E93F-4274-9D00-DEC4119B8F69@island-resort.com> <3310947D-EA31-4107-8FF0-B917A027C955@intel.com> <20191111213249.4p7z2ovkvqy2u5go@anna.jacobs.jacobs-university.de> <3C967A22-DBB0-4EA7-923D-B423920EB9BD@intel.com> <0AACCF7B-36A9-4AF9-B18A-BF18DC35986E@island-resort.com>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <a72c6bb0-0f96-3d25-0faf-d5a1fe92a2c8@sit.fraunhofer.de>
Date: Tue, 12 Nov 2019 09:28:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <0AACCF7B-36A9-4AF9-B18A-BF18DC35986E@island-resort.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.157.164]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/yGxXUzUT6Ks2AAemT8rp6BoS3zw>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2019 08:28:28 -0000

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 <ned.smith@intel.com 
>> <mailto:ned.smith@intel.com>> 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" 
>> <rats-bounces@ietf.org <mailto:rats-bounces@ietf.org> on behalf of 
>> J.Schoenwaelder@jacobs-university.de 
>> <mailto:J.Schoenwaelder@jacobs-university.de>> 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" 
>>> <rats-bounces@ietf.org 
>>> <mailto:rats-bounces@ietf.org><mailto:rats-bounces@ietf.org> on 
>>> behalf of lgl@island-resort.com 
>>> <mailto:lgl@island-resort.com><mailto:lgl@island-resort.com>> 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 
>>> <lgl@island-resort.com 
>>> <mailto:lgl@island-resort.com><mailto:lgl@island-resort.com>> wrote:
>>>
>>> On Nov 10, 2019, at 9:20 PM, Michael Richardson 
>>> <mcr+ietf@sandelman.ca 
>>> <mailto:mcr+ietf@sandelman.ca><mailto:mcr+ietf@sandelman.ca>> 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
>>> RATS@ietf.org <mailto:RATS@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/rats
>>
>>
>>    --
>>    Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>    Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>    Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>>    _______________________________________________
>>    RATS mailing list
>> RATS@ietf.org <mailto:RATS@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rats
>>
>>
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>