Re: [Panic] notes on Panic Draft

Adam Montville <adam.w.montville@gmail.com> Wed, 26 July 2017 20:55 UTC

Return-Path: <adam.w.montville@gmail.com>
X-Original-To: panic@ietfa.amsl.com
Delivered-To: panic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDB413146C for <panic@ietfa.amsl.com>; Wed, 26 Jul 2017 13:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUoZc7d_tUj2 for <panic@ietfa.amsl.com>; Wed, 26 Jul 2017 13:55:49 -0700 (PDT)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 443E9129A9F for <Panic@ietf.org>; Wed, 26 Jul 2017 13:55:49 -0700 (PDT)
Received: by mail-io0-x22c.google.com with SMTP id g35so39747535ioi.3 for <Panic@ietf.org>; Wed, 26 Jul 2017 13:55:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5XCVUM/FR74HKyE/pCcgUK2bOExoQghklEVlhPZxw0Y=; b=eZZtgJZEWVwMAZsuD4FyBk4/xOjYzfvv7JdEzwrbGJMGzfuMcx9FleRYpHv8I9CdsY s8ugLZQevBLzLDVYsNeZwGfWjmckLzvEQb/8FZhAL1aqIVwRF0blTV7csMpqIyUp+Bc7 YQ+U5+CCr4G+lizkK99nXx7Q5d4G/9SjW3EiP5lGTEs9bF5u9FDYlZrFJfE9bNcyH/Rq CkxRGcW+yfDpZ7hJ4jV44JPLU91R+kSAs2zdejacLbaz0ojY0JyNTsXIY0S+tX4lrioP DkWR1pmsCO8hmv7vgPzod2a+4MMjCaJx38jHW4Jae86v2U1lB2tUTWD4SZHW4qfN5VWT zUuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5XCVUM/FR74HKyE/pCcgUK2bOExoQghklEVlhPZxw0Y=; b=obl63c560FvILa0bG3M9myIJl5vqC8LnIMN+BPDoYkcmplBKbNYv1g/y+h9GlgAPgi Cfyizw9giehIBZxE9VDH5CmigjqWK5zLKD6WNcqu8Lf66k3X1GjdTljMyDQpyyxmuG2K JV8g2yz6Dc/tjoIlgUMSLA9fsh2a4XyhaJjpCUIL9Xmu9BRV6rsiBpOLZzBH7KiHkVL7 cx24pNkNOYZWT7+b7WE/+CCUKIVnU0DskUD8NW5mfIDyExt3iawklOu5Fa2/Y8nDOj2g 7Jh7xeAXfNJR7cDrOUlYozDSrY0q8YTQOEG3TMNBDfY8a7+Ezg/cspnYsJzOXB6OJiAr +iSQ==
X-Gm-Message-State: AIVw111t8vo82zieGkUGDqRW1PY2Qv451nQuk+bfQi8NVAe23LfDB3EN f0KyymgaCRnn046Akcx2/wNIV9uREXSJ
X-Received: by 10.107.183.17 with SMTP id h17mr2748567iof.188.1501102548432; Wed, 26 Jul 2017 13:55:48 -0700 (PDT)
MIME-Version: 1.0
References: <BN1PR05MB309E68BF47317CB858B8B40BAA40@BN1PR05MB309.namprd05.prod.outlook.com> <CAM+R6NUyt+Vk0sXvGJ7+3oga74FywwV32pSRagRnYgDZttPp4Q@mail.gmail.com>
In-Reply-To: <CAM+R6NUyt+Vk0sXvGJ7+3oga74FywwV32pSRagRnYgDZttPp4Q@mail.gmail.com>
From: Adam Montville <adam.w.montville@gmail.com>
Date: Wed, 26 Jul 2017 20:55:37 +0000
Message-ID: <CACknUNXF3sHxj1K9GwZsncjiD7YUUTJy7y+snn5SnQASZj1DOQ@mail.gmail.com>
To: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>, Guy Fedorkow <gfedorkow@juniper.net>
Cc: Panic@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c0b77be2bb9ca05553eacb0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/panic/i8SI6OjFQ0rPl5_7xPqgATsmf7I>
Subject: Re: [Panic] notes on Panic Draft
X-BeenThere: panic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Posture Assessment Through Network Information Collection \(panic\)" <panic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/panic>, <mailto:panic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/panic/>
List-Post: <mailto:panic@ietf.org>
List-Help: <mailto:panic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/panic>, <mailto:panic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jul 2017 20:55:54 -0000

Hi everyone.

It's really good to see additional interest in this subject area! I
encourage you to review the existing ongoing work in the SACM working group
- specifically the requirements draft (hopefully through IESG soon; see
[1]), one of the drafts under adoption consideration (Endpoint Compliance
Profile: draft-haynes-sacm-ecp) [2], and a data model proposal for carrying
SACM statements (YANG subscribed notifications via SACM Statements:
draft-birkholz-sacm-yang-content; see [3]).

After a successful hackathon in Prague, we are redoubling our efforts on
several of the topics with which PANIC appears to be concerned.  While not
all of the work PANIC may imply should necessarily be done in the SACM
group, I would suggest that those of us interested in PANIC look toward
current working group drafts as well as those being considered for adoption
as potentially viable approaches to the PANIC problem.

Our SACM-related hackathon efforts are mostly documented at [4]. (Note that
there were two SACM-related efforts, though only one was exclusive to
SACM.) We have designs for the next hackathon to integrate these two
related efforts (which may help answer the question about the link between
posture server and data store), which could look something like the diagram
at the bottom of that page (also at [5]).

Of course, there may be little-to-no overlap between what SACM has been
attempting to accomplish and what PANIC would like to ultimately achieve.

Kind regards,

Adam

[1] https://datatracker.ietf.org/doc/draft-ietf-sacm-requirements/
[2] https://datatracker.ietf.org/doc/draft-haynes-sacm-ecp/
[3] https://datatracker.ietf.org/doc/draft-birkholz-sacm-yang-content/
[4]
https://github.com/sacmwg/vulnerability-scenario/tree/master/ietf_99_hackathon

[5]
https://raw.githubusercontent.com/sacmwg/vulnerability-scenario/master/ietf_99_hackathon/graphics/hackathon_deployment_combined.png



On Wed, Jul 26, 2017 at 1:46 PM Jessica Fitzgerald-McKay <jmfmckay@gmail.com>;
wrote:

> 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 <gfedorkow@juniper.net>;
> 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:
> http://nvlpubs.nist.gov/nistpubs/ir/2016/NIST.IR.8060.pdf) 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 (
> https://www.trustedcomputinggroup.org/wp-content/uploads/Server_Discovery_And_Validation_v1_0r19-PUBLIC-REVIEW.pdf).
> 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.
>>
>> Thx,
>>
>> /guy
>>
>>
>>
>>
>>
>> _______________________________________________
>> Panic mailing list
>> Panic@ietf.org
>> https://www.ietf.org/mailman/listinfo/panic
>>
>> _______________________________________________
> Panic mailing list
> Panic@ietf.org
> https://www.ietf.org/mailman/listinfo/panic
>