[saag] Re: [nasr] Re: Re: Re: Re: NASR BOF Follo w-Up
"Liuchunchi\(Peter\)" <[email protected]>
| Newsgroups | gmane.ietf.saag |
|---|---|
| Message-ID | <[email protected]> |
> 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...) 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 <[email protected]> > Sent: Friday, April 11, 2025 8:11 AM > To: Eric Rescorla <[email protected]> > Cc: Henk Birkholz <[email protected]>; Michael Richardson > <[email protected]>; [email protected]; IETF SAAG <[email protected]> > 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 > > <[email protected]> > > 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 > > > > <[email protected] <mailto:mcr%[email protected]>> wrote: > > > > > > > > > > > > Eric Rescorla <[email protected] <mailto:[email protected]>> 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 <[email protected] > > > > <mailto:mcr%[email protected]>> . o O ( IPv6 IøT consulting ) > > > > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > saag mailing list -- [email protected] <mailto:[email protected]> > > > > To unsubscribe send an email to [email protected] > > > > <mailto:[email protected]> > > > > > > > > > > -- > > nasr mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > -- > --- > [email protected] > > -- > nasr mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ saag mailing list -- [email protected] To unsubscribe send an email to [email protected]