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

[刘鹏辉 <[e-mail]>]

Hi all,




As I mentioned before, as a trusted node, network devices must first pass some form of third-party authoritative trusted authentication (or operator customized authentication), and at the same time run pre built authenticated trusted components on the device. These trusted components have undergone strict testing and cannot run other non authenticated software on the network. By obtaining these authentication information (as evidence) to prove whether the network device is a trusted node, it is selected by the arranger when providing business services. These authentication information as evidence, such as certificates, operational status, configuration information, etc., should be available for customers to query. The orchestration and network equipment here are owned by the operator. The POT containing evidence is retained along with the transmitted business data for verification in case of legal issues.

NASR is written into the SLA as a service to clarify the responsibilities of both parties.

If these cannot be met, customers may as well choose physical dedicated lines to transmit data without the need for NASR.




BR,

Penghui liu














At 2025-04-11 08:11:12, "Toerless Eckert" <[e-mail]> wrote:
>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]