August 2003 - ncc-services-wg

Fwd: [db-wg] X.509 authentication in the RIPE Database, take II
by Joao Luis Silva Damas 20 Aug '03

20 Aug '03

On Friday, August 15, 2003, at 04:23 PM, Shane Kerr wrote: > Joao, > > Joao Luis Silva Damas wrote: >> adding a new strong authentication method to the Database, is in my >> own personal opinion, a good thing(tm), particularly if the same >> credential can be used for other interactions with the RIPE NCC, make >> user's life easier. >> I wonder however about a few questions: >> - will this auth method be available only to RIPE NCC members? Is it >> not seen as a valuable general addition for non-member users of the >> IRR part of the RIPE DB? > > Initially it will only be available for RIPE NCC members. Another interesting change in the model? When you say initially, does this mean it will be extended or not? Shall on read the current proposal as implicitly stating this? > There are three ways we could extend the service to non-LIRs: > > 1. Accept certificates from certain "well-known" CAs, for example > Thawte, Verisign, etc. > > 2. Issue certificates from a RIPE NCC CA established for this purpose, > and accept them. > > 3. Accept all certificates, including self-signed certificates. > > #1 is relatively easy - the main overhead would be maintaining the > Certificate Revokation Lists from the CAs. Deciding which CAs to > support may also be tricky. #2 is also relatively easy, since we > already have the technology. #3 is more difficult, and would require > a slight change of the design, and administration issues (see below). For DB authentication purposes, why do you need to verify the certificate? As with the PGP model[1], the only assumption one needs to make is that the message issuer is the holder of the private part of the certificate. If the RIPE DB is going to start making assertions about the real identity of the message sender, rather than just authorise or refuse updates, this seems to be a change in the model that warrants discussion in the working group. Is this so, or am I misinterpreting your description of the mechanism? > >> - Why the choice of not publishing the pulic part of the certificated >> in the DB? The choice to have a key-cert for the PGP method was not >> to do with issues of web of trust but rather for purposes of helping >> the users with their data maintenance. As a matter of fact the >> recommendation regarding the use of PGP in the RIPE DB, as described >> in the RFC and the minutes of the DBSEC TF, was to use a PGP key for >> this purpose that was not used elsewhere. > > When you receive a PGP-signed message, you need the public key of the > signer to verify the signature. The program that updates the Database > needs this information, and it is stored in the key-cert objects(*). > > With S/MIME, the certificate is sent with the message, and this > certificate is signed by the CA. Since the database is configured to > know how to verify certificates issued by specific CAs, we can verify > the signature. No key-cert is necessary. > > But if we decide to allow any certficate, including self-signed, then > we need some way to allow users to store this information in the > database, for example key-cert objects. Unfortunately, this may cause > problems, because (for instance) someone could create a key-cert > object for a CA run by another organisation with bogus data, > preventing users from using certificates *actually* issued by that CA. > > We could possibly require these sort of key-cert objects be reviewed > by some method, for example RIPE DBM. However, if the RIPE NCC has no > relationship with the CA, we have no real way to know the validity of > any one request. Why do you need to verify the certificate. Also, part of the idea of having a key-cert object was to allow users to check, not the DB, and to maintain DB self-consistency. Are these no longer desired features? Joao [1] RFC 2726

3 2

Charter
by Kurt Erik Lindqvist 20 Aug '03

20 Aug '03

All, I called for volunteers to help me write the proposal of the charter some weeks ago. My plan was to get this done while I was on vacation, and once back take it to the list. Unfortunately the laptop-gods where against me and my laptop crashed. So in order to save some time, I will take the charter directly to the list. My apologies to all those that volunteered, and many thanks for offering to help out. Attached is my rudimentary proposal. Please feel free to comment! Best regards, - kurtis -

1 0

Proposal: Reduction of RIPE-NCC Actvities
by Peter Galbavy 20 Aug '03

20 Aug '03

OK, I have had off list support from people who are maybe not quite willing to be seen above the walls (yet). I would like to put a proposal before the annual meeting - which I will NOT be able to attend personally. Is anyone else willing to carry this in my absence ? Let me guess, too late for this year... The core of the proposal is: -- It is proposed that the RIPE-NCC (a) immediately cease all activities not directly required for the management of those registry functions necessary to the continued well being of the Internet in Europe and other related territories, and (b) undertakes a program of rationalisation that reflects the ongoing commercial consolidation of it's membership while maintaining an efficient and adequate level of service. -- I want help with rewording (b) above. It is not quite right. i.e. "feel the pain" instead of "gravy train". rgds, -- Peter Galbavy Knowtion Ltd. uk.kml

6 8

X.509 authentication in the RIPE Database, take II
by Shane Kerr 15 Aug '03

15 Aug '03

All, [Apologies for duplicate e-mails] Attached please find a proposal for X.509 authentication in the RIPE Database. From the Database point of view (that is, syntax and semantics), it is the same as the one sent 3 July 2003. The difference is that it contains only the specific details of the change, in a straightforward fashion. I hope that we have addressed questions about the use of X.509 that arose in earlier discussions. -- Shane Kerr RIPE NCC Addition of X.509 authentication to the Database Proposal: To add an X509 authentication type to the "auth:" attribute. Attributes with this type will use the Distinguished Name (DN) of the certificate to identify it. Motivation: X.509 allows a single authentication method to work for both e-mail and the web. LIRs can receive an X.509 certificate through the LIR Portal, and should be able to use this to update records they control in the Database. X.509 is "strong", like PGP, although a different trust model is used. Details: The "auth:" attribute of the mntner class will have a new authentication scheme, X509. The DN, as defined in RFC 2253, will be used to identify the specific certificate used. Note that there is no key-cert object for the X509 scheme. Instead, the certificate must be signed by a trusted authority. The trusted authority will be the RIPE NCC Certificate Authority (CA) that is currently only available to LIRs. It is possible to configure additional CAs in future, should this become desirable. For instance, existing commercial CAs could be allowed, or the RIPE NCC could create a CA to issue certificates to non-LIRs for this purpose only. Below is an example of a maintainer with X.509 authentication: mntner: EXAMPLE-MNT descr: Sample maintainer for example. admin-c: SWK1-RIPE tech-c: RD132-RIPE tech-c: HOHO-RIPE upd-to: ripe-dbm(a)ripe.net mnt-nfy: ripe-dbm(a)ripe.net auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user1 auth: X509 C=NL, O=RIPE NCC, OU=Members, CN=zz.example.user2 notify: ripe-dbm(a)ripe.net mnt-by: EXAMPLE-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20030813 source: RIPE Usage: E-mail updates for objects maintained by a maintainer with X509 authentication must be sent in S/MIME format and signed (not encrypted) using the private key associated with the issued certificate. Synchronous updates for objects maintained by a maintainer with X509 authentication must use an SSL connection using the private key from the issued certificate on the client side. Web updates for objects maintained by a maintainer with X509 authentication can use a browser with the certificate loaded. The web updates screens will allow users to specify that they want to identify themselves using the client-side private key, over an SSL connection.

3 3

RIPE tasks and the Board
by Bovio＠aol.com 14 Aug '03

14 Aug '03

Folks, I have carefully read the various postings on the list and I think it is time for me to step forward and try to help in answer/clarify some of the less informed opinions that were expressed. The RIPE/RIPE-NCC issue. Formally Gert is right, but to some extend also the people who say RIPE and the RIPE-NCC are the same thing are somewhat right too, it all depends on how one look at it. In the early years RIPE was some 15-20 people in a room 3 times a year, (almost only from research and academic institutions) trying to coordinate the European IP networks activities and operations. Among the matters at hand it was the need to get IP address space from IANA, and also the need to perform a number of related technical activities that would allow the embryo of the European Internet to grow and function. Soon it became obvious to these people that it was not possible to do that via "volunteers" work, but some dedicated staff was necessary. Shortly thereafter the RIPE-NCC was born, its purpose to get address blocks from IANA, to be distributed locally, and to perform all the technical functions deemed necessary by the community. Back then the relationship between RIPE and the RIPE-NCC was quite obvious to everybody, also because the people participating at RIPE meetings represented pretty much 100% of the "customers" of the RIPE-NCC services: RIPE would discuss and approve the policy to be implemented by the RIPE-NCC. RIPE would also provide input, discuss and approve the activity plan of the RIPE-NCC. As of today the RIPE-NCC still implement the policies discussed and approved at RIPE meetings (yes, yes, Randy, I am aware of the criticism that the process is not altogether transparent anymore), and still seek guidelines from RIPE about technical activities. The main difference is that no longer 100% of the membership of the RIPE-NCC attend RIPE meetings (but only some 10% on average) and that the Activity plan/budget/fees are formally approved by those members who show up at the AGMs. From this point of view, for the members who do not attend either RIPE meetings or AGMs, RIPE and the RIPE-NCC are perceived as the same thing, although formally they are not. (notice that if from now on the RIPE-NCC AGM is held back to back with RIPE meetings this will probably increase this perception). Most of the organizations that joined the RIPE-NCC in the last 3-4 years (and they represent the majority of the membership now) seem to have no idea of all the above, and only joined the RIPE-NCC organization because their corporations need IP addresses and AS numbers to sell their business and make money. They could not care less about attending RIPE meetings (short or long), conservation of Ipv4 address space, and all the policies that were discussed and approved for that purpose, nor for the various technical activities that go with it, to make sure it works, or to anticipate possible future issues and make the Internet a better place, all they want is address space (and they only want to pay for that, darn!), and quick, because every customer lost represent a step toward bankruptcy or toward acquisition by some bigger fish, so for them the RIPE-NCC is only a monopolistic obstacle to their business. As it was stated on the list: nobody has objection to what the RIPE-NCC has been doing or how its being done, its more an objection of the "forced" participation through the funding of the NCC which is completely unfair. I can see very well this point of view, and having been in the research world for quite sometime I can also see very well why, IMHO, it is flawed. Mind you, I am not stating here that the RIPE-NCC is lean and mean as I would like it to be, there is definitely room for progress, but I have to say I think it seems a very non-educated idea to me to split the funding this way. The Board-has-is-head-in-the-sand-and-does-not-realize-the-situation issue. Well, I can only speak for myself of course, but putting my board hat on I can tell you that I am very well aware of the fact that the Internet boom has caused, in the last few years, a gap between RIPE/the RIPE-NCC and its membership, and it took quite sometime to wake up and get the ball rolling to fix the situation, I plead guilty as charged here. I think, however, that a number of steps have been taken in the last 12 months or so to close the gap (the new proposed billing categories, the new algorithm taking in account Ipv6 and assignment dates to compute the fees, the survey, and this list being few examples) and more will be taken following member's input once we get it. As I stated already, anybody should feel free to approach us either at meetings, via mail, or by phone, all our data is available on the web site. Btw, I also welcome any proposal anybody wants to discuss and put before the AGM (and I do not see why anybody would not be willing to be seen "above the walls", anyway, what is he concerned about?), there are various ways to reach members and try to build enough consensus for that, via mailing lists (this one for instance), or just by looking at the web site, the full list is available there. In conclusion I can assure everybody that the board is carefully listening in the discussion and has the highest interest to follow and implement the willingness of the majority of the RIPE-NCC members. Cheers Daniele

1 0

Re: [ncc-services-wg] RIPE tasks
by Axel Pawlik 14 Aug '03

14 Aug '03

Neill, all, First of all I must say that I like the fact that the new RIPE NCC Services Working Group obviously is taking off :-) With regard to the repeatedly stated opinion that the RIPE NCC management, and the RIPE NCC Executive Board are unaware of the members' opinions, and needs, I am convinced that those members of the community who have followed the events, presentations and planning discussions of the last year (from the conduct of the membership survey 2003, the move of the General Meeting to the Friday of the RIPE Meeting, and through to the proposal of the Activity Plan and other documents in preparation of that General Meeting), know full well that we are very aware of these concerns, and that actions continue to be proposed, and are taken where approved, to adjust activities to the expressed need of RIPE NCC members and stakeholders. The existence of this Working Group and mailing list in itself is just one minor outcome. The point of "Just Registration Service" is moot. As we all now, the industry has changed. Well, actually the running of a geeks' network instead of the politically correct technology has *become* the industry before that. And thus has attracted all sorts of people, politicians, lawyers, bureaucrats, the lot. We cannot go back to the old days of just registering numbers. The risk is high that one day we would awake to the ITU doing Internet Governance. "Please see your local MP to effect a change in IP allocation policy, to be discussed at the next plenipotentiary of the ITU." We need to do more, to establish the RIPE NCC in the minds of politicians, journalists, "the public" as a trustworthy place you can turn to to gain insight in the operations of the Internet. About the RIPE meetings: They are crucially important to the functioning of the RIPE NCC, and of industry self regulation. Yes, they should be self supporting, but they aren't fully. Can we raise the meeting fees? Of course. But we need to balance this very carefully, as we cannot run the risk of eating into attendance numbers too much. regards, Axel

6 8

E-mail list removeal
by Mark Brett 13 Aug '03

13 Aug '03

Please remove mark(a)brett.com from allo f your lists asap. Thanks. Mark Mark Brett Tel: 0208 529 8614 Mobile: 07720 101 733 PO Box 6733. Chingford, London. E4 8UD

2 1

RIPE NCC Services
by Chris Hallam 13 Aug '03

13 Aug '03

Stephen Burley wrote: All of which the NCC do well and should be commended, anything else is surplus to requirement there is one other thing the NCC has never done and never fully justified and that is a help desk you can talk to. Other RIR's do it. I think it helps cut away the sterile faceless image and lets you see what you are getting for your money - discuss === I think the inclusion of a telephone help desk service would benefit a lot of members. I imagine it would be difficult to implement due to the number of bilingual staff that would be required. This would therefore require substantial funding which would probably affect member fees. In addition, most of the actual processes would have to remain based on the email system. Even so, if the operational scope was clearly defined it would be useful for help, advice, and a reliable point of contact. Chris ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. **********************************************************************

1 0

RE: [ncc-services-wg] Re: [address-policy-wg] Re: ICANN vs RIPE N CC, was Re: Summary of the PI ......
by Mike Norris 12 Aug '03

12 Aug '03

I agree fully with you, Daniele. Mike Norris -----Original Message----- From: ncc-services-wg-admin(a)ripe.net [mailto:ncc-services-wg-admin@ripe.net]On Behalf Of Bovio(a)aol.com Sent: Tuesday, August 12, 2003 9:21 AM To: address-policy-wg(a)ripe.net; ncc-services-wg(a)ripe.net Subject: [ncc-services-wg] Re: [address-policy-wg] Re: ICANN vs RIPE NCC, was Re: Summary of the PI ...... In a message dated 11/08/03 17:51:19 W. Europe Daylight Time, daniel.karrenberg(a)ripe.net writes: I have not stopped listening to concrete ideas about improving the RIPE NCC. I am still here at the RIPE NCC working and listening. Of course the bureaucratic developments you sneer at *do* happen to some degree. This is inevitable and both you and I know it. The ability of individuals like you and me to influence things immediately and directly is reduced. Of course I personally I do not agree with all things the RIRs do and more often I do not agree with *how* things are done. What seems to divide us is that I still work to improve the 'least of all evils' structure and you sneer at it providing no alternative. I would hope that more people will chose the former instead of the latter. I also hope that people still see the relative mertis and the differences in legitimacy that exist between the various organisations. Sneering at the RIPE NCC without suggesting either alternatives or improvements does not help. I stand 100% with Daniel here. I can't speak for the others RIRs but I strongly believe the RIPE-NCC has made significant efforts in the recent past to listen to its membership, streamline procedures, and positively react to constructive criticism. There is more work to do, no doubt about it, but I can't see how flaming on mailing lists helps. Whomever has concrete ideas: I propose we move this discussion to the ncc-services-wg list/group, that was created exactly for this purpose. Daniele

1 0

RIR statistics on IPv6 allocations
by Membership Liaison Officer 06 Aug '03

06 Aug '03

Dear Colleagues, Recently, interest has been expressed for having RIR Statistics published by the RIPE NCC include IPv6 allocation data. This data is now published daily under the following directory: ftp://ftp.ripe.net/ripe/stats/new/ Please note that the format of the file is subject to change, as there are ongoing discussions on a common format between the four RIRs. Regards, Sabrina Wilmot -------------------------------------------------- Membership Liaison Officer <contact(a)ripe.net> Tel +31 20 535 4444 http://www.ripe.net/ Fax +31 20 535 4445 RIPE Network Coordination Centre (RIPE NCC) P.O. Box 10096, 1001 EB Amsterdam, The Netherlands -------------------------------------------------- See you at the RIPE 46 Meeting 1-5 September, 2003, in Amsterdam, The Netherlands http://www.ripe.net/ripe/meetings/ripe-46/index.html

1 0