- ncc-services-wg - mailman.ripe.net

Re: [ncc-services-wg] struct. differences in PI vs. PA request forms & use of role:
by Wilfried Woeber, UniVie/ACOnet 01 Mar '04

01 Mar '04

>Hi Wilfried, > >Thanks for your comments. Thanks for the comments and explanation! Wilfried.

1 0

struct. differences in PI vs. PA request forms & use of role:
by Wilfried Woeber, UniVie/ACOnet 01 Mar '04

01 Mar '04

Dear community and NCC, while talking with one of my colleagues (who very recently attended a LIR training), and processing a request submitted by one of our customers to change their inetnum: contact details I started to wonder: As far as I can remember there was a rule (strong recommendation?) to use a "real" person as the contact in admin-c:, while a role: could be used for tech-c: and zone-c: (But maybe I am mixing [legacy] domain object requirements or some TLD admin's requirements with the address registry...) I was told that the LIR training course _does_ mention the role: object, but _does not_ offer guidance about the use. So, I started digging for documentation about the use of, and linkage to, person: and role: objects for inet[6]num. No success. I probably missed some section where it is described. Then I had a look at the PI and PA request forms and accomp. notes. Again, no guidance as to where a role c/should be used (or not). At the same time I became aware again, that the _new_ PI and PA address request forms are different: the PI form still has the database object section, but that was dropped from the PA form! I am left with 2 questions now: A) why is there a difference between PI and PA forms regarding DB information? B) is there still a recommendation or requirement to use a "real" person: as the reference for an admin-c:? Thanks for any help. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Improved Secure Communication for Registration Services (RS) Mailboxes
by Shane Kerr 01 Mar '04

01 Mar '04

All, The RIPE NCC is nearing completion of the database phase of the "Improved Secure Communications for RIPE NCC Members" project. The next phase will focus on e-mail communication between RIPE NCC members and the Registration Services Department. The attached document presents our ideas regarding this, and also raises some questions for the membership. Please have a look, and comment. There will also be a presentation and discussion at the NCC Services Working Group next week at RIPE 47, for those interested in voicing their opinions in person. -- Shane Kerr Software Engineering Department Manager RIPE NCC Filiz Yilmaz Bican Senior Hostmaster RIPE NCC Improved Secure Communication for Registration Services (RS) Mailboxes 0. Overview ----------- This is a discussion document with the aim of obtaining members point's of view on the usage of PKI for RS mailboxes. It may result in a proposal document after such feedback is gathered. There is a need for secure communication between the RIPE NCC and its members due to the following: - discussions should be avoided with unauthorised persons representing the member organisation. - members should be able to ensure that they are communicating with the RIPE NCC. - communication with the RIPE NCC contains confidential information for the members. Accordingly, it was decided that the RIPE NCC would work on the implementation of a secure system. More information can be found at: RIPE NCC Activities, Expenditures, and Charging Scheme 2003 http://www.ripe.net/ripe/docs/ap2003.html Therefore the RIPE NCC is currently working on a "Secure Communications" project that can be found at: Draft: Improved Secure Communication System for RIPE NCC Members http://www.ripe.net/ripe/draft-documents/archive/pki-20030429.html The secure communications project has several phases as areas of communication with the RIPE NCC to implement security. Securing the communication with the RIPE NCC Registration Services (RS) is the third phase of the project. (A full description of the phases can be found at the above URL.) 1. Introduction --------------- Secure communication between a member and the RIPE NCC requires authentication, non-repudiation and data confidentiality. Most of the interaction between a member contact and a RIPE NCC Hostmaster is via e-mail. Currently, the RIPE NCC authenticates a received mail based on the "Full Name" of the member contact. This is either found in the mail headers or in the body of the mail. This is a very weak form of authentication and can sometimes result in repudiation (not accepting the sender as an authorised contact). Currently, authentication and non-repudiation requirements are only supported from the RIPE NCC by signing all outgoing mail sent to a member contact with the RIPE NCC's PGP key. It is not possible to authenticate a member through a digital signature or to send information in encrypted format. The system discussed below will meet the "authentication" and "non-repudiation" requirements for the communication between RS and member contacts (if desired). However, this is not a solution to the requirement "data confidentiality". This requirement and a possible solution to it are discussed in Section 3. 2. Discussion: Integration of X.509 PKI technology for RS Mailboxes ------------------------------------------------------------------- In order to secure the communication for "authentication" and "non-repudiation" between a member contact and a RIPE NCC Hostmaster X.509 Public Key Infrastructure will be used. The member-only mailboxes for this kind of communication are: - <hostmaster(a)ripe.net> (Internet Resource Requests mailbox) - <lir-help(a)ripe.net> (Help mailbox) The level of security can be chosen by the member contact, the options are the following: Mails from Member Contact to RIPE NCC (Incoming mails to RS mailboxes): ----------------------------------------------------------- I1. Nothing (This corresponds to the current system). I2. X.509 PKI Signed mail from the member contact is required. Mails from RIPE NCC to Member Contact (Outgoing mails from RS Mailboxes): ------------------------------------------------------------- O1. PGP Key (mail sent PGP signed with the RIPE NCC's PGP Key which is the current system). O2. X.509 PKI Signed mail from the RIPE NCC is required. The system will work in the following manner: 2.1 Initialisation of the system on the member side --------------------------------------------------- 1. The member (registry) should have an LIR Portal "admin" account. For registries without an "admin" account, the following link can be used to activate one: https://lirportal.ripe.net/lirportal/activation/activation_request.html 2. Within the "admin" account, "Administrative Preferences" (corresponding to I1 or I2 and O1 or O2 described above) should be configured. These "Administrative Preferences" will describe the preferences of the organisation so they can override the "User Preferences" (described in point 4 below) if preferred. 3. Through the "admin" account users should be created for staff members needing to contact the RIPE NCC Hostmasters. 4. Users should configure their "User Preferences" (corresponding to I1 or I2 and O1 or O2 described above) through their LIR Portal accounts. The user will only be given the list of options that match the "Administrative Preferences" set by the "admin". 5. If the user chooses O2 they should install the RIPE NCC's CA Root Certificate[1]. 2.2 Communication Flow ---------------------- 2.2.1 Incoming Mails to RIPE NCC RS Mailboxes --------------------------------------------- 1. The sender's e-mail address on the mail headers (From) will be checked against the "User Preferences" stored in the LIR Portal for the user. 2. If the "User Preferences" require I2 (X.509 PKI Signed mail from the member contact) 2.1 AND the signature is valid, the RIPE NCC RS Robot will accept the mail. 2.2 AND the signature is NOT valid OR the mail is not signed at all, the mail will be bounced back to the sender. Help information will be provided in the bounce message (see Section 2.3 HELP). 3. If the "User Preferences" require I1 (Nothing), the RIPE NCC RS Robot will process the mail (this is identical to the current situation). 4. If there is no user in the LIR Portal corresponding to the sender's e-mail address 4.1 AND the "Admin Preferences" is set to I1 (Nothing), the RIPE NCC RS Robot will process the mail (this is identical to the current situation). 4.2 AND the "Admin Preferences" is set to I2 (X.509 PKI Signed mail from the member contact), the mail will be bounced back to the sender. Help information will be provided in the bounce message (see Section 2.3 HELP). 2.2.2 Outgoing Mails from RIPE NCC RS Mailboxes ----------------------------------------------- 1. The recipient's e-mail address on the mail headers (To) will be checked against the "User Preferences" stored in the LIR Portal for the user. 2. If the "User Preferences" require O2 (X.509 PKI Signed mail from the RIPE NCC) the mail will be signed with the RIPE NCC's certificate (On the user's end, this signature can be validated through the installed CA Root Certificate of the RIPE NCC). 3. If the "User Preferences" requires O1 (PGP Key), the mail will be signed with the RIPE NCC's PGP key (this is identical to the current situation). 4. If there is no user in the LIR Portal corresponding to the recipient's e-mail address 4.1 AND the "Admin Preferences" is set to O1 (PGP Key), the mail will be signed with the RIPE NCC's PGP key (this is identical to the current situation). 4.2 AND the "Admin Preferences" is set to O2 (X.509 PKI Signed mail from the RIPE NCC), the mail will be signed with the RIPE NCC's certificate (On the user's end, this signature can be validated through the installed CA Root Certificate of the RIPE NCC). 5. If there are multiple recipients (multiple addresses in To and/or Cc), the mail will be sent containing multiple MIME parts. Each of these MIME parts will contain specific security according to each recipient's case as described above. In summary, there will be flexible options for those members willing to deploy more security in their communication with the RIPE NCC RS. There will be no implications to members who are not willing to deploy such a security system. There will also be no implications to members who do not have an LIR Portal "admin" account activated. 2.3 HELP -------- In case a mail is bounced back due to the failure in verification of the signature, the mail will contain instructions explaining possible reasons for the problem and pointers on how to solve it. It will also provide an e-mail address to contact about the problem. 3. Future Developments/Phases ----------------------------- The system discussed above is open to changes in accordance to member feedback. One of the possible future developments could be the integration of this system to other RIPE NCC RS mailboxes, e.g. <inaddr(a)ripe.net>, <reg-review(a)ripe.net> etc. As mentioned earlier, the system discussed above is only a solution to the "authentication" and "non-repudiation" requirements. It is not a solution to the "data confidentiality" requirement. Data confidentiality can only be met once the communication is in an encrypted format. This can be achieved with the usage of X.509 PKI technology. Once this is implemented other security options for "Admin Preferences" and/or "User Preferences" can be added as follows: Mails from Member Contact to RIPE NCC (Incoming mails to RS Mailboxes): ----------------------------------------------------------- X.509 PKI encrypted mail from the member contact is required X.509 PKI signed and encrypted mail from the member contact is required. Mails from RIPE NCC to Member Contact (Outgoing mails from RS Mailboxes): ------------------------------------------------------------- X.509 PKI encrypted mail from the RIPE NCC is required The encryption process requires a more detailed set of definitions and rules to be clarified before any technical implementation can take place. For such a set of definitions and rules to be outlined, the RIPE NCC needs input from the members. Some pointer questions regarding encryption are listed below that require feedback from the community: - Do members' security concerns in communication with the RIPE NCC require this type of security? - Should all mails to the RIPE NCC RS mailboxes be encrypted? - Should all mails from the RIPE NCC RS mailboxes be encrypted? - Should there be different levels of security for different mailboxes? - Should there be different levels of security for incoming and outgoing mails to/from the RIPE NCC RS mailboxes? - Should there be different levels of security depending on the content of the messages. (For example to indicate sensitive content, every ticket initiated with an encrypted message should carry on as encrypted.) - If all the keys expired for a registry which "prefers" an encrypted communication and the RIPE NCC needed to contact the registry, how should this communication be initialised by the RIPE NCC? - How should the encryption be done when there are multiple recipients, or where "User Preferences" do not match? - How should the encryption be done when there are different registries involved in communication in specific cases, for example mergers and takeovers? - How/what should be the back-up system if the encrypted format cannot be processed by the member contact or by the RIPE NCC for some reason? Please provide your feedback to the following: - <pki-suggestions(a)ripe.net> or - <ncc-services-wg(a)ripe.net> Feedback can also be given during the RIPE NCC Services Working Group at RIPE 47, 26-30 January 2004, Amsterdam. [1] CA Root Certificate: Certification Authority Certificate. The RIPE NCC will be the Certification Authority (CA) in this system.

9 25

REMINDER: Inter-Domain Routing Workshop, RIPE NCC, Amsterdam (May 1-2, 2004)
by Matthew Williams 27 Feb '04

27 Feb '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicate mails] Dear All, The Inter-Domain Routing Workshop will take place at the RIPE NCC in Amsterdam during the weekend before RIPE 48 (May 1-2, 2004). This RIPE meeting will also be held in Amsterdam. The goal of the workshop is to bring together a focused group of operators, vendors, and researchers to discuss important mid- and long-term operational problems, as well as new academic ideas, in an OPEN forum. The wide scope for topics was intended on our part. The organisers are: * Intel Research * Universität Karlsruhe Institut für Telematik * Technische Universität München, Computer Science Department * RIPE NCC * Schlund+Partner AG, Karlsruhe See URL for more information: http://www.tm.uka.de/idrws/ We are hoping that these discussions will become an invigorating and lively affair. Please feel free to drop us a line at idrws(a)ripe.net. Kind regards, Matthew Williams --- > Matthew Williams (MW243-RIPE) > Customer Liaison Engineer > RIPE NCC - http://www.ripe.net/np/ -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.4 iQA/AwUBQD9V5sHkFbJe+GdoEQJM9ACfYr/r7uErUN7VG8As7AFszid7LS0AnRzB /ieShHagijt6tCx7Q4wvA/O2 =NAT1 -----END PGP SIGNATURE-----

1 0

Re: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes
by Wilfried Woeber, UniVie/ACOnet 27 Feb '04

27 Feb '04

Hi Gert! >> I would argue that it is the other way around; given the forced choice of >> "only one" the broadest support exists for PGP. > >I don't see anyone talking about "only one". Why are you worried? Well, the "only one" may come from the wording in the document, and it was suggested already during this discussion (although _in favour_ of PGP!!): ______________________________________________________________________ From: Kurt Jaeger <lists(a)complx.LF.net> To: ncc-services-wg(a)ripe.net Subject: Re: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes Date: Thu, 26 Feb 2004 08:59:38 +0100 HI! > > No but it highlights one of the reasons why X.509 might be the > > better choice. > to repeat myself, why is there a choice at all? why one xor the > other, as opposed to one or the other? Because in the long run, providing both ways will cost more than consolidating into one. So, sometime in the future, we will be asked: Does someone still use the GPG way ? Aha, only a minority. So: We will close that down, to save costs. [ .... ] Frankly, if the cost in implementing the x.509 way had been invested in the GPG way, we would have exactly one and better solution than having now to run/use both. -- MfG/Best regards, Kurt Jaeger 16 years to go ! LF.net GmbH fon +49 711 90074-23 pi(a)LF.net Ruppmannstr. 27 fax +49 711 90074-33 D-70565 Stuttgart mob +49 171 3101372 ______________________________________________________________________ >(If someone proposed abandoning PGP, I would be one of the loudest voices >opposing it) So I guess you should voice your opinion :-) >Gert Doering > -- NetMaster >-- >Total number of prefixes smaller than registry allocations: 58081 (57882) > >SpaceNet AG Mail: netmaster(a)Space.Net >Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 >80807 Muenchen Fax : +49-89-32356-299 Wilfried.

1 0

Re: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes
by Wilfried Woeber, UniVie/ACOnet 27 Feb '04

27 Feb '04

>However, the document under discussion appears to offer X.509 as the >only method for securing communication with RS mailboxes, If this is the case then I strongly suggest to amend the wording! >the >alternative is continue as today, where this communication is going >unsigned and in the clear in both directions. Not really, the Reg.Serv Dept. obviously applies PGP signatures to outgoing mail by default (see below). And I really appreciate that!! >Regards, > >- Håvard Regards, Wilfried. ______________________________________________________________________ To: Woeber(a)CC.UniVie.ac.at Subject: NCC#2004xxxxxx AW raise From: RIPE NCC Hostmaster <hostmaster(a)ripe.net> Date: Fri, 30 Jan 2004 15:18:10 +0100 This is a cryptographically signed message in MIME format. ------------=_1075472293-11892-0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-length: 280 Dear Wilfried, Thank you for approaching us this morning. We have decided to raise your Assignment Window from /xx to /xx (you will receive an official approval message within a few moments). If you have any question please let us know. Kind regards, Andrea Cima RIPE NCC - ------------=_1075472293-11892-0 Content-Type: application/pgp-signature Content-Disposition: inline Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Comment: For info see https://www.ripe.net/rs/pgp/ iD8DBQFAGmelaF6b6AtxYiURAmMIAJ4kseNxvU+D7NoFdPpe8ikAY2EYRwCfW8pm Ww6xtXPHUtuKACSDvWMq0Q8= =eCb7 -----END PGP SIGNATURE----- ------------=_1075472293-11892-0-- --------------------------------------------------------------------------------

1 0

RE: [address-policy-wg] New Draft Document: De-boganising New AddressBlocks
by Michel Py 27 Feb '04

27 Feb '04

> Rob Thomas wrote: > The reality is that the miscreants are seeing a lower > return on the investment when spoofing from bogon prefixes. Because they are being filtered :-) If more people filtered bogons, the "ROI" would be even lower. Although it is clear that bogon filtering is not a complete cure for spoofing, it does help and it also helps for some spammers. The only negative effect of bogon filtering is not-up-to-date filters, which is why we have written this draft that will expand the applicability domain of bogon route servers and other filtering schemes. Michel.

1 0

New Document available: RIPE-301
by RIPE NCC Document Announcement Service 26 Feb '04

26 Feb '04

New RIPE Document Announcement -------------------------------------- A new document is available from the RIPE document store. Ref: ripe-301 Title: Mergers, Acquisitions, Takeovers and Closures of Organisations Operating an LIR Author: Kamran Khalid Nurani Nimpuno Sabrina Wilmot Date: February 2004 Format: PDF=195891 TXT=13941 Obsoletes: ripe-185, ripe-241 Obsoleted by: Updates: Updated by: Short content description ------------------------- This document provides guidelines to Local Internet Registries (LIRs) on the steps to take when the organisation operating an LIR changes ownership (due to a merger, sale or takeover) or stops serving entirely as an LIR. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URL:. http://www.ripe.net/docs/mergers.html The RIPE Document Store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-301.pdf PDF Version ftp://ftp.ripe.net/ripe/docs/ripe-301.txt plain text version

4 3

Re: [address-policy-wg] New Draft Document: De-boganising New Address Blocks
by Michael.Dillon＠radianz.com 26 Feb '04

26 Feb '04

>The RIPE NCC has prepared a draft document titled "De-Bogonising New >Address Blocks": That is a misleading title. The problem is that ISPs cannot react quickly enough to open filters when new ranges are allocated. The proposed solution is to provide advance notification. I suppose this could allow ISPs to open filters before the new addresses are actually in use officially. However, it will also allow spammers to announce this space and get it through bogon filters. The real solution to this problem is to make it possible for ISPs to closely track RIR allocations in their filters in a semi-automated way. There may still be a few days of delay before a new allocation is fully routable but ISPs can compensate for that with internal processes. Why can't ISPs subscribe to a feed of all new RIPE allocations in near real-time? --Michael Dillon

10 15

Re: [ncc-services-wg] Improved Secure Communication for Registration Services (RS) Mailboxes
by Wilfried Woeber, UniVie/ACOnet 25 Feb '04

25 Feb '04

Hi Shane! >Ignoring the "PGP versus X.509" question, does the membership want us to >support signed e-mail at all? What about encrypted e-mail? Of course I cannot speak for the membership, I can only do so for our LIR: Yes, signed email communication should be supported. In particular with the current situation that "from" and "to" lines are just "random text" in a "subset" of messages being sent on the net these days ;-) I think that encryption almost comes for free when we've got signatures, and should be offered as well, _but not be required_. >- -- >Shane Kerr >RIPE NCC Wilfried (at.aconet)

1 0