Re: [Rats] Call for adoption (after draft rename) for Yang module draft

[Kathleen Moriarty <[e-mail]>]

On Fri, Nov 15, 2019 at 9:38 AM Eric Voit (evoit) <[e-mail]> wrote:

> *From:* Dave Thaler, November 15, 2019 2:39 AM
>
> Netconf is not the only protocol supported by routers.
>
> Routers also support IPv4, IPv6, link-layer protocols such as Ethernet,
> routing protocols, often things like DHCP relay, RADIUS, etc.
>
> <Eric> Below I would have said " Router/YANG" below rather than
> "Router/NETCONF".
>
>
>
> I have not yet seen a compelling reason to use a pull-based mechanism
> instead of a push-based mechanism via another protocol the routers already
> support.
>
> <Eric> Router vendors want push-based mechanisms too.  And NETCONF does
> push.  See RFC-8640 and RFC-5277.
>
>
>
> The only reason I’ve heard so far is “because they support netconf and
> we’re used to it”, to which the counter argument is as above:
>
> they support other things too and we’re used to them too.
>
> <Eric> There is piles of documentation in the IETF and beyond detailing
> the reasoning and extent of consolidation on YANG for network management.
>   IETF, IEEE, MEF, OpenConfig, and others forums are defining these.  I
> wouldn't expect another anytime soon.
>
>
>
> NETCONF can support YANG. Other transports can support YANG.   The current
> draft under an adoption call does not specifically reference NETCONF.
>
>
>
> In order to know who to pull data from, the Verifier has to have some
> indication from the Attester that triggers the attestation request
>
> indicated as Step 1 in draft-fedorkow-rats-network-device-attestation.  So
> in reality, there has to be a step before step 1,
>
> whereby the Attester does something that makes the Attester discoverable
> by the Verifier.   That step could have included the EAT or the TPM data
>
> expressed in the YANG draft, or whatever else, and then you’ve avoided the
> need for netconf, and reduced the number of round trips,
>
> improving latency and bandwidth.
>
> <Eric> It is already possible to subscribe to existing proprietary YANG
> attestation models.  This requires zero extra round-trips.   The push can
> be leave the Attester in <1 sec.
>
>
>
> If there is a compelling reason to support a pull-based mechanism, and we
> get consensus that we need it, then great.
>
> But so far I haven’t heard one.
>
> <Eric> A YANG model supports both push and pull.  Application vendors want
> a standard attestation model.  That is why you have many network vendors
> authoring this YANG draft under the adoption call.
>
>
>
> Honestly I don't understand the push-back.   This should be a no-brainer.
>

Agreed, seems like an unnecessary rat hole.  The conversation should move
on.

Thanks,
Kathleen


>
>
> /Eric
>
>
>
> Dave
>
>
>
> *From:* Laurence Lundblade <[e-mail]>
> *Sent:* Wednesday, November 13, 2019 10:07 AM
> *To:* Dave Thaler <[e-mail]>
> *Cc:* Smith, Ned <[e-mail]>; Oliver, Ian (Nokia - FI/Espoo) <
> ian.oliver@nokia-bell-labs..com <[e-mail]>>; Nancy
> Cam-Winget (ncamwing) <[e-mail]>; [e-mail]; Henk Birkholz <
> [e-mail]>
> *Subject:* Re: [Rats] Call for adoption (after draft rename) for Yang
> module draft
>
>
>
> My version of technology bases for attestation is something like this:
>
>
>
> *Router/Netconf World*
>
> Millions of devices. Currently TPM oriented. Long possible transition to
> EAT. YANG used to create very specific fine-grained interactions. No
> privacy issues.
>
>
>
> *Web Browser World*
>
> Billions of devices. Current attestation use is primarily WebAuthN / FIDO.
> JWT is used heavily for authentication so would be more EAT oriented, but
> TPM attestation is supported in FIDO. Larger use of attestation may evolve.
> Fine-grained interactions are with WebAPIs (Javascript) (sort of parallel
> to YANG for routers). Big privacy issues.
>
>
>
> *Mobile App World*
>
> Billions of devices. Main attestation use is Android’s Keystore. This is
> EAT-like, but based on X.509. Fine grained interactions are Android APIs. I
> may be out of date, but so far IoS doesn’t do attestation. Privacy issues
> vary by app.
>
>
>
> *IoT World*
>
> Billions of devices most likely going to trillions. Attestation is a
> critical enabling feature in this world. There are lots of protocols and
> formats involved. TPMs are too expensive for many of these, but are
> probably in use somewhere. No privacy issues for a large portion of this
> world.
>
>
>
> The router world is the smallest, but it is “well represented” because
> this is the IETF.
>
>
>
> I see EAT as applicable to all these worlds, where the YANG module is just
> for the smallish router world. So I mostly agree with Dave about
> proportions, however this is the IETF where YANG modules are created.
>  (Maybe I should go join the W3C world and work on attestations APIs for
> browsers after RATS is done).
>
>
>
> LL
>
>
>
>
>
>
>
> On Nov 11, 2019, at 5:43 PM, Dave Thaler <[e-mail]> wrote:
>
>
>
> As far as I can understand from draft-birkholz-rats-basic-yang-module-01
> and
>
> draft-fedorkow-rats-network-device-attestation-01, they break down the use
> case
>
> space as follows:
>
>
>
>                         Requirements?
>
>          +--------------+---------------+---------++---------------
>
>          |  RoT         | Host Firewall | Privacy ||   Solution
>
>          |  Type        |   Enabled     | Needed  ||    Pieces
>
>          +--------------+---------------+---------++---------------
>
>       1  |  SGX         | No            | No      ||
>
>       2  |  SGX         | No            | Yes     ||
>
>       3  |  SGX         | Yes           | No      ||
>
>       4  |  SGX         | Yes           | Yes     ||
>
>       5  |  TrustZone   | No            | No      ||
>
>       6  |  TrustZone   | No            | Yes     ||
>
>       7  |  TrustZone   | Yes           | No      ||
>
>       8  |  TrustZone   | Yes           | Yes     ||
>
>       9  |  TPM         | No            | No      ||
> draft-birkholz-rats-basic-yang-module-01
>
>      10  |  TPM         | No            | Yes     ||
>
>      11  |  TPM         | Yes           | No      ||
>
>      12  |  TPM         | Yes           | Yes     ||
>
>      13  |SecureElement | No            | No      ||
>
>      14  |SecureElement | No            | Yes     ||
>
>      15  |SecureElement | Yes           | No      ||
>
>      16  |SecureElement | Yes           | Yes     ||
>
>      17  | Firmware     | No            | No      ||
>
>      18  | Firmware     | No            | Yes     ||
>
>      19  | Firmware     | Yes           | No      ||
>
>      20  | Firmware     | Yes           | Yes     ||
>
>      .... |   ...        |               |         ||
>
>
>
> And draft-fedorkow-rats-network-device-attestation-01 further scopes
> itself down
>
> by only being applicable to cases with "embedded" apps only = Yes, and
> where
>
> the security policy is only an Exact match against reference values = Yes.
>
> I believe that the yang draft doesn't have those two restrictions, from my
> reading.
>
> However, the point is that both drafts are VERY narrow, and in the table
> shown above,
>
> only address 1 out of 20 possibilies in that space.
>
>
>
> In contrast, the TEEP WG decided that it was not interested in narrow
> scopings
>
> (specifically something Global Platform specific), but instead wanted one
> general solution.
>
>
>
> If the RATS WG spends effort on something that only addresses a single row
> out of 20+ rows,
>
> then do we expect 19+ other solutions to also be done in the WG?  Or could
> we work on things
>
> that are broader and happen to also work for row 9?
>
>
>
> I've seen others commenting on the fact that the YANG module only supports
> TPMs and not
>
> other things (EATs etc), which would just add support for a couple more
> rows, but still not
>
> be general.
>
>
>
> Personally, I would much rather see the WG spend effort on things that
> really are generic,
>
> i.e., work with or without host firewalls, work with multiple RoT/TEE
> types, etc., rather
>
> than seeing an explosion of point solutions.
>
>
>
> Dave
>
>
>
> *From:* RATS <[e-mail]> *On Behalf Of *Smith, Ned
> *Sent:* Monday, November 11, 2019 10:12 AM
> *To:* Oliver, Ian (Nokia - FI/Espoo) <ian.oliver@nokia-bell-labs..com
> <[e-mail]>>; Laurence Lundblade <
> [e-mail]>; Nancy Cam-Winget (ncamwing) <[e-mail]>
> *Cc:* [e-mail]; Henk Birkholz <[e-mail]>
> *Subject:* Re: [Rats] Call for adoption (after draft rename) for Yang
> module draft
>
>
>
> Right. This implies the RATS “token” should support existing “binary”
> formats as an encapsulation (signed by a second TA where the TPM is a first
> TA) or as a conveyance (unsigned?) token. Possibly, the only added value of
> the latter is a tag that identifies it as a TPM binary format?
>
>
>
>
>
> On 11/10/19, 23:21 PM, "RATS on behalf of Oliver, Ian (Nokia - FI/Espoo)" <
> [e-mail] on behalf of ian.oliver@nokia-bell-labs..com
> <[e-mail]>> wrote:
>
>
>
> > Remote TPM attestations are useful and necessary the short run, but are
> of very limited capability. I believe that > EAT will replace TPM
> attestations in the long run (maybe decades) because they are far more
> expressive. I know > others believe that too.
>
>
>
> I would disagree with the statement of "short run" ... TPM is practically
> the only existing standardised (hardware, software, firmware, measurement -
> x86 only etc) hardware root of trust in common use, ie: practically all x86
> machines,  The attestation mechanisms provided are going to be around for a
> very long time.
>
>
>
> From telco experience, 30 years ago we said SS7 would only be around in
> the short term.
>
>
>
> > Thus, I am opposed to adoption with the current TPM-only draft. I’d be
> OK with the current draft and a promise > to add EAT to it.
>
>
>
> Agree
>
>
>
> Ian
>
>
>
> --
>
> Dr. Ian Oliver
>
> Cybersecurity Research
>
> Distinguished Member of Technical Staff
>
> Nokia Bell Labs
>
> [phone]
>
>
> ------------------------------
>
> *From:* Laurence Lundblade <[e-mail]>
> *Sent:* 11 November 2019 00:44
> *To:* Nancy Cam-Winget (ncamwing) <[e-mail]>
> *Cc:* Henk Birkholz <[e-mail]>; rats@ietf..org <
> [e-mail]>
> *Subject:* Re: [Rats] Call for adoption (after draft rename) for Yang
> module draft
>
>
>
>
>
> On Nov 10, 2019, at 2:20 PM, Nancy Cam-Winget (ncamwing) <
> [e-mail]> wrote:
>
>
>
> So, Laurence, are you still OK with the adoption of the current draft with
> a rename for now?
> Thanks, Nancy
>
>
>
> I think the value add to the larger RATS effort of adding EAT support to
> this YANG protocol is really high. It a core thing to do that helps bring
> together the two attestation worlds and make the TPM and EAT work here less
> like ships in the night.
>
>
>
> Remote TPM attestations are useful and necessary the short run, but are of
> very limited capability. I believe that EAT will replace TPM attestations
> in the long run (maybe decades) because they are far more expressive. I
> know others believe that too.
>
>
>
> If we don’t include EAT in the YANG mode it is sort of like defining HTTP
> to only convey HTML to the exclusion of PDF. We’re defining an attestation
> protocol that can only move one kind of attestation even though we have
> consensus on what the other one looks like.
>
>
>
> It seems relatively simple to add EAT support (or promise to add EAT
> support). Pretty sure I heard Henk agree to add it.
>
>
>
> Thus, I am opposed to adoption with the current TPM-only draft. I’d be OK
> with the current draft and a promise to add EAT to it.
>
>
>
> LL
>
>
>
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>


-- 

Best regards,
Kathleen