[ncc-services-wg] RPKI Resource Certification: building features

Mon Oct 4 12:03:26 UTC 2010

>> 
>> No... I'm saying that if ISPs aren't the only entities that hold their
>> private keys, then they aren't the only entities that can sign their
>> resources.
> 
> The hosted system that we created uses Hardware Signing Modules (HSM)
> for generating keys and signing operations. By design it is impossible
> to retrieve the private keys. Any process or feature that would involve
> the transferral of keys cannot be implemented.
> 
In other words, not only do you hold the resource holders private key, but,
they do not. This means that the ability to sign their resources is 100% under
your control and 0% under their control except to the extent that you allow
it.

While I'm not accusing RIPE of nefarious conduct and do not believe that
there is any malicious intent in the system, I do believe that it is a security
model that any rational provider would likely consider untenable.

The fact that you cannot retrieve the key is of little relevance, since you
have full use of the key without retrieving it.

> Access to the *use* of the keys is a different thing though. This is
> controlled by the software. Although we cannot extract the keys, we can
> instruct the HSM to create a new key, or use an existing key to sign
> something.
> 
Exactly...

> Our hosted software controls all (activated) hosted member certificate
> authorities. The process has potential access to the *use* of *all* keys
> in the system. However, other security layers are implemented to ensure
> that for a given LIR only those users that have the 'certification'
> group enabled are *authorised* to use the hosted system -- and thereby
> the applicable keys.
> 
But by the very nature, the administrators of the system have the ability
to make themselves members of the certification group.

While I'm not saying that I think RIPE would do such a thing, the reality
is that using this hosted solution is placing a tremendous amount of
trust in the system and the administrators of the system. I have no
problem with LIRs that choose to do this, so long as they are making
an informed decision and understand the risks.

I think the risks have been substantially down-played.

>> 
>> If you choose to delegate the CA role for signing your resources
>> to someone else, then, obviously, you have to give them a valid
>> private key with which to sign those resources.
>> 
> 
> 
> Given this setup a member can authorise any person to use the system by
> creating an LIR Portal account for them and enabling the certification
> group. Only the LIR's admin user can do this.
> 
Really? There's no way for any member of RIPE staff to make corrections
to an LIR's admin account such that it would be possible to bypass this?
I tend to doubt that any sustainable system could be built in such a manner.

Again, I am not accusing RIPE of doing so, but, pointing out that for such
a hosted solution to remain functional over time, there must be certain
compromises in the trust model. These compromises should at least
give one pause and be carefully considered prior to handing over that
level of trust.

>> However, in doing that, you've created a situation where your 
>> signature is now much easier to forge. Kind of like automatic
>> signing machines for checks. Benefit: The accounting department
>> can sign thousands of checks and the CFO doesn't have to.
>> Draw-back... The accounting department can sign thousands of
>> checks without the CFO knowing they did so.
>> 
> 
> The current system has an audit history page that shows all the commands
> executed by users. It includes details like the name of the user, the
> time of the change and further details: e.g. in case of the modification
> of a ROA specification the complete new specification is visible in the
> history.
> 
So at least if someone does something horrible, assuming the system
integrity is not compromised in the process, we can tell what happened
and either who did it, or, at least who they chose to impersonate. That's
good, but, by itself it is not enough.

> There is currently no additional notification mechanism implemented but
> that would be fairly trivial to add if there is a demand.
> 
That would be a good additional safety feature.

> 
> Non-hosted:
> =====
> 
> Of course we put a lot of effort into maintaining security and quality
> of the implementation we built. But we can well imagine that for some
> people it is a matter of principle that they want full local access to
> their own private keys and important configuration objects such as ROAs
> -- and don't want to be hosted on a shared system outside of their
> control. Other members may not mind so much about this and choose to
> trust and use the hosted services.
> 
Exactly my point... Such a choice should be an informed decision and if
it is not a matter of choice made by the organization holding the resource
(as is currently the case), then, there are issues.

> There is standard that is close to completion in the SIDR WG in the IETF
> that defines a protocol by which a parent and child Certificate
> Authority can communicate.
> 
> http://tools.ietf.org/html/draft-ietf-sidr-rescerts-provisioning-06
> 
Which is a major step forward in this area.

> In our case the RIPE NCC system could function as the parent CA for a
> non-hosted LIR child CA. The LIR can then deploy anything they see fit
> themselves. They would have full access to their own private keys and
> everything else in their system and can delegate as they see fit. And
> add new features of course.
> 
Another alternative in the meantime would be for the resource holder
to maintain their private key and have transactions accomplished through
a CSR process, but, obviously, this comes with a different set of tradeoffs,
not the least of which is a certain amount of manual and mechanical
complexity.

> But..
> 1) We have not implemented support for this yet. We plan to go live with
> the fully hosted version first and extend it with support for non-hosted
> systems around Q2/Q3 2011.
> 
> 2) It can take considerable effort for LIRs to set up their own
> non-hosted solution from scratch. We know that ISC is developing an open
> source solution (rpkid) that may be useful for LIRs that want to run
> their own instance. From our side we will make sure that we test
> interoperation with this system when we implement this protocol in our
> system.
> 
I think that's a good plan. However, Randy's criticisms of the hosted
solution are not without merit. While I am glad to see that the RIPE
hosted solution is not such a scheme, my comments were based on
the fact that other schemes I have seen for other certificate systems
involved the user holding their private key after it was given to them
by the hosted system. Such a system would obviously the worst of
all worlds from a security standpoint.

Owen