Do you think there is value in creating a system like this?
yes. though, given issues of errors and deliberate falsifications, i am
not entirely comfortable with the whois/bgp combo being considered
formally authoritative. but we have to do something.
Are there any glaring holes that I missed
yes. the operator should be able to hold the private key to their
certificate(s) or the meaning of 'private key' and the security
structure of the [ripe part of the] rpki is a broken.
randy
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
Do you think there is value in creating a system like this?
yes. though, given issues of errors and deliberate falsifications, i am
not entirely comfortable with the whois/bgp combo being considered
formally authoritative. but we have to do something.
But blindly considering whois/BGP authoritative is not what I am
proposing. I want to confront the network operator with what is registered
in the IRR and what is seen in BGP, and let the human element make
decisions and corrections, improving data quality in the process.
Are there any glaring holes that I missed
yes. the operator should be able to hold the private key to their
certificate(s) or the meaning of 'private key' and the security
structure of the [ripe part of the] rpki is a broken.randy
In the hosted implementation the RIPE NCC currently has, only a registered
contact for an LIR with whom we have a business relationship has access to
the secured LIR Portal in which the Certification system is embedded.
The reason to offer a hosted system initially, is to take away the burden
from an LIR of having to run their own Certificate Authority. We offer a
service that makes the entry barrier for Certification as low as possible.
Properly running your own CA, with all the crypto aspects, is no small
feat for a lot of LIRs (technically, but perhaps more psychologically).
You may argue that it's easy and cheap to do yourself, but just look at
adoption rates and levels of IPv6 and DNSSEC *at an LIR level* to see what
reality is like.
After the production launch on 1 January 2011, the next step we will take
is to implement the up/down protocol, allowing people to run their own
Certificate Authority if they choose to do so. We plan to roll this out in
the first half of 2011. We'll go one step further by having our software
certified by an external independent company, and releasing it as open
source to the Community, so they can be sure they adopt a robust system if
they choose our package.
So in the end our implementation is not 'broken' as you say, it is in he
middle of a planned, phased approach. Not everything is possible yet and
that is a deliberate decision.
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
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.
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.
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.
Owen
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.
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
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.
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.
calling it isc's is a bit incorrect, but no difference.
it is an open source, bsd license, i.e. free as in free, implementation
of all of the rpki protocols, provisioning, up/down, publication, relying
party, proto-gui to manage your resources, ... the full monty. it has
been operational in a testbed with isp players from asia, the states,
europe, ... for some time.
randy
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
alex, i am not gonna argue with you.
96% of your users will be happy for you to do everything for them,
despite the fact that the wrong holder has the keys (and, as john says,
the liability).
but 96% of your address space, i.e. the large holders, will want to hold
their own keys and talk up/down to you and deal with publication points.
kinda like the irr.
so write back when you have done the full job.
randy