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
