Re: [Panic] notes on Panic Draft

Guy Fedorkow <> Sun, 13 August 2017 23:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0327133037 for <>; Sun, 13 Aug 2017 16:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 HWshytHBgmSs for <>; Sun, 13 Aug 2017 16:22:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD7391339DE for <>; Sun, 13 Aug 2017 16:22:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MTT4w6dLsHZWACpi92T5efIQMaujjYNL4oXS9BmTdUg=; b=k6xN1n/bGP1podtdLd5QTVhFJU6MFNT2H3EILwr1KV1SqdwimSdj8QhiCoLHF7mzXBrYF9gVByOfXS7fdOFJz27nfjvbbfLmKGg+e+0SRh6dFi0Kw7w2j77s1MNHU6X0VhLqVJ19/QHXuxBniWmRFMR/DpC9G5ZgUtWpBfLPMLY=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Sun, 13 Aug 2017 23:22:44 +0000
Received: from ([]) by ([]) with mapi id 15.01.1304.025; Sun, 13 Aug 2017 23:22:44 +0000
From: Guy Fedorkow <>
To: "Waltermire, David A. (Fed)" <>, "Panos Kampanakis (pkampana)" <>
CC: "" <>, Jessica Fitzgerald-McKay <>
Thread-Topic: [Panic] notes on Panic Draft
Thread-Index: AdMCY8IYY6zBEz8yT9uERQZ0qXAFnQD26z4AAF4VMoACiv5B8ACj6KMA
Date: Sun, 13 Aug 2017 23:22:43 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN1PR05MB233; 6:WgMBDo8LyLjYQnkALUz55+WmchK88nHQX3eHffOp10vG/0FB8rcz+UC7aoLzUe/pI65sitU7NC+BvmzQQnlOVmiCo5XBlDxl4KA4WDmtp2hy/Oik3619sLS5Ep9PnMv6hHy67kqyeeA24Ek20RurwlRtsFnF7mstAWoCTOBLCutAUIgoihBF5Mn+onXWyyB5CriCFkbzFDfE9hdVMT/5Ctx1pUmrZP7j2d2CyBBVTK3/1DwZ/nnfxbhc2Lk3jaThapOo2W8LkAlYOTODax5mvAralwAx9li/HCZqk8a9Q644L3NcpaZs9CDpF8PID5HXHzS0RRqcAcXpC0XdWDNL8w==; 5:tW8wljL+x59T78g2DJ60sJ1mOqW0fNpPK/3oO/oDhhUurHr4mtasHXURDpPrz0BKAyjUZ01Vw84jyCTaPghrtnXYvqLT0+RiIEdvsWWrNPWhVw4VyClEQViWcCtVSTP8yYL9qxzo8Oe1KxroNFD2Sg==; 24:23nNqgn8kaK6ThyHO3pUQq/sP8KLKzvdplmLmkJryxn02W6vvtbLZx3ZQw5p+3/Yrj+iClLQdMWH9yN1URlaUVuIThaF+QGurjPQUnoXwLE=; 7:iLt1N/CBWF2XtsqQxnjxOmJTcxnVCwuhQrzcC4bBfl1VFUaD8m+x3wj2oM/89bArMCPsDGe2uwf9qzYGSnNKZr7SCMWhjDyD0GT0HgfBKAw+sRxxDFXGhWgMRoGCmU69JULCIdz8FicB884nb1aCy3DbqnhZrVt/2GVNlN/t3ZkY6ycmAfUP1D1dALhdAOe5Yus51FTyNd6MKjtiOkJUoKwHcnSkMXsvcbgqyqJ67AU=
x-ms-office365-filtering-correlation-id: 08731370-27af-445c-5ffb-08d4e2a23360
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN1PR05MB233;
x-ms-traffictypediagnostic: BN1PR05MB233:
x-exchange-antispam-report-test: UriScan:(158342451672863)(65766998875637)(72170088055959)(192374486261705)(271806183753584)(138986009662008)(95692535739014)(155532106045638)(21748063052155);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN1PR05MB233; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN1PR05MB233;
x-forefront-prvs: 03982FDC1D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(24454002)(54094003)(40224003)(51914003)(189002)(199003)(377454003)(189998001)(6436002)(3846002)(4326008)(74316002)(790700001)(606006)(6116002)(53546010)(102836003)(101416001)(97736004)(8656003)(966005)(14454004)(9326002)(478600001)(105586002)(236005)(54356999)(25786009)(50986999)(76176999)(54896002)(229853002)(68736007)(6306002)(106356001)(9686003)(2900100001)(77096006)(6506006)(6246003)(7736002)(39060400002)(3660700001)(53936002)(5660300001)(2906002)(81166006)(81156014)(66066001)(8676002)(3280700002)(8936002)(7696004)(33656002)(19609705001)(93886004)(2950100002)(54906002)(55016002)(99286003)(86362001)(15398625002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB233;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN1PR05MB309852E17C0A46238A68DDBBA8F0BN1PR05MB309namprd_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2017 23:22:43.9678 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB233
Archived-At: <>
Subject: Re: [Panic] notes on Panic Draft
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Posture Assessment Through Network Information Collection \(panic\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Aug 2017 23:22:51 -0000

Hi Dave,
  I can’t say anything about what my employer is doing on this topic, but I will say that we’ve spent quite a bit of time in Trusted Computing Group on analyzing the use of signed SWID tags to convey version identification information from network vendors to attestation systems.  I’m not aware of other alternatives that come as close to solving the problem.

  If anyone is interested, it might be good to plug into the TCG work and make sure you think the result will work!

/guy fedorkow

From: Waltermire, David A. (Fed) []
Sent: Thursday, August 10, 2017 10:43 AM
To: Panos Kampanakis (pkampana) <>om>; Jessica Fitzgerald-McKay <>om>; Guy Fedorkow <>
Subject: RE: [Panic] notes on Panic Draft


I’d like to address your statement below about SWID tags. While we have a number of non-network vendors that are producing SWID tags, we do not have network vendors adopting yet. Much of the previous adoption of SWID tags has been driven by software licensing use cases. Vendors have adopted SWID tags in part because it helps them to know how much of their software is deployed across a given enterprise when performing license audits. At the same time, SWID tags provide software manageability to enterprises that need to know what software and patches are installed, if that software has been tampered with, and that the software has come from the actual supplier. The last point also helps vendors address counterfeit software and software distributions containing malware.

At NIST we are promoting SWID tags because SWID tags use a single data format that can provide information supporting multiple operational and security use cases simultaneously. They have a clear role in managing software licenses, detecting installed software (and patches/updates), identifying vulnerable software, managing secure configurations, and preventing the execution of malicious code on devices. All of these use cases apply to network devices. I talk with network device customers and they have similar concerns as other device users. They have troubles keeping the software on their network devices up-to-date. They have difficulties identifying if they have vulnerable software installed on their network devices.

SWID tags can be generated when building a software distribution package, which means after the initial investment into integrating SWID tags into the build and packaging system, all built software can have a SWID tag that is automatically generated. So why not support SWID tags if they will help with these things?


From: Panic [] On Behalf Of Panos Kampanakis (pkampana)
Sent: Friday, July 28, 2017 11:40 AM
To: Jessica Fitzgerald-McKay <<>>; Guy Fedorkow <<>>
Subject: Re: [Panic] notes on Panic Draft

Hi Jess,

To try to address two questions:

> I would like a sense of how widely implemented they are for network device software and operating systems. Anyone have any insight there?

I am not aware of any network vendors that use SWID tags.

> 802.1ar requires installation ​
​of an IDevID, from which many LDevIDs can be created. I'm happy to geek out on the added security of cryptographic IDs, but, can we talk though the workflow of getting the initial IDevID installed (who would be responsible for that? Do network equipment vendors use IDevIDs today?

I can’t speak for all vendors, but Cisco has been using IDevIDs in their products for some time and more platforms are adopting it. The private key for the 802.1AR cert is stored in a secure storage chip (similar TPM) so the IDevID cannot be compromised. I applaud adopting a secure immutable identity or better a subsequently acquired LDevID to authenticate the reported data from the endpoint. Fallback or additional auth mechanisms will also be necessary for other usecases though.


From: Panic [] On Behalf Of Jessica Fitzgerald-McKay
Sent: Wednesday, July 26, 2017 2:46 PM
To: Guy Fedorkow <<>>
Subject: Re: [Panic] notes on Panic Draft

Thanks for the feedback, Guy. Responses in-line. I have more questions than answers, and I'd like others on the list to weigh in. Looking forward to hearing from everyone.

On Fri, Jul 21, 2017 at 5:18 PM, Guy Fedorkow <<>> wrote:

Hi Dave, Jessica,
  Thanks for updating the PANIC draft…  I think it’s starting to take shape!

  It seems that the next step in moving this forward might be to outline the kind of information we want to retrieve from the endpoints.  I’d assume you’d want some kind of info to identify the device – manufacturer, serial number, etc, plus something that shows the software revision of the relevant modules.  Could that be something like a set of SWID tags?

​Personally, I would be delighted if software load could be captured in a SWID tag. Failing that, I would like to be able to collect a swid-like set of information from​ the network device. I took a look at NISTIR 8060 (which you can read here: and it looks like-- ignoring data about the tag itself, like tagID, entity information about the tag creator, etc--  required fields for a primary tag are:

  *   software name and
  *   software version,
which should be easy enough to collect on their own.

But, SWID tags offer additional information that could be useful to us. Evidence and payload fields, for instance, can be used to communicate file hashes that comprise the software. Tag signatures could allow us to have move trust in the entity that created the tag (for example, a tag from the software vendor is potentially more trust worthy than one created by a third party). And SWIDs allow us to easily communicate what patches are installed on the product, which is necessary for vulnerability and compliance assessments.

All things considered, I'd like to use SWID tags. I would like a sense of how widely implemented they are for network device software and operating systems. Anyone have any insight there?

  It might be good to pattern the device information on IEEE 802.1AR.  Using a cryptographic ID might not be a ‘must’, but it’s probably a desirable option, so making sure it would fit might be helpful.

802.1ar requires installation ​
​of an IDevID, from which many LDevIDs can be created. I'm happy to geek out on the added security of cryptographic IDs, but, can we talk though the workflow of getting the initial IDevID installed (who would be responsible for that? Do network equipment vendors use IDevIDs today? If not, could the device owner install one without a lot of hassle?)​.

Also, secure though 802.1ar is, it often has no relation to any observable device identities on the network. I'm thinking about a behavior monitoring use case here, in which I notice a device behaving in an unexpected manner, and want to investigate it's posture while I figure out what is going on. Is there a way to gather many identities from an network device using netconf/yang?

  It might be good to add a note saying whether the draft should extend to virtualized devices, e.g., NFV instances.  I’d assume that it should, but that might make identity a bit more complicated.

​In section 3 of the draft, we say "​Virtualized network functions are currently considered in scope". Of course, I worded it that way because I, too, am concerned about whether their inclusion makes our solution overly complicated. Are there any netconf experts that can speak to this concern?

  On the topic of scope, I suppose it might be good to say if “Things”, as in IoT, are in scope or not.  I can’t guess if that has an impact on the technical spec, but there certainly could be an impact on implied scaling needs, and it might help remind readers that figuring out what’s running in the IoT is a getting to be a big problem.

​Agreed that IoT is a problem. Do many "Things" that compose the Internet of Things implement netconf?​ It's such a broad space, I worry that some "Things" could handle netconf, and others (things like "smart dust", etc.) couldn't handle the added weight.

  The diagram in the front of the draft shows an interconnect between Posture Server and Data Store…  seems like there could be some complicated transactions across that link…  Do you think there’s existing practice that could be used for this?

​Sadly, I know of nothing we could easily point to and say "that is the protocol we will use for server-datastore communication". But, what I do not know could fill volumes. Maybe others have ideas where we can start?
  The draft also mentions methods that Endpoints can use to find Posture servers.  I wonder if Zeroconf or some kind of DHCP trick might work for this?

​Zeroconf is an option. TCG has some prior art here ( I am happy to consider all viable options.​

  Finally, in Security Considerations, I wonder if there should be something about how much we do or don’t trust the endpoint to report its Information truthfully. The combination of 802.1AR and signed SWID tags might help with a way to assess the reliability of the information.

​Agreed, I will add that to the next revision. ​

  Great start, let’s try to start breaking down some of the top-level topics to get to the next level of requirements.

Panic mailing list<>