Re: [Rats] RIV and the RATS architecture

Dave Thaler <> Mon, 04 November 2019 22:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1509120A9F for <>; Mon, 4 Nov 2019 14:29:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SYaqsHNvw9ZI for <>; Mon, 4 Nov 2019 14:29:01 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6E5A120127 for <>; Mon, 4 Nov 2019 14:29:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=m7M/47/nAIyxJ8GuGzOZb8JMxds8DvYpOF93aroGVGzSmyM8Mf1ZGUPFDAfF5wOXqS7D4HP1odpPmLAHwl5EoH12ILiyjNA3zksAi1i0/b7Myz63nAYPa5yrEut6YrX6QrEFe21ztx6g+uJAfHHB8WWh1v2U7EqRSQ/KUWFn9wBzKCxKWiDIRnkh57s35QENumQxBYz6Mlm92VhfGy7Xv/UJeUUewnM1rme6GRg4X5MpgTqrUDM+BxjFdisv56UqaTTpkTD1A5y74bpLZnSf7nyeNCJdfxW7OEKIQMxenXn4krJ4LTbffomiVL6+CIAvvMdZ9rmxDIJB/H8mT63IDA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f8fc4zOz2Y+ezoJWRFybjdbCHN9qOLQRuMOp09XbAZg=; b=At0aBhQLcHKg/mfVkslIEpmUjdJDUHUUicmIcWU7IG3cMIU3SasTmSlxPItvv8TzmtvwADPHX631d4uJfu0ui5FQyvpBCsF0bmC/YXHaJXKTGrEVfImdW+xUL8UMCYpeCNJ3d/pJ+qx9Ux1FiN7MWviqr/2qEHbnRq7BH53Zlu2O8xy96P05gafRc6bZ6IovMIDT4L0LLRjf57Yc7sBs6TgFSZfjK1khD/5FpsXG6wzDxBdvBiVHjWuwkib5xiwx2+rT3nJGkTWtu+8s2DH8UMe8vBWvmHBi1YWAcc3FikxdJvW5pv6Hw09APSmzJT/7wwnei1aVjjWgJXCoYzLdHQ==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f8fc4zOz2Y+ezoJWRFybjdbCHN9qOLQRuMOp09XbAZg=; b=cJFsGGQ5QkOD1o/FdSyj2n5y0t12taJvZGyNAi5kLOmkqUG8KC9+X2d9LAbQPY8jnlddqjt8JBl5oWCFgXNgjcxpPfAPhgztq1MjP0glHeRMz2KqkhlXURXLWa4a1jUou2eH5EEL4huRWRyMSCj3g6TNn8RYPwKUPpgXIkwVAKw=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.7; Mon, 4 Nov 2019 22:28:57 +0000
Received: from ([fe80::8d41:8f86:8654:8439]) by ([fe80::8d41:8f86:8654:8439%11]) with mapi id 15.20.2430.017; Mon, 4 Nov 2019 22:28:57 +0000
From: Dave Thaler <>
To: Henk Birkholz <>, Guy Fedorkow <>
CC: "" <>, Thomas Hardjono <>, "Smith, Ned" <>, Jessica Fitzgerald-McKay <>
Thread-Topic: [Rats] RIV and the RATS architecture
Date: Mon, 4 Nov 2019 22:28:57 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-04T22:28:56.8907863Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=2fafed79-064d-4630-9794-88013d0e4cae; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:2:b11b:e793:787c:bd6b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 4f15475d-9ebb-47f6-0451-08d761766229
x-ms-traffictypediagnostic: MWHPR21MB0160:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0211965D06
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(366004)(346002)(376002)(39860400002)(396003)(13464003)(189003)(199004)(10290500003)(6116002)(22452003)(81156014)(66556008)(86362001)(110136005)(966005)(25786009)(64756008)(66946007)(71190400001)(71200400001)(8936002)(99286004)(6246003)(74316002)(66476007)(6506007)(11346002)(305945005)(8990500004)(4326008)(66446008)(7736002)(2906002)(33656002)(76176011)(6306002)(55016002)(316002)(256004)(53546011)(76116006)(5660300002)(14444005)(102836004)(476003)(8676002)(478600001)(486006)(446003)(52536014)(9686003)(186003)(10090500001)(7696005)(81166006)(54906003)(14454004)(46003)(6436002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0160;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: mrfDsMGFhb545kIKrszSvISKnlqGzY56SjEp7foDcx8lsDMUlcqskPy5tJw4DSfW83nuwfJdZ4ZyYw6AdC7FlaYvnF4ZL9+D/XPc1+eKUqBTEgR6lbqHhrM5mzmNyenj9fXVw3bA6JZA3zQeLmDaZ8Ou8NGBGi6jzJGROHCROw7x+/bfqbkDi2GD0DD4V8BJ0tlbEEYUVy1uzyNhixD3XRy0Kc46hXeZIZ97ODcBPATNFg5xQWF1YRl+HAxbfGHrOn2OoNmW/LAgbN3RgIym+ZmpttFFPJ/9P7J8TrXfk7HkLO1teqteZdhfeK3h1ZCBExGf3x6QikeATC/jkoH8y2MtISF5GYjLY+DZF13rkxgVhMCtNbIsWmLZszFk20B3Wo8ctOdQG0bx6Etw4z9iG5XVh6rqjCvXsQBwWuXfrKTQ1hFTYBPZu3EHUlASzNqk
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 4f15475d-9ebb-47f6-0451-08d761766229
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2019 22:28:57.1517 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WNU84IwRsHr2Wj3IzxXi/vw3Ia47nswOgoc6ZABOz/M9nQQmdDVOZCAF0WnRjXHIclCkyzLrBwrBGLMjGWIeqQrUZOI9T9kWme5hNHGHSnk=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0160
Archived-At: <>
Subject: Re: [Rats] RIV and the RATS architecture
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Nov 2019 22:29:04 -0000

Thanks Henk for the note.

I hope the WG can converge more as I think there is still much confusion, and reviewing
updated documents will help people to understand concepts better and see where there is alignment and
where there is still lack of alignment.

I haven't gotten any direction from the chairs yet as to whether I should update my contribution or not, but
since there have been specific questions asked on the list (Juergen, Guy, etc.), and apparently some mischaracterization
in email messages about text in my contribution, I'm inclined to submit an update unless the chairs tell me otherwise.

I am absolutely open to co-authoring, or contributing, or merging, or whatever else, going forward.

Looking forward to a productive discussion,

-----Original Message-----
From: RATS <> On Behalf Of Henk Birkholz
Sent: Monday, November 4, 2019 1:23 PM
To: Dave Thaler <>om>; Guy Fedorkow <>
Cc:; Thomas Hardjono <>du>; Smith, Ned <>om>; Jessica Fitzgerald-McKay <>
Subject: Re: [Rats] RIV and the RATS architecture

Hi Dave, Guy, et al.

we did a "best fit" matching of use cases with the two message flows "passport" and "back-end", and while it is possible to cluster those with some... leniency, the goal is to provide the basis for mapping by using both roles and message flows in the architecture document. 
"Passport" and "Back-End" flows really helped to streamline the progress (Thanks Dave). As we (Thomas, Ned, Michael & me, with 'unfortunately' 
too much input from group members! Thanks all) went through seven examples now (still missing a prominent GP one, I think) we are pretty confident that this works consistently.

Sorry again that we did not address all issues raised. The priority stack that is our action item list was in a continuous swirl :)

There will be one or more submissions before cut-off.

Viele Grüße,


On 04.11.19 21:56, Dave Thaler wrote:
> Hi Guy, sorry for the delay, I was at a conference (Open Source 
> Summit, Confidential Computing Consortium, and Linux Security Summit 
> were all
> co-located) all last week and traveling there/back.
> Responses inline below.
> *From:* RATS <> *On Behalf Of *Guy Fedorkow
> *Sent:* Thursday, October 31, 2019 12:27 PM
> *To:* Dave Thaler <>
> *Cc:*; Thomas Hardjono <>du>; Smith, Ned 
> <>om>; Henk Birkholz 
> <>de>;
> Jessica Fitzgerald-McKay <>
> *Subject:* [Rats] RIV and the RATS architecture
> Hi Dave,
>    Thanks for your doc
> bf86f141af91ab2d7cd011db47%7C1%7C0%7C637085028413254093&amp;sdata=kc6Y
> 4pawY8qtlcCEbuU4jslXVhktsexy8rCHoVv6q%2FE%3D&amp;reserved=0
> <;;sdata=kc6Y4pawY8qtlcCEbuU4jslXVhktsexy8rCHoVv6q%2FE%3D&amp;reserved=0>.
>    Do you have a view as to how the TPM-based attestation described in 
> RIV would fit with the proposed categorization?
> amp;
> 16d3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63708502841325409
> 3&amp;sdata=mTKpVUjdcsj5YLY4yfQMSCUi4JRYxroPFzBlBTMdJW8%3D&amp;reserve
> d=0 
> <
> &amp;
> 616d3410%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6370850284132640
> 89&amp;sdata=EZTwUJ70nIQCDMwYlmjIN73q8MVZWAQvY%2FeqOOw7prE%3D&amp;rese
> rved=0>
> Great question. From my reading of
> draft-fedorkow-rats-network-device-attestation-00, it's a background 
> check model, as section 2.3 of your doc explains:
>>   3.  A Relying Party, which has access to the Verifier to request
>>       attestation and to act on results.
> That sentence above is by definition the background check model.
> That is, the Attester talks to the Relying Party, the Relying Party 
> then requests a background check by consulting a Verifier,
> and will accept whatever answer the Verifier decides.
> There are ways where you could use the passport model for network 
> device attestation,
> but your document only covers the background check model.
>    It doesn't seem to be a passport, since the attester only provides 
> raw evidence, not a pre-approved passport
> Agreed, from my reading of your document.
>    It doesn't seem to be a background check, as it's the verifier that 
> collects and analyzes the evidence.
> If I understand your point here, you're saying that the verifier talks 
> directly to the attester (e.g., by querying the yang module), without 
> going back through the relying party, and that that seemed to you to 
> be different from a classic "background check" diagram.  Did I get 
> your point correctly?
> If so, then I see it as a variation of the background check model, as 
> opposed to a separate model per se.
>    I'm not sure it matters to RIV, as we haven't drawn much 
> distinction between the relying party and the verifier.  As you say, 
> if they're on the same machine, the distinction is almost moot.
> Agree.
> And if they're not, I think the communication is out of scope for RIV 
> (if not for RATS).
> I disagree that it's out of scope for RATS.
> I have no opinion on whether it's out of scope for RIV, since I still 
> have some confusion on the intended scope of RIV.
> I note that your document constrains its scope (in section 1.5) to 
> only TPM-based embedded devices, and not other
> types of devices.   I couldn't tell if the scope of RIV and the scope 
> of the draft (which does not have RIV in the name, or in
> section 1.5) are similar or one is a subset of the other.   Indeed, 
> the title of the document is far wider than just TPM-based
> embedded devices, so in that sense the title doesn't match the scoping 
> in section 1.5.   Just explaining why there's not
> enough information for me to have an opinion on verifier-relying party 
> communication in RIV.
> There can be other network attestation solutions that look quite 
> different from the flow in your draft
> (and I have no skin in this game, so don't have a bias towards any 
> solution in particular).   For example,
> some other solution might involve a RADIUS server being a Verifier, so 
> the verifier - relying party communication might
> be RADIUS in that example.   There's many ways to construct solutions, 
> and so I imagine there's probably multiple
> solutions already out there, since the NEA problem is not new even in 
> the IETF 
> (
> C9dfd693759294a279a9e08d7616d3410%7C72f988bf86f141af91ab2d7cd011db47%7
> C1%7C0%7C637085028413264089&amp;sdata=ExcrMYn5%2Bvd%2FbSz1%2FZ7Wz4KB0D
> x%2Bd6KCaU6M2nweXw4%3D&amp;reserved=0 has
> pointers to RFCs for anyone reading this who's not already aware of it).
>    But it would be good ensure the architecture and the applications 
> of it actually do fit together.
> Absolutely.
> Dave
>    Thanks
> /guy
> Juniper Business Use Only

RATS mailing list;;sdata=kxj3Z9NJnOFsek3AScAuAtvvi8c4%2B8gKIpY73qWxq%2FY%3D&amp;reserved=0