My position is that during a large scale disaster it would be foolish of us to
think that security is somehow less important.
BRSKI supports nonceless tokens that can be distributed in advance. These
include the serial number of the device and the domain CA cert so it IS NOT a
"master key".
A “master key” is too similar to a “back door” for me to support it.
BRSKI client may support physical presence (buttons etc) that put them in
‘trust on first use’ mode.
BRSKI addresses ‘time without clocks’ through the use of nonces and section
3.1.5.
I could be persuaded toward a more generic tofu model only if devices include
an integrated hardware assisted endpoint assessment (think TPM style
attestation w/ runtime measurements). That technology isn’t really available
yet.
The approaches provided here work with some prior planning but are not magical.
Do you have pixie dust to suggest?
- max
> On Nov 1, 2016, at 8:53 PM, Brian E Carpenter <[email protected]>
> wrote:
>
> Something over on homenet prompted me to send the following. I do have the
> same concern for BRSKI - what's the disaster recovery mechanism when all
> vendor MASAs are unreachable but we must restart the network anyway?
>
> Brian
>
> -------- Forwarded Message --------
> Subject: Re: [homenet] write up of time without clocks
> Date: Wed, 2 Nov 2016 08:38:04 +1300
> From: Brian E Carpenter <[email protected]>
> Organization: University of Auckland
> To: [email protected]
>
> On 02/11/2016 03:52, Philip Homburg wrote:
> ...
>> Which brings me to the following: given that all code has security issues,
>> maybe devices should check for updates and just shutdown if they can't
>> verify that they are running the latest firmware?
>
> That sounds absolutely dreadful for disaster recovery scenarios where
> the Internet is badly broken (after a hurricane, earthquake, etc.)
> and people need to restart essential systems (or they need to restart
> themselves).
>
>> So the device should have the vendor's long term TLS certicate. With possibly
>> an option for the user to disable this kind of security if the device is
>> not actually connected to the internet.
>
> No, during disaster recovery the last thing you need is for ordinary people
> to be faced with strange security alerts that they've never seen before.
> (It's rather like advising people to go into the BIOS to change an option
> while the fire alarm is ringing.)
>
> Things need to just work during disaster recovery.
>
> Brian
>
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
