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

Hi Jess,

Yes to all of your responses and suggestions.

Cheers,
- Ira

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, Jul 25, 2019 at 11:11 AM Jessica Fitzgerald-McKay <
jmfmckay@gmail.com> wrote:

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