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

From: Thomas Hardjono <[email-masked]>
Date: Tue, 6 Aug 2019 21:45:23 +0000

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

---

From: Ira McDonald <[email-masked]>
Date: Tue, 6 Aug 2019 20:27:38 -0400

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: [email-masked]
PO Box 221  Grand Marais, MI 49839  906-494-2434

On Tue, Aug 6, 2019 at 5:45 PM Thomas Hardjono <[email-masked]> wrote:

> 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:
>
> (ii) Unauthorized exfiltration of end-point state information (i.e.
> exfiltration of data, both system-data and user-data, from a machine).
>
> 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
> [email-masked]
> https://www.iab.org/mailman/listinfo/model-t
>

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 7 Aug 2019 00:38:09 +0000

Hi Ira,

I’m familiar with NEA — NEA & TNC (and NAP & NAC) are relatively recent.  I’m talking about the majority of RFCs coming out of the Security Area since the mid-1990s.

This was a core part of the End-to-End Principle (e.g. key management and handling of keys at the edges, out side the scope of the IETF).

/thomas/

___________________________________

On Aug 6, 2019, at 8:24 PM, Ira McDonald <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Cheers,
- Ira

mailto: [email-masked]<mailto:[email-masked]>

— thomas —

--
Model-t mailing list
[email-masked]<mailto:[email-masked]>
https://www.iab.org/mailman/listinfo/model-t

---

From: Watson Ladd <[email-masked]>
Date: Tue, 6 Aug 2019 20:33:07 -0700

Kerberos and NFS are two notable exceptions.

On Tue, Aug 6, 2019 at 5:38 PM Thomas Hardjono <[email-masked]> wrote:
> On Aug 6, 2019, at 8:24 PM, Ira McDonald <[email-masked]> wrote:
>
> Hi,
>

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 7 Aug 2019 20:21:53 +0000

As far as know, RFC 1520, 4120 and 2743/44 does not support the reporting of the *state* of keys in the KDC, the software-stack of the KDC, etc. etc.

I think my point is non-contentional: the End to End argument in the late 80s and into the 1990s made the inquiry of (reporting of) endpoint security state information out-of-scope for the IETF's work. Its corollary of the end to end principle.

-- thomas --

________________________________________
From: Watson Ladd [[email-masked]]
Sent: Tuesday, August 6, 2019 11:33 PM
To: Thomas Hardjono
Cc: Ira McDonald; [email-masked]
Subject: Re: [Model-t] What are we trying to protect