...

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

On 4 Oct 2010, at 23:18, Randy Bush wrote:

...

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.

this is a significant slip from the 1q11 we were told in prague. care to explain.

Let me run you through the roadmap and the motivation for our choices at RIPE61. In short, everything we do is about providing *value* for our membership and the community. This means that with the resources we have, we have to make a choice between (1) offering a solution with every feature under the sun, but contains little value and usability or (2) we choose to do a phased approach where the entry barrier into the system is low, hassle is taken away from the operator, value and user-friendlyness is high while still being standards compliant and keeping the operator in the driver's seat. Soon we'll get to the full package where all options, like running your own CA, are available. It perhaps just isn't done in the order that a purist would like to see. Let me illustrate with two examples: I've delivered full day training courses on Routing Registry and DNSSEC. With the RR course, by the time I was done explaining how to use the IRRToolset to aid in making routing decisions based on the IRR, people had given up and decided that doing it manually was easier. Like you said at RIPE60: "people are voting with their feet." In the DNSSEC training, by the time I was done explaining how to do a manual key roll-over, most LIRs decided 'this is not for me, the cure is worse than the disease'. This is why I want to get back to my original point, Randy. You agreed in your first reply to me that something has to be done to create an easy way to get started with the system. We can provide a full, standards-compliant solution with up/down and every other feature, but how is that going to get all ~350,000 prefixes and ~35,000 ASs into the system with ROAs? Manually? I proposed an IRR+BGP import system as a value-added tool to help a network operator get started making ROAs. That's a pretty good starting point. Where do you suggest we go from here? Of course I appreciate everyone else's response to this thread as well! :) Cheers, -Alex