July 2003 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Release of prototypes of RPSLng IRRToolSet and Whois Server
by DB-News 30 Jul '03

30 Jul '03

[ Apologies for multiple messages ] Dear Colleagues, The RIPE NCC is pleased to announce version 4.8.0 prototype release of IRRToolSet, and version 0.1 prototype release of RIPE Whois Server Software containing RPSLng extensions. RPSLng is an effort to extend RPSL language, enabling the language to document routing policies for the IPv6 and multicast address families currently used on the Internet. The prototype of IRRToolSet implements the Internet Draf Document draft-blunk-rpslng-01 (http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt). The prototype release contains peval and rpslcheck that already work with a new dictionary (you can also try the Web prototype for peval). Currently work is in progess to make other tools RPSLng compatible. More details can be found at: http://www.ripe.net/db/irrtoolset The source code of version 0.1 prototype release of RIPE Whois Server Software can be found at ftp://ftp.ripe.net/ripe/dbase/software/ripe-dbase-RPSLNG.0.1.tar.gz More details can be found at http://www.ripe.net/db/rpslng . Please contact dbtools(a)ripe.net for any comments. -- Best regards, Engin Gunduz Katie Petrusha RIPE NCC

1 0

X.509 authentication in the RIPE Database
by Tiago Antao 22 Jul '03

22 Jul '03

Dear Colleagues, [Apologies for duplicate e-mails] As previously discussed in RIPE 44 and 45, please find below the proposal to add X.509 authentication to the RIPE Database. ******************************************************************** X.509 Certificate Authentication in the RIPE Database 0. Objective To make a new method of authentication available using X.509 certificates. 1. Motivation The RIPE Database currently has 5 methods of authentication, none of these are completely satisfactory with regard to security, standards support (de facto and de jure), pervasiveness and integration. The X.509 authentication mechanism would satisfy all of these factors: 1. Security: X.509 allows for the use of digital signatures, making it unnecessary to send clear passwords via e-mail. The current PGP authentication also provides this feature. 2. Standards support: X.509 is an ISO standard and is the only mechanism supported by mailers and clients used in more than 90% of communications with the RIPE NCC. 3. Pervasiveness: X.509 can be utilised with several communication mechanisms, not only mail. A common example is SSL/HTTPS. No other authentication mechanism is as strong and easily available with the web. 4. Integration: This authentication method will integrate seamlessly with the general framework of security in use at the RIPE NCC. It is also important to note that, the general trend among the other Regional Internet Registries (RIRs) is the use of X.509 as a main authentication method. 2. User visible changes a. Requirements To be able to the X.509 authentication method the user requires a certificate issued through the RIPE NCC LIR portal. Information on how to obtain a certificate can be found at: http://lirportal.ripe.net/lirportal/faq/pki.html Therefore the X.509 method would only be available to LIRs. This can be changed if the community so desires. b. Maintainers The auth: attribute of the mntner object will have a new authentication scheme, X509. The parameter will be a Distinguished Name (DN) according to RFC 2253. There is an important fundamental difference between PGP authentication and X.509; the database does not need a key-cert object for X.509 certificates, the DN has to be trusted. This means the certificate must be signed by a trusted authority and that self-signed certificates will not be accepted. The trusted authority will be the RIPE NCC Certificate Authority that is currently only available to LIRs. Following is an example of a maintainer with X.509 authentication: mntner: RIPE-DBM-MNT descr: Mntner for RIPE DBM objects. admin-c: AMR68-RIPE tech-c: RD132-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=eu.ripe.dbm notify: ripe-dbm(a)ripe.net mnt-by: RIPE-DBM-MNT referral-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20030617 source: RIPE For users the only variable part within the new auth: attribute is the CN (Common Name). c. Submitting updates via 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. This key must also be made available to the mailer. Users that have a mail user agent that does not support S/MIME might consider using OpenSSL S/MIME facilities to prepare their mails. d. Submitting updates via webupdates Webupdates will accept client-side certificates. This means that the strongest type of authentication possible will be easily available for users using the web. For this to be possible the certificate and private key have to be loaded in the user browser.

4 4

New Draft Documents for review: IPv4 Policy & Status Attribute in Inetnum objects
by leo vegoda 21 Jul '03

21 Jul '03

Dear Colleagues, The RIPE NCC is pleased to announce the publication of a draft of the updated RIPE IPv4 policy document, “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” (currently ripe-234). We have also published a draft document detailing proposed changes to the “status:" attribute in inetnum objects. Both documents can be downloaded from the "Drafts" section in the RIPE Document Store, found at: <http://www.ripe.net/ripe/draft-documents/> The major updates to the draft IPv4 policy document include the following: - Recent policy changes have been incorporated, including the policy allowing assignments for Internet experiments and the sub-allocation policy. - Wording has been improved to make it easier to read. - The explanation of how to use the database has been removed as a separate "RIPE Database User Manual: Getting Started" was published in September last year. - The document now incorporates the text from "Provider Independent vs Provider Aggregatable Address Space" (ripe-127). - The document now specifies database registration requirements. If the community accepts this document it will replace the existing IPv4 Policy document (ripe-234) and the "Provider Independent vs Provider Aggregatable Address Space" document (ripe-127). The draft document on “status:" attributes proposes changes to the values of “status:" attributes. There is a new “status:" attribute value to support the sub-allocation policy, approved by the RIPE LIR Working Group. New wording is suggested, too. This should make the meaning of “status:" attributes more clear to the majority of Whois users. Feedback on both documents should be sent to the <address-policy-wg(a)ripe.net> mailing list for a period of five weeks. This review period will end on 28 August 2003. Kind regards, -- leo vegoda RIPE NCC Registration Services Manager

1 0

Re: [db-wg] Re: [ncc-services-wg] X.509 authentication in the RIPE Database
by Wilfried Woeber, UniVie/ACOnet 16 Jul '03

16 Jul '03

Randy, >let the RIRs spend a few of the bucks they have getting their certs >signed by a well-trusted root CA. is there any? Or to be more precise, why (as an RIR customer) should I trust a commercial CA more than a RIR? >randy I think what is happening here is a misunderstanding and/or an attempt to mix and match advantages, capabilities and technology of a hierarchical 3rd party trust system vs. a (PGP-like) web of trust approach. Wilfried.

1 0

Re: [ncc-services-wg] X.509 authentication in the RIPE Database
by Tim Christensen 11 Jul '03

11 Jul '03

> when you say that the trend among the other RIRs is to go for X.509 > certificates, could you please elaborate on what they are > doing and how > far they are? Greetings all, Currently, ARIN is working toward deployment of X.509 as a strong authentication method for securing email template submissions. We expect implementation to occur later this year. After X.509 deployment for templates, ARIN will explore both the expansion of X.509 into other methods of interfacing with ARIN, as well as other strong authentication mechanisms. Regards, Tim Christensen Database Administrator American Registry for Internet Numbers (ARIN) (703) 227 9876

1 0