Re: [sacm] WGLC for draft-ietf-sacm-ecp

Ira,
Thank you for the review. Responses in-line denoted by [jmf].

On Tue, Jul 2, 2019 at 12:07 PM Ira McDonald <blueroofmusic@gmail.com>
wrote:

> Hi,
>
> Ira's comments on <draft-ietf-sacm-ecp-05>
>
> 3.2.1.  Provisioning
>
> - Describes one-time setup examples of serial numbers (immutable),
> hardware certificates (long-lived), and device MAC addresses, which
> are NOT immutable and *should* be changing for Random MAC address
> usage over time, per recent IEEE 1609 (WAVE), IEEE 802.11 (Wi-Fi),
> and Common Criteria protection profile recommendations.
>
> - Recommend removing the MAC address example from this clause.
>

[jmf] We've had lots of discussion around the MAC address issue. I realize
here you are not arguing against it's use as a device identifier, but are
saying that it ought to be differentiated from other more permanent
identifiers. I believe, though, that we still want to capture the idea that
a device should be provisioned with a MAC address initially, even though
that MAC address ought to change. Perhaps we can remove the MAC address
example from this sentence, but add a new sentence immediately afterwards
saying that the device should have one, and it should change over time.
Would that work?

>
> 6.  Future Work
>
>    "Reassess the use of MAC addresses, including market research to
>    determine if MAC addresses continue to be a widely implemented
>    device identifier among network tools."
>
> - Market research showing the continued unwise use of fixed MAC
> addresses in Enterprise networks is not a valid criteria.  This is
> one of many bad security practices that are hard to stamp out.
>
> - Recommend changing to:
>    "Reassess the use of MAC addresses, based on technical research
>    into current security best practices in IoT, automotive, mobile,
>    and other privacy sensitive market domains."
>

[jmf] I agree with you, but, MAC addresses continue to be used by network
tools, and the ECPC will likely not change that. We've been round and round
on this issue, and I'd like to firmly settle it, but, until the market
moves along with us, it'll remain open. I would like to add in your words
about technical research, and keep the notion that we are really only
collecting MAC addresses because we need to be able to share data with our
network tools. It moves the security ball forward while acknowledging the
reality of network-based defense. Does that work?

>
>
> 10.  Privacy Considerations
>
>    "The EPCP specifically addresses the collection of posture data from
>    enterprise endpoints by an enterprise network.  As such, privacy is
>    not going to often arise as a concern for those deploying this
>    solution."
>
> - Stongly disagree.  If enterprise (or cloud) servers with endpoint
> posture metadata are successfully hacked (they're an attractive target),
> then major privacy issues arise with location/time-of-day association
> with PII for mobile users.  In the EU, GDPR protections definitely do
> apply to enterprise networks.
>
> - Recommend changing to:
>
>    "The EPCP specifically addresses the collection of posture data from
>    enterprise endpoints by an enterprise network.  As such, privacy is
>    a fundamental concern for those deploying this ECP solution, given
>    EU GDPR, California CCPA, and many other privacy regulations.  The
>    enterprise SHOULD implement and enforce their duty of care."
>

[jmf] Agreed, thank you for the better words.

>
>    "An enterprise network should limit access to endpoint posture and
>    identification information to authorized users."
>
> - Very weak statement.  Potentially large number of network admins and
> IT support people may have access to endpoint posture metadata.  They
> should always have training about the importance of protecting this
> endpoint posture metadata.
>
> - Recommend changing to:
>
>    "An enterprise network SHOULD limit access to endpoint posture and
>    identification information to authorized users and SHOULD enforce
>    policies that prevent export of endpoint posture metadata to third
>    parties (except duly authorized law enforcement personnel)."
>
> [jmf] I like your ideas here. Maybe we can change the edit to read  "An
enterprise network SHOULD limit access to endpoint posture and identification
information to authorized users and SHOULD enforce policies that prevent
export of endpoint posture metadata to *unauthorized *third parties".

>
> Cheers,
> - Ira
>
>
Thanks again,
Jess

> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Co-Chair - TCG Metadata Access Protocol SG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
> http://sites.google.com/site/blueroofmusic
> http://sites.google.com/site/highnorthinc
> mailto: blueroofmusic@gmail.com
> PO Box 221  Grand Marais, MI 49839  906-494-2434
>
>
>
> On Thu, Jun 27, 2019 at 4:34 PM Karen O'Donoghue <odonoghue@isoc.org>
> wrote:
>
>> Folks,
>>
>> As discussed at our virtual interim on Tuesday, this begins a three week
>> working group last call for:
>> Endpoint Posture Collection Profile
>> https://datatracker.ietf.org/doc/draft-ietf-sacm-ecp/
>>
>> Please reply to this email thread with an indication that you have read
>> the document, any comments you may have, and your assessment of whether or
>> not it is ready to proceed to publication.
>>
>> DEADLINE: Please reply by Friday 19 July 2019.
>>
>> Thanks!
>> Karen and Chris
>>
>> _______________________________________________
>> sacm mailing list
>> sacm@ietf.org
>> https://www.ietf.org/mailman/listinfo/sacm
>>
>