[ca-tf] CA-TF meeting minutes, 20 March 2008
Daniel Karrenberg daniel.karrenberg at ripe.net
Fri Mar 28 13:47:11 CET 2008
Hi all,
Please find attached a draft of the minutes for the Certification
Task Force meeting held last week in Amsterdam.
Please note that I've prepended some of the key points with "***".
Regards,
Chris Buckridge
Technical Writer, RIPE NCC
-------------------------------------------
Certification Task Force Meeting Minutes, 20 March 2008
Location: Sheraton Hotel, Amsterdam
ATTENDEES: Paul Rendek, Axel Pawlik, Andrew De La Haye, Ronald van
der Pol, Peter Tavenier, Tim Bruijnzels, Serge Beaumont, Filiz
Yilmas, Nigel Titley, Andrei Robachevsky, Vasily Dolmatov, Ruediger
Volk, Chris Buckridge (scribe)
Andrew de la Haye outlined the agenda for the day's meeting, and
passed on Gert Doering's apologies.
INTRODUCTION
Andrew discussed the background and drivers of the current status of
certification in the RIPE community. He also noted the various areas
already identified by the Task Force as key to the project: Policy,
Services, Technical, RIR-wide and Applications. He noted that recent
discussions with RIR colleagues showed that the work being done by
the RIPE CA-TF is valuable globally.
He then outlined the programme for today's meeting, including
demonstrations of the progress made by the RIPE NCC and Xebia (a
software consulting firm employed by the RIPE NCC to assist in the
development of a certification system).
Daniel asked whether there were any other items the TF would like to
have on the agenda. There were none.
Serge Beaumont, a consultant from Xebia, outlined his role in the
technical development process, and laid out the basic processes of
certification. He also discussed the fundamental bases of the project:
- Certificates are representations of the true situation
- Certificates are not pre-requisites for transfers or proof of
holdership
- The only thing that certificates can prove is that the RIPE NCC
has made that statement!
Certificates can enhance the existing RIPE Database and its role.
Filiz Yilmaz gave an introduction to the policy issues raised by the
certification proposal. This includes the proposed phased
introduction of certification, first to PA address holders (RIPE NCC
members), then PI and ASN holders, and finally ERX holders. Except
for PA holders, all of these will be affected by policy proposal
2007-01, which would provide clarity on who are the holders of PI or
ERX space.
The initial proposal is for PA holders, or RIPE NCC members, and will
entail a one-time operation to issue certificates to all existing
LIRs. Filiz clarified that LIRs will receive certificates whether
they want it or not, however the RIPE NCC will be signing the
certificates.
There was discussion about how secure this arrangement would be, but
Serge noted that as long as there is a secure channel between the
RIPE NCC and the member, then the member can ask NCC to hold the
private key securely for them; otherwise the member can hold the key
themselves – it depends how much key management the member wants.
Daniel Karrenberg expressed some reservations about creating and
keeping private keys without the explicit consent of the members
concerned, and noted that this would create a considerable
responsibility and associated liability for the RIPE NCC should these
keys be compromised or just appear to have been compromised.
Ruediger Volk noted that a certificate only has operational value
when someone holds and uses the private key, and that there is
therefore only a risk if someone gets hold of the private key.
Vasily Dolmatov noted that it is important to detail the procedures
required in a resource certification system. He stressed that it is
not an "organisation" that holds the private key, but a single
person, and that there need to be security procedures to identify the
authorised person. He also noted that if the authorised person
resigns, it is important that there be a procedure to transfer
authority.
Daniel noted that we envisage the authorisation process occurring
through the LIR Portal, in line with the current operational
practice, and that the LIR Portal deals with personal accounts, each
one associated with an organisation, at least in theory.
He also noted that when dealing with transfers, the actions available
to users of the LIR portal will have more serious consequences than
the current actions available within the portal. The RIPE NCC senior
management has identified this and the RIPE NCC is reviewing both the
authorisation and authentication methods used in the LIR Portal; a
possible extension of the authorisation model would be to offer sign-
off by more than one individual for certain actions.
*** The key question to be decided is whether to do a mass generation
of certificates for all members/resources or to simply supply
certificates on-demand. Daniel strongly advocated on-demand and
Vasily and Ruediger agreed that there may be a negative value to be
issuing certificates and keys to those who do not want them or know
what to do with them.
Ruediger also noted that if authorisation is to be checked via the
LIR Portal, there will need to be a review of the security
requirements of certification and ability of the LIR Portal to meet
those requirements. Daniel suggested that authentication and
authorisation in the LIR portal
be reviewed at the same time.
*** [Action item on the RIPE NCC?]
Vasily calirified that LIR Portal authorisation is done through the
MNTNER object, and that this is an impersonal object. Daniel
suggested that it might also be useful to look at imposing a minimum
LIR authorisation level for those wishing to use certificates.
*** It was agreed that the policy should include specific reference
to using the LIR Portal (or some other agreed-on mechanism), though
it is important not to lock the system into a mechanism that may
become obsolete.
There was discussion of whether non-payment would mean the revocation
of the certificate, and whether it would this also mean the
reclamation of the resources. Vasily suggested a holding period (say
a year, two years) before the resources are reclaimed. Ruediger noted
that we need to make the proposal acceptable to the entire community,
and that, based on other RIR experiences, procedures for upholding
resources, even in cases of dispute, seem to be a political
necessity. He also noted that even if we don't examine this
explicitly, the issue will probably still be identified by someone
else, and it will be important to have a strong answer for it. Vasily
suggested that it might also be possible to re-issue a different
certificate stating "unpaid", but also noted that the concept of
revocation has no strong support in PKI infrastructure.
Ruediger suggested that there are already situations of closing down
members and cleaning up their resources; this may offer a model.
Andrei Robachevsky suggested that we remove the reference to
reclaiming addresses, as this has nothing to do with certification,
but we could still revoke certificates, as this is a service which
are no longer providing. Andrei also noted that if the member ceases
to pay, we have no idea who the "member" is anymore.
Ruediger suggested that ceasing to pay membership does not
necessarily change the "relationship" between the certificate holder
and the issuer. Andrei noted that the there is an option to allow
certificates expire if there is non-payment, which Vasily is happier
with. Ruediger warned against placing responsibilities on members
that require some technical expertise and a certain amount of work
(that is, more than in the past). He noted that increasing the
requirements for paricipation in the industry is likely to break good
will.
Daniel noted that we need to distinguish between the business PKI and
the resource PKI – the resource PKI doesn't identify people. Daniel
also noted that resource PK, and in particular secure routing
protocols, create a lot of fear in ISPs, because the current model of
routing gives ISPs considerable freedom to (mis-)configure their
routing policies, and once valid certificates and ROAs are required
for routing to function, they see single points of failure in the
RIRs and potential limitations to their current freedom of
configuration that they do not like.
There was general agreement that single certificates for multiple
resources is a good idea.
*** There was discussion on who will propose the policy. Nigel Titley
noted that it would be better that it come from the member side
(rather than from the NCC). It was generally agreed that the Task
Force itself would bring the proposal forward.
AUTOMATIC PROVISIONING
Daniel outlined the white paper on automatic provisioning. He noted
that a major selling point for this is that the RPKI is global
whereas the current allocation databases are regional and require
verification in each of them separately rather than one global system
(though Ruediger noted that having a global system would not
necessarily require PKI infrastructure, to which Daniel replied that
in practice we never succeeded in making it happen).
Serge took the group through a specific scenario, and Tim Bruijnzels
demonstrated the system. Serge noted the importance of making the
export facility easy for LIRs.
Serge noted that for the purposes of the demonstration system, the
first level (relationship with RIPE NCC) is fixed – when rolling out
the full version there would be the facility for LIRs to do their own
sub-delegation. Ruediger suggested that for the purposes of selling
the system, we need to demonstrate the whole thing in some form,
including the full recursive model. Serge noted that the system will
eventually allow for all possibilities – LIRs can have full control,
or hand over all control to the RIPE NCC, or any mid-point between
those extremes. Ruediger noted that the proposal will have to spell
out which parts of the functionality are in the business and schedule
plan. The simple demo should not show all the complicated cases but
it is important to spell out a road map – how precisely do the more
complex examples map with the simple demo? Andrew agreed that if
present a demo at the RIPE Meeting, it will be important to provide
some context.
Serge noted that since it is a recursive model, and that anything put
into place by the RIPE NCC could be used by lower level users as
well. This is why we are focusing on a single level, and getting that
right.
Ruediger noted that the NCC would have to make a statement about
whether the developed software would be made available for use by
third parties, and that solid protocols would have to be published.
Some of the LIRs that might offer services like this may already be
running commercial CAs, and in those cases it might be difficult to
incorporate with the NCC model. He noted that it might be difficult
to get budget for developing this if a different section of the
company already has an alternative model.
Andrew noted that communication around this is a priority.
Vasily noted that there are large commercial enterprises that have
already developed their own systems for PKI – will the RIPE NCC
system accept third party certificates? Serge noted that this should
be possible, but that most people will rely on RIPE NCC, not on their
own PKI systems, so this is more valuable in terms of RIPE NCC
business model.
There was some discussion on whether signing an ROA actually provides
proof of holdership.
SECURE ROUTING
Daniel outlined the possibilities for secure routing. This provides a
companion to automatic provisioning, allowing the AS holder to say,
"yes, I will route this prefix". Is it worth developing this?
Ruediger thinks it is valuable to have this proposal on the table,
but that rolling out the rich model for provisioning and getting the
ERX data done is more important. The work in these areas may be done
by different groups, however, so the comparison may not be relevant.
Vasily noted that an object taken from the database should be signed
twice to ensure that it cannot be changed in transit.
Serge noted that actual secure BGP, of whatever flavour, is still a
long way off. He noted, however, that a significant obstacle is the
absence of a PKI infrastructure, and certification rollout would go
some way toward fixing this.
Vasily noted that this would be purely optional, so there would not
be any policy implications.
RESOURCE TRANSFER
Daniel gave an outline of this subject, noting that when the IPv4
free pool runs out, there will probably emerge a market for IPv4 and
there will need to be mechanisms available for transferring resources
between parties. Ruediger noted that policy will be required for any
transfers – this is already being looked at and will be discussed
later in this meeting.
Serge outlined a scenario and Tim presented the demo. This includes
"overlapping validity", in which there occurs a brief period, during
a transfer, when two parties both have "holdership" of a resource.
There was discussion of how this would be administered, including the
possibility of extending the RFC3779 resource extension to include
"in transition" information. Andrew noted, however, that there was
little support for this in the IETF, as there is concern that it
could take the foundation out from the whole thing.
Ruediger noted that the process might be a little confusing for those
with many resources, and that it might be better to have the resource
in transit held under a separate certificate.
Daniel suggested that the user interface allow for the ROAs be listed
by prefix rather than AS (or at least have the option to search ROA
by prefix).
Ruediger noted that the discussion seemed to focus on one authority
doing the whole thing, which is fine for many cases, but when the
situation includes hierarchical delegation, it will be more difficult
to prevent conflicts, and tools to do this will be of a very high
practical importance.
Vasily noted that the procedures for conflict resolution should be
clearly spelled out, and that the existing white paper seems to be
based on the notion that all parties will have good will (in a
commercial situation, this may not be the case).
Ruediger suggested that the demo include a back-up slide that
discusses how things would happen in the case of multiple CAs (say,
Megacorp has been running its own CA, but Minicorp wants to be served
by a different CA). Serge reiterated that they have been working on
getting the one level right, and that the recursive model should
allow for development of these multiple CA scenarios. Daniel noted
that in the up-down protocol, all the primitive elements are in
place. But he agreed that we should define the different levels of
complexity – it may be easier to transfer resources that are unused,
and advise on issues like this would be useful, perhaps defining
"beginner" versus "expert" levels.
*** Paul Rendek emphasised the need for clarity in any "external"
demonstration (such as RIPE 56), and suggested investigating the use
of multimedia.
Andrew noted that it seems clear that resource transfers will be an
important area; the Task Force agreed. Ruediger emphasised that we
need to be following and mapping the possibilities as resource
transfers emerge.
Filiz discussed the policy matters related to resource transfers. She
noted that there are already policy discussions in various RIRs about
transfers (not necessarily related to certification). In the RIPE
region, proposal 2007-08 is already being discussed, and is shifting
the idea of transfers from acquisitions to a resource market. It also
mentions resources being "signed", thereby implying some sort of
certification system.
There was agreement that the issue of left-over blocks fitting the
minimum allocation size needs to be discussed/considered.
It was also agreed that non-permanent transfers be treated as sub-
allocations, though Ruediger noted that there needs to be a mechanism
for these to be reflected in the certificates, and the owner of the
lease needs a means of creating ROAs.
Filiz noted that ARIN has a very detailed proposal for transfers,
though it is not closely tied to certification development. They have
a large number of rules, including that the recipient still needs to
prove their need to ARIN.
Paul noted that it would be good to get a round-up of what the other
RIR transfer proposals are, and how they might fit with certification
deployment. Daniel noted that we need to do the mechanics such that
they can implement any policy that they want to (especially those we
see looming on the horizon) – we don't want to be in a position where
we are making policy to match systems. He also noted that the
discussion of these other RIR policies should be in the Address
Policy WG, and that the ARIN policy seems far more elaborate than any
of the other RIR policies.
Daniel argued that so far we have avoided the issue of inter-RIR
transfers, even though inter-RIR transfer has been a major selling
point of certification. Ruediger suggested that the inter-RIR thing
is not a pressing problem, and the number of organisations who will
deal with collecting allocations from all regions would seem to be
small, and if the market gets so tight that everyone is forced to
seek inter-region allocations then there will be other issues anyway.
Daniel noted that Randy Bush is already saying that he doesn't like
ARIN policies and may transfer his resources to the RIPE NCC – this
is therefore a scenario that we will need to address.
Ruediger suggested that there is no reason for "inter-RIR" transfers
– the RIR responsible for a given resource block will remain
responsible that block. Serge pointed out that it has been suggested
that RIRs be each others' "subs". Filiz noted that the problem of
having five RIRs with five different policies – in the ARIN policy,
it is also required that address space must be used in the ARIN
region. Ruediger noted that we need to plan for a situation where any
block (of minimum size) might be on the move.
*** Filiz will come up with a table comparing transfer policies in
the different regions, for both the CA-TF and Address Policy WG. She
also noted that for PI space, we need to wait and see the outcome of
2007-01.
The policy may need to specify a period during which a resource is
"locked" during transfer, and it may be important to specify this
period. There is also the question of whether the entire allocation
be locked, or only the block which is to be transferred. Serge noted
that there is a case for locking the whole allocation (to prevent
quick, multiple transfers that might result in a fragmented remaining
block). Ruediger noted that unless you wish to place major
restrictions on large address space holders, you have to only block
the block being transferred. Tim also noted that there was already a
discussion of respecting the /21 bit boundary for remainder blocks,
removing that justification for locking the entire allocation.
Filiz noted that in 2007-08 there is a requirement that resources not
be transferred again within 24 months.
There was discussion of whether the RIPE NCC would allowing transfer
of AS Numbers – it was noted that under current scenarios, transfers
could only be conducted between LIRs, but it is not only LIRs who
have ASNs. Filiz suggested that at some point it will be important to
discuss this, probably in the Address Policy WG. Daniel noted that
it might well be reasonable to tell anyone who wants to transfer an
ASN that they must become an LIR (if only because they would have to
become an LIR to get a certificate). Andrei noted that we have to
allow such transfers, if only to support mergers and acquisitions.
Filiz noted that these policies will need to be proposed at some
point, but this can be discussed in more detail at a later date.
Ruediger noted that once a certification system is in place, it might
be worth encouraging a number of large ERX address holders to get
certificates over their prefixes. This may involve considerable work
for the RIPE NCC, so some planning should be done for this. Daniel
agreed, noting that it might be necessary to bring on some extra
resources to handle the avalanche of requests that may eventuate, and
possibly to solicit ERX holders.
Ruediger noted that there is a case that can be made to ERX holders
("you don't want what happened to YouTube to happen to you, you
should get your resources certified"), but there needs to be a
feasible short-term way for the RIPE NCC to handle the extra
workload. Daniel noted that the RIPE NCC is a flexible organisation
and would be able to accommodate this.
PUBLISHING ROAs AS RPSL OBJECTS
Daniel outlined the idea, which is to turn ROAs into RPSL objects and
publish them in the RIPE Routing Registry. He stressed that Ruediger
came up with this good idea.
There was general agreement that it was a good idea, and that it's
important to have a distinctive source (this is specified in the
white paper). There would need to be some infrastructure put in place
for this though. The update would be done twice a day, or daily.
Serge asked whether being real-time would be an issue, or is only the
longest time an issue (ie. can you be too fast?). Ruediger noted that
this shouldn't be an issue, and that for the most part it would not
be close to real-time.
There was gneral agreement that the information would typically be
queried about once every 24h. Daniel suggested that this means it
would be sufficient to update it about every 12h.
It was generally agreed that this is a good idea and should be done.
CLOSING
Andrew outlined the coming steps, particularly in relation to RIPE
56. This would include readying a "pre-production" version (for
allocated PA), and forming a closed user group for testing. It would
also involve presentations and demos at the meeting, and getting the
policy discussions started. The CA-TF will have a short meeting on
the first day of the RIPE Meeting.
Andrew also noted that the goal is to launch the first production
service at RIPE 57 (with associated fanfare).
There was discussion of priorities for the project. Nigel suggested
shifting secure routing down the list, because as presented in the
white paper, we don't seem to get much more than we are currently
getting out of the RIPE Database, while resource transfers may become
an issue much sooner than we expect. Ruediger noted that supporting
transfers will mean tracking holdership, and that preparing for that
is very important – he noted that doing the transfers before we have
the provisioning processes doesn't make sense. Inserting the
immediate update of the quality of the current routing information
would make sense as a high priority (while secure routing in a rigid
sense is a long way off, and the RIPE NCC would not necessarily do
the technical development of this anyway!). The important thing is
preparing the database so that we can use it should we need to.
A final list of priorities was agreed on:
1. Provisioning
2. Automated provisioning
3. Transfer
4. ROAs as RPSL objects
5. Distributed model
Ruediger noted that there has been discussion of getting standards
for CPs into the IETF, and that some support will be needed to get
potential LIR-signed CAs up to speed. IT would therefore be good to
have an idea how and when things should be taken up when we meet in
Berlin. Andrei noted that it's important that we know what sort of
policies we want in this area, and that we need a single global
policy for this, but the process for deciding this will probably not
be the IETF process. But there is commitment from all RIRs to work on
this document.
Tim noted that there had been concerns raised about the business PKI
side of the project, and suggested that it might make sense to keep
it simple for the moment. Andrew noted that we should make very clear
what we expect of people in the test group. Vasily volunteered to
assist with testing if necessary.
[ Ca-tf Archive ]
