ncc-services-wg

Download

ncc-services-wg@ripe.net

March 2004

12 participants
12 discussions

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