Re: [Model-t] What are we trying to protect

Hi,

I disagree with this characterization of the IETF's historic interest.

IETF NEA (built on contributed TCG TNC protocols) is *all* about
the security and health of endpoints.  And IETF NEA is now being
leveraged heavily in IETF SACM for that very reason.  SACM is
of course *mostly* about the security and health of endpoints and
only incidentally about middleboxes.

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 Tue, Aug 6, 2019 at 5:45 PM Thomas Hardjono <hardjono@mit.edu> wrote:

>
> >>> 1) Attacking the system directly.
>
> >>> 2) Delivering an attack through a user-initiated session or
> exfiltrating data through said session
>
> >>> 4) Passive monitoring of all traffic
>
> >>> 5) Monitoring and tracking all user's traffic inside their session.
>
>
> Historically the IETF has focused on protocols and communications
> security. This was an explicit choice/decision of the IETF community in the
> mid-1990s. So, all the protocols we have (ISAKMP, IKE, IPsec, TLS, etc.)
> have addressed a threat model that was focused on the communications
> channel. The security of the end-point, such as a Client or device, was out
> of scope (until now, I guess, depending).
>
> If the IETF’s scope is going to be expanded, I’d suggest the IETF
> developing an abstraction model and terminology that helps discussion.
> Otherwise we end up boiling the ocean with too many words, use-cases and
> scenarios.
>
> At the Montreal SAAG meeting I mentioned the term end-point “state”.  One
> way to map the above list of threats would be to express it abstractly in
> terms of state and the protection of state information/data. So, the above
> list could be mapped to something like this:
>
> (i) Unauthorized modification of end-point state. (i.e. attacking a client
> OS.).
>
> (ii) Unauthorized exfiltration of end-point state information (i.e.
> exfiltration of data, both system-data and user-data, from a machine).
>
> (iii) Malicious substitution of state in transit (i.e. hi-jacking a
> connection and doing a MITM).
>
> (iv) Unhindered reporting of end-point state information (i.e. authentic
> reporting from a MIB in a device).
>
>
> You get my point. It’s no longer just about protection of the
> communication channel and transport protocol resiliency.  It’s now about
> the “stuff” at the end of the channel.
>
>
> — thomas —
>
> --
> Model-t mailing list
> Model-t@iab.org
> https://www.iab.org/mailman/listinfo/model-t
>