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, [email protected] 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 > [email protected] > https://www.ietf.org/mailman/listinfo/anima > > > > > _______________________________________________ > Anima mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/anima > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
