Subject: [OPSAWG] draft-ietf-opsawg-sbom-access and BRSKI ?

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 May 2021 01:38:44 +0200

One hought that cam up when reading subject draft:

SBOM is likely something many devices may want to keep confidential.
But SBOM may also be highly beneficial for attestation during bootstrap.

In BRSKI (RFC8995), we have a boostrap TLS connection for which the client device
receives a very strong authentication (from its own manufacturer via a voucher),
that the other end of the connection should be consiered to be the owner of the
device - and hence could be sosidered to be a valid receiver of the SBOM, if anyone is.

On the other hand, BRSKI currently has no way to perform
attestation of the device itself to decide whether or not it should trust it.

Long story short: I think it would be great if this SBOM draft would support
BRSKI in so far as:

-> If device supporting this SBOM standard also supports BRSKI, and
   it wants to support attestation for BRSKI enrollment, then the device
   will offer to  provide it's SBOM to the BRSKI registrar after successfully
   completing authentication of the provisional BRSKI TLS connection.

-> offering to provide it's SBOM could be done by a GET to a new
   well-known URI, something like /.well-known/brski/sbom-offer
   and some well-defined response format providing e.g.: the actual URI
   to send the SBOM to, followed by a POST to that URI

This would allow BRSKI to take SBOM into consideration whether or not to
provide a certificate to the client device in the next BRSKI stps,
or (in more intelligent environments), make the registrar provide a
different certificate than a normal operational one, when the
device can not yet be full trusted, but some additional remote software
upgrades or the like could make that happen.

There is actually very little i see fitting as extensions to BRSKI before
enrolling the client with a cert, but SBOM would pretty much be on the
top of that list. HWBOM would of course be nice too, but most often the
significant aspects of that are deducible from the X520SerialNumber for good vendors.

Cheers
    Toerless

In-Reply-To: <[email-masked]>

On Tue, May 25, 2021 at 03:01:14PM +0200, Eliot Lear wrote:
> Hi,
> 
> For those of you who don???t know, Common Security Advisory Format (CSAF) is
> an evolution on Common Vulnerability Reporting Framework.  Such an object
> could easily be delivered with an SBOM.  It has a slightly different
> characteristic in terms of update frequency.  CSAF changes may happen
> independently of software updates, and generally would*not* be hosted on
> individual devices (at least, I don???t see the use case).
> 
> CSAF files indicate what products and versions are vulnerable (and what are
> not), and what if any remediations are available, not unlike a classic PSIRT
> advisory.
> 
> My proposal is to add into the draft an optional URL that indicates the CSAF
> object for This device, a???la:
> 
> > container sbom {
> > ???
> >    leaf csaf-location {
> >       type inet:uri;
> >       description ???Location of CSAF file???;
> >   }
> 
> I would add some descriptive text similar to the above in as well.
> 
> Does this raise any concerns?
> 
> Eliot

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 May 2021 07:24:45 +0200

Hi Toerless,

I think you may have overcomplicated things.  If the device or 
manufacturer wants to provide the SBOM, the easisest thing would be to 
put a MUD URL into the cert that can be resolved, and then use 
.well-known/sbom, where you authenticate either the trust anchor 
provided in the voucher or subsequent trust anchors provided by EST to 
the pledge.  Absent that authentication you can just return a 400.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 May 2021 10:23:21 -0400

> SBOM is likely something many devices may want to keep confidential.

I think that national security will eventually trump (might be a
pun, not sure), emotional insecurities of manufacturers who made poor choices.

    > In BRSKI (RFC8995), we have a boostrap TLS connection for which the
    > client device receives a very strong authentication (from its own

    > On the other hand, BRSKI currently has no way to perform attestation of
    > the device itself to decide whether or not it should trust it.

Yes.
So, an open work item on BRSKI is to fit remote attestation into the flow.
What is requires is some choices around proof of freshness.
(See
https://www.ietf.org/archive/id/draft-ietf-rats-architecture-12.html#name-appendix-a-time-considerati
)

I think that SBOM fits best as an attestation attribute, and not the other way around.

We also already know how to integrate MUD with BRSKI, and this connects MUD
with SBOM, so really, I don't think we need more.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 May 2021 17:16:24 +0200

> pun, not sure), emotional insecurities of manufacturers who made poor choices.

Can not quite parse this. Rephrase pls. I was just thinking about known exploits for
specific software versions as the reason for not making the SBOM available
to anyone who asks. I ran into that problem i think more than a decade ago
when customers asked to not have software version be included in LLDP
information freely available to anyone on the same LAN. Such as the virus
infested employee PC whereas that virus would hen easily find attackable
network equipment. Not much different when there is a well-known URL that
such attacking systems could probe.

> (See > https://www.ietf.org/archive/id/draft-ietf-rats-architecture-12.html#name-appendix-a-time-considerati > )

I guess the SBOM draft authors should chime in to explain if/how
the SBOM information delivered would indicate if/how fresh the information is.

> I think that SBOM fits best as an attestation attribute, and not the other way around.

If you have a larger attestation framework, sure. But if
a more generic attestation framework might take a lot longer
to complete, it would be nice to not have to stall solutions
for SBOM if they can be had faster.

Likewise, i would think that most uses of SBOM outside of BRSKI
would be for attestation, and i don't think we would want to
stop progressing SBOM information there with the argument that
we first need an attestation framework. Or do we ?

(i have no strong opinions other than just having been through a
 not so pleasent head-of-line blocking exercise for 7 years ;-))

> with SBOM, so really, I don't think we need more.

So tell me, how do you think a registrar would be able to include
SBOM information in its decision whether to, or what certificate
to give to a pledge during the EST enrollment. I don't see a
solution for that without a solution like he one i proposed.
I may of course be missing something.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 May 2021 17:31:41 +0200

On Fri, May 28, 2021 at 07:24:45AM +0200, Eliot Lear wrote:
> Hi Toerless,
> 
> I think you may have overcomplicated things.  If the device or manufacturer
> wants to provide the SBOM, the easisest thing would be to put a MUD URL into
> the cert that can be resolved, and then use .well-known/sbom, where you
> authenticate either the trust anchor provided in the voucher or subsequent
> trust anchors provided by EST to the pledge.  Absent that authentication you
> can just return a 400.

Explain to me how this work flow would allow for the registrar to
decide whether to and/or what certificate to give to the pledge via EST based
on SBOM information. I can only venture to guess your work flow would only
allow to retrieve SBOM information after the pledge has already received a
certificate. The whole point is to not give a pledge a "you're fully trusted"
cert if it can not be fully trusted because of its SBOM.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 May 2021 18:59:53 +0200

On 28.05.21 17:31, Toerless Eckert wrote:
> on SBOM information.

Well, in that case, if the registrar has the iDevID of the pledge, it 
can retrieve the MUD file, which points to an SBOM.  My guess is that 
such an SBOM would have to live off device, because there is no trust 
yet between pledge and registrar.  And so if trust is required to 
retrieve the SBOM, then it has to be between the registrar and the 
manufacturer.

This having been said, I think you may be applying the right policy at 
the wrong time.  It may make more sense to first establish trust, but 
limit access to the device until you have the SBOM.  In fact you want to 
do it that way, because at any time the posture of a device can be found 
to be wanting.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 May 2021 19:49:28 +0200

On Fri, May 28, 2021 at 06:59:53PM +0200, Eliot Lear wrote:
> Well, in that case, if the registrar has the iDevID of the pledge, it can
> retrieve the MUD file, which points to an SBOM.

Except that we of course will also want to support many deployment cases
where there may be an airgap during enrolment. And if the primary interest
of a workflow is SBOM/attestation, then the manufacturer may not want to
engage in the cost of MUD cloud service.

Aka: i like o keep solutions modular so we're not forcing manufacturers to
have to invest into more system components than necessary/beneficial for
their customers use-cases.

>  My guess is that such an
> SBOM would have to live off device, because there is no trust yet between
> pledge and registrar.

Right.

> And so if trust is required to retrieve the SBOM,
> then it has to be between the registrar and the manufacturer.

Which in addition to the above problems also includes the problem that
tracking of firmware load is even more work, especially when there can
be reseller firmware upgrades/customization or the like.

> This having been said, I think you may be applying the right policy at the
> wrong time.  It may make more sense to first establish trust, but limit
> access to the device until you have the SBOM.

That again also requires an additional layer of in-system complexity.
So far, we have designed systems nicely with domain security indicated
by their certificate. Now you need to add a whole new layer of per-device
in-system security differentiation. I have seen how difficult those
solutions become in enterprise 802.1 solutions. Additional VLANs, lots
of radius server complexity of parameters to be pushed, etc. pp.

> that way, because at any time the posture of a device can be found to be
> wanting.

Parsing failed. rephrase pls.

In any case, to me, the local retrievel of SBOM information during BRSKI
enrolment time seems to be very simple, very trustworthy by both sides,
very simple to implement, very much in line with the purpose of BRSKI
and with the least amount of system overhead. Aka: To me it would be
the lowest hanging fruit option to bring in attestation by BOM.

Cheers
    Toerless

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 May 2021 20:04:18 +0200

Toerless,

Ultimately this is an authorization problem.  How you do that is 
entirely up to you.  I have given you a few examples.  I don't see how 
an additional endpoint to retrieve the same object would change that.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 May 2021 20:16:26 +0200

On Fri, May 28, 2021 at 08:04:18PM +0200, Eliot Lear wrote:
> Toerless,
> 
> Ultimately this is an authorization problem.  How you do that is entirely up
> to you.  I have given you a few examples.  I don't see how an additional
> endpoint to retrieve the same object would change that.

I don't think you have described any workflow that would allow to
achive what i claim is highly beneficial workflow: BRSKI decision to decide on whether/what
certificate to assign based on SBOM information without introducing a lot
of additional complexity (cloud service) and likely impossible dynamic
update of such cloud based SBOM information.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Fri, 28 May 2021 20:37:54 +0200

Toerless,

Feel free to come up with whatever work flows you want. However...   I'm 
less fine with is creating a new endpoint to retrieve the exact same 
information.  The magic you want to implement, so far as I can tell, is 
entirely in the authorization model and that is orthogonal to the 
RESTful endpoint.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 28 May 2021 20:53:08 +0200

On Fri, May 28, 2021 at 08:37:54PM +0200, Eliot Lear wrote:
> information.

Agreed.

But: when we want to make attestation information available for BRSKI,
we can not use "retrieval" == "push" URLs, we need to use some form of  "push"
URL because in BRSKI the SBOM device itself is the client, not the server.

So, the proposal actually would NOT introduce a duplicate URL for exactly
the same thing, but like MUD embedding a different "namespace" option.

> The magic you want to implement, so far as I can tell, is
> entirely in the authorization model and that is orthogonal to the RESTful
> endpoint.

Not magic, just policy like i would expect to be the result of pretty much any
SBOM workflow. Yes, that policy result is outside of scope. Like the rest
of the existing SBOM proposal, this would purely be the namespace definitions
to enable the workflow.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 May 2021 18:08:27 -0400

Toerless Eckert <[email-masked]> wrote:
    >> Toerless Eckert <[email-masked]> wrote: > SBOM is likely something many
    >> devices may want to keep confidential.
    >>
    >> I think that national security will eventually trump (might be a pun,
    >> not sure), emotional insecurities of manufacturers who made poor
    >> choices.

    > Can not quite parse this. Rephrase pls. I was just thinking about known
    > exploits for specific software versions as the reason for not making
    > the SBOM available to anyone who asks.

The need for all entities in all sorts of supply chains to know exactly what
possible issues there are.
This will lead to many audits, mandated by national security concerns.
Manufacturers who feel shy about revealing what they used, will find themselves
with multiple month delays at borders.
I also think that we are going towards mandatory disclosure of all breaches.

    > I ran into that problem i think
    > more than a decade ago when customers asked to not have software
    > version be included in LLDP information freely available to anyone on
    > the same LAN. Such as the virus infested employee PC whereas that virus
    > would hen easily find attackable network equipment. Not much different
    > when there is a well-known URL that such attacking systems could probe.

Right, "Think about the children".
So, now IT can't find the vulnerable PC either.
The malware never needed or cared about the LLDP version.
What's the proof?  The presence of virus infected PCs.

    >> We also already know how to integrate MUD with BRSKI, and this
    >> connects MUD with SBOM, so really, I don't think we need more.

    > So tell me, how do you think a registrar would be able to include SBOM
    > information in its decision whether to, or what certificate to give to
    > a pledge during the EST enrollment. I don't see a solution for that
    > without a solution like he one i proposed.  I may of course be missing
    > something.

Because SBOM is just an attribute that is part of remote attestation.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Fri, 28 May 2021 18:12:17 -0400

Eliot Lear <[email-masked]> wrote:
    > limit access to the device until you have the SBOM.  In fact you want
    > to do it that way, because at any time the posture of a device can be
    > found to be wanting.

No, it's the right time.

We specifically designed the voucher flow such that it could contain
attestation artifacts (evidence).   Max was quite articulate about that!

The evidence is communicated through the registrar to the MASA.  This is
identically the background check flow from the RATS architecture.
The MASA is the Verifier.  The Verifier is who needs access to the SBOM, and
conveniently, that's also the manufacturer.

The Registrar is the Relying Party.

What we didn't document is how we do freshness for the evidence.
There are a number of choices.

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 29 May 2021 01:04:19 +0200

> I also think that we are going towards mandatory disclosure of all breaches.

Thanks. Interesting. And agreed.
But i think this is mostly orthogonal to the problem at hand unless the manufactur
could really track software changes performed by users. And i would guess
at least in th IETF there seem to be enough participants trying to minimize
tracing by vendors.

> Right, "Think about the children".

I think it is "think of the children" (https://www.youtube.com/watch?v=RybNI0KB1bg)

> So, now IT can't find the vulnerable PC either.

There are enough other mechanisms. And of course, if all this information was
broadcasted into a trusted domain like ACP, the story would be different.

> What's the proof?  The presence of virus infected PCs.

Well, the more info an attacker has, the less probing it needs to do, and the
less probing it does the less its catched by heuristic, oops, artificially
intelligent, IPS.

> Because SBOM is just an attribute that is part of remote attestation.

Thats fine. I agree that we should look into an optional remote attestation
step after upgrading the TLS connection and before handing out keying materials.
I guess i need to read up more. Rats ?! ;-)

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 29 May 2021 01:06:09 +0200

Hah. But thats an even earlier step than what i was thinking of. Yes,
attestation during voucher setup is an interesting option to. It just
would put the pledge into the "even more under control by the manufacturer"
bucket. Which some users will prefer, and some will not like.

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Sat, 29 May 2021 16:06:29 +0200

So this raises an interesting question, which is probably more 
appropriate for RATS.  What information should be shared with whom and 
how?  The voucher is shipped in the clear without much prompting.  There 
are different views about how sensitive software inventory is.  This is 
why the draft doesn't take a position on the subject, other than to 
allow for the notion that some requests *may* need to be authenticated.

Eliot

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 29 May 2021 18:00:06 +0200

On Sat, May 29, 2021 at 04:06:29PM +0200, Eliot Lear wrote:
> So this raises an interesting question, which is probably more appropriate
> for RATS.  What information should be shared with whom and how?  The voucher
> is shipped in the clear without much prompting.  There are different views
> about how sensitive software inventory is.  This is why the draft doesn't
> take a position on the subject, other than to allow for the notion that some
> requests *may* need to be authenticated.

SBOM or anything else carried in a voucher can of course be encrypted, for example
with the public key of the registrar. 

I can also imagine vouchers or bearer tokens where SBOM would be unencrypted
as a statement from the manufacturer "this is the software the device had
when it left the manufacturing floor". Implying "if you see any other software
on it, someone else had hands on it, ... warranty void... ? " ;-)

Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sat, 29 May 2021 18:00:44 -0400

Toerless Eckert <[email-masked]> wrote:
    > would put the pledge into the "even more under control by the
    > manufacturer" bucket. Which some users will prefer, and some will not
    > like.

The registrar could take the Evidence and pass it on to any third party
for verification, provided that third party had enough information to make a
judgement.
The interface from Endorser to Verifier is intentionally not standards in the
current RATS architecture, but many want to do this.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 29 May 2021 18:20:41 -0400

Eliot Lear <[email-masked]> wrote:
    > how?  The voucher is shipped in the clear without much prompting. 

How so in the clear?
It's DNS-ID or pinned TLS from Registrar to MASA (which is across the Internet).
Getting a voucher requires a voucher-request, signed by the device.
That could be obtained by a malicious registrar, true, but that requires
on-link-ish access to the device.

    > There are different views about how sensitive software inventory is. 
    > This is why the draft doesn't take a position on the subject, other
    > than to allow for the notion that some requests *may* need to be
    > authenticated.

I agree that this is the right approach for the document to take.
I'm expressing the view that it's fundamentally security through obscurity.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 31 May 2021 09:04:47 +0200

> on-link-ish access to the device.

Sorry- let me restate: it's not that the voucher or request is not 
encrypted, but rather that the voucher-request is received by a party 
that may not be authorized to onboard that client.  The client doesn't 
know that until it sees the response from the MASA.  Therefore, whatever 
information it reveals should be minimized at this point in the 
transaction.  Once the device has installed a trust anchor, then it has 
at least some reason to trust the other party with what its designers 
may view as more sensitive information.

> I'm expressing the view that it's fundamentally security through obscurity.

Fair enough, but I posit a world in which the attacker has at its 
disposal a bag of tricks that is indexed by RATS evidence, and a limited 
window of time to apply those tricks.  In that sense, a little bit of 
security through obscurity might prevent some break-ins.  Not that it's 
an excuse to not fix those vulnerabilities, of course, but simply a bit 
of defense in depth.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 May 2021 11:16:38 -0400

Eliot Lear <[email-masked]> wrote:
    >> Eliot Lear <[email-masked]> wrote: > So this raises an interesting
    >> question, which is probably more > appropriate for RATS.  What
    >> information should be shared with whom and > how?  The voucher is
    >> shipped in the clear without much prompting.
    >>
    >> How so in the clear?  It's DNS-ID or pinned TLS from Registrar to MASA
    >> (which is across the Internet).  Getting a voucher requires a
    >> voucher-request, signed by the device.  That could be obtained by a
    >> malicious registrar, true, but that requires on-link-ish access to the
    >> device.

    > know that until it sees the response from the MASA.  Therefore,
    > whatever information it reveals should be minimized at this point in
    > the transaction.  Once the device has installed a trust anchor, then it
    > has at least some reason to trust the other party with what its
    > designers may view as more sensitive information.

Yes, that's true.  The unknown Registrar could see the Evidence.
The Evidence clearly needs to be encrypted from Attester(pledge) to
Verifier(MASA).  This could be done with ECIES, I think.

If there was a need for an audit of the Evidence at the Registrar, then I
think that the MASA could reveal the cipher key to the Registrar after it has
determined that it's the right authorized party.

    >> > than to allow for the notion that some requests *may* need to be >
    >> authenticated.
    >>
    >> I agree that this is the right approach for the document to take.  I'm
    >> expressing the view that it's fundamentally security through
    >> obscurity.

    > disposal a bag of tricks that is indexed by RATS evidence, and a
    > limited window of time to apply those tricks.  In that sense, a little
    > bit of security through obscurity might prevent some break-ins.  Not
    > that it's an excuse to not fix those vulnerabilities, of course, but
    > simply a bit of defense in depth.

That reads like a poorly researched Hollywood plot to me :-)
We weren't discussing RATS Evidence, we we were discussing the contents of an SBOM.
There is a difference, I think.
I don't expect the attestation to be done in the clear.

I do think that the list of components of a
not-thought-to-be-vulnerable-at-this-moment device to be visible.
There are many purposes that the SBOM serves, including validation of
licenses, vulnerability to patent-litigation [remember that some countries
respect moral rights], ...