[nasr] Re: [saag] Re: Re: Re: NASR BOF Follow-Up

[Eric Rescorla <[e-mail]>]

On Fri, Apr 11, 2025 at 2:34 AM Liuchunchi(Peter) <[e-mail]>
wrote:

> > In the same way, you would start collecting enough attestation to trust
> the
> > commands through which you retrieve operational state (including prior
> > valiation of all credentials to talk to the routers). Such as (YANG
> equiv) "show
> > int * macsec state"
> > or the like (to circle back to my most favourite feature ;-). Which
> would show
> > enough details to know the credentials of the peer and that the
> interfaces
> > traffic is MacSEC secured with approved session and data encryption
> > protocols.
>
>
> Yes, and such configuration state and operational state should both be
> collected as baselines in the step 1 of NASR architecture.
>
> For device A in the path A-B-C, its "baseline hash" to obtain from the
> step 1 is a keyed hash for example AHash= hash(expected config state,
> expected operational state, expected Ingress Interface, expected Egress
> Interface...)
>
> For device B, it does it recursively like BHash  = hash(received-AHash,
> expected config state, expected operational state, expected Ingress
> Interface, expected Egress Interface...)
>

Which brings us back to the question of whether there are in fact a small
number of enumerable
good states.

-Ekr


>
> And when actual step 2 forwarding takes place, repeat the
> take-and-hash-and-replace process, only to change " expected config state "
> to " actually measured config state ". And a canonical verification can be
> done.
>
> Hope I am not oversimplifying to confuse people...
>
> Peter
>
> > -----Original Message-----
> > From: Toerless Eckert <[e-mail]>
> > Sent: Friday, April 11, 2025 8:11 AM
> > To: Eric Rescorla <[e-mail]>
> > Cc: Henk Birkholz <[e-mail]>; Michael Richardson
> > <[e-mail]>; [e-mail]; IETF SAAG <[e-mail]>
> > Subject: [nasr] Re: [saag] Re: Re: Re: NASR BOF Follow-Up
> >
> > Eric,
> >
> > >From my understanding, this analysis does not need to be constrained to
> > configuration state. In fact, i would never want to trust configuration
> state
> > alone, but only configuration and operational state.
> >
> > This is the same for existing rats for e.g.: secure bootstrap. The
> attestation
> > provided by a device is not that it has some "operating system file with
> some
> > cert/signature", but that that is actually the running OS.
> >
> > In the same way, you would start collecting enough attestation to trust
> the
> > commands through which you retrieve operational state (including prior
> > valiation of all credentials to talk to the routers). Such as (YANG
> equiv) "show
> > int * macsec state"
> > or the like (to circle back to my most favourite feature ;-). Which
> would show
> > enough details to know the credentials of the peer and that the
> interfaces
> > traffic is MacSEC secured with approved session and data encryption
> > protocols.
> >
> > It is then the controller who provides the attestation for the fact that
> the
> > network (or subdomain or whatever) is running MacSec beteween all
> > members.
> >
> > And if we could get scripts into routers to do this analysis of
> operational state
> > locally on a router, that would be even better, because then it could
> probably
> > be extending what the router can attest to itself - and the NASR
> controller
> > needs to primarily provide only attestation as to the seamless
> connectivity of
> > the per-hop encrypted topoloy or path of interest.
> >
> > Cheers
> >     toerless
> >
> > On Thu, Apr 10, 2025 at 12:28:39PM -0700, Eric Rescorla wrote:
> > > On Thu, Apr 10, 2025 at 11:02 AM Henk Birkholz
> > > <[e-mail]>
> > > wrote:
> > >
> > > > Hi ekr,
> > > >
> > > > auditing the "correctness" of configuration or configurable state is
> > > > an additional step that comes with its own security considerations,
> I think.
> > > >
> > > > The fact that a network device is trustworthy (it is doing what it
> > > > is intended to do (by the Verifier Owner) and nothing else) does not
> > > > directly translate to an operational state that is doing what every
> > > > Relying Party expects it to do, I think.
> > > >
> > > > In remote attestation, the Verifier can be considered a trusted
> > > > third party that takes on the burden of Evidence appraisal. As there
> > > > are can be a quite colorful bouquet of Attester and Evidence types,
> > > > that (sometimes quite significant burden/complexity) burden of
> > > > Evidence appraisal is off-loaded to Verifiers so that the audience
> > > > of Relying Parties can consume digestible Attestation Results
> tailored to
> > their needs.
> > > >
> > > > If there is additional "relevant stuff" w.r.t. a network device
> > > > which needs to be evaluated, that might be a task that remote
> > > > attestation is only in support of - but that does not seem to be an
> > > > explicit part of establishing trust in the trustworthiness in a
> > > > remote peer/router. Or am I missing something very obvious here?
> > > >
> > >
> > > I don't know if you're missing something, but I don't really see how
> > > this addresses my point, which is about the complexity of evaluating
> > > the relevant Evidence, not about who does it. Specifically, my concern
> > > is that it will not be practical to determine whether a given router
> > > configuration enforces the high level semantics desired by the Relying
> > > Party, e.g., that the data is going directly from this system to
> > > system B without any ability for anyone else to see it. In order to
> > > ensure this, someone has to know that all configuration values that
> > > might implicate this guarantee are in known good states. That could
> > > happen by, for instance:
> > >
> > > - The Verifier seeing Claims for all the relevant configuration values
> > > - The vendor determining which configuration values are relevant and
> > > causing the device to emit a higher level Claim
> > >
> > > But in either case, someone needs to take on the analysis of all the
> > > configuration values. Has this been done for the types of devices in
> > > question?
> > >
> > > -Ekr
> > >
> > >
> > > >
> > > >
> > > > Viele Grüße,
> > > >
> > > > Henk
> > > >
> > > > On 06.04.25 22:52, Eric Rescorla wrote:
> > > > >
> > > > >
> > > > > On Sun, Apr 6, 2025 at 12:41 PM Michael Richardson
> > > > > <[e-mail] <mailto:[e-mail]>> wrote:
> > > > >
> > > > >
> > > > >     Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
> > > > >          > However, it's not clear to me that that's true in this
> case,
> > > > >     because
> > > > >          > unlike media players, network devices are highly
> configurable
> > > > >     and a
> > > > >          > large number of the configuration directives might
> impact the
> > > > >     relevant
> > > > >          > security claims. Thus, determining whether an element
> > > > > is
> > > > policy
> > > > >          > conformant is a matter of knowing not just what code it
> is
> > > > >     running
> > > > >          > but the state of every relevant configuration
> directive. One
> > > > >     could
> > > > >          > imagine this working at least three ways:
> > > > >
> > > > >     I think you are making routers sound way more complicated than
> > > > > they
> > > > are.
> > > > >
> > > > >
> > > > >     1. 90% of directives have little to no affect.
> > > > >         (I have one toe in the routing/operations space. I'm
> > > > > ASN26227)
> > > > >
> > > > >
> > > > > Perhaps, but they still need to be individually examined in order
> > > > > to to determine that. Has someone done that?
> > > > >
> > > > >
> > > > >     2. they are significantly less complicated than Windows, yet
> all
> > > > >     that media
> > > > >         based DRM stuff you mentioned is dependant upon windows
> boot
> > > > >     doing the
> > > > >         right thing.
> > > > >
> > > > >
> > > > > But essentially none of the relevant stuff that needs to be
> > > > > attested to is configurable (by design). You just attest to the CDM
> > contents.
> > > > >
> > > > >
> > > > >          > In the former case, it is quite likely that there will
> > > > > be a
> > > > large
> > > > >          > number of valid states, because each directive may have
> > > > multiple
> > > > >          > acceptable values, and so you end up with combinatoric
> > > > explosion
> > > > >          > issues if you just have a list of hashes [0]. In the
> latter
> > > > >     case we
> > > > >
> > > > >     yet, the *routing* people with the expertise here, and a few
> > > > >     operators seem
> > > > >     pretty sure they can do this.
> > > > >
> > > > >
> > > > > It's not uncommon to see people be overconfident about things
> > > > > prior to attempting them, especially in the area of security. Has
> > > > > someone actually gone through the exercise of examining every
> > > > > directive and determining which ones are relevant?
> > > > >
> > > > > -Ekr
> > > > >
> > > > >
> > > > >          > Either approach requires studying the impact of every
> existing
> > > > >          > configuration directive for each device type to know
> what the
> > > > >          > impact will be on the relevant policy claims. This seems
> > > > >     challenging
> > > > >          > at best.
> > > > >
> > > > >     --
> > > > >     Michael Richardson <[e-mail]
> > > > >     <mailto:[e-mail]>>   . o O ( IPv6 IøT
> consulting )
> > > > >                 Sandelman Software Works Inc, Ottawa and Worldwide
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >     _______________________________________________
> > > > >     saag mailing list -- [e-mail] <mailto:[e-mail]>
> > > > >     To unsubscribe send an email to [e-mail]
> > > > >     <mailto:[e-mail]>
> > > > >
> > > >
> >
> > > --
> > > nasr mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> >
> >
> > --
> > ---
> > [e-mail]
> >
> > --
> > nasr mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
>