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

Hi,

as one of the main developers of the RIPE NCC implementation I would
like to give some answers to the questions raised by Owen.

On 10/4/10 11:59 AM, Owen DeLong wrote:
>>
>>> I'll go a step further and say that the resource holder should be
>>> the ONLY holder of the private key for their resources.
>>>
>>> Owen
>>
>> If you're saying that ISPs can only participate in an RPKI scheme if they
>> run their own Certificate Authority, then I think that would practically
>> ruin the chances of Certification actually ever taking off on a large
>> scale.
>>
>> -Alex
> 
> 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.

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.

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.

> 
> 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.

> 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.

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


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.

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

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.

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.

Randy Bush who is cc-ed may be able to provide some more insight in the
features offered by the ISC rpkid. I don't know whether the features
mentioned by Alex in his first message will be supported by this system.


Regards


Tim Bruijnzeels
RIPE NCC


> Owen
>