Firstly, no, I have no pixie dust, and I agree that we need to preserve security even after a disaster. But on the other hand, if autonomic networks matter at all, they will matter then, and we can't safely assume that network operators are available even to switch on some sort of emergency MASA server. Also, how would a temporary tactical network used by emergency responders configure itself if no vendor MASA server is accessible?
I'm not suggesting that the basic BRSKI mechanisms need to solve this, but I think we need to have it on the list of issues to be tackled before we can consider Anima complete. Brian On 03/11/2016 05:15, Eliot Lear wrote: > 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 <brian.e.carpen...@gmail.com> >>> 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 <brian.e.carpen...@gmail.com> >>> Organization: University of Auckland >>> To: home...@ietf.org >>> >>> 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 >>> Anima@ietf.org >>> https://www.ietf.org/mailman/listinfo/anima >> _______________________________________________ >> Anima mailing list >> Anima@ietf.org >> https://www.ietf.org/mailman/listinfo/anima > > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
