> If DHCP is used for bootstrapping, it should provide enough information
> to fulfill the expectations required in this draft.
Imagine your company ships you a SIP phone for your work-from-home office.
It gets shipped directly from a warehouse, and never visits HQ... because
pandemic or just logistics.
So the DHCP server at your *home* has no ability to provision the right
things... it perhaps *could*, but you have no idea how to actually configure
that.
If this use case is not clear from the introduction, can you say so?
Hmmm... I think this comment was in answer to a specific question from
the review request. The question was whether the local DHCP server would
have enough information to allow the bootstrapping to work. My response
was it would--the device really only needs a local IP address and the
address of a recursive server, which should be enough to make the system
work.
> Minor Issues:
> The Pledge does not know who its owner will be when
> manufactured. Instead, in BRSKI it is assumed that the network to which
> the Pledge connects belongs to the owner of the Pledge and therefore
> network-supported discovery mechanisms can resolve generic, non-owner
> specific names to the owners Registrar.
> Is this a new attack surface? Does this need to be mentioned in the
> security considerations section?
well, if it's a strongly coupled supply chain, where the cloud-registrar know
which customer has bought which device, then no voucher would be issued to an
invalid registrar.
In half-strong coupled supply chain, it might not be known which device which
to which customer, but as long as it went to *a* valid customer, it would be
okay. Generally, brski-cloud only works for strongly coupled supply chains;
a reason for multiple 307 redirects is because the manufacturer might only
know which VAR the device was sent to, while the chain of VARs would know
where they shipped the device.
If someone purchases a similar unit and uses information from a valid
device, they cannot register the device? I'm assuming there is some list
of serial numbers someplace for accepted devices? Even if so, is it
possible for an attacker to discover all the necessary elements to
register a rogue device?
I don't know that there is a defense for this, I was just thinking about
how I would attack this if I wanted to, and if there is some new attack
surface here if readers should be aware of it.
> == ... it can return a voucher that pins the actual Owner Registrar.
> I'm not certain about the use of "pins" here (?) ... maybe "describes"
> or "redirects to" or something similar? "Pins" doesn't seem to be used
> in a lot of other places in the document.
well, it's widely used in PKIs to speak about how a certificate or public key
is kept the same. It's not in RFC4949 though, which I find weird.
Okay ... just wanted to make certain readers should/would be familiar
with this term.
:-) /r
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
