Re: [sacm] ECP question

Ruben Oliva <david.oliva@verizon.net> Sat, 27 April 2019 02:44 UTC

Return-Path: <david.oliva@verizon.net>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B38120145 for <sacm@ietfa.amsl.com>; Fri, 26 Apr 2019 19:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 XCXhS_Jq3L8H for <sacm@ietfa.amsl.com>; Fri, 26 Apr 2019 19:44:48 -0700 (PDT)
Received: from sonic311-25.consmr.mail.gq1.yahoo.com (sonic311-25.consmr.mail.gq1.yahoo.com [98.137.65.206]) (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 441391200F8 for <sacm@ietf.org>; Fri, 26 Apr 2019 19:44:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1556333087; bh=I9GiQnDyFq9u9dw4FsVRO7PI82/fVemEIdFh8vFvxCE=; h=Date:From:To:Cc:Subject:References:From:Subject; b=tb7O3IWaltX4dsnsDu0hw9uuENNRVIBFyI7La0AgG3RTPT4eGBVQxHSKt5+gxEbLwfEMRFrIm+ol+NOXchTwiyaLxsFJR0gp28ASjBRTVtbpktAe0MmdBeSqIvsSaZ23LA250WivGqRWeXo4CTWm5pnXjz3EKtxrxwuWt4D7SA2uNunxtbU1O7Wc8PGTqxxaPuUFBv44O6UDJ4y/UbhVjt8fdWrvM+Sfi6lbcDHaY093nRdEMuAVByA4o470kI1/hkd9shUP1yJKJVGBjlgIEtTSWpEVSlHfwUz/9cQT5HRcVyBkQd29KLK26fnlc9lSUN3eveMmso/L/Q1lJPcQww==
X-YMail-OSG: fKpejDAVM1kDiT4TVnuTaQkpK77rNSoxVv967Zo_McEoPdZXC_MIHoUfL79iwwv FN_cUN2X27pp.sTT_KjD2TBa.57wi7nppLTfj7AFkPwMlKETLUBaZ_NWiZGY902qCBW6J5B7gAK5 HJl9Zjf29WIEMdv0zoRo9yZWoPlSDMG6fSftk0T3r5zzj1ch10aloNtJ646AMMnTcBaCRBbdcMnq fVSV.SjJPQAU_5aSNK4BS66xQ47D6C9rQv5KflnU4y2b7Upl.iia3xj2_3Wgn09TlfmC.u6NECXL t.a7i3KnKucE0ckAeu2vhyPv1a9.zQ77aQP7WBH.7G1x9QpqqlQCU9qUp_jZXZ2TNDULHcTeSJx2 LQY1vfLwb97f9DxPJZ8fGc4Zf3AZQtZtZy3WZlMeiRCyvBuxPMqARJYK5fUsijFPUEbzP507KH0q BWVZs0fI85cUSJStXrFg6Pf92eOsVgb41f4UYWSX7ZEBetb6vh3QIxPiXJ2J9FCMpXK_oLF43_1e cT7FP..XqEqM__.dpILMjmU4w6e1ywQ57lABN8HhmIsCoQbNBdcEsrvl3o3IX9ec44mJtrbX_ggA JeHjiSmYY292RgIWkEXzfQDIsLBy3vS0Myp0ji_PI6Va01HQLBPk2fLug8hPUBdMG3oBJQoxXSFp 6bVempLSBmi2jFYkNt3bLWhvm5nruMYm08z2nXHz5MHB02e80tKFeRf1ke9DmllTNNugipSJMDv1 KqROjcVT2srh97bK5evMXatsM4isqANJdvJZcTHVprkpOoP3LT9D3zvHy0f9zuOXZNSc5QdzHPeF zbv00Doj5fTfUcAm6JC7qUmRSELp5zk0KVu8MrStCzUDtF1L82pq8XjWk1RkMRiTWypPlhfWBUm_ j5ruWrG11f2TPgL1Yha7R1BaNDxe8zd40KJa9eIRxhe3oa0eemuebOmq19ydrcwDa2nkmdYdMJzy fRwWnPQfw0lc9bdfjgw4IkSbDCLLDoMdLK4HD8A35C_tYx0UT8Ypm7Bs.BXPLojtiaY9J0CKx8Ao WGpYnRM7isZqYxqY8Ki5XEP5UnCtwVn8dJDrULIc0fAMfOGKOLUwz_.0Uc9WBYcXK_biWA9522_R IqVPIOaHvEOy.NEFgZMQYL5deNc_lCRiECwtImpP1o0ek.34OAH6rNcQEMKj7BClwoJ3opy2bUBM 5nXsKxmcTp40-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.gq1.yahoo.com with HTTP; Sat, 27 Apr 2019 02:44:47 +0000
Date: Sat, 27 Apr 2019 02:44:46 +0000 (UTC)
From: Ruben Oliva <david.oliva@verizon.net>
To: kathleen.moriarty.ietf@gmail.com, jmfmckay@gmail.com
Cc: draft-ietf-sacm-ecp@ietf.org, dan@ehrlichserver.com@dmarc.ietf.org, sacm@ietf.org
Message-ID: <938745215.1173888.1556333086822@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_1173887_2066412604.1556333086820"
References: <938745215.1173888.1556333086822.ref@mail.yahoo.com>
X-Mailer: WebService/1.1.13554 aolwebmail Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/ne8U-I4rXpny7eEjrVgqnUTzm70>
Subject: Re: [sacm] ECP question
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Apr 2019 02:44:51 -0000

 Hello team:
Here's two additional cents to this trail.
MAC addresses are used in events correlation and auditing.

David Oliva
 
 
-----Original Message-----
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>;
To: Jessica Fitzgerald-McKay <jmfmckay@gmail.com>;
Cc: draft-ietf-sacm-ecp@ietf.org <draft-ietf-sacm-ecp@ietf.org>;; Dan Ehrlich <dan=40ehrlichserver.com@dmarc.ietf.org>;; sacm@ietf.org <sacm@ietf.org>;
Sent: Fri, Apr 26, 2019 10:06 am
Subject: Re: [sacm] ECP question

Hi,
On Fri, Apr 26, 2019 at 8:52 AM Jessica Fitzgerald-McKay <jmfmckay@gmail.com>; wrote:

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,Kathleen

Thanks again for taking the time to share your thoughts!

Jess

On Fri, Apr 12, 2019 at 8:45 PM Dan Ehrlich <dan=40ehrlichserver.com@dmarc.ietf.org>; wrote:

Link I mentioned: https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/?include_text=1
Section 3.2.1
On Fri, Apr 12, 2019 at 5:42 PM Dan Ehrlich <dan@ehrlichserver.com>; 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 EhrlichAustin, Texashttps://linkedin.com/in/danehrlich/

_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm

_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm



-- 

Best regards,Kathleen_______________________________________________
sacm mailing list
sacm@ietf.org
https://www.ietf.org/mailman/listinfo/sacm