I myself would be concerned over a downgrade attack. Recall that this only impacts BRSKI in as much as the device needs to be provisioned *during* the disaster. While there may yet be some classes of devices that require this, I'm going to hazard (cough) a guess that most first responders will have trained with the equipment they have *prior* to the disaster. For the remaining equipment, if it is part of critical infrastructure and requires a network, then the network needs to be up. The only question then is whether the MASA server needs to be up. It is perfectly possible to design a system where that is the case.
Eliot On 11/2/16 5:05 PM, Max Pritikin (pritikin) wrote: > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
