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

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Tue, 5 Nov 2019 22:54:51 +0000

All,
Thanks for the feedback and responses received thus far on the https://datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/
draft.

There  was consensus that the focus of the draft is more about TPM based attestations so the draft should be modified accordingly.  A suggested title would be “Yang Module for TPM based Remote Attestations”, the file, once adopted, would be renamed to draf -rats-tpm-yang-module

With this proposed update, this is a call for adoption for that draft with the modified name.  We would like to close the confirmation by the Friday of the IETF 106, e.g. Friday Nov 22 EOD (IETF time).  If you have objections on adopting the draft, please state your rationale as well.

Warm regards,
                Nancy

---

From: Guy Fedorkow <[email-masked]>
Date: Wed, 6 Nov 2019 18:58:41 +0000

Nancy,
  I'm fine with this proposal
  Thx
/guy

Juniper Business Use Only
From: RATS <[email-masked]> On Behalf Of Nancy Cam-Winget (ncamwing)
Sent: Tuesday, November 5, 2019 5:55 PM
To: [email-masked]
Subject: [Rats] Call for adoption (after draft rename) for Yang module draft

All,
Thanks for the feedback and responses received thus far on the https://datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/__;!8WoA6RjC81c!UMJUzm2VocF8BEy9_UYeBtXkmzvaiZpxgF45wUJxlo1AbOhpLfBKpM2Dn6sLOAZCdRs$>
draft.

There  was consensus that the focus of the draft is more about TPM based attestations so the draft should be modified accordingly.  A suggested title would be "Yang Module for TPM based Remote Attestations", the file, once adopted, would be renamed to draf -rats-tpm-yang-module

Warm regards,
                Nancy

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 6 Nov 2019 11:44:03 -0800

I think we have accepted that this WG will do standardization for / around the following attestation token formats (aka attestation evidence formats):
EAT (lots of detailed work in IETF to define)
JWT
CWT
(possibly also ASN.1 / X.509)
TCG (fixed years ago by the TCG)
TPM 1.2 signed Quote
TPM 2 signed Audit Session

I think any conveyance protocol we work on MUST carry all of these. I don’t think this is hard. If it were hard I wouldn’t say this.

To adopt the YANG module, I think it should be modified to carry EAT/JWT/CWT and retain its name. It can still have the other TPM-specific stuff in it for use when in TPM mode, but it should have an EAT mode too.

LL

> On Nov 5, 2019, at 2:54 PM, Nancy Cam-Winget (ncamwing) <[email-masked]> wrote:
> 
> All,
> Thanks for the feedback and responses received thus far on the https://datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/ <https://datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/>
> draft.  
>  
> _______________________________________________
> RATS mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rats <https://www.ietf.org/mailman/listinfo/rats>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 6 Nov 2019 21:09:16 +0100

I am fine with that proposal as well. Sorry for the latency, noisy inbox 
syndrome.

On 06.11.19 19:58, Guy Fedorkow wrote:
> Nancy,
> 
>    I’m fine with this proposal
> 
>    Thx
> 
> /guy
> 
> *From:*RATS <[email-masked]> *On Behalf Of *Nancy Cam-Winget 
> (ncamwing)
> *Sent:* Tuesday, November 5, 2019 5:55 PM
> *To:* [email-masked]
> *Subject:* [Rats] Call for adoption (after draft rename) for Yang module 
> draft
> 
> All,
> 
> Thanks for the feedback and responses received thus far on the 
> https://datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/ 
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/__;!8WoA6RjC81c!UMJUzm2VocF8BEy9_UYeBtXkmzvaiZpxgF45wUJxlo1AbOhpLfBKpM2Dn6sLOAZCdRs$>
> 
> draft.
> 
> There  was consensus that the focus of the draft is more about TPM based 
> attestations so the draft should be modified accordingly.  A suggested 
> title would be “Yang Module for TPM based Remote Attestations”, the 
> file, once adopted, would be renamed to draf -rats-tpm-yang-module
> 
> With this proposed update, this is a call for adoption for that draft 
> with the modified name.  We would like to close the confirmation by the 
> Friday of the IETF 106, e.g. Friday Nov 22 EOD (IETF time).  If you have 
> objections on adopting the draft, please state your rationale as well.
> 
> Warm regards,
> 
>                  Nancy
> 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rats
>

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 6 Nov 2019 21:10:58 +0100

And bad sequence of replies, too...

Does that have an impact on the title? I think it does not. Laurence?

Viele Grüße,

Henk

On 06.11.19 20:44, Laurence Lundblade wrote:
> I think we have accepted that this WG will do standardization for / 
> around the following attestation token formats (aka attestation evidence 
> formats):
> 
>   * EAT (lots of detailed work in IETF to define)
>       o JWT
>       o CWT
>       o (possibly also ASN.1 / X.509)
>   * TCG (fixed years ago by the TCG)
>       o TPM 1.2 signed Quote
>       o TPM 2 signed Audit Session
> 
> 
> I think any conveyance protocol we work on MUST carry all of these. I 
> don’t think this is hard. If it were hard I wouldn’t say this.
> 
> To adopt the YANG module, I think it should be modified to carry 
> EAT/JWT/CWT and retain its name. It can still have the other 
> TPM-specific stuff in it for use when in TPM mode, but it should have an 
> EAT mode too.
> 
> LL
> 
> 
>> On Nov 5, 2019, at 2:54 PM, Nancy Cam-Winget (ncamwing) 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> All,
>> Thanks for the feedback and responses received thus far on 
>> thehttps://datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/
>> draft.
>> There  was consensus that the focus of the draft is more about TPM 
>> based attestations so the draft should be modified accordingly.  A 
>> suggested title would be “Yang Module for TPM based Remote 
>> Attestations”, the file, once adopted, would be renamed to draf 
>> -rats-tpm-yang-module
>> with the modified name.  We would like to close the confirmation by 
>> the Friday of the IETF 106, e.g. Friday Nov 22 EOD (IETF time).  If 
>> you have objections on adopting the draft, please state your rationale 
>> as well.
>> Warm regards,
>>                 Nancy

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 6 Nov 2019 12:24:14 -0800

For a version of it that carries EATs, the current name, YANG Module for Basic Challenge-Response-based Remote Attestation Procedures, draft-birkholz-rats-basic-yang-module-01 is fine IMO.

LL

> On Nov 6, 2019, at 12:10 PM, Henk Birkholz <[email-masked]> wrote:
> 
>>> On Nov 5, 2019, at 2:54 PM, Nancy Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> All,
>>> Thanks for the feedback and responses received thus far on thehttps://datatracker.ietf.org/doc/draft-birkholz-rats-basic-yang-module/
>>> draft.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sun, 10 Nov 2019 22:20:27 +0000

Hi,
Given the feedback, it was noted that "as is", the draft is more about TPM; ergo for the current adoption, it would be good to just call it TPM for now.
But yes, once adopted, if we can begin to track issues and requests to have it include other claims, we can change to a more appropriate name.

So, Laurence, are you still OK with the adoption of the current draft with a rename for now?
Thanks, Nancy

On 11/6/19, 12:24 PM, "RATS on behalf of Laurence Lundblade" <[email-masked] on behalf of [email-masked]> wrote:

    LL

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 10 Nov 2019 14:44:31 -0800

> On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing) <[email-masked]> 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.

Remote TPM attestations are useful and necessary the short run, but are of very limited capability. I believe that EAT will replace TPM attestations in the long run (maybe decades) because they are far more expressive. I know others believe that too. 

If we don’t include EAT in the YANG mode it is sort of like defining HTTP to only convey HTML to the exclusion of PDF. We’re defining an attestation protocol that can only move one kind of attestation even though we have consensus on what the other one looks like.

It seems relatively simple to add EAT support (or promise to add EAT support). Pretty sure I heard Henk agree to add it.

Thus, I am opposed to adoption with the current TPM-only draft. I’d be OK with the current draft and a promise to add EAT to it.

LL

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Nov 2019 08:21:00 +0800

When it comes to JWT encapsulation and YANG serialized JSON there are
some potential conflicts that I want to bring up.  This is worth a 5
minute discussion at a future meeting (perhaps premature for IETF106).

I've posted about this to other lists in the past two weeks, but I don't
have the references, and I don't have enough Internet to look them up
from here.

The specific conflict is that JWT, coming from the web space, uses
base64URL encoding for binary objects (signatures..., etc.) while YANG,
uses base64 encoding for binary objects.  This is a documentation
annoyance, but it will catch at least one implementer.

Tolerant decoders might accept both (but neither Python or Ruby base64
decoders are tolerant), but I don't think we can in general, demand that
either is acceptable, so we have to say which to use each time.

We will just have to be clear going forward, and hit people over the
head with this.  I can easily see YANG described data (signatures on
Evidence) from a TPM device being base64 encoded, and then placed into a
JWT container which is base64URL signed (for a Claim).

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Nov 2019 13:20:28 +0800

On 2019-11-11 6:44 a.m., Laurence Lundblade wrote:
>
>> On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing)

You suggested the name:

“Yang Module for TPM based Remote Attestations”

But, I think that it should say instead, "Yang Interface to TPM 2.0"

>
> 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?
Maybe I'm daft here.

The current document is essentially a YANG wrapper around the TPM 2.0
specification.  It's RPC, data in motion.

While EAT is primary a JWT/CWT object, which is data-at-rest.
I think that you are looking for a way to express non-TCG defined
evidence containers.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 11 Nov 2019 05:39:58 +0000

Hi Michael,
See comments below:

On 11/10/19, 9:21 PM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    
    You suggested the name:

    But, I think that it should say instead, "Yang Interface to TPM 2.0"
[NCW] That is a fair point.....my point is that it should be named to reflect core of description which is based around TPMs.

    Can you explain what it would mean to add EAT support for a YANG module?
    Maybe I'm daft here.
[NCW]. Hmmm, I did NOT state that?  I think that was Laurence.  I view EAT as defining claims that use  JWT/CWT data structures.
If there are claims (not format) that can be represented in Yang, then yes (and I think some can).  But the "general EAT", I'm not
sure how those structures map to the TPM interfaces...but they certainly could be represented in YANG.

    While EAT is primary a JWT/CWT object, which is data-at-rest.
    I think that you are looking for a way to express non-TCG defined
    evidence containers.
[NCW] I'm not sure why these object would be data-at-rest?  I view them as claims represented in specific structures, e.g. JWT/CWT
But can be transported using any transport (e.g. TLS, et al)....similar to YANG?  
While it is true that the YANG draft also exposes the TPM interface, it also contains the claims albeit that are TPM specific.
So perhaps you are referring to the interface aspect?

Best, Nancy

---

From: "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Date: Mon, 11 Nov 2019 07:20:37 +0000

> Remote TPM attestations are useful and necessary the short run, but are of very limited capability. I believe that > EAT will replace TPM attestations in the long run (maybe decades) because they are far more expressive. I know > others believe that too.

I would disagree with the statement of "short run" ... TPM is practically the only existing standardised (hardware, software, firmware, measurement - x86 only etc) hardware root of trust in common use, ie: practically all x86 machines,  The attestation mechanisms provided are going to be around for a very long time.

>From telco experience, 30 years ago we said SS7 would only be around in the short term.

> Thus, I am opposed to adoption with the current TPM-only draft. I’d be OK with the current draft and a promise > to add EAT to it.

Agree

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Distinguished Member of Technical Staff

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Laurence Lundblade <[email-masked]>
Sent: 11 November 2019 00:44
To: Nancy Cam-Winget (ncamwing) <[email-masked]>
Cc: Henk Birkholz <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>> wrote:

LL

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 11 Nov 2019 10:57:32 +0100

Hi all,

on one hand, we have to address the overlap between YANG and EAT 
information elements (statements & Claims) and how to deal with them 
(one obvious issue, for example, would be potential redundant 
information model content in two different drafts).

On the other hand, Laurence's original point was the payload of 
conveyance protocols used by RATS. Specializations of this topic are 
apparently:

* Web Tokens via YANG Interfaces, and
* YANG modeled data via other conveyance protocols (other than *CONF) 
that can transport Web Tokens.

There are examples of how YANG modeled data is used outside of *CONF 
protocols, for example MUD. We have to understand and agree about:

* this is possible on a technical level, and
* this is useful wrt to protocol scope, intent & semantics, I think.

This is one items of the 5 minutes slot I gave back. And I am happy to 
see this on the list.

Viele Grüße,

Henk

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 11 Nov 2019 11:11:18 +0100

Hi Michael,

you are bringing up an issue that might look tiny, but I think you are 
right when you say: "it will catch at least one implementer".

And there is no easy fix for his, it seems? JWT is set, and YANG modeled 
data, such as RFC 7951, is also set. I am not sure that there is a thing 
such as "tolerant decoders" in practice, I am afraid.

In summary, as a last resort I'd agree with you that we need to "hit 
people over the head with this", extensively.

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Nov 2019 19:37:01 +0800

> information model content in two different drafts).

Can you give me an example, but I'm not getting the issue.
I think that we will be the first to attempt to use JOSE to sign a JSON
serialized YANG object, resulting in a JWT.  Well, technically, it's
probably not a JWT, because we aren't going to base64url it and put
periods between the pieces, I think.  It's just JOSE, but I don't mind
if we call it a JWT.

draft-ietf-anima-constrained-voucher does CBOR serialized YANG which is
signed with COSE.

> * this is useful wrt to protocol scope, intent & semantics, I think.

MUD (RFC8520) does it, but so does ANIMA vouchers (RFC8366).
Again, data-at-REST described by YANG.

But the document in question does not seem to be data-at-rest, but RPC
access via *CONF protocols to TPM 2.0 objects, so I feel that you are
further muddying this thread by asking the above question.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 11 Nov 2019 19:48:45 +0800

> right when you say: "it will catch at least one implementer".

I started a private discussion with Mike Jones and Tim Bray a few weeks
ago about a clarifying BCP about always using base64URL in JSON going
forward.  (I thought I had posted this to a list.)
Or... would an errata be enough? 
That would put the current serialization of YANG (RFC7951) on the wrong
side of the tracks, which is unfortunate.

> And there is no easy fix for his, it seems? JWT is set, and YANG
> modeled data, such as RFC 7951, is also set. I am not sure that there
> is a thing such as "tolerant decoders" in practice, I am afraid.

It's not hard, there are only two characters:
  62 is either +(original) or -
  63 is either / (original) or _

I was rather surprised that common implementations didn't just accept
both already.
I stubbed my toe on this when processing Jim Schaad's excellent JOSE
reference vectors, and couldn't figure out why one of the public keys
was too short, until I learnt that the decoder I was using just stopped
when it got an invalid character, and I was using base64 rather than
base64url.

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 11 Nov 2019 13:13:49 +0100

Hi Michael,

please see in-line.

>> information model content in two different drafts).

Examples of the same information elements that are used in different 
data models via Claims or statements:

* EAT Time stamp / YANG clock info
* EAT Origination / YANG attestation key cert, or
* EAT Uptime / YANG tpm ticks

> periods between the pieces, I think.  It's just JOSE, but I don't mind

As far as I know, simply wrapping a "JSON serialized YANG object" in 
JOSE does not create a JWT. RFC 7951 is not based on RFC 7519. The 
Base64/Base64URL confusion is limited to value representation in JSON 
serialization, I think.

> draft-ietf-anima-constrained-voucher does CBOR serialized YANG which is

With CBOR serialization most things more straightforward and a tad bit 
simpler. I do not think that we have any issues on the binary side of 
things here. Or am I missing something obvious?

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 11 Nov 2019 13:18:54 +0100

A single reply in-line.

> side of the tracks, which is unfortunate.

This is what I meant by "not easy". Both are used already. The technical 
differences (see below) are not that big, I agree.

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 11 Nov 2019 15:02:02 +0100

Having multiple ways to do one thing was never a good idea.  COSE would suffice.
Regarding the Base64-encoding of X5C objects, the rational was to be PEM compatible which also was a pretty bad idea since X5C simply isn't PEM compatible by a long shot.

Both are excellent examples of "design by committee".

Anders

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 11 Nov 2019 16:26:36 +0000

So far the group has used the term "EAT" to refer to both the information model and data serialization expressions. When extending information model to YANG or some other serialization (e.g. ASN.1). Given the possibility for an IM expression to be realized by different serializations, what term should we give to the IM description? 

The term "Claim" has been used extensively. Do we want to agree to use "claim" to refer to anything that is an IM expression in RATS and "Token" for any serialization (realization) even if it isn't a JWT or CWT?  

Thx,
Ned

On 11/11/19, 4:14 AM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Michael,
    
    please see in-line.

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 11 Nov 2019 18:11:30 +0000

Right. This implies the RATS “token” should support existing “binary” formats as an encapsulation (signed by a second TA where the TPM is a first TA) or as a conveyance (unsigned?) token. Possibly, the only added value of the latter is a tag that identifies it as a TPM binary format?

Agree

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

Cc: Henk Birkholz <[email-masked]>; rats@ietf..org <[email-masked]>

LL

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 11 Nov 2019 19:22:54 +0100

Laurence provided options as a basis for discussion a while ago.

He highlighted that CWT must be signed and illustrated pro & con wrt:

* null cipher,
* an "unsigned" flavor of CWT
* an "arbitrary signature"

It might be a valid assumotion that a single "tpm Claim" would have no 
significant added value, but multiple Claims in a message bundle might 
(although this might be a solution looking for a problem?).

Viele Grüße,

Henk

On 11.11.19 19:11, Smith, Ned wrote:
> Right. This implies the RATS “token” should support existing “binary” 
> formats as an encapsulation (signed by a second TA where the TPM is a 
> first TA) or as a conveyance (unsigned?) token. Possibly, the only added 
> value of the latter is a tag that identifies it as a TPM binary format?
> 
> On 11/10/19, 23:21 PM, "RATS on behalf of Oliver, Ian (Nokia - 
> FI/Espoo)" <[email-masked] <mailto:[email-masked]> on 
> behalf of [email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> I would disagree with the statement of "short run" ... TPM is 
> practically the only existing standardised (hardware, software, 
> firmware, measurement - x86 only etc) hardware root of trust in common 
> use, ie: practically all x86 machines,  The attestation mechanisms 
> provided are going to be around for a very long time.
> 
> ------------------------------------------------------------------------
> 
> *From:*Laurence Lundblade <[email-masked]>
> *Sent:* 11 November 2019 00:44
> *To:* Nancy Cam-Winget (ncamwing) <[email-masked]>
> *Cc:* Henk Birkholz <[email-masked]>; rats@ietf..org 
> <[email-masked]>
> *Subject:* Re: [Rats] Call for adoption (after draft rename) for Yang 
> module draft
> 
> 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.
> 
> Remote TPM attestations are useful and necessary the short run, but are 
> of very limited capability. I believe that EAT will replace TPM 
> attestations in the long run (maybe decades) because they are far more 
> expressive. I know others believe that too.
> 
> If we don’t include EAT in the YANG mode it is sort of like defining 
> HTTP to only convey HTML to the exclusion of PDF. We’re defining an 
> attestation protocol that can only move one kind of attestation even 
> though we have consensus on what the other one looks like.
> 
> It seems relatively simple to add EAT support (or promise to add EAT 
> support). Pretty sure I heard Henk agree to add it.
> 
> Thus, I am opposed to adoption with the current TPM-only draft. I’d be 
> OK with the current draft and a promise to add EAT to it.
> 
> LL
>

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 11 Nov 2019 18:35:51 +0000

Given the architecture supports hybrids of passport and background check models, it seems there could be a rich combination of attesters, verifiers and relying parties where partial results could be supplied by Verifier A to RP B who in turn verifies as Verifier B and produces results B etc... If so, then possibly a TPM encapsulated "claim" gets passed on to multiple verifiers until one that can parse a TPM encapsulation is found. Maybe this is a contrived use case, but it seems reasonable based on what has been discussed so far. By not allowing a TPM encapsulation, it implies there is some other encapsulation besides a "Token" that carries the TPM produced Evidence. 

-Ned

On 11/11/19, 10:23 AM, "RATS on behalf of Henk Birkholz" <[email-masked] on behalf of [email-masked]> wrote:

    
    * null cipher,

    Viele Grüße,
    
    Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 11 Nov 2019 11:47:58 -0800

> 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

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 11 Nov 2019 11:52:37 -0800

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 <[email-masked]> wrote:
> 
> On Nov 10, 2019, at 9:20 PM, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>>

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 11 Nov 2019 21:27:09 +0000

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" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

LL

On Nov 11, 2019, at 11:47 AM, Laurence Lundblade <[email-masked]<mailto:[email-masked]>> wrote:

On Nov 10, 2019, at 9:20 PM, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

Server                               Device
GetAttestationTypes —>

LL

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Mon, 11 Nov 2019 21:32:50 +0000

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

-- 
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/>

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 12 Nov 2019 00:56:36 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    /js

---

From: Dave Thaler <[email-masked]>
Date: Tue, 12 Nov 2019 01:43:10 +0000

As far as I can understand from draft-birkholz-rats-basic-yang-module-01 and
draft-fedorkow-rats-network-device-attestation-01, they break down the use case
space as follows:

                        Requirements?
         +--------------+---------------+---------++---------------
         |  RoT         | Host Firewall | Privacy ||   Solution
         |  Type        |   Enabled     | Needed  ||    Pieces
         +--------------+---------------+---------++---------------
      1  |  SGX         | No            | No      ||
      2  |  SGX         | No            | Yes     ||
      3  |  SGX         | Yes           | No      ||
      4  |  SGX         | Yes           | Yes     ||
      5  |  TrustZone   | No            | No      ||
      6  |  TrustZone   | No            | Yes     ||
      7  |  TrustZone   | Yes           | No      ||
      8  |  TrustZone   | Yes           | Yes     ||
      9  |  TPM         | No            | No      || draft-birkholz-rats-basic-yang-module-01
     10  |  TPM         | No            | Yes     ||
     11  |  TPM         | Yes           | No      ||
     12  |  TPM         | Yes           | Yes     ||
     13  |SecureElement | No            | No      ||
     14  |SecureElement | No            | Yes     ||
     15  |SecureElement | Yes           | No      ||
     16  |SecureElement | Yes           | Yes     ||
     17  | Firmware     | No            | No      ||
     18  | Firmware     | No            | Yes     ||
     19  | Firmware     | Yes           | No      ||
     20  | Firmware     | Yes           | Yes     ||
     ... |   ...        |               |         ||

And draft-fedorkow-rats-network-device-attestation-01 further scopes itself down
by only being applicable to cases with "embedded" apps only = Yes, and where
the security policy is only an Exact match against reference values = Yes.
I believe that the yang draft doesn't have those two restrictions, from my reading.
However, the point is that both drafts are VERY narrow, and in the table shown above,
only address 1 out of 20 possibilies in that space.

In contrast, the TEEP WG decided that it was not interested in narrow scopings
(specifically something Global Platform specific), but instead wanted one general solution.

If the RATS WG spends effort on something that only addresses a single row out of 20+ rows,
then do we expect 19+ other solutions to also be done in the WG?  Or could we work on things
that are broader and happen to also work for row 9?

I've seen others commenting on the fact that the YANG module only supports TPMs and not
other things (EATs etc), which would just add support for a couple more rows, but still not
be general.

Personally, I would much rather see the WG spend effort on things that really are generic,
i.e., work with or without host firewalls, work with multiple RoT/TEE types, etc., rather
than seeing an explosion of point solutions.

Dave

From: RATS <[email-masked]> On Behalf Of Smith, Ned
Sent: Monday, November 11, 2019 10:12 AM
To: Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; Laurence Lundblade <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>
Cc: [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Agree

Ian

--

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

________________________________
From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: 11 November 2019 00:44
To: Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>>
Cc: Henk Birkholz <[email-masked]<mailto:[email-masked]>>; rats@ietf..org<mailto:rats@ietf..org> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 11 Nov 2019 20:16:58 -0800

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:
EAT Attestation Token
TPM Token (that can be carried by HTTP and almost any conceivable protocol extension)
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 <[email-masked]> wrote:
>

---

From: Dave Thaler <[email-masked]>
Date: Tue, 12 Nov 2019 04:19:18 +0000

Ned Smith wrote:

> So far the group has used the term "EAT" to refer to both the information model and data serialization expressions.

I would rather see the term EAT (and any other terms ending in Token, like JWT and CWT) only be used to refer to

data serialization expressions, not the information model.

> When extending information model to YANG or some other serialization (e.g. ASN.1). Given the possibility for an IM

> expression to be realized by different serializations, what term should we give to the IM description?

That’s a fine question, and I don’t have any strong preference right now, other than to not use the same term as something else.

Offhand, my preference would be to not define a term, and just use Evidence and Attestation Result as the terms for

format-independent discussion.  I think it is useful to distinguish between Evidence vs Attestation Results in many cases.

And if you need to refer to both, then we can always use both together, such as “Evidence and Attestation Results”.

> The term "Claim" has been used extensively. Do we want to agree to use "claim" to refer to anything that is an IM
> expression in RATS and "Token" for any serialization (realization) even if it isn't a JWT or CWT?

I would say no. To me, a claim is one particular piece of information, where a “Token” or whatever else has a set of claims.

Dave

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 11 Nov 2019 21:57:28 -0800

Clarifying questions and comments.

Where did this table come from?

Is a firewall here a typical IP-level thing that filter Internet traffic? (If so, why is that relevant?). Or is it memory protection between the attestation host (e.g. RoT) and the other parts of the system? Something else?

What is privacy here? Is it the untrackability of attestations because they use ECDAA, shared keys or such? That is privacy in the web browser / GDPR sense.

One of them is not like the other: Firmware. It typically isn’t isolated and doesn’t have a CPU.

There are other isolating execution environment approaches such as separate CPUs and virtualization, particularly Microsoft VBS.

LL

> On Nov 11, 2019, at 5:43 PM, Dave Thaler <dthaler=[email-masked]> wrote:
> 
>                         Requirements?

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 12 Nov 2019 07:15:52 +0000

> YANG I already being used to describe attestation flows and attestation related data. So the reason why is it is already deployed.

Do you have any pointers / references?
 
> YANG has been used as an IM language but more commonly as a DML.

Do you have references?

/js

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 12 Nov 2019 09:21:06 +0100

Hi Dave,
hi all,

is it correct that the intent of tokens - in general - is that they have 
a life-span and are somehow like... certificates, but with a smaller 
life-cycle? The claims defined by the Web Token RFCs are indicating as 
such, I'd assume.

Having said that, the features we use are the object / tagged map 
structure, the continuous list of defined Claims & corresponding 
registry, and the imperative guidance how to use {C|J}OSE. In 
combination with the fact that all Web Token Claims are optional, we can 
use these features for purposes other than the original intent of tokens 
and that is okay. Simply calling them tokens, though, might be confusing 
to readers that already use tokens?

In conveyance protocols for RATS I would like to see at least three 
things defined and differentiated:

* the Interaction Models the protocols use, most prominent, 
challenge/response, time-based, and subscription,
* the Message (Content) that is conveyed, most prominent Evidence, 
Endorsements, Reference Values (aka Known Good Values), and Attestation 
Results, and
* the Roles between which Messages are conveyed via protocols, most 
prominent .

This is applicable to EAT (specific claim set serializations) and YANG 
(specific statements serializations, APIs, and conveyance protocols) or 
others - and unless there are really good reasons against this, I'd 
consider these definitions/categorizations a MUST.

After the discussions we had, I am a bit at a loss how to deal with "the 
same information elements used in different message types and content" 
or "how to not use the same term as something else" (aka the Information 
Model), I have to admit. I do not see a viable solution at the moment.

Viele Grüße,

Henk

On 12.11.19 05:19, Dave Thaler wrote:
> Ned Smith wrote:
> 
>  > So far the group has used the term "EAT" to refer to both the 
> information model and data serialization expressions.
> 
> I would rather see the term EAT (and any other terms ending in Token, 
> like JWT and CWT) only be used to refer to
> 
>  > When extending information model to YANG or some other serialization 
> (e.g. ASN.1). Given the possibility for an IM
> 
> That’s a fine question, and I don’t have any strong preference right 
> now, other than to not use the same term as something else.
> 
> Offhand, my preference would be to not define a term, and just use 
> Evidence and Attestation Result as the terms for
> 
> format-independent discussion.  I think it is useful to distinguish 
> between Evidence vs Attestation Results in many cases.
> 
> And if you need to refer to both, then we can always use both together, 
> such as “Evidence and Attestation Results”.
> 
>  > The term "Claim" has been used extensively. Do we want to agree to 
> use "claim" to refer to anything that is an IM
> I would say no. To me, a claim is one particular piece of information, 
> where a “Token” or whatever else has a set of claims.
> 
> Dave
>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Nov 2019 16:22:47 +0800

On 2019-11-12 3:52 a.m., Laurence Lundblade 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.

YANG is an information model (think ASN.1). 
It is for humans and for code generators, protocol inspectors, etc, it
is never bits on the wire.
It needs to be expressed somehow (XML, JSON, CBOR), which is akin to
BER/DER.
XML, JSON and CBOR all have signature standards (maybe more than one).
A specific claim could well have a complex set of information that it
conveys and that could be expressed in YANG, but I find it difficult to
imagine such a thing.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Nov 2019 16:28:00 +0800

> You’re saying YANG fills a gap that is similar to what OpenAPI/RAML fills?

I don't know what those things are.
I might say it was similar to CORBA, but I'd be dating myself and I
never really knew CORBA very well.

> 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).
>

CDDL could be used to explain how the YANG serialization to CBOR or JSON
worked.
But, CDDL is also not a bits-on-the-wire thing, it's also probably human
and code generator.
(Carsten says that this is not exclusive the case, anymore, but I think
having Turing complete
information modeling languages is a bad thing, and might lead to Daleks
Invasions and Cybermen Kings)

I would expect that an RFC or other industry document that detailed a
series of claims might use CDDL to describe the contents of the data
that made up the details of the claim.
But, again, for the code generators (whether human or machine)

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 12 Nov 2019 09:28:15 +0100

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.
> 
>   * Self-securing signed attestation token
>   * Token conveyance protocol
> 
> 
>  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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> YANG I already being used to describe attestation flows and 
>> attestation related data. So the reason why is it is already deployed.
>>
>> On 11/11/19, 13:33 PM, "RATS on behalf of Schönwälder, Jürgen" 
>> <[email-masked] <mailto:[email-masked]> on behalf of 
>> [email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>    Hi,
>>
>>> 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)?
>>>
>>> On 11/11/19, 11:52 AM, "RATS on behalf of Laurence Lundblade" 
>>> <[email-masked] 
>>> <mailto:[email-masked]><mailto:[email-masked]> on 
>>> behalf of [email-masked] 
>>> <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>>
>>> On Nov 11, 2019, at 11:47 AM, Laurence Lundblade 
>>> <[email-masked] 
>>> <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>>
>>> On Nov 10, 2019, at 9:20 PM, Michael Richardson 
>>> <[email-masked] 
>>> <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Tue, 12 Nov 2019 08:59:01 +0000

> YANG is an information model (think ASN.1).

YANG people believe YANG is used to define data models.

> It needs to be expressed somehow (XML, JSON, CBOR), which is akin to

This is what YANG people call an encoding (or representation) of
instance data (that conforms to a YANG schema). YANG today supports
XML and JSON, CBOR is in the making (but for a long time).

/js

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Nov 2019 17:38:25 +0800

> YANG people believe YANG is used to define data models.

Yes, I mis-spoke.

> XML and JSON, CBOR is in the making (but for a long time).

Well, yes, I'm using it on anima-constrained-voucher, and yes, it has
been a long time, but we are mostly done, so I think we can say that
CBOR is included.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 12 Nov 2019 17:44:55 +0800

> * EAT Uptime / YANG tpm ticks

Those aren't EATs, those are attributes of claims that an EAT could include.
If you are saying that we could write a YANG module describing those
claims, and that they could be used to describe both claims of an EAT,
but also results from a TPM 1.2/2.0 call, then I understand finally.  
> JOSE does not create a JWT. 

A JWT is a triple of three base64URL encoded objects, one of which is a
JOSE format signature.
We want COSE and JOSE, not CWT and JWT, I think.

> things here. Or am I missing something obvious?

In CBOR, binary is not encoded in any special way, so no issues, agreed.
If that argues for doing CBOR-only, I personally do not mind, but the WG
has been pretty clear about wanting both.

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 12 Nov 2019 11:10:31 +0100

> but also results from a TPM 1.2/2.0 call, then I understand finally.

Yes, that is basically a way to phrase the question, I think.

Specialized questions are: do we need to do that? Do we want to do that? 
Is it technically okay to instead convey opaque EAT blobs via a YANG 
statement?

And yes, those are not EATs :-) I was referring to the information 
elements and their serialization (statements & Claims) above.

---

From: "Smith, Ned" <[email-masked]>
Date: Tue, 12 Nov 2019 16:30:25 +0000

It wasn't my intention to assert that CDDL was a 'bits on the wire' format. 

On 11/12/19, 0:28 AM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 12 Nov 2019 09:56:41 -0800

> On Nov 12, 2019, at 12:22 AM, Michael Richardson <[email-masked]> wrote:
> 

Got that one totally wrong. I even knew everything you describe about YANG.

I still think it is better if we just stick to EAT / CWT / JWT claims described with CDDL as the way we define claims in RATS, except for a few TPM-specific claims. 

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 12 Nov 2019 10:35:44 -0800

An EAT would show up as a single statement in the RATS YANG module. The EAT would be opaque in the RATS YANG module. The RATS work group would not author any YANG to describe the claims described in the EAT document. 

The attester side implementation of this would:
Have code that creates CWT/COSE/CBOR formatted EAT tokens. This would probably be new code. Could also be JWT/JOSE/JSON.
Not need a TPM
Probably re use some existing libraries (JSON or XML or such) to implement what is described in the RATS YANG Module. That would not be anything to do with claims, so this part would exist primarily transport the opaque EAT.
I imagine if you were to use X.509 certificates with YANG, it would be really similar. The EAT is analogous to the X.509 certificate. There would be no YANG text authored to describe the internals of the X.509 certificate.

What I’ve described so far is what I want in the RATS YANG Module in order for it to be adopted.  The next paragraphs are about the idea of the TPM Token.

One way to describe my proposal is to split the current RATS YANG Module document into two.

A new TPM Token document would be created. It would describe a list of claims and a signature over those claims. This would be compatible with TPM signing. It would essentially be a serialization of the output of a TPM.

The RATS YANG Module document would have a large amount of its text replaced with a single statement that is for the transfer of either an EAT or a TPM Token.

LL

My thought is that EATs are opaque to the transport / conveyance protocol and that the YANG module should just describe a transport pr

> On Nov 12, 2019, at 12:28 AM, Henk Birkholz <[email-masked]> wrote:
> 
> 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 Nov 11, 2019, at 4:56 PM, Smith, Ned <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> On 11/11/19, 13:33 PM, "RATS on behalf of Schönwälder, Jürgen" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>    Hi,
>>> 
>>>> On 11/11/19, 11:52 AM, "RATS on behalf of Laurence Lundblade" <[email-masked] <mailto:[email-masked]><mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>>> 
>>>> On Nov 11, 2019, at 11:47 AM, Laurence Lundblade <[email-masked] <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>>> 
>>>> On Nov 10, 2019, at 9:20 PM, Michael Richardson <[email-masked] <mailto:[email-masked]><mailto:[email-masked]>> wrote:
>>>> 
>>>>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 12 Nov 2019 19:14:21 +0000

As a network equipment vendor, TEEP environments and EAT format work highlight interesting futures.  And I support these works on that basis.

On the other hand, TPMs are embedded today in routers.  And they are integrated to existing network operations applications.  However we have no standardized based industry management model.  And therefore today we see no applications which span equipment vendor types.

So the TPM based YANG has immediate applicability, and should be adopted.  

Eric

From: RATS, November 11, 2019 8:43 PM

space as follows:

                        Requirements?

      1  |  SGX         | No            | No      ||

      2  |  SGX         | No            | Yes     ||

      3  |  SGX         | Yes           | No      ||

      4  |  SGX         | Yes           | Yes     ||

     10  |  TPM         | No            | Yes     ||

     11  |  TPM         | Yes           | No      ||

     12  |  TPM         | Yes           | Yes     ||

     ... |   ...        |               |         ||

be general.

Dave

From: RATS <[email-masked] <mailto:[email-masked]> > On Behalf Of Smith, Ned
Sent: Monday, November 11, 2019 10:12 AM
To: Oliver, Ian (Nokia - FI/Espoo) <[email-masked] <mailto:[email-masked]> >; Laurence Lundblade <[email-masked] <mailto:[email-masked]> >; Nancy Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; Henk Birkholz <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

 

Agree

Ian

-- 

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

  _____  

From: Laurence Lundblade <[email-masked] <mailto:[email-masked]> >
Sent: 11 November 2019 00:44
To: Nancy Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]> >
Cc: Henk Birkholz <[email-masked] <mailto:[email-masked]> >; rats@ietf..org <mailto:rats@ietf..org>  <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft 

On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]> > wrote:

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 12 Nov 2019 19:41:35 +0000

With YANG, it is possible to support both opaque transport of information, as well as extracting that opaque information from a chip contained within the attester.  We will need both supported.  

For an example of why, consider a local Wireless Access Point which gets signed GPS location from a chip: 

*	The Wireless Access Point will need to understand the GPS location because it might only legally be allowed to turn on various radio frequencies based on the country.
*	Remote devices might use YANG to ask the Wireless Access Point to only send signed proof of location if it turns out they are in a particular geography.

YANG models can support both opaque and explicitly typed data, even within the same model.  I expect that will be done in the cases described below.  It is also possible to have opaque data object with its internals YANG modeled and decipherable by the recipient of that opaque data.   If you want more details on how this can be done, check out: draft-ietf-netmod-yang-data-ext.

Thanks,
Eric

From: RATS, November 12, 2019 1:36 PM

*	Have code that creates CWT/COSE/CBOR formatted EAT tokens. This would probably be new code. Could also be JWT/JOSE/JSON.
*	Not need a TPM
*	Probably re use some existing libraries (JSON or XML or such) to implement what is described in the RATS YANG Module. That would not be anything to do with claims, so this part would exist primarily transport the opaque EAT.

 

LL

 

On Nov 12, 2019, at 12:28 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]> > wrote:

Hi Laurence,

Viele Grüße,

Henk

On Nov 11, 2019, at 4:56 PM, Smith, Ned <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>> wrote:

On 11/11/19, 13:33 PM, "RATS on behalf of Schönwälder, Jürgen" <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>> wrote:

   Hi,

   /js

-Ned

On 11/11/19, 11:52 AM, "RATS on behalf of Laurence Lundblade" <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]>> wrote:

LL

On Nov 11, 2019, at 11:47 AM, Laurence Lundblade <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]>> wrote:

On Nov 10, 2019, at 9:20 PM, Michael Richardson <[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]><mailto:[email-masked]>> wrote:

Server                               Device
GetAttestationTypes —>

LL

_______________________________________________
RATS mailing list
[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rats

[email-masked] <mailto:[email-masked]>  <mailto:[email-masked]>

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 12 Nov 2019 12:21:59 -0800

Here’s three possible versions of the RATS YANG Module:
1) As is today, TPM only, no separation of transport from attestation token. no EAT
2) As is today + EAT transport. There’s separation of transport from token format for EAT, but not for TPM attestation
3) Full separation of transport from attestation token.  The RATS YANG modules focuses on transport

I want a commitment to 2) or 3) for adoption. I agree that RATS should support some YANG-based means for attestation for routers.

Dave seems to be saying none at all.

Which do you want?  My guess is one MUST be pursued by RATS. You’d be happy with 1) and probably 2). 3) is probably still to fuzzy to say.

LL

> On Nov 12, 2019, at 11:14 AM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Smith, Ned
> To: Oliver, Ian (Nokia - FI/Espoo) <[email-masked] <mailto:[email-masked]>>; Laurence Lundblade <[email-masked] <mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>; Henk Birkholz <[email-masked] <mailto:[email-masked]>>
> On 11/10/19, 23:21 PM, "RATS on behalf of Oliver, Ian (Nokia - FI/Espoo)" <[email-masked] <mailto:[email-masked]> on behalf of [email-masked] <mailto:[email-masked]>> wrote:
>  
> From: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> To: Nancy Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]>>
> Cc: Henk Birkholz <[email-masked] <mailto:[email-masked]>>; rats@ietf..org <mailto:rats@ietf..org> <[email-masked] <mailto:[email-masked]>>
> On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Tue, 12 Nov 2019 21:26:36 +0000

Hi Laurence,

From: Laurence Lundblade, November 12, 2019 3:22 PM

<Eric> It depends on what you mean by transport.  YANG models are supposed to be transport agnostic.  E.g., information in YANG models is commonly transported over NETCONF+XML and RESTCONF+JSON.  But NETCONF and RESTCONF themselves are built on transactional interactions which might or might not align with how EAT information is intended to be requested and distributed from a source.

The nuance for me here is YANG ecosystems exist at the operations boundary of a piece of network equipment.  And EAT at the boundary of a chip.    In both cases some transport structure needs to instigate the transfer of the desired information.  This is the problem I believe you are referencing when you talk in 3) about the full separation of transport.

<Eric> I certainly would love to see 2) & 3) done too.  Personally I don't need it until routers have chips supporting EAT.  As a result, I don't 1), 2), & 3) should be in single model.  The reason is as follows:  I don't know of a customer yet who would pull both TPM2 and EAT from a single device.  So why make the model implementer care to understand a more complex model than necessary?

<Eric>  It seems that way.  And this doesn't makes sense to me. 

<Eric> I believe 1) MUST be pursed.  I think 2) should be pursed. 

Eric

LL

On Nov 12, 2019, at 11:14 AM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> > wrote:

Eric

space as follows:

                        Requirements?

      1  |  SGX         | No            | No      ||

      2  |  SGX         | No            | Yes     ||

      3  |  SGX         | Yes           | No      ||

      4  |  SGX         | Yes           | Yes     ||

     10  |  TPM         | No            | Yes     ||

     11  |  TPM         | Yes           | No      ||

     12  |  TPM         | Yes           | Yes     ||

     ... |   ...        |               |         ||

be general.

Dave

 

Agree

Ian

-- 

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

  _____  

 

LL

---

From: Dave Thaler <[email-masked]>
Date: Wed, 13 Nov 2019 00:20:18 +0000

Response below…

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Henk Birkholz
Sent: Tuesday, November 12, 2019 12:21 AM
To: Dave Thaler <[email-masked]>; Smith, Ned <[email-masked]>; Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Hi Dave,

hi all,

is it correct that the intent of tokens - in general - is that they have a life-span and are somehow like... certificates, but with a smaller life-cycle? The claims defined by the Web Token RFCs are indicating as such, I'd assume.

I think so too, yes.

Having said that, the features we use are the object / tagged map structure, the continuous list of defined Claims & corresponding registry, and the imperative guidance how to use {C|J}OSE. In combination with the fact that all Web Token Claims are optional, we can use these features for purposes other than the original intent of tokens and that is okay. Simply calling them tokens, though, might be confusing to readers that already use tokens?

Not sure I understand your point (e.g., who’s “we”?).  Can you rephrase?

In conveyance protocols for RATS I would like to see at least three things defined and differentiated:

* the Interaction Models the protocols use, most prominent, challenge/response, time-based, and subscription,

* the Message (Content) that is conveyed, most prominent Evidence, Endorsements, Reference Values (aka Known Good Values), and Attestation Results, and

* the Roles between which Messages are conveyed via protocols, most prominent .

This is applicable to EAT (specific claim set serializations) and YANG (specific statements serializations, APIs, and conveyance protocols) or others - and unless there are really good reasons against this, I'd consider these definitions/categorizations a MUST.

Personally, I don’t see a strong requirement to differentiate an interaction model from a message descriptions, in any concrete solution/protocol document.

(Some people are just confused by extra complexity in documents that isn’t necessary to understand and implement the protocol, and I’m all for avoiding gratuitous complexity.)

I’m fine with docs that do so, and I’m fine with docs that don’t.

I agree it is important to define which Roles (Attester, Verifier, Relying Party…) a message is intended to go between.

As elaborated on in my doc, I disagree however that “Reference Values (aka Known Good Values)” should be a top-level concept, but is fine as a common example.

In general, exact match is too narrow a concept for the types of security policies I see people wanting to do, which may be exact match, may be a test that a claimed value is a member of a specified set of values,

may be range checks, may be even more complex logic.

After the discussions we had, I am a bit at a loss how to deal with "the same information elements used in different message types and content"

or "how to not use the same term as something else" (aka the Information Model), I have to admit. I do not see a viable solution at the moment.

Sounds like more work is needed on solutions.

Dave

Viele Grüße,

Henk

>  > When extending information model to YANG or some other

> serialization (e.g. ASN.1). Given the possibility for an IM

>  > expression to be realized by different serializations, what term

> should we give to the IM description?

> And if you need to refer to both, then we can always use both

> together, such as “Evidence and Attestation Results”.

> use "claim" to refer to anything that is an IM  > expression in RATS

> and "Token" for any serialization (realization) even if it isn't a JWT

> or CWT?

RATS mailing list

[email-masked]<mailto:[email-masked]>

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C3fc94f07304b4be4ef2f08d767494ed4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637091436880001200&amp;sdata=xcH8jcr%2FEqf7etD%2BC3%2Brmeu3tB1%2FR3XOkXEwQhENk7Y%3D&amp;reserved=0

---

From: Dave Thaler <[email-masked]>
Date: Wed, 13 Nov 2019 00:22:49 +0000

Thanks Michael, I realize I may have had some confusion on YANG terminology (in my first response to Ned) as well in retrospect. 
Your explanation is great for understanding.

Thanks,
Dave

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Michael Richardson
Sent: Tuesday, November 12, 2019 12:23 AM
To: Laurence Lundblade <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

> here, not as a way to format a signed attestation token.

YANG is an information model (think ASN.1). It is for humans and for code generators, protocol inspectors, etc, it is never bits on the wire.
It needs to be expressed somehow (XML, JSON, CBOR), which is akin to BER/DER.
XML, JSON and CBOR all have signature standards (maybe more than one).
A specific claim could well have a complex set of information that it conveys and that could be expressed in YANG, but I find it difficult to imagine such a thing.

---

From: Dave Thaler <[email-masked]>
Date: Wed, 13 Nov 2019 00:56:31 +0000

Answers to clarifying questions…

From: Laurence Lundblade <[email-masked]>
Sent: Monday, November 11, 2019 9:57 PM
To: Dave Thaler <[email-masked]>
Cc: Smith, Ned <[email-masked]>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

I created it based on my interpretation of statements made in draft-birkholz-rats-basic-yang-module and
draft-fedorkow-rats-network-device-attestation-01 (and based on Guy’s responses on this list to confirm/correct my understanding).
Of course since there seems to be some confusion about what YANG is, my statement about the applicability of the yang draft
may or may not be correct.   I will say I believe it is correct when the YANG module is used by any pull-based protocol like
netconf or restconf, which is the model draft-fedorkow-rats-network-device-attestation discusses as I understand it.
If you can encapsulate the YANG information inside some existing in-band protocol like 802.1x then it would be more aligned
with what I’m arguing since that would be usable both with and without the presence of a host firewall.

Yes it’s a typical IP-level thing.  (See RFC 7288 for lots of IAB discussion on that term.)
It’s relevant because if the only way for a Relying Party to get attestation information is to separately ask the attester
via a different protocol that the attester has to accept unsolicited inbound communication for, then a host firewall whose
job it is to prevent unsolicited inbound communication will of course prevent that solution from working at all.
Whereas a mechanism that passes attestation information in a protocol the Attester initiates anyway, such as 802.1x
or any similar network authentication protocol, such conveyance will work with or without a firewall, and so be far more
broadly usable for network authentication, and be usable both by routers and non-routers, with a single common solution,
rather than having a bunch of point solutions.

Ask Guy, it’s from his draft ☺
But my own interpretation is that privacy means the network cannot tell that the specific device now is Bob’s or Alice’s device,
and cannot tell that the specific device is the same device it saw yesterday.
See section 5 of RFC 6973.

Various solutions at various layers may or may not provide this property.
For example, MAC address randomization is an example of a technique to try to provide this property, and
draft-ietf-dnssd-prireq is an example of IETF work on providing this for DNS service discovery.
Intel’s EPID arguably addresses this for their scenarios, the general point being that
It is possible to attest to the trustworthiness of a device without revealing a unique device identifier.
Whether that’s a requirement or not depends on the use case, the administrator, the device, etc.
But draft-fedorkow-rats-network-device-attestation is constrained only to cases that don’t need privacy,
and my reading (perhaps incorrect) is that draft-birkholz-rats-basic-yang-module
also has that scope, in that it reveals some device identifier.   If it is changed so that is optional,
then its applicability widens.  I am just arguing for broad solutions, not narrow ones.

ALL of them are not like the others.   Every one is unique in some way.  But people want attestation in all of these scenarios.
They don’t provide the same degree of strength, but that doesn’t mean you can’t have common protocols/techniques/claim formats/etc.

Agree, there are more RoT types in general, and I argue for solutions that can easily be extended to more of them.
(By “Firmware” I meant what you call “virtualization”, not just Microsoft VBS in particular, but just the notion that a hypervisor or firmware
provides some level of attestation guarantees for higher layer components.)

I didn’t mention AMD in the table either, and AMD has things like AMD-SEV and the recently announced<https://www.youtube.com/watch?v=yr56SaJ_0QI&list=PLbzoR-pLrL6rF8E5yyknJzrVQaHeYszTR&index=16&t=0s> SEV-SNP,
and for RISC-V there’s Hex-Five’s MultiZone.  Etc.

Dave

LL

On Nov 11, 2019, at 5:43 PM, Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]>> wrote:

                        Requirements?

---

From: Dave Thaler <[email-masked]>
Date: Wed, 13 Nov 2019 01:06:41 +0000

For my thoughts on the more general topic here, see https://tools.ietf.org/html/draft-thaler-rats-architecture-01#section-4

Here’s one relevant paragraph (but the other paragraphs there are relevant too):
   Especially for constrained nodes, however, there is a desire to
   minimize the amount of parsing code needed in a Relying Party, in
   order to both minimize footprint and to minimize the attack surface
   area.  So while it would be possible to embed a CWT inside a JWT, or
   a JWT inside an X.509 extension, etc., there is a desire to encode
   the information natively in the format that is natural for the
   Relying Party.

Dave

From: RATS <[email-masked]> On Behalf Of Laurence Lundblade
Sent: Monday, November 11, 2019 11:53 AM
To: Michael Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

LL

Server                               Device
GetAttestationTypes —>

LL

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Nov 2019 18:59:30 +0800

On 2019-11-13 4:21 a.m., Laurence Lundblade wrote:
> 2) As is today + EAT transport. There’s separation of transport from
> token format for EAT, but not for TPM attestation

So, this YANG model (which an abstraction of an RPC mechanism of
RESTCONF, etc.) would have one or more leaves from which a token could
be collected by a read operation.

Is it arbitrary or specific?
Just whatever token the device happens to be able to provide?  JSON/JWT
or CBOR/CWT? Both?
Or do you want a series of leafs, one per claim type, which returns an
EAT when that claim filled in?
Do you want to support combinations of claims? 
How is a freshness nonce provided for the EAT?  Do we write to another
leaf?
If so, are there other any other leafs that are writeable?  Will you
write the security considerations section for that part?
Is it okay for the people who'd like to do things with TPM devices to
wait an extra 2-3 years while we sort these things out?

> I want a commitment to 2) or 3) for adoption. I agree that RATS should
> support some YANG-based means for attestation for routers.

Wanting to have a transport for EAT tokens doesn't mean that we have to
have the TPM YANG model support EAT.
It's like you are demanding that the *HTTP* protocol spec must support
youtube URLs.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Nov 2019 19:04:40 +0800

> I still think it is better if we just stick to EAT / CWT / JWT claims described with CDDL as the way we define claims in RATS, except for a few TPM-specific claims. 

Nothing I've said is opposed to that.
I rather agree.  I don't think that EAT is complex enough to require a
definition in YANG.

But, that also has nothing to do with whether we'd need a YANG signing
standard if we defined them in YANG.
We wouldn't, because we'd be signing JSON, CBOR (or XML if someone
insisted) using JSOE and COSE.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Nov 2019 19:11:55 +0800

On 2019-11-12 4:28 p.m., Henk Birkholz wrote:
> convey opaque EATs via a single statement. Or is it necessary to
> create YANG statements for each well-defined EAT Claim?

Mostly, i want to answer that: It's not a well formed question.
Yes, we can have a YANG leaf called "eat" that is of type binary, and
returns some serialization of a EAT.
But, I don't think it does anything at all useful.

Yes, we can define each claim type in terms of YANG (describing the data
in YANG types, so "uptime" would have some kind of interval value, and
boottime would have a date type), and then we could use YANG groupings
to build composite sets of claims that when serialized as a group, would
represent a single token.  We have to do this for each use case I
think.  So users of each use case would wind up with their own profile
document, and we'd probably share no code at all.
With care and a lot of fore-thought the result could be less destructive
than the disaster that
X500->509->509v3->PKIX->six-broken-profiles-for-specific-applications
has given us.  Less destructive in the way that hurricanes tend to be
less destructive than asteroid strikes.

I have no interest in going that way.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Nov 2019 19:13:54 +0800

On 2019-11-13 2:35 a.m., Laurence Lundblade wrote:
> An EAT would show up as a single statement in the RATS YANG module.
> The EAT would be opaque in the RATS YANG module. The RATS work group
> would not author any YANG to describe the claims described in the EAT
> document. 
>
>   * Have code that creates CWT/COSE/CBOR formatted EAT tokens. This
>     would probably be new code. Could also be JWT/JOSE/JSON.
>   * Not need a TPM
>   * Probably re use some existing libraries (JSON or XML or such) to
>     implement what is described in the RATS YANG Module. That would
>     not be anything to do with claims, so this part would exist
>     primarily transport the opaque EAT.
>

And the Attester would then use RESTCONF to ....

Please fill this sentence, because that's what having EATs in a YANG
(RPC, data-in-motion) module means.

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 13 Nov 2019 11:14:17 +0000

> insisted) using JSOE and COSE.

I am still confused but so far for me it may make sense to have the
following:

- A YANG defined transport for "tokens" which likely treats tokens as
  opaque objects.

- A way to include arbitrary YANG defined data as claims in some form
  of "tokens" that can carry YANG defined data. There is lots of stuff
  defined in YANG models that may be reused as claims.

- Whether we need a YANG defined "token" format is unclear to me. It
  is also unclear to me why we would need it specifically for TPMs.

While there is a lot of talk here about different kinds of "token"
recently, I note that this term is not defined in
draft-birkholz-rats-architecture-03.txt nor in
draft-thaler-rats-architecture-01.txt.

/js

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Nov 2019 19:15:08 +0800

On 2019-11-13 3:41 a.m., Eric Voit (evoit) wrote:
>
> With YANG, it is possible to support both opaque transport of
> information, as well as extracting that opaque information from a chip
> contained within the attester.  We will need both supported. 
>
>  
>
>   * The Wireless Access Point will need to understand the GPS location
>     because it might only legally be allowed to turn on various radio
>     frequencies based on the country.
>   * Remote devices might use YANG to ask the Wireless Access Point to
>     only send signed proof of location if it turns out they are in a
>     particular geography.
>

Where is the EAT token in this case?
Remember that's it's opaque binary.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Nov 2019 19:24:10 +0800

> - A YANG defined transport for "tokens" which likely treats tokens as

okay, and we need this in the same document (the same model?) as the TPM
stuff?

I think that the process works okay for TPM, because we don't really
expect the system that hosts the RESTCONF interface to actually use the
RESTCONF interface to talk to the TPM.  We are just providing a gateway
to it.

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 13 Nov 2019 12:25:21 +0100

One reason for this - and I tried to express that carefully - is that 
just using the word "token" could be very confusing. We are using 
"Claim" as a synonym to "Assertion" at the moment. Outside of the IETF 
that makes a lot of sense. Inside the IETF, we still have to be a bit 
careful here, as "Claim" is well defined in Web Tokens - and it is a 
data model term (basically: a specific key value representation).

An EAT is a CWT (or JWT, not the point). So both are Claim sets that 
compose tokens. The architecture is intended to be representation (I am 
using this term to dance around the sanity rending 
serialization/encoding words, and to spare Rich some of the pain) 
agnostic. Claims in the architecture are therefore representation 
agnostic, too. Claims in tokens - by RFC definition - are not.

I am not a super big fan of this compromise, but it found consensus, 
removed a blocker, and we were able to progress.

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Nov 2019 19:28:00 +0800

On 2019-11-12 6:10 p.m., Henk Birkholz wrote:
> Specialized questions are: do we need to do that? Do we want to do
> that? Is it technically okay to instead convey opaque EAT blobs via a
> YANG statement?

Sorry to be more pendantic.
Do you mean: Is it okay to convey attributes of claims that an EAT could
include as blobs in a YANG model?
Or you mean: Is it okay to convey a binary serialization (say to CWT) of
an EAT in a binary blog in a YANG model?

(The answer to both is yes.  I don't know if it's useful)

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 13 Nov 2019 11:32:29 +0000

> okay, and we need this in the same document (the same model?) as the TPM

Likely not.
 
> RESTCONF interface to talk to the TPM.  We are just providing a gateway

So which applications are using this RESTCONF interface? Can I somehow
relate this back to the architecture models? Henk's doc seems to be
telling me that the idea is that $something likes to retrieve
"evidence" by invoking YANG RPCs. So what is $something and why is
the evidence TPM specific?

/js

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 13 Nov 2019 12:39:17 +0100

For convenience of some readers, please find the reply at the bottom.

> (The answer to both is yes.  I don't know if it's useful)

Isn't that supposedly my job?

To the point. I meant: Is it okay to convey a binary serialization (say 
to CWT) of an EAT in a binary blog in a YANG model?

Why am I asking that? (well, actually now you did)

YANG modules thrive on well defined semantics for each statement. I just 
want to make sure that it is okay to convey an unknown composition of 
Claims (opaque semantics) via the web token format in a YANG module 
statement.

Laurence brought up a good example, I think. If "Identity Document" is 
good enough. Probably "Attestation Evidence" is good enough, too.

To comment on Michael's quote: Do "we need this in the same document 
(the same model?) as the TPM stuff?". I think "need" would be a very 
strong word here and therefore I would not recommend to make it 
mandatory and impose more code on YANG datastores/rpcs.

Viele Grüße,

Henk

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Wed, 13 Nov 2019 11:44:44 +0000

On Wed, Nov 13, 2019 at 12:25:21PM +0100, Henk Birkholz wrote:
> One reason for this - and I tried to express that carefully - is that just
> using the word "token" could be very confusing. We are using "Claim" as a
> synonym to "Assertion" at the moment. Outside of the IETF that makes a lot
> of sense. Inside the IETF, we still have to be a bit careful here, as
> "Claim" is well defined in Web Tokens - and it is a data model term
> (basically: a specific key value representation).

I looked into JWT and I think I roughly know what they mean by claim.
Now we have "assertion" (also not defined in your architecture draft).
Hmm.
 
> An EAT is a CWT (or JWT, not the point). So both are Claim sets that compose
> tokens. The architecture is intended to be representation (I am using this
> term to dance around the sanity rending serialization/encoding words, and to
> spare Rich some of the pain) agnostic. Claims in the architecture are
> therefore representation agnostic, too. Claims in tokens - by RFC definition
> - are not.

To me, it seemed like in JWT, we have 'sets of claims' and then these
claim sets are serialized into a string representation ('serialized
sets of claims') and the serialization is finally digitally signed and
encrypted, giving us a token. This works for me.

The notion of "claim sets that compose token" confuses me. If I compose
token, I get a "set of tokens". Yes, indirectly I get also a union(?)
of the claim sets included in the tokens.

Anyway, we need to get terminology worked out or we will not
understand what we are doing or worse we agree on something but
people interpret the agreement differently...

> I am not a super big fan of this compromise, but it found consensus, removed
> a blocker, and we were able to progress.

Progress is when we all agree on the same thing.

/js

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 13 Nov 2019 12:55:29 +0100

Please find comments and replies in-line.

> Now we have "assertion" (also not defined in your architecture draft).

Yes. I am sorry it is this way. If you have a look at ITU-T 1252 Section 
6.6 (free reference here: 
https://www.itu.int/SG-CP/example_docs/ITU-T-REC/ITU-T-REC_E.pdf) it is 
not that bad. But that is "outside IETF". Not every Attestation 
Evidence, Endorsement or (let's not call it Reference Value to address 
Dave's comment, but) Appraisal Policy? is using "Web Token Claims", they 
all use Assertions. We will add text that highlights that in the scope 
of the architecture these are synonyms and not the Web Token Claims.

> of the claim sets included in the tokens.

Bad wording. Readability. My weak spot as it seems. What I meant was 
that (literally) a set of Claims in a JSON object compose a Web Token. 
Very simple nothing more :) I think we mean the same. Please correct me, 
if I am wrong.

> people interpret the agreement differently...

We are in wild agreement here.

> Progress is when we all agree on the same thing.

There was. At some point. If it is not anymore, we can make this an 
issue in the upcoming converged architecture I-D.

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 13 Nov 2019 08:42:06 -0800

Understood and agree with your firewall and privacy explanations.

> On Nov 12, 2019, at 4:56 PM, Dave Thaler <dthaler=[email-masked]> wrote:
> 
> (By “Firmware” I meant what you call “virtualization”, not just Microsoft VBS in particular, but just the notion that a hypervisor or firmware provides some level of attestation guarantees for higher layer components.)

I think of firmware as some very basic boot-type software that is in ROM or in flash memory. When updated, it is usually by some re flashing or factory reset operation.  A hypervisor is definitely not what I think of as firmware.

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 13 Nov 2019 10:07:02 -0800

My version of technology bases for attestation is something like this:

Router/Netconf World
Millions of devices. Currently TPM oriented. Long possible transition to EAT. YANG used to create very specific fine-grained interactions. No privacy issues.

Web Browser World
Billions of devices. Current attestation use is primarily WebAuthN / FIDO. JWT is used heavily for authentication so would be more EAT oriented, but TPM attestation is supported in FIDO. Larger use of attestation may evolve. Fine-grained interactions are with WebAPIs (Javascript) (sort of parallel to YANG for routers). Big privacy issues.

Mobile App World
Billions of devices. Main attestation use is Android’s Keystore. This is EAT-like, but based on X.509. Fine grained interactions are Android APIs. I may be out of date, but so far IoS doesn’t do attestation. Privacy issues vary by app.

IoT World
Billions of devices most likely going to trillions. Attestation is a critical enabling feature in this world. There are lots of protocols and formats involved. TPMs are too expensive for many of these, but are probably in use somewhere. No privacy issues for a large portion of this world.

The router world is the smallest, but it is “well represented” because this is the IETF.

I see EAT as applicable to all these worlds, where the YANG module is just for the smallish router world. So I mostly agree with Dave about proportions, however this is the IETF where YANG modules are created.  (Maybe I should go join the W3C world and work on attestations APIs for browsers after RATS is done).

LL

> On Nov 11, 2019, at 5:43 PM, Dave Thaler <[email-masked]> wrote:
>

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 14 Nov 2019 14:06:01 +0000

> I see EAT as applicable to all these worlds, where the YANG module is just for the smallish router world. So I mostly agree with Dave about proportions, however this is the IETF where YANG modules…

If EAT is the common format for "token", then it does not make sense
to me to define a YANG version of it. It may make sense to carry EAT
token over protocols such as NETCONF or RESTCONF and to have a YANG
module defining this may make sense for the networking device world.
This is then a definition of an interaction protocol, but not the
token format itself.

If EAT is the common format for "token", then it may make sense to be
able to include "claims" that are YANG defined data. That may be an
extension of the core EAT definition (but EAT would have to allow for
such an extension to work). There is a lot of formally defined data in
YANG modules that would be convenient to reuse as claims in a
networking world.

/js

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 14 Nov 2019 16:02:53 +0100

Hi Jürgen,

I think this is very useful input.

On the list, Laurence and I already started to discuss Claims for "YANG 
modeled data" and Claims for "TPM modled data" (referred to as tpm 
tokens recently).

The remaining questions are about: What do you think is the upcoming/TBD 
impact on the current YANG module for challenge-response RATS?

Leveraging YANG modeled data comes up again and again. Maybe there is 
good approach here.

The TPM Interface based YANG Module does not simply convey native TPM 
structure, but decomposes them down the values that are useful and 
common on the management plane because the building blocks themselves 
have well defined semantics (always ensuring canonical re-composition).

Viele Grüße,

Henk

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 14 Nov 2019 16:02:02 +0000

Hi Jürgen,
Hi Henk,

What routers need is exactly what you said.  
 - currently: the retrieval of TPM originated/signed quotes.   
 - in the future: the retrieval EAT Tokens

Knowing when to retrieve these items is a function of the value of specific claims inside those structures.  For example, I might want to use RFC-8641 to make a YANG Subscription to a router so that I will be pushed the latest TPM quote when a specific PCR changes.  For this to work in the router world, we must have the structures of Quotes/Tokens exposed by a YANG model.

Eric

> modeled data" and Claims for "TPM modled data" (referred to as tpm tokens
> recently).
> 
> >> I see EAT as applicable to all these worlds, where the YANG module is just
> for the smallish router world. So I mostly agree with Dave about proportions,
> however this is the IETF where YANG modules are created.  (Maybe I should
> go join the W3C world and work on attestations APIs for browsers after RATS
> is done).
> >>
> >

---

From: "Smith, Ned" <[email-masked]>
Date: Thu, 14 Nov 2019 20:00:45 +0000

@Eric Voit (evoit) Is this suggesting that RATS architecture should define a token-like DM structure that is a *request* "token" having only tags identifying interesting claims while a *response* "token" would have claims with data values populated?

On 11/14/19, 8:02 AM, "Eric Voit (evoit)" <[email-masked]> wrote:

    Hi Jürgen,
    Hi Henk,

    
    Eric

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 14 Nov 2019 20:42:42 +0000

My belief is that a Relying Party will rarely want the full universe of signed claims coming from some Attester's chip.   We need ways to pre-filter the results.  How would we do this without a model?

To fill this need, I always hoped that EAT claims could become leafs of some future YANG data model.  This would allow GET and SUBSCRIBE requests to be made to an Attester.  What would be returned to the Relying Party would be the signed results of interest from some chip within the Attester.  

I have no position on whether the WG wants to integrate GET and SUBSCRIBE requests so that they can provision claims are ultimately placed within the EAT token.

Eric

> @Eric Voit (evoit) Is this suggesting that RATS architecture should define a
> token-like DM structure that is a *request* "token" having only tags
> identifying interesting claims while a *response* "token" would have claims
> with data values populated?
> 
>     Knowing when to retrieve these items is a function of the value of specific
> claims inside those structures.  For example, I might want to use RFC-8641 to
> make a YANG Subscription to a router so that I will be pushed the latest TPM
> quote when a specific PCR changes.  For this to work in the router world, we
> must have the structures of Quotes/Tokens exposed by a YANG model.
> 
>     Eric
> 
>     > Hi Jürgen,
>     >
> tokens

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Fri, 15 Nov 2019 00:44:02 +0000

Hi all,
I totally agree with Jurgen that RATS for network devices is not only the token format, but also an interaction protocol. So the netconf + YANG provide a very good solution set.
One example is that we may need the yang pub/sub & push mechanism for the remote attestation for some reason. If you are interested, we have a new individual draft about it:
https://tools.ietf.org/html/draft-xia-rats-pubsub-model-01

B.R.
Frank

-----邮件原件-----
发件人: RATS [mailto:[email-masked]] 代表 Sch?nw?lder, Jürgen
发送时间: 2019年11月14日 22:06
收件人: Laurence Lundblade <[email-masked]>
抄送: Smith, Ned <[email-masked]>; Henk Birkholz <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; Dave Thaler <[email-masked]>; [email-masked]
主题: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

> I see EAT as applicable to all these worlds, where the YANG module is just for the smallish router world. So I mostly agree with Dave about proportions, however this is the IETF where YANG modules…

If EAT is the common format for "token", then it does not make sense to me to define a YANG version of it. It may make sense to carry EAT token over protocols such as NETCONF or RESTCONF and to have a YANG module defining this may make sense for the networking device world.
This is then a definition of an interaction protocol, but not the token format itself.

If EAT is the common format for "token", then it may make sense to be able to include "claims" that are YANG defined data. That may be an extension of the core EAT definition (but EAT would have to allow for such an extension to work). There is a lot of formally defined data in YANG modules that would be convenient to reuse as claims in a networking world.

/js

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Fri, 15 Nov 2019 00:48:41 +0000

Hi Eric,
You are exactly expressing my mind here~~

B.R.
Frank

-----邮件原件-----
发件人: RATS [mailto:[email-masked]] 代表 Eric Voit (evoit)
发送时间: 2019年11月15日 0:02
收件人: Henk Birkholz <[email-masked]>; Schönwälder, Jürgen <[email-masked]>; Laurence Lundblade <[email-masked]>
抄送: Nancy Cam-Winget (ncamwing) <[email-masked]>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; Smith, Ned <[email-masked]>; Dave Thaler <[email-masked]>; [email-masked]
主题: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Hi Jürgen,
Hi Henk,

Eric

> On the list, Laurence and I already started to discuss Claims for 
> "YANG modeled data" and Claims for "TPM modled data" (referred to as 
> tpm tokens recently).
> 
> The remaining questions are about: What do you think is the 
> upcoming/TBD impact on the current YANG module for challenge-response RATS?
> 
> for the smallish router world. So I mostly agree with Dave about 
> proportions, however this is the IETF where YANG modules are created.  
> (Maybe I should go join the W3C world and work on attestations APIs 
> for browsers after RATS is done).
> >>
> >
> > If EAT is the common format for "token", then it may make sense to 
> > be able to include "claims" that are YANG defined data. That may be 
> > an extension of the core EAT definition (but EAT would have to allow 
> > for such an extension to work). There is a lot of formally defined 
> > data in YANG modules that would be convenient to reuse as claims in 
> > a networking world.
> >
> > /js
> >
>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 15 Nov 2019 07:38:32 +0000

Netconf is not the only protocol supported by routers.
Routers also support IPv4, IPv6, link-layer protocols such as Ethernet, routing protocols, often things like DHCP relay, RADIUS, etc.

I have not yet seen a compelling reason to use a pull-based mechanism instead of a push-based mechanism via another protocol the routers already support.
The only reason I’ve heard so far is “because they support netconf and we’re used to it”, to which the counter argument is as above:
they support other things too and we’re used to them too.

In order to know who to pull data from, the Verifier has to have some indication from the Attester that triggers the attestation request
indicated as Step 1 in draft-fedorkow-rats-network-device-attestation.  So in reality, there has to be a step before step 1,
whereby the Attester does something that makes the Attester discoverable by the Verifier.   That step could have included the EAT or the TPM data
expressed in the YANG draft, or whatever else, and then you’ve avoided the need for netconf, and reduced the number of round trips,
improving latency and bandwidth.

If there is a compelling reason to support a pull-based mechanism, and we get consensus that we need it, then great.
But so far I haven’t heard one.

Dave

Sent: Wednesday, November 13, 2019 10:07 AM

Router/Netconf World

Web Browser World

Mobile App World

IoT World

LL

On Nov 11, 2019, at 5:43 PM, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:

                        Requirements?

Dave

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Smith, Ned
Sent: Monday, November 11, 2019 10:12 AM
To: Oliver, Ian (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>>; Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Agree

Ian

LL

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 15 Nov 2019 14:38:11 +0000

From: Dave Thaler, November 15, 2019 2:39 AM

<Eric> Below I would have said " Router/YANG" below rather than "Router/NETCONF".   

<Eric> Router vendors want push-based mechanisms too.  And NETCONF does push.  See RFC-8640 and RFC-5277.

<Eric> There is piles of documentation in the IETF and beyond detailing the reasoning and extent of consolidation on YANG for network management.    IETF, IEEE, MEF, OpenConfig, and others forums are defining these.  I wouldn't expect another anytime soon.  

NETCONF can support YANG. Other transports can support YANG.   The current draft under an adoption call does not specifically reference NETCONF.

<Eric> It is already possible to subscribe to existing proprietary YANG attestation models.  This requires zero extra round-trips.   The push can be leave the Attester in <1 sec.

<Eric> A YANG model supports both push and pull.  Application vendors want a standard attestation model.  That is why you have many network vendors authoring this YANG draft under the adoption call.

Honestly I don't understand the push-back.   This should be a no-brainer.

/Eric

Dave

From: Laurence Lundblade <[email-masked] <mailto:[email-masked]> > 
Sent: Wednesday, November 13, 2019 10:07 AM
To: Dave Thaler <[email-masked] <mailto:[email-masked]> >
Cc: Smith, Ned <[email-masked] <mailto:[email-masked]> >; Oliver, Ian (Nokia - FI/Espoo) <[email-masked] <mailto:[email-masked]> >; Nancy Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]> >; [email-masked] <mailto:[email-masked]> ; Henk Birkholz <[email-masked] <mailto:[email-masked]> >
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Router/Netconf World

Web Browser World

Mobile App World

IoT World

LL

On Nov 11, 2019, at 5:43 PM, Dave Thaler <[email-masked] <mailto:[email-masked]> > wrote:

space as follows:

                        Requirements?

      1  |  SGX         | No            | No      ||

      2  |  SGX         | No            | Yes     ||

      3  |  SGX         | Yes           | No      ||

      4  |  SGX         | Yes           | Yes     ||

     10  |  TPM         | No            | Yes     ||

     11  |  TPM         | Yes           | No      ||

     12  |  TPM         | Yes           | Yes     ||

     ... |   ...        |               |         ||

be general.

Dave

 

Agree

Ian

-- 

Dr. Ian Oliver

Cybersecurity Research

Nokia Bell Labs

+358 50 483 6237

  _____  

 

LL

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 15 Nov 2019 18:56:50 +0100

Hi Dave,

I'd like to highlight and elaborate on a very specific topic here:

Yes, routers (or network equipment ranging from AS routing to access 
layer distribution) most defiantly use "IPv4, IPv6, link-layer protocols 
such as Ethernet, routing protocols, often things like DHCP relay, 
RADIUS". I am in total agreement with that. This is (in itself) 
obviously true.

I'd dare to say every RATS solution will be using IPv4, IPv6, 
Industrial/Automotive EtherNet (please note the spelling) and various 
routing protocols & AAA solutions. That is true, too.

I'd like to add to that (with the exception of everything carrying EAP 
et. al. - that is an interesting path to explore) that it is very 
obvious that of course layer 2/3 & layer 4 solutions are involved 
always. But that this natural, yet coincidental, fact has an impact on 
all of rats RATS - via meaningful, structured synergized solution that 
are base on these assumption - seems like a non sequitur to me. Please 
help me understand.

Yes, the afore mentioned heterogeneous mix of things is used - literally 
by basically everything.

RATS TUDA for example could use ICMP Echo Requests. Is it possible? In 
Yokohama we concluded - sure! Is it an academic exercise and therefore a 
solution looking for a problem - probably yes.

What I am trying to say is: DHCP (via options), AAA (via extension) are 
used in the scope of routing equipment - sure! - and can be augmented 
with useful and believable evidence/attestation results about 
trustworthiness about a remote peer.

But is that a reason to not pursue the near term target of creating a 
unified procedure to establish unified trust relationships wrt 
trustworthiness between interconnected network equipment?

No.

It is actually very important to do this today. This neither implies 
niche solutions nor does it imply a lack of extensible later.

I am literally confuzzled by the notion that this approach is not 
addressing an immediate need today in a meaningful manner.

Dave, could you please elaborate why this is not useful, or 
counterproductive, or not in scope? I find your table to be a 
misrepresentation of the actual current relevance due to its initial 
column being types of RoT. Please help me to understand what you are 
trying to say here.

Viele Grüße,

Henk

On 15.11.19 15:38, Eric Voit (evoit) wrote:
> *From:* Dave Thaler, November 15, 2019 2:39 AM
> 
> Routers also support IPv4, IPv6, link-layer protocols such as Ethernet, 
> routing protocols, often things like DHCP relay, RADIUS, etc.
> 
> I have not yet seen a compelling reason to use a pull-based mechanism 
> instead of a push-based mechanism via another protocol the routers 
> already support.
> 
> The only reason I’ve heard so far is “because they support netconf and 
> we’re used to it”, to which the counter argument is as above:
> 
> <Eric> There is piles of documentation in the IETF and beyond detailing 
> the reasoning and extent of consolidation on YANG for network 
> management.    IETF, IEEE, MEF, OpenConfig, and others forums are 
> defining these.  I wouldn't expect another anytime soon.
> 
> NETCONF can support YANG. Other transports can support YANG.   The 
> current draft under an adoption call does not specifically reference 
> NETCONF.
> 
> In order to know who to pull data from, the Verifier has to have some 
> indication from the Attester that triggers the attestation request
> 
> indicated as Step 1 in draft-fedorkow-rats-network-device-attestation.  
> So in reality, there has to be a step before step 1,
> 
> whereby the Attester does something that makes the Attester discoverable 
> by the Verifier.   That step could have included the EAT or the TPM data
> 
> expressed in the YANG draft, or whatever else, and then you’ve avoided 
> the need for netconf, and reduced the number of round trips,
> 
> <Eric> It is already possible to subscribe to existing proprietary YANG 
> attestation models.  This requires zero extra round-trips.   The push 
> can be leave the Attester in <1 sec.
> 
> If there is a compelling reason to support a pull-based mechanism, and 
> we get consensus that we need it, then great.
> 
> <Eric> A YANG model supports both push and pull.  Application vendors 
> want a standard attestation model.  That is why you have many network 
> vendors authoring this YANG draft under the adoption call.
> 
> *From:* Laurence Lundblade <[email-masked] 
> <mailto:[email-masked]>>
> *Sent:* Wednesday, November 13, 2019 10:07 AM
> *To:* Dave Thaler <[email-masked] <mailto:[email-masked]>>
> *Cc:* Smith, Ned <[email-masked] <mailto:[email-masked]>>; 
> Oliver, Ian (Nokia - FI/Espoo) <[email-masked] 
> <mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) 
> <[email-masked] <mailto:[email-masked]>>; [email-masked] 
> <mailto:[email-masked]>; Henk Birkholz <[email-masked] 
> <mailto:[email-masked]>>
>     *Router/Netconf World*
>     Millions of devices. Currently TPM oriented. Long possible
>     transition to EAT. YANG used to create very specific fine-grained
>     interactions. No privacy issues.
> 
>     *Web Browser World*
> 
>     Billions of devices. Current attestation use is primarily WebAuthN /
>     FIDO. JWT is used heavily for authentication so would be more EAT
>     oriented, but TPM attestation is supported in FIDO. Larger use of
>     attestation may evolve. Fine-grained interactions are with WebAPIs
>     (Javascript) (sort of parallel to YANG for routers). Big privacy issues.
> 
>     *Mobile App World*
> 
>     Billions of devices. Main attestation use is Android’s Keystore.
>     This is EAT-like, but based on X.509. Fine grained interactions are
>     Android APIs. I may be out of date, but so far IoS doesn’t do
>     attestation. Privacy issues vary by app.
> 
>     *IoT World*
> 
>     Billions of devices most likely going to trillions. Attestation is a
>     critical enabling feature in this world. There are lots of protocols
>     and formats involved. TPMs are too expensive for many of these, but
>     are probably in use somewhere. No privacy issues for a large portion
>     of this world.
> 
> I see EAT as applicable to all these worlds, where the YANG module is 
> just for the smallish router world. So I mostly agree with Dave about 
>     As far as I can understand from
>     draft-birkholz-rats-basic-yang-module-01 and
> 
>     *From:* RATS <[email-masked] <mailto:[email-masked]>>
>     *On Behalf Of *Smith, Ned
>     *Sent:* Monday, November 11, 2019 10:12 AM
>     *To:* Oliver, Ian (Nokia - FI/Espoo) <[email-masked]
>     <mailto:[email-masked]>>; Laurence Lundblade
>     <[email-masked] <mailto:[email-masked]>>; Nancy
>     Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>; Henk Birkholz
>     <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject:* Re: [Rats] Call for adoption (after draft rename) for
>     Yang module draft
> 
>     Right. This implies the RATS “token” should support existing
>     “binary” formats as an encapsulation (signed by a second TA where
>     the TPM is a first TA) or as a conveyance (unsigned?) token.
>     Possibly, the only added value of the latter is a tag that
>     identifies it as a TPM binary format?
> 
>     firmware, measurement - x86 only etc) hardware root of trust in
>     common use, ie: practically all x86 machines,  The attestation
>     mechanisms provided are going to be around for a very long time.
> 
>     *From:* Laurence Lundblade <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* Nancy Cam-Winget (ncamwing) <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Henk Birkholz <[email-masked]
>     <mailto:[email-masked]>>; rats@ietf..org
>     <mailto:rats@ietf..org> <[email-masked] <mailto:[email-masked]>>
>     *Subject:* Re: [Rats] Call for adoption (after draft rename) for
>     Yang module draft
> 
>     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.
> 
>     Remote TPM attestations are useful and necessary the short run, but
>     are of very limited capability. I believe that EAT will replace TPM
>     attestations in the long run (maybe decades) because they are far
>     more expressive. I know others believe that too.
> 
>     Thus, I am opposed to adoption with the current TPM-only draft. I’d
>     be OK with the current draft and a promise to add EAT to it.
> 
>     LL
>

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 15 Nov 2019 11:13:46 -0800

Here’s a try at an analogy of EAT Tokens with X.509 Certificates.

For both the core of the definition is of the signed serialized data format. A set of fields / claims is defined in the core standard. That core standard is solely focused on the definition of those fields / claims and shouldn't get intertwined with other protocol definitions.

However, other protocols may decide to have fields that are the same as, maybe even defined in terms of the fields  / claims in the token / certificate. Those definitions are probably normative references to the fields / claims in the core token / certificate standard. TLS makes normative references to PKIX this way in section 4.2.5. I think this is perfectly reasonable things to do.

So, I have no trouble with some EAT claims being used in YANG designs, but I’d like it to be by reference to EAT. I’d also like EAT to only use CDDL for the data model and nothing else.

I think trying for a single information model that is common to EAT and YANG designs is too big, too much intertwining and is scary. It will lead to schedule interlocks between the documents.

Another reason is that I view router / YANG use of attestation as only one (well-represented) use case for EAT. YANG-based use cases shouldn’t be central to EAT's design. If we were to intertwine with YANG, maybe we should intertwine with JavaScript and a bunch of IoT protocols too.

LL

> On Nov 14, 2019, at 12:42 PM, Eric Voit (evoit) <[email-masked]> wrote:
> 
>> upcoming/TBD
>> just
>> proportions,

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 15 Nov 2019 20:30:25 +0100

Hi Laurence,

I would like to highlight this quote:

> I’d also like EAT to only use CDDL for the data model and nothing else

This is a significant change of turn. I would like to get more 
background about why you are not intending to use CDDL as an information 
model anymore and also why you think using CDDL as a data model 
specification is helpful to define Claims.

I can see the point that CDDL was not done when CWT was done. And I 
think that would be a good argument.

Alas, I am more at a loss now how we intend to deal with the IM aspect 
in RATS now. The thing we tried to propose initially was an English 
description. That did not find consensus and CDDL seemed to be the new 
approach. What are we doing now, if you are proposing to down-level CDDL 
to data model again, creates a vacuum. Are we going back to English text 
es we initially proposed? In retrospect, why are you dropping the 
approach your were advocating for quite some time?

My concern is that this accumulation of changes in a lot of places has 
the exact opposite effect of expedition - which was the primary 
incentive for the initial proposal, I think?

Having said that, cddl is literally a data definition language. I just 
think it is hard to argue why we are changing horses do close to the 
finish line. I do not object on a technical level, I just want to 
highlight that is a significant change of direction.

Viele Grüße,

Henk

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 15 Nov 2019 12:46:38 -0800

I want to do it like the current EAT document (current draft’s labeling of info and data model aside)
Normative definitional text per claim
CDDL per claim
Largely mechanical rules to go from CDDL to CBOR & JSON.

The subtleties of info vs data model escape me (and don’t seem that critical to me for the work at hand). The main thing I care about is that we one main definition of a claim that is not replicated and it can mechanically to go CBOR, JSON and maybe other serializations.

You can tell me how to label 1, 2, and 3 however you want and I’ll probably just use that in the EAT doc.

Also, by this I meant

>> I’d also like EAT to only use CDDL for the data model and nothing else

no YANG for the primal definition of claims and no YANG in the EAT document (see my other recent email with the X.509 analogy for suggestion on how to integrate with YANG expression of claims).

LL

> On Nov 15, 2019, at 11:30 AM, Henk Birkholz <[email-masked]> wrote:
> 
> Hi Laurence,
> 
> This is a significant change of turn. I would like to get more background about why you are not intending to use CDDL as an information model anymore and also why you think using CDDL as a data model specification is helpful to define Claims.
> 
> I can see the point that CDDL was not done when CWT was done. And I think that would be a good argument.
> 
> Alas, I am more at a loss now how we intend to deal with the IM aspect in RATS now. The thing we tried to propose initially was an English description. That did not find consensus and CDDL seemed to be the new approach. What are we doing now, if you are proposing to down-level CDDL to data model again, creates a vacuum. Are we going back to English text es we initially proposed? In retrospect, why are you dropping the approach your were advocating for quite some time?
> 
> My concern is that this accumulation of changes in a lot of places has the exact opposite effect of expedition - which was the primary incentive for the initial proposal, I think?
> 
> Having said that, cddl is literally a data definition language. I just think it is hard to argue why we are changing horses do close to the finish line. I do not object on a technical level, I just want to highlight that is a significant change of direction.
> 
> Viele Grüße,
> 
> Henk
> 
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 15 Nov 2019 22:23:21 +0000

From: Laurence Lundblade, November 15, 2019 3:47 PM
To: Henk Birkholz <[email-masked]>

1.	Normative definitional text per claim
2.	CDDL per claim
3.	Largely mechanical rules to go from CDDL to CBOR & JSON.

 

Also, by this I meant

This is fine with me.  Let's expose EAT claims within YANG objects when somebody needs this.

Eric

LL

On Nov 15, 2019, at 11:30 AM, Henk Birkholz <[email-masked] <mailto:[email-masked]> > wrote:

Hi Laurence,

Viele Grüße,

Henk

On Nov 14, 2019, at 12:42 PM, Eric Voit (evoit) <[email-masked] <mailto:[email-masked]> > wrote:

Eric

On 11/14/19, 8:02 AM, "Eric Voit (evoit)" <[email-masked] <mailto:[email-masked]> > wrote:

   Hi Jürgen,
   Hi Henk,

   Eric

Hi Jürgen,

tokens

recently).

upcoming/TBD

Leveraging YANG modeled data comes up again and again. Maybe there

is

good approach here.

The TPM Interface based YANG Module does not simply convey native

TPM

structure, but decomposes them down the values that are useful and
common on the management plane because the building blocks

themselves

Viele Grüße,

Henk

On Wed, Nov 13, 2019 at 10:07:02AM -0800, Laurence Lundblade

wrote:

just

proportions,

however this is the IETF where YANG modules are created.  (Maybe I

should

go join the W3C world and work on attestations APIs for browsers after

RATS

is done).

If EAT is the common format for "token", then it does not make sense
to me to define a YANG version of it. It may make sense to carry EAT
token over protocols such as NETCONF or RESTCONF and to have a

YANG

/js

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Sun, 17 Nov 2019 14:41:29 +0000

> But so far I haven’t heard one.

I hope I get the terminology right...

Research papers I have seen often use a challenge response model where
the 'verifier' sends a specific challenge that the 'attester' has to
answer (often with time constraints, minimizing the chance to relay
the challenge and such things). I think I pointed this out before.

Perhaps RATS does not need this form of challenge response attestation
and perhaps RATS is fine with the assumption that the attester somehow
knows which claims a verifier needs. But then it would be nice to
spell this out clearly so that people looking for challenge response
attestation attestation flows know that RATS is not for them.

/js

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Mon, 18 Nov 2019 08:35:51 +0000

> From: Schönwälder, Jürgen, November 17, 2019 9:41 AM
> 
> > If there is a compelling reason to support a pull-based mechanism, and we
> get consensus that we need it, then great.
> the 'verifier' sends a specific challenge that the 'attester' has to answer
> (often with time constraints, minimizing the chance to relay the challenge
> and such things). I think I pointed this out before.
> 
> Perhaps RATS does not need this form of challenge response attestation and
> perhaps RATS is fine with the assumption that the attester somehow knows
> which claims a verifier needs. But then it would be nice to spell this out
> clearly so that people looking for challenge response attestation attestation
> flows know that RATS is not for them.

Commercial products which do challenge/response type remote attestation currently exist.  E.g.: https://www.cisco.com/c/dam/en/us/td/docs/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/1-5-x/integrity_verification/release-notes_ver_275/Cisco_IV_App_RN_1_5_0_275.pdf 

I am hoping that RATS supports such applications.

Eric

---

From: Dave Thaler <[email-masked]>
Date: Mon, 18 Nov 2019 08:52:26 +0000

Challenge response can be done in a protocol initiated by the Attester, whether the Attester talks directly to the Verifier (passport model),
or indirectly via a Relying Party (normal background check model), without having the device needing to run a server of some sort like netconf or restconf.

At the hackathon, Nancy provided the first actual answer to my question I've seen, so I'll try to summarize it here.
I'm also going to use "device initiated" instead of "push", and "verifier initiated" instead of "pull" in case others have different definitions of push/pull than I intend.

Here's the two cases I've heard for device attestations that are verifier initiated (or "network initiated" if you prefer since these are network use cases):
Case 1) The network notices anomalous traffic coming from a device already on the network, which triggers a verifier to ask the device to attest to its health (which may have changed since it was last attested).  Here there might even be no Relying Party involved per se. 
Case 2) The network has not noticed anything odd, but wants to proactively query a device anyway, e.g., because the network's appraisal policy of what is considered trustworthy has just changed.  Again there might even be no Relying Party involved.

It was also pointed out at the hackathon that using a L2 protocol like EAP to trigger the device to attest, can work in cases where a host firewall is present.
However, not all devices/links use EAP.

Dave

-----Original Message-----
From: Schönwälder, Jürgen <[email-masked]> 
Sent: Sunday, November 17, 2019 10:41 PM
To: Dave Thaler <[email-masked]>
Cc: Laurence Lundblade <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; Smith, Ned <[email-masked]>; Henk Birkholz <[email-masked]>; [email-masked]
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Research papers I have seen often use a challenge response model where the 'verifier' sends a specific challenge that the 'attester' has to answer (often with time constraints, minimizing the chance to relay the challenge and such things). I think I pointed this out before.

Perhaps RATS does not need this form of challenge response attestation and perhaps RATS is fine with the assumption that the attester somehow knows which claims a verifier needs. But then it would be nice to spell this out clearly so that people looking for challenge response attestation attestation flows know that RATS is not for them.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.jacobs-university.de%2F&amp;data=02%7C01%7Cdthaler%40microsoft.com%7C6dddd58781f6453012ea08d76b6c40b3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637095985013049843&amp;sdata=0LoEUlR96Nh%2BAQfVufe7EWD7yY7qQkLyklZphmltb8c%3D&amp;reserved=0>

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 18 Nov 2019 16:59:15 +0800

> On Nov 18, 2019, at 4:52 PM, Dave Thaler <dthaler=[email-masked]> wrote:
> 

I would call the network the relying party. Attestation always has a relying party because there would be no point if no one cared (if a tree falls in a forest…)

LL

---

From: Dave Thaler <[email-masked]>
Date: Mon, 18 Nov 2019 09:04:01 +0000

If all you do is log, then there is no enforcement, and since the device doesn’t talk to the log, you can’t call the log a “Relying Party”.
I didn’t say there was never a Relying Party (if you do enforcement and kick the device off the network or something then yes there’s a Relying Party), I said “might be no”.
So I disagree with “Attestation always has a relying party” based on my discussion with Nancy.
Before the hackathon I would have agreed with that statement ☺

From: Laurence Lundblade <[email-masked]>
Sent: Monday, November 18, 2019 4:59 PM
To: Dave Thaler <[email-masked]>
Cc: "Schönwälder, Jürgen" <[email-masked]>; Smith, Ned <[email-masked]>; Henk Birkholz <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; [email-masked]
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

On Nov 18, 2019, at 4:52 PM, Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]>> wrote:

LL

---

From: Dave Thaler <[email-masked]>
Date: Mon, 18 Nov 2019 09:09:17 +0000

I do think it would be useful to keep your statement true, so I will think about how to define Relying Party since I suspect there’s a way around it that we would both like.

From: RATS <[email-masked]> On Behalf Of Dave Thaler
Sent: Monday, November 18, 2019 5:04 PM
To: Laurence Lundblade <[email-masked]>
Cc: Smith, Ned <[email-masked]>; Henk Birkholz <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>; [email-masked]; "Schönwälder, Jürgen" <[email-masked]>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

From: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Sent: Monday, November 18, 2019 4:59 PM
To: Dave Thaler <[email-masked]<mailto:[email-masked]>>
Cc: "Schönwälder, Jürgen" <[email-masked]<mailto:[email-masked]>>; Smith, Ned <[email-masked]<mailto:[email-masked]>>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

LL

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 18 Nov 2019 17:17:08 +0800

If a tree falls in a forest, even if no one hears it, there is a log.

LL

> On Nov 18, 2019, at 5:09 PM, Dave Thaler <dthaler=[email-masked]> wrote:
> 
> From: RATS <[email-masked] <mailto:[email-masked]>> On Behalf Of Dave Thaler
> To: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> Cc: Smith, Ned <[email-masked] <mailto:[email-masked]>>; Henk Birkholz <[email-masked] <mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; "Schönwälder, Jürgen" <[email-masked] <mailto:[email-masked]>>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked] <mailto:[email-masked]>>
> Before the hackathon I would have agreed with that statement J
>  
> To: Dave Thaler <[email-masked] <mailto:[email-masked]>>
> Cc: "Schönwälder, Jürgen" <[email-masked] <mailto:[email-masked]>>; Smith, Ned <[email-masked] <mailto:[email-masked]>>; Henk Birkholz <[email-masked] <mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) <[email-masked] <mailto:[email-masked]>>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Nov 18, 2019, at 4:52 PM, Dave Thaler <dthaler=[email-masked] <mailto:dthaler=[email-masked]>> wrote:
>

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 18 Nov 2019 10:56:09 +0100

How is a nonce included as a proof of freshness in this scenario=

Viele Grüße,

Henk

On 18.11.19 09:52, Dave Thaler wrote:
> Challenge response can be done in a protocol initiated by the Attester,

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Mon, 18 Nov 2019 10:04:09 +0000

> or indirectly via a Relying Party (normal background check model), without having the device needing to run a server of some sort like netconf or restconf.

I asked about a challenge/response interaction model in the
architecture; how communication is done should not be relevant for the
architecture.

Disclaimer: While I have been somewhat involved in the design of yang
/ restconf / netconf, that does not mean I believe these technologies
are always a good fit. (I specifically asked why people believe YANG
is a good fit for TPM since this appeared to be a rather surprising
use of YANG to me.) I am not here to push yang or netconf or restconf,
I am here because I am interested in remote attestations.

/js

---

From: Henk Birkholz <[email-masked]>
Date: Mon, 18 Nov 2019 11:09:30 +0100

OH - I see, you want to include a call home feature in the ecosystem of 
interaction models. There be dragons, though.

On 18.11.19 09:52, Dave Thaler wrote:
> triggers a verifier to ask the device to attest to its health

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Nov 2019 18:33:58 +0800

>> Case 1) The network notices anomalous traffic coming from a device
    >> already on the network, which triggers a verifier to ask the device to
    >> attest to its health (which may have changed since it was last
    >> attested).  Here there might even be no Relying Party involved per se.

    >> Case 2) The network has not noticed anything odd, but wants to
    >> proactively query a device anyway, e.g., because the network's
    >> appraisal policy of what is considered trustworthy has just changed.
    >> Again there might even be no Relying Party involved.

Laurence Lundblade <[email-masked]> wrote:
    > I would call the network the relying party. Attestation always has a
    > relying party because there would be no point if no one cared (if a
    > tree falls in a forest…)

I would be even more specific to say that the network's Policy Enforcement
Point is the relying party. 

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Xialiang (Frank, Network Standard & Patent Dept)" <[email-masked]>
Date: Mon, 18 Nov 2019 10:39:21 +0000

Policy Enforcement Point or Policy Decision Point?

-----邮件原件-----
发件人: RATS [mailto:[email-masked]] 代表 Michael Richardson
发送时间: 2019年11月18日 18:34
收件人: [email-masked]
主题: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

    > relying party because there would be no point if no one cared (if a

I would be even more specific to say that the network's Policy Enforcement Point is the relying party. 

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Dave Thaler <[email-masked]>
Date: Mon, 18 Nov 2019 11:06:40 +0000

There are many ways, and we shouldn't constrain then in the architecture, if we want existing protocols to be usable.

But for example, a 3-way handshake:
1) Device sends message to other side (Relying party or Verifier)
2) Other side responds with a nonce
3) Device sends attestation that includes the nonce

Dave

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Henk Birkholz
Sent: Monday, November 18, 2019 5:56 PM
To: Dave Thaler <[email-masked]>; Schönwälder, Jürgen <[email-masked]>
Cc: Nancy Cam-Winget (ncamwing) <[email-masked]>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; Smith, Ned <[email-masked]>; Laurence Lundblade <[email-masked]>; [email-masked]
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

Viele Grüße,

Henk

_______________________________________________
RATS mailing list
[email-masked]
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frats&amp;data=02%7C01%7Cdthaler%40microsoft.com%7Cd029262a3f6b46eeb0f208d76c0d998a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637096677988223749&amp;sdata=e3ek1ou8kKErdV7SJ7ryb4yMmsERZL19%2Bf%2Be4aUyGQo%3D&amp;reserved=0

---

From: Dave Thaler <[email-masked]>
Date: Mon, 18 Nov 2019 12:08:13 +0000

> My belief is that a Relying Party will rarely want the full universe of signed claims coming from some Attester's chip.   We need ways to pre-filter the results.  How would we do this without a mod…

Because Relying Parties don't parse claims from Attesters at all.
Attesters send evidence to a Verifier, which generates Attestation Results that are parsed by Relying Parties.
Therefore the filter or translation is part of the Verifier's job.

Dave

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 18 Nov 2019 07:42:52 -0500

In reading this thread, I do hope we don't spend a lot of time on the
definition of a token.  I think it's been stated pretty clearly in this
thread, so let's just get it down in a document and move on.  I did see one
place mention a set of claims is a token (the point in the thread argued
that and I agree as it's more than just claims).  A token is some data,
some claims, and a signature.  I think it was Jurgen's previous message to
this one that had a pretty good definition.

Also on the point of binary - when I present anything that has to do with
JOSE and COSE, this is one of the things I start out with as the
differences between the two as well as COSE being designed for constrained
devices, so it's more compact.  Perhaps stating a preference for CWT with
this justification makes sense to someone else's point about not supporting
multiple formats.  This would continue to support multiple formats for
EATs, but would set a recommendation.  I won't go as far as to say a
Mandatory to implement as that doesn't make sense in a full JSON
environment where you wouldn't want to introduce COSE.

Sorry for the top post.  This was a long thread to catch up on and the
other points from my thoughts were addressed.

Thanks,
Kathleen

On Thu, Nov 14, 2019 at 9:06 AM Schönwälder, Jürgen <
[email-masked]> wrote:

> (Maybe I should go join the W3C world and work on attestations APIs for
> browsers after RATS is done).
> >
>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 18 Nov 2019 07:46:15 -0500

On Fri, Nov 15, 2019 at 9:38 AM Eric Voit (evoit) <[email-masked]> wrote:

> instead of a push-based mechanism via another protocol the routers already
> support.
>
> the reasoning and extent of consolidation on YANG for network management.
>   IETF, IEEE, MEF, OpenConfig, and others forums are defining these.  I
> wouldn't expect another anytime soon.
>
>
>
> NETCONF can support YANG. Other transports can support YANG.   The current
> draft under an adoption call does not specifically reference NETCONF.
>
>
>
> indicated as Step 1 in draft-fedorkow-rats-network-device-attestation.  So
> in reality, there has to be a step before step 1,
>
> expressed in the YANG draft, or whatever else, and then you’ve avoided the
> need for netconf, and reduced the number of round trips,
>
> attestation models.  This requires zero extra round-trips.   The push can
> be leave the Attester in <1 sec.
>
>
>
> <Eric> A YANG model supports both push and pull.  Application vendors want
> a standard attestation model.  That is why you have many network vendors
> authoring this YANG draft under the adoption call.
>
>
>

Agreed, seems like an unnecessary rat hole.  The conversation should move
on.

Thanks,
Kathleen

>
>
> /Eric
>
>
>
> Dave
>
>
>
> *From:* Laurence Lundblade <[email-masked]>
> *To:* Dave Thaler <[email-masked]>
> *Cc:* Smith, Ned <[email-masked]>; Oliver, Ian (Nokia - FI/Espoo) <
> ian.oliver@nokia-bell-labs..com <[email-masked]>>; Nancy
> Cam-Winget (ncamwing) <[email-masked]>; [email-masked]; Henk Birkholz <
> [email-masked]>
> Millions of devices. Currently TPM oriented. Long possible transition to
> EAT. YANG used to create very specific fine-grained interactions. No
> privacy issues.
>
>
>
> *Web Browser World*
>
> Billions of devices. Current attestation use is primarily WebAuthN / FIDO.
> JWT is used heavily for authentication so would be more EAT oriented, but
> TPM attestation is supported in FIDO. Larger use of attestation may evolve.
> Fine-grained interactions are with WebAPIs (Javascript) (sort of parallel
> to YANG for routers). Big privacy issues.
>
>
>
> *Mobile App World*
>
> Billions of devices. Main attestation use is Android’s Keystore. This is
> EAT-like, but based on X.509. Fine grained interactions are Android APIs. I
> may be out of date, but so far IoS doesn’t do attestation. Privacy issues
> vary by app.
>
>
>
> *IoT World*
>
> critical enabling feature in this world. There are lots of protocols and
> formats involved. TPMs are too expensive for many of these, but are
> probably in use somewhere. No privacy issues for a large portion of this
> world.
>
>
>
>      .... |   ...        |               |         ||
> *From:* RATS <[email-masked]> *On Behalf Of *Smith, Ned
> *To:* Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs..com
> <[email-masked]>>; Laurence Lundblade <
> [email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>
> *Cc:* [email-masked]; Henk Birkholz <[email-masked]>
> formats as an encapsulation (signed by a second TA where the TPM is a first
> TA) or as a conveyance (unsigned?) token. Possibly, the only added value of
> the latter is a tag that identifies it as a TPM binary format?
>
>
>
>
>
> On 11/10/19, 23:21 PM, "RATS on behalf of Oliver, Ian (Nokia - FI/Espoo)" <
> [email-masked] on behalf of ian.oliver@nokia-bell-labs..com
> <[email-masked]>> wrote:
>
>
>
> of very limited capability. I believe that > EAT will replace TPM
> expressive. I know > others believe that too.
>
>
>
> I would disagree with the statement of "short run" ... TPM is practically
> the only existing standardised (hardware, software, firmware, measurement -
> x86 only etc) hardware root of trust in common use, ie: practically all x86
> machines,  The attestation mechanisms provided are going to be around for a
> very long time.
>
>
>
> OK with the current draft and a promise > to add EAT to it.
>
>
>
> Agree
>
>
>
> Ian
>
>
>
> --
>
> Dr. Ian Oliver
>
> Cybersecurity Research
>
> ------------------------------
>
> *From:* Laurence Lundblade <[email-masked]>
> *Cc:* Henk Birkholz <[email-masked]>; rats@ietf..org <
> [email-masked]>
> 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.
>
>
>
> Remote TPM attestations are useful and necessary the short run, but are of
> very limited capability. I believe that EAT will replace TPM attestations
> in the long run (maybe decades) because they are far more expressive. I
> know others believe that too.
>
>
>
> If we don’t include EAT in the YANG mode it is sort of like defining HTTP
> to only convey HTML to the exclusion of PDF. We’re defining an attestation
> protocol that can only move one kind of attestation even though we have
> consensus on what the other one looks like.
>
>
>
> Thus, I am opposed to adoption with the current TPM-only draft. I’d be OK
> with the current draft and a promise to add EAT to it.
>
>
>
> LL
>
>
>
>

-- 

Best regards,
Kathleen

---

From: Guy Fedorkow <[email-masked]>
Date: Mon, 18 Nov 2019 19:59:55 +0000

I know I’m responding to a message from the ancient past, but I’d like to try to clarify a couple of the characterizations of RIV.
  It’s true that I asked Dave whether the relying party was required to shuttle information between the attester and the verifier, as shown in the Background Check model.  If the two are processes on the same network management machine, such a requirement seems odd.  But if they have different network reachability due to separate machines and firewalls and all, then of course the relying party can proxy information to the Verifier.  We specifically avoided distinguishing the two roles in the RIV draft, but I don’t think that can be taken to mean that the solution cannot work with firewalls.  But let me know if there was some other restriction that motivated the table entry
  The non-privacy clause in the RIV draft is also coincidental.  The TPM has a wide range of mechanisms to deal with degrees of privacy expectations, all of which relate to key provisioning.  For routers, we haven’t seen a need for complex measures to hide identity, and in fact I think most operators would not want routers with a secret identity on their network.  But if someone does want preservation of privacy, they can change to Local DevID keys and coordinate those keys between device and verifier using whatever approach they want.  I don’t think it has any impact on the RIV workflow.
  But I should probably say more explicitly somewhere in the draft that we’d want to the solution to work with zero touch provisioning, such as RFC 8572.  That’s not ‘required’ for RIV, but may help explain two things:

  *   sZTP assumes the device can identify itself.  Hence the non-privacy-preserving statement, and the request that manufacturers pre-provision identity and attestation keys.
  *   sZTP requires that the device announce itself so that it can be configured.  By the time it would be possible to do attestation, the device has already revealed its presence.  And indeed one might link the two – I don’t think it’s part of anyone’s spec, but a ZTP provisioning system might well want to run software integrity attestation once it’s figured out what the device is and whether it has a plausible to reason to want to connect.  But again, that seems out of scope to the draft.
  Finally, I don’t see YANG as the exclusive protocol for TPM-based attestation; it happens to be the one that’s already there for routers, and it’s a lot easier to get someone to add a YANG model to their router for network management, than to convince them to bring in a new protocol suite.
  But for other applications, YANG wouldn’t be the right thing…  Industrial IoT probably would ask for attestation via a protocol I’ve never heard of 😊  And I think there would be different protocols more suitable to end user computing, such as laptops and servers.  Glad to talk it over if someone wants to extend the scope.

  Thanks for reading a long response…  Let me know if this is clarifying or muddying!
/guy

Juniper Business Use Only
From: RATS <[email-masked]> On Behalf Of Dave Thaler
Sent: Monday, November 11, 2019 8:43 PM
To: Smith, Ned <[email-masked]>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked]>; Laurence Lundblade <[email-masked]>; Nancy Cam-Winget (ncamwing) <[email-masked]>
Cc: [email-masked]; Henk Birkholz <[email-masked]>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

                        Requirements?

Dave

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 18 Nov 2019 21:33:19 +0000

The log is merely a way to defer actions taken by a Relying Party. Presumably, there is not reason to log something if the log is never processed.

The Roles workflow isn’t necessarily time dependent while possibly the arch models (passport, BGC) are?

From: Laurence Lundblade <[email-masked]>
Date: Monday, November 18, 2019 at 1:17 AM
To: Dave Thaler <dthaler=[email-masked]>
Cc: "Smith, Ned" <[email-masked]>, Henk Berkholz <[email-masked]>, Nancy Cam-Winget <[email-masked]>, "[email-masked]" <[email-masked]>, ""Schönwälder, Jürgen"" <[email-masked]>, "Oliver, Ian (Nokia - FI/Espoo)" <[email-masked]>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

LL

On Nov 18, 2019, at 5:09 PM, Dave Thaler <dthaler=[email-masked]<mailto:dthaler=[email-masked]>> wrote:

From: RATS <[email-masked]<mailto:[email-masked]>> On Behalf Of Dave Thaler
Sent: Monday, November 18, 2019 5:04 PM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>
Cc: Smith, Ned <[email-masked]<mailto:[email-masked]>>; Henk Birkholz <[email-masked]<mailto:[email-masked]>>; Nancy Cam-Winget (ncamwing) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; "Schönwälder, Jürgen" <[email-masked]<mailto:[email-masked]>>; Oliver, Ian (Nokia - FI/Espoo) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

LL

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Nov 2019 14:33:38 +0800

{why do people insist on CC people who are on the list?
Do you enjoy getting three copies of emails with different headers}

    > instead of a push-based mechanism via another protocol the routers

I agree.

    > whereby the Attester does something that makes the Attester
    > discoverable by the Verifier.   That step could have included the EAT
    > or the TPM data

I have a todo item to write up:
  1) a use case for Attestation at BSKI onboarding time.
     (really this is a RIV sub-case, I think)

  2) a document explaining how to carry EAT in BRSKI voucher-requests and
     RFC8366 vouchers.

That works well for initial attestation before a device is accepted onto a
network, but does not manage the ongoing safety of the device.  An open item
in BRSKI is finding a way to signal that a device supports RESTCONF, and
should have it's configuration loaded in that way.
That signaling could very well indicate that attestation is available that
way; well actually I think that once RESTCONF is up, the controller can
discover that it supports our EAT-YANG-module.

Having said all of this, I was surprised that my question on Friday's meeting
about what claims would be in the EAT that be returned from
entity-attestation-token-challenge-response did not elicit more understanding
and aha.

I want to be clear: I object to including the EAT in the *TPM* module,
because:
  1) it's mixing two different things and there is no reason a device
     that supports one should have to support the other.
  2) I believe that the use case is completely different.
  3) returning EATs is way too important to get it wrong like this.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Nov 2019 14:36:43 +0800

> Policy Enforcement Point or Policy Decision Point?

*I take the fifth*
(what? Singapore and Canada do not let me avoid testifying against myself?)

I think it could be either, but it depends upon the architecture of system/network.

    > -----邮件原件-----发件人: RATS [mailto:[email-masked]] 代表
    > Michael Richardson发送时间: 2019年11月18日 18:34收件人: [email-masked]
    > 题: Re: [Rats] Call for adoption (after draft rename) for Yang module
    > draft

    >>> already on the network, which triggers a verifier to ask the device
    >>> to attest to its health (which may have changed since it was last

    > _______________________________________________ RATS mailing list
    > [email-masked] https://www.ietf.org/mailman/listinfo/rats

---

From: "Smith, Ned" <[email-masked]>
Date: Sat, 23 Nov 2019 19:16:38 +0000

The step-0 protocol may have payload size or timing limitations that prevents fully attesting. This is the case for 802.1X ethernet ports.

---

From: Guy Fedorkow <[email-masked]>
Date: Mon, 25 Nov 2019 15:21:33 +0000

Hi Ned,
  The Step Zero I've been keeping at the back of my mind is RFC 8572, which already has a number of complicated mechanisms to reach out and obtain configuration information.  I think a RIV-style attestation exchange could be added to the steps without deleterious interactions.
  That's not to say that RFC 8572 is the only applicable environment, it's just one that seems like a good match.
  /guy

-----Original Message-----
From: RATS <[email-masked]> On Behalf Of Smith, Ned
Sent: Saturday, November 23, 2019 2:17 PM
To: Michael Richardson <[email-masked]>; [email-masked]
Subject: Re: [Rats] Call for adoption (after draft rename) for Yang module draft

    

_______________________________________________
RATS mailing list
[email-masked]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/rats__;!8WoA6RjC81c!WBOTLYKwF7oGS_PDI_8B6397ox_eo22P68lVRLKBHlP2nNJzBT67iO4pPLrQmQ6zj9g$