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

[Henk Birkholz <[e-mail]>]

Hi Dave,

I'd like to highlight and elaborate on a very specific topic here:

Yes, routers (or network equipment ranging from AS routing to access 
layer distribution) most defiantly use "IPv4, IPv6, link-layer protocols 
such as Ethernet, routing protocols, often things like DHCP relay, 
RADIUS". I am in total agreement with that. This is (in itself) 
obviously true.

I'd dare to say every RATS solution will be using IPv4, IPv6, 
Industrial/Automotive EtherNet (please note the spelling) and various 
routing protocols & AAA solutions. That is true, too.

I'd like to add to that (with the exception of everything carrying EAP 
et. al. - that is an interesting path to explore) that it is very 
obvious that of course layer 2/3 & layer 4 solutions are involved 
always. But that this natural, yet coincidental, fact has an impact on 
all of rats RATS - via meaningful, structured synergized solution that 
are base on these assumption - seems like a non sequitur to me. Please 
help me understand.

Yes, the afore mentioned heterogeneous mix of things is used - literally 
by basically everything.

RATS TUDA for example could use ICMP Echo Requests. Is it possible? In 
Yokohama we concluded - sure! Is it an academic exercise and therefore a 
solution looking for a problem - probably yes.

What I am trying to say is: DHCP (via options), AAA (via extension) are 
used in the scope of routing equipment - sure! - and can be augmented 
with useful and believable evidence/attestation results about 
trustworthiness about a remote peer.

But is that a reason to not pursue the near term target of creating a 
unified procedure to establish unified trust relationships wrt 
trustworthiness between interconnected network equipment?

No.

It is actually very important to do this today. This neither implies 
niche solutions nor does it imply a lack of extensible later.

I am literally confuzzled by the notion that this approach is not 
addressing an immediate need today in a meaningful manner.

Dave, could you please elaborate why this is not useful, or 
counterproductive, or not in scope? I find your table to be a 
misrepresentation of the actual current relevance due to its initial 
column being types of RoT. Please help me to understand what you are 
trying to say here.

Viele Grüße,

Henk

On 15.11.19 15:38, Eric Voit (evoit) 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.
> 
> /Eric
> 
> Dave
> 
> *From:* Laurence Lundblade <[e-mail] 
> <mailto:[e-mail]>>
> *Sent:* Wednesday, November 13, 2019 10:07 AM
> *To:* Dave Thaler <[e-mail] <mailto:[e-mail]>>
> *Cc:* Smith, Ned <[e-mail] <mailto:[e-mail]>>; 
> Oliver, Ian (Nokia - FI/Espoo) <[e-mail] 
> <mailto:[e-mail]>>; Nancy Cam-Winget (ncamwing) 
> <[e-mail] <mailto:[e-mail]>>; [e-mail] 
> <mailto:[e-mail]>; Henk Birkholz <[e-mail] 
> <mailto:[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]
>     <mailto:[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] <mailto:[e-mail]>>
>     *On Behalf Of *Smith, Ned
>     *Sent:* Monday, November 11, 2019 10:12 AM
>     *To:* Oliver, Ian (Nokia - FI/Espoo) <[e-mail]
>     <mailto:[e-mail]>>; Laurence Lundblade
>     <[e-mail] <mailto:[e-mail]>>; Nancy
>     Cam-Winget (ncamwing) <[e-mail] <mailto:[e-mail]>>
>     *Cc:* [e-mail] <mailto:[e-mail]>; Henk Birkholz
>     <[e-mail]
>     <mailto:[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] <mailto:[e-mail]> on
>     behalf of [e-mail]
>     <mailto:[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]
>     <mailto:[e-mail]>>
>     *Sent:* 11 November 2019 00:44
>     *To:* Nancy Cam-Winget (ncamwing) <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* Henk Birkholz <[e-mail]
>     <mailto:[e-mail]>>; rats@ietf..org
>     <mailto:rats@ietf..org> <[e-mail] <mailto:[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] <mailto:[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
>