It would also be good if the correct acronym could be used in emails as it makes it easier to track down what people are referring to.
Jonathan > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com] > Sent: 08 November 2016 05:09 > To: jonat...@hansfords.net; Toerless Eckert <t...@cs.fau.de>; Max Pritikin > (pritikin) <priti...@cisco.com> > Cc: Toerless Eckert <tte+i...@cs.fau.de>; Anima WG <anima@ietf.org>; Eliot > Lear <l...@cisco.com> > Subject: Re: [Anima] Desaster recover... > > Jonathan, > > BRSKI (I not Y) is defined in draft-ietf-anima-bootstrapping-keyinfra-04 > "Bootstrapping Remote Secure Key Infrastructures (BRSKI)". If there are > incomplete or incorrect references in other documents, of course they need > to be completed or corrected. > > Regards > Brian > > On 07/11/2016 21:42, jonat...@hansfords.net wrote: > > Hi, > > > > Following ANIMA in fits and starts and saw the reference to BRSKY. Tried to > follow up on what it was all about and found the reference to it in > draft-ietf- > anima-autonomic-control-plane-04. Section 5.2.4 is entitled “Discovery and > BRSKY” but appears to make no reference to it and, despite three uses of the > term BRSKY in the document, I find the protocol is actually the Bootstrapping > Remote Secure Key Infrastructures (BRSKI). > > > > Is the intention to rename to BRSKY or is it just that people have got into > the habit of calling it that? > > > > Jonathan > > > > =O) > > > > From: Toerless Eckert > > Sent: 07 November 2016 06:01 > > To: Max Pritikin (pritikin) > > Cc: Toerless Eckert; Eliot Lear; Anima WG > > Subject: Re: [Anima] Desaster recover... (was: Re: [homenet] write up > > oftime without clocks) > > > > On Fri, Nov 04, 2016 at 09:23:15PM +0000, Max Pritikin (pritikin) wrote: > >> There is a lot here. Attempting to comment on it all. > >> > >> It would really help if we could relate these discussions to specific text > sections that could be improved. Otherwise we???re just blowing into the > wind. (Where it seems obvious I???ve added such notes). > > > > Sure, but lets high level agree what type of content is useful and > > where it would fit. > > > >>> - Large organizations will have spares. With ANIMA, those spares > >>> should be stored pre-enrolled to avoid MASA/registrar dependency > >>> during > >>> recovery/replacements: Receive gear on any site (no central > >>> provisioning site needed), but unpack, plug in for short period, then > stash away. > >> > >> Devices that have been brought up and are in the network post bootstrap > are not relevant to the BRSKI document. > > > > To me the most important goal should be to provide candidate users > > with deployment guidance. This should fit ANIMA goals given how its an > OPS group. > > > > Lets say we have two options: > > > > a) keep spares unenrolled, enrol during desaster recovery with satellite > link > > b) enrol spare devices when they are stocked, deploy during desaster. > > > > lets assume we agree both are relevant deployment options that users > > should understand, compare pro/cons for their case and choose. If you > > think we can not mention both in the BRSKY spec, then i think it would > > be better to have a separate document where both could be discussed. > > > >>> This is imo an easy requirement also useful without desaster > >>> requirements > >>> - aka: enrolled spares would likely also have better theft/abuse > >>> protection than non-enrolled. And yes, you will have to power up > >>> these spares once a year. Which IMHO is ok. And of course certs > >>> should therefore be somewhat longer than 1 year). > >> > >> This could be captured as a discussion: what does a device do when its > credentials are out of date? Does it fall back on full bootstrapping? If so > this > becomes a potential attack vector wherein the attacker can convince the > device it is out of date and then force it to restart bootstrapping. That > would > be bad. > > > > Haha... ;-) i just wanted to show what IMHO are the most simple > > deployment options to deal with desaster recover. Now you're the one > > who is opening another round of discussions trying to figure out the > > best security compromise for those deployment processes. Which is great. > > Just don't blame me that there are more and more interesting details > > to capture somewhere. > > > >> So, should there be an injection point into the bootstrapping state > machine that says something like: > >> > >> If a device fails to join the ANI after [some number] of attempts it > attempts to repeat bootstrapping using its original SUDI credentials. > > > > I'd prepare a flag 'operational' set by SDN controller or ASA after > > the device is "provisioned" (config/intent applied). > > > >> During this bootstrapping attempt it MUST only bootstrap on a Registrar > that provides both a valid voucher and an identity recognizably within the > same PKI hierarchy the device was in previously. This is detected by the > device by either (a) the domainCAcert is an exact match for the current > domain trust anchor known to the device or (b) the EST /cacerts response > includes a chain that terminates in the current domain trust anchor known to > the device. > >> > >> This extends the lifetime of such a stored device beyond its own > certificate (maybe 1 year) *and* beyond the current CA certificate (maybe a > 2year cert) an all the way into the next CA certificate (another 2 years). > That > is a pretty solid lifetime (up to 4 years) for recovery. > > > > Interesting thought. > > > > a) Would like to understand how this compares to just making certs > > longer-lived, eg: 3 years, but doing normal renewal after 30% time. > > > > b) Seem like there's quite a bit of analysis to be done of how > > different parameter/options will work together: > > - device with/without reliable RTC > > - what would be necessary/beneficial with nonce-less vouchers ? > > how about nonceless vouchers with sequence number... -> remember > > ownership voucher and allow for it to be replaced only with one that > > hass a higher serial number. > > > >>> - If sparing would be cross-locations (eg: spares sent from some > >>> site to other sites during recovery), then its important that the > >>> ANIMA certs do not include any location specific attributes that > >>> would prohibit thart movement. So far BRSKY does not include any > >>> such attributes, but in discussions, three has been interest to > >>> lock into the cert some device role specific attributes, and for a > >>> spare piecce of equipment, those attributes may not be > predetermined. > >>> > >>> Aka: Desaster sparing means domain certs need to be simple, devices > >>> reuseable across domain. > >> > >> I agree that certs should include the absolute minimum information about > the device. The actual ID is sufficient in my book. Attribute Certs or backend > database lookups or short term tokens obtained by the device in place are all > methods of distributing additional information. > > > > Desaster recovery seems to be one good motivation to not put more than > > the minimum into the certs. I was a fan of putting more into certs in > > the past... > > > >>> - If spares are done by a shared facility: vendor, FEMO (for fed > >>> networks) or the like, one could think of that entity offering > >>> (emergency) enrolment service. > >>> > >>> Such an entity would have desaster proof MASA connectivity on site, > >>> and the customers would provide it with (emergency) registrar certs. > >> > >> Ok. So like a Cisco NERV truck that provides connectivity sufficient to > rebuild a network in place. > >> > >> Issuing a new Registrar ID would mean being able to bring up the PKI > infrastructure during the recovery process. But this is exactly the time > period > when having as much of the critical keying infrastructure offline and secured > could be beneficial for longterm security. One could argue that extra > attempts should be made to ensure the PKI is offline. > > > > My thought was > > a) the desaster recovery registrar-IDs are preprovisioned _before_ > desaster > > (contract between domain and desaster/spare recovery entity). > > b) The facility to which they are allocated is shared across multiple > > domains. > > c) the facility is not "desaster on-site" -> the spares will not be on-site, > > but will be stored at some central site. Enrollment would happen at > > that central site, then they'd be shipped onto-desaster-site. > > > >>> (emergency) meaning that the entity is only permitted to enrol > >>> during emergencies, and the customer could be able to verify the > >>> emergency entities behavior by pulling from the MASA an audit log. > >> > >> Section 5.6 doesn???t include the Registrar identity only the domainID in > the log. Do folks think the Registrar ID should be included as well? > > > > Oh, right. i confused domain-id with registrar-ID. > > > > I definitely think registrar-ID would be necessary to log so that > > audit-logs become more useful to backtrack what happened. > > > >> If this was done then does it matter if the Registrar cert has role > information in it? As per the above what would happen if all devices in the > ANI could act as a registrar? There would be a higher chance that one of > them would mess up and actually perform registrar activities incorrectly ??? > but it would be logged so the admin could watch for that. > > > > > > I don't think we need many/all devices to be registrars. I don't think > > we've got a working security model to do this anyhow - eg: > > authenticating all those devices against the CA. I hope we do not need > > to discuss other roles beside "registrar" in this context. > > > >> Thoughts? I???m worried but see the conversation going that way. > > > >>> If the customer would give the emergeny registrar credentials > >>> cert/private/public-key to the emergeny entities, then the customer > >>> itself also has the cert/private-key and could ask the MASA. > >>> This option would work with current BRSKY text. I am just not sure > >>> about security BCP (having two copies of a public key pair???). > >> > >> Sorry - I can???t write text around copying a private key. If we???re going > that route lets dump all the PKI stuff and just use bearer tokens and be up > front about the security we???re providing. See above for different ideas. > > > > Yepp. There should be easier options to achieve the same goal. > > > > Eg: I create a registrar as a VM, and run it onprem of the desaster > > recovery provider so that provider can enroll devices for my domain in > > case there is a desaster in my domain. > > > >>> - If the shared spare storage facility is Best Buy, and the Jones > >>> family wants to replace some electric storm victims @home while > >>> their ISP takes its days (my ISP C*...*T took almost 48 hours in one > >>> case), then the gear should probably come with a nonceless voucher > >>> printed on on a scratcher piece of paper inside the box. > >> > >> Even a nonceless voucher includes the domainCAcert so this idea > doesn???t fly with the current text. What you???re looking for is some form > of ???bearer voucher??? that contains a symmetric key. > > > > Probably. Yes. I guess we have not discussed how to apply BRSKY > > enrollment for home users. It's outside of scope for ANIMA anyhow, but > > would be interesting. Some of those home thoughts likely equally apply > > to low-end IoT devices. > > > >> Anybody who can scan it off the box can deploy the device. > > > > Thats why i said "scratcher", eg: some one-time-unveil where you can > > easily check that its untampered when you buy the device. > > > >> I???d normally rail against this but am actually pleased to see it fit so > >> well > into the model. A bearer voucher sorta sucks but creating one didn???t > change any of our messaging flow or anything. Interesting positive that??? > > > >> I???m thinking that it is time for a section 3.7 ???Voucher types??? that > digs into what we???re talking about for these different voucher types. > Currently the text is scattered in the other sections. > > > > We could also start discussing those aspects in the submission from > > Kent et. al. about vouchers and move into BRSKY when we see it fit. > > > > Cheers > > Toerless > > > >> - max > >> > >>> Beyond these BRSKY considerations, the next cool ANIMA piece to > >>> consider for these use-cases is of course the ASA driven > >>> "re-configuration" of the spare device, aka: In larger outages, you > >>> should not except the whole network provisioning backend to be up > >>> and running. And its IMHO illusionary to expect devices to ONLY be > >>> driven from intent for many years (in complex networks... in a clean > >>> homenet they are driven by intent today..). > >>> > >>> Aka: for pre-intent-only desaster proof networks, we'd need: > >>> - ASA to cache neighbors configs. > >>> - reapply neighbor stored config when replacement gear is inserted. > >>> - IMHO: An anima definition for a "device-role-id" which is not > >>> the ACP IPv6 address (which will change upon gear replacement > >>> without enrolment support). > >>> > >>> Cheers > >>> toerless > >> > > > > _______________________________________________ > > 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
