[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 ]