Re: [sacm] ECP question

Kathleen Moriarty <> Fri, 26 April 2019 14:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03F83120432; Fri, 26 Apr 2019 07:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bNxZDH5G7civ; Fri, 26 Apr 2019 07:06:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCD771201D9; Fri, 26 Apr 2019 07:06:43 -0700 (PDT)
Received: by with SMTP id s24so2688518otk.13; Fri, 26 Apr 2019 07:06:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CEFPj8Z4KxaQeVDxVIvqpLYFy1PDyHxIrmzcgxaDhNc=; b=UaWBxmHH5n6iRBpHYT0RuRTuOaFd8FHoXQetK8yVwIILME4szrpqQ107wNmAq1otng 7L7cyFbBMOFUpRv2Faiov6hunA1RNmcbUt0+cVyn0sCzt5gPJIPou5kgtVWgjKPh+xtx daiUeHK6tXEnE3qopUsR/AWvNCLyPZtzc4mlH3GfltyQWeTOhRJuCGmw+HusJqsSIoWH B/7+bXqHZY1fxa9424ZGTYGZacSB5ehE6+A7wGLbbcK+G1dlE8G0eZcHwIqacEZZGslA 1swkWdjAFfl4DlQ1BjyHwFTh9tqmrE3ap4HgiUPcNrd2Unh4bIt8XOfQLJGdSkrKxyNu IK8Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CEFPj8Z4KxaQeVDxVIvqpLYFy1PDyHxIrmzcgxaDhNc=; b=e13HyE3WSzu8PHM1b4WuQLgzfVwJRo9U8E+p8w3r4V/K+spP+3mF3NUX9qArhbDE+3 rrEXEB2pFGCMjugDLJRKCIvLaUEhfXd8287o3rVpAezpVThGHzIIn41+lfhe7U0VCBgo dUJsPByyZh5I0y3vieFwXpikoRgN1LVM7bh6CdQTUgbWUT4//twC0Hkrbmf7zXxnrnow rsXqYvlZoOOYb/DtmYj+8ngIuA1bcT43EUiizJu5WEx/Wru/2SrWWZkEvlyxyuOjyGB4 iUyHYstCHNfFNVhzcByRC9JVgQIwv38anjRRGOyWKwMGKoTEcEt1AcOSRFBLVN0/xB83 QWOg==
X-Gm-Message-State: APjAAAVUgohdcaUdQ7flPziis3wxOxPxGQ5J+LkT0tWOITpydhesDqFk Ys/lpf5v2dzQrwa/Muioy/gxKi2R1lBPj+bY/cc=
X-Google-Smtp-Source: APXvYqy6pltqN7lzhnP9ic5XxnBR7FOPpb0/isD6pC/lB8uw6EEw+6SguZgUB7N3Fx3G+gTjx6LcC4+6TKwS0cSLbbw=
X-Received: by 2002:a9d:2e8:: with SMTP id 95mr28988721otl.283.1556287603048; Fri, 26 Apr 2019 07:06:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Kathleen Moriarty <>
Date: Fri, 26 Apr 2019 10:06:06 -0400
Message-ID: <>
To: Jessica Fitzgerald-McKay <>
Cc: Dan Ehrlich <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000bf84b505876f71c0"
Archived-At: <>
Subject: Re: [sacm] ECP question
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SACM WG mail list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Apr 2019 14:06:46 -0000


On Fri, Apr 26, 2019 at 8:52 AM Jessica Fitzgerald-McKay <>;

> Dan,
> Thank you for the review! Your understanding of MAC addresses mirrors
> mine: they are not trustworthy as a sole device identifier. I think that,
> despite that, they are still worth collection, for two reasons:
> 1) For device identity correlation-- For some network analytics, the MAC
> address is what they can see. These analytics should have the capability to
> correlate the behavior they see from an endpoint with a particular MAC
> address to a better device identifier. One way to do that is to provide all
> the identifiers an endpoint has (IP address, MAC address, device
> certificate, etc.) to the CMDB. For traditional endpoints, the ECP requires
> IF- IMC and (on the server side) IF-IMV. These interfaces allow endpoints
> to share multiple forms of identity to the server, and then stored in the
> CMDB for this sort of use case.
> 2) For attack identification-- ECP enables event-driven collection of
> endpoint data. That is, if something changes on the endpoint, ECP enables
> that change to be immediately (or, close to immediately) sent to the
> server, and then to the CMDB. An endpoint could share any changes to its
> MAC address as a part of that event-driven collection, which would help
> network tools notice a malicious change in near-real-time.
> Given these reasons, I would like to keep MAC addresses as a type of
> device identity in the ECP.
> I wonder if we could resolve your comments by including a note in the
> security considerations about the trust limitations of MAC addresses. We
> can say that they really should not be used as a sole device identifier,
> and, if other identities can be reported, they really ought to be collected
> at the same time as a MAC address. What do you think?

I think this is a good idea.  They may also be in a Privacy Considerations
section.  You may want to call out the scope of collection in this
description as well.  For instance, it may be recommended for use only
within a closed network (datacenter, managed network, enterprise, etc.).
For MAC addresses, randomization has been defined separately by multiple
vendors, but in ways that you can detect who the vendor is by their
randomization pattern.  Privacy work to mitigate that came out of IEEE to
standardize the randomization method across vendors.  I don't think that is
well deployed.

IMO, The section should touch on each of the identifier types and perhaps
limit the recommended scope of use as a precautionary measure to assist
with privacy. This will help address comments that could come in IETF last
call or from the IESG.

Thank you,

> Thanks again for taking the time to share your thoughts!
> Jess
> On Fri, Apr 12, 2019 at 8:45 PM Dan Ehrlich <dan=
>>; wrote:
>> Link I mentioned:
>> <>
>> Section 3.2.1
>> On Fri, Apr 12, 2019 at 5:42 PM Dan Ehrlich <>;
>> wrote:
>>> In the RFC for ECP, there is a section that mentions the potential use
>>> of MAC addresses for identifying endpoints.
>>> My understanding is that there are many things wrong with MAC addresses
>>> today, such as that they can now be changed randomly by software, can't
>>> really be verified, can be spoofed easily, etc.
>>> I cannot find the link I was using from yesterday, but can the MAC
>>> address mention be removed from ECP?
>>> Apologies if I viewed an old draft or if this was previously discussed,
>>> Dan Ehrlich
>>> Austin, Texas
>>> <>
>> _______________________________________________
>> sacm mailing list
> _______________________________________________
> sacm mailing list


Best regards,