October 2006 - db-wg - mailman.ripe.net

FW: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi, > From: Gert Doering [mailto:gert@space.net] > Changing from CRYPT-PW to MD5-PW doesn't incur any > operational changes, and doesn't require key management and > crypto of any sort, but *will* improve security. No "operational changes"? Let's look at the plan to get an image that it's not so "problemless". I don't speak about RIPE resources which should support this change. About security: there was several opponents of your view already. I'm adding myself to them. > From: Gert Doering [mailto:gert@space.net] > Security issues in the IRR DB impact all of us (like "fake objects, > use that to leverage a routing attack"). Let's not say fairy tales about that. I have asked about REAL LIFE problems with the scheme. Nobody has answered. As for security issues... I think the better way to do this things is to educate people, convince them to have better way of security. Up to now it is only "small group words" and 3500 usages... I'm against the proposal. Vladislav Potapov Ru.iiat

2 1

RE: [db-wg] Re: [enum-wg] Proposal for new org-type
by Antoin Verschuren 05 Oct '06

05 Oct '06

leo vegoda wrote: > Do people find org-type values like IANA, RIR, LIR and so on useful? > If not, maybe we just need two values: REGISTRY for IANA, RIRs, LIRs, > TLDs and Tier 1 ENUM operators and NON-REGISTRY for everyone else. > However, if people really find the hierarchical distinctions in the > current org-type values useful, maybe we need some additional > granularity for the different kinds of domain registries? > > If the extra granularity is useful, perhaps we need to allow > organisations to have multiple org-type values? That's probably > preferable to having multiple objects for a single organisation. It depends on what is is supposed to be used for in the DB. If is is needed to distinguish types of organisations when making queries, the types makes sense. But if it's only there to give a label and it is never used, it doesn't. I wouldn't mind changing the "NON-REGISTRY" into "OTHER", like I now have to apply for a RIPE meeting. But on the other hand, if RIPE wants to use it as a differentiation of their customers, and this would be expressed in the RIPE DB, I think ENUM-REGISTRY would be appropriate, and I would also find it logical I can register at a RIPE meeting as "ENUM-REGISTRY". It's then just a customer type. I can see a reason for the term "REGISTRY" if RIPE intends to expand heir services to more than IP network services, and doesn't feel to create a long list of different marketing terms for different organisations. I work for a ccTLD registry that is not an LIR, and even though that is a clear Internet registry function like IANA, RIR or LIR, RIPE currently does not supply a service for that function that requires an entry in the DB. Conclusion: I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. I cannot live with the org-type NON-REGISTRY. My prefference would be the ENUM-REGISTRY org-type. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

4 3

Re: FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Gert Doering 05 Oct '06

05 Oct '06

Hi, (I'm adding db-wg(a)ripe.net back into the CC: list) On Thu, Oct 05, 2006 at 01:50:09PM +0400, Potapov Vladislav wrote: > > From: Gert Doering [mailto:gert@space.net] > > Changing from CRYPT-PW to MD5-PW doesn't incur any > > operational changes, and doesn't require key management and > > crypto of any sort, but *will* improve security. > No "operational changes"? In the day-to-day operation ("sending in mails to change objects to the RIPE DB") going from CRYPT-PW to MD5-PW *will* *not* *change* *anything*. The mail will still contain a "password: <something>" block, just the way this password is hashed in the maintainer object is different. > Let's look at the plan to get an image that it's not so "problemless". So where exactly *do* you see "problems"? In your mail you speak about "crypto" - which is NOT involved here (except hashing the password) - this proposal is not forcing anybody to go to PGP, just to a different password storing scheme. > I don't speak about RIPE resources which > should support this change. > About security: there was several opponents of your view already. I'm > adding myself to them. Please get a reality check on what is proposed, and what is proposed as replacement. > > From: Gert Doering [mailto:gert@space.net] > > Security issues in the IRR DB impact all of us (like "fake objects, > > use that to leverage a routing attack"). > Let's not say fairy tales about that. I have asked about REAL LIFE > problems with the scheme. Nobody has answered. *Good* security is fixing problems *before* they happen. Like "lock your front door when you leave your house, even if you have never been burglared yet". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster(a)Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234

1 0

Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Katie Petrusha 05 Oct '06

05 Oct '06

Dear colleagues, Here follows the proposal to deprecate CRYPT-PW authorisation in mntner objects in the RIPE Database. Comments would be appreciated. Background and motivation ------------------------- In the RIPE Database there are several authorisation types currently supported: CRYPT-PW, MD5-PW, PGPKEY and X509. These authorisation types define what kind of authorisation tokens can be used in "mntner" objects. CRYPT-PW authorisation type is based on UNIX crypt() functionality and is vulnerable to both dictionary and brute force attacks given the fixed password length and lack of cryptographic strength given today's computing power. While maintaining and protecting objects in the RIPE Database is the responsibility of the respective maintainer, the RIPE DB WG agreed that it's the responsibility of the community to ensure that only appropriate tools and algortihms are used and maintained. Since CRYPT-PW does no longer fulfill this requirements with the reasons given above, the WG also agreed to phase out CRYPT-PW. PGPKEY and X.509 have been the recommended authentication schemes for some time (http://www.ripe.net/db/support/security/security.html) MD5-PW shares two weaknesses with CRYPT-PW: passwords are sent in clear together with update requests and MD5 is vulnerable to dictionary attacks,as well. Still, MD5-PW will not be phased out together with CRYPT-PW, since at least the dictionary attack can be prevented by chosing passwords or pass phrases of appropriate length and entropy. MD5 offers a short path of migration away from CRYPT-PW without major change in processes. LIRs should, however, seriously consider a migration towards a public key based authentication scheme (PGPKEY or X.509). The MD5-PW method will be addressed separately. We propose to deprecate the CRYPT-PW authorisation step-by-step. Affected objects ---------------- There are currently ~3500 mntner objects in the RIPE Database that have only CRYPT-PW authorisation. There are about 300 mntner objects that have mixed authorisation of CRYPT-PW and some other authorisation types. Plan ---- 1. Gather mntner objects: group A: only CRYPT-PW authorisation group B: CRYPT-PW and (PGP or X509 or MD5) authorisation 1a. E-mail the contacts of those mntner objects (notify, admin-c, tech-c, mnt-nfy) to notify them about the coming change. 1b. notify the DB-WG mailing list 1 month later: 2. Modify the RIPE Database software: 1) reject any change to mntner object that adds new CRYPT-PW. 2) show a warning if CRYPT-PW was used during authorisation. 3) show a warning if object being updated still contains (existing) CRYPT-PW. 2a. E-mail the contacts of the mntner objects (notify, admin-c, tech-c, mnt-nfy) notifying them about the change and the next steps. 2b. notify the DB-WG mailing list 1 month later: 3. Modify the RIPE Database software: 1) disable CRYPT-PW in the syntax 2) disable CRYPT-PW in authorisation 3a. Modify mntner objects. group A: auth: is changed to MD5-PW, new password generated. group B: auth: CRYPT-PW is changed into "remarks" line "remarks: "your object was modified due to CRYPT-PW deprecation" is added 3b. Notify the contacts of the mntner objects: group A: explanation about the changes done, and URL with details on how to 'recover' the locked mntner object (similar to NONE deprecation process) group B: explanation about the changes done 3c. notify the DB-WG mailing list 4. Finished. -- Katie Petrusha RIPE NCC

7 9

FW: [db-wg] Proposal to deprecate CRYPT-PW authorisation in the RIPE Database
by Potapov Vladislav 05 Oct '06

05 Oct '06

Hi, Personally I don't agree with the proposal. It's wrong from several points of view. First of all, "There are currently ~3500 mntner objects in the RIPE Database that have only CRYPT-PW authorisation. There are about 300 mntner objects that have mixed authorisation of CRYPT-PW and some other authorisation types." I think the number of the objects in the DB with only CRYPT-PW authorisation shows that the method is useful and handy. Speaking about weakness... I remember the previous global deprecation of no-authorisation-at-all. The main argument was a case which involved several hundreds objects changing by an MISTAKE. I think then the deprecation was the right thing. Are there cases which involves cracking objects with CRYPT-PW authorisation? Maybe we should compare the gravity of the consequencies of leaving the authorisation scheme with complexity of mainteinance mostly informational resource? Then: "While maintaining and protecting objects in the RIPE Database is the responsibility of the respective maintainer, the RIPE DB WG agreed that it's the responsibility of the community to ensure that only appropriate tools and algortihms are used and maintained." means for me: all users of the DB are right, but the WG is more important. Am I right? Maybe we should leave the resolution of the problem to the maintainers? There are several methods of authorisation: if someone want to severe the protection of his/her objects he/she can do it right now without any modifications! I should say about one more point. For several types of organisations in Russia (for example) there are some restrictions about using encryption and keys of some sort (for example in the e-mail messages). I think the news will bring additional concerns and problems for the organisation (I think not only in Russia). Conclusion: the proposal is rather early, unreasoned and unnessesary. Kind regards, Vladislav Potapov Ru.iiat It seems that Dear colleagues, Here follows the proposal to deprecate CRYPT-PW authorisation in mntner objects in the RIPE Database. Comments would be appreciated. Background and motivation ------------------------- In the RIPE Database there are several authorisation types currently supported: CRYPT-PW, MD5-PW, PGPKEY and X509. These authorisation types define what kind of authorisation tokens can be used in "mntner" objects. CRYPT-PW authorisation type is based on UNIX crypt() functionality and is vulnerable to both dictionary and brute force attacks given the fixed password length and lack of cryptographic strength given today's computing power. While maintaining and protecting objects in the RIPE Database is the responsibility of the respective maintainer, the RIPE DB WG agreed that it's the responsibility of the community to ensure that only appropriate tools and algortihms are used and maintained. Since CRYPT-PW does no longer fulfill this requirements with the reasons given above, the WG also agreed to phase out CRYPT-PW. PGPKEY and X.509 have been the recommended authentication schemes for some time (http://www.ripe.net/db/support/security/security.html) MD5-PW shares two weaknesses with CRYPT-PW: passwords are sent in clear together with update requests and MD5 is vulnerable to dictionary attacks,as well. Still, MD5-PW will not be phased out together with CRYPT-PW, since at least the dictionary attack can be prevented by chosing passwords or pass phrases of appropriate length and entropy. MD5 offers a short path of migration away from CRYPT-PW without major change in processes. LIRs should, however, seriously consider a migration towards a public key based authentication scheme (PGPKEY or X.509). The MD5-PW method will be addressed separately. We propose to deprecate the CRYPT-PW authorisation step-by-step. Affected objects ---------------- There are currently ~3500 mntner objects in the RIPE Database that have only CRYPT-PW authorisation. There are about 300 mntner objects that have mixed authorisation of CRYPT-PW and some other authorisation types. Plan ---- 1. Gather mntner objects: group A: only CRYPT-PW authorisation group B: CRYPT-PW and (PGP or X509 or MD5) authorisation 1a. E-mail the contacts of those mntner objects (notify, admin-c, tech-c, mnt-nfy) to notify them about the coming change. 1b. notify the DB-WG mailing list 1 month later: 2. Modify the RIPE Database software: 1) reject any change to mntner object that adds new CRYPT-PW. 2) show a warning if CRYPT-PW was used during authorisation. 3) show a warning if object being updated still contains (existing) CRYPT-PW. 2a. E-mail the contacts of the mntner objects (notify, admin-c, tech-c, mnt-nfy) notifying them about the change and the next steps. 2b. notify the DB-WG mailing list 1 month later: 3. Modify the RIPE Database software: 1) disable CRYPT-PW in the syntax 2) disable CRYPT-PW in authorisation 3a. Modify mntner objects. group A: auth: is changed to MD5-PW, new password generated. group B: auth: CRYPT-PW is changed into "remarks" line "remarks: "your object was modified due to CRYPT-PW deprecation" is added 3b. Notify the contacts of the mntner objects: group A: explanation about the changes done, and URL with details on how to 'recover' the locked mntner object (similar to NONE deprecation process) group B: explanation about the changes done 3c. notify the DB-WG mailing list 4. Finished. -- Katie Petrusha RIPE NCC

2 1

RE: [enum-wg] Proposal for new org-type
by Antoin Verschuren 05 Oct '06

05 Oct '06

Marco d'Itri wrote: > On Oct 03, leo vegoda <leo(a)ripe.net> wrote: > >> Do people find org-type values like IANA, RIR, LIR and so on useful? >> No. What would be the point? As Leo pointed out: Looking back into the mail archives for 2003 and 2004 I think the original purpose was to let people know how close to the End User the registration on a block of IP addresses was. If my memory is correct, the org-type was introduced after it was felt that status attribute values like "ALLOCATED-BY-IANA" or "ALLOCATED-BY-RIR" would overburden the status attribute syntax unnecessarily. One of the possible functionality could be that you'd not like to contact certain organisations holding numberblocks when abuse comes from them since you will know these numbers are distributed in a specific fashon, and you'll probably be not reaching an end user. Don't know if such routines are used. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

1 0

RE: [enum-wg] Proposal for new org-type
by Antoin Verschuren 04 Oct '06

04 Oct '06

Niall O'Reilly wrote: > This message has two purposes. > > It is addressed to the ENUM WG with the purpose of determining > consensus in this WG on the proposal from Antoin Verschuren. To let there be no misunderstanding, the final proposal with most consensus so far is: >> In order for ENUM registries to not be misinterpreted in the RIPE >> NCC database, I want to propose to change an organization type to be >> used in the organization object. >> Current organization types are: >> >> IANA >> RIR >> NIR >> LIR >> NON-REGISTRY >> >> I would like this NON-REGISTRY to be changed to OTHER. > > I will declare consensus in the ENUM WG unless objections to Antoin's > proposal are posted on the ENUM WG mailing list before 12:00 UTC on > Thursday, 18 October 2006. Regards, Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

1 0

Re: [enum-wg] Proposal for new org-type
by leo vegoda 04 Oct '06

04 Oct '06

Hi, I cc'd the Database WG list for input on object syntax. On 3 Oct 2006, at 4:52GMT+02:00, Ondřej Surý wrote: [...] > My point was that not only ENUM registries exists in current internet. > We are .cz domain registry and while I don't have problem with > whatever > label we have in RIPE database (we do have LIR atm), we don't exactly > fall into LIR category (in it's original meaning - ie. ISP). Hence I > could easily imagine that our org-type: would be changed to > REGISTRY to > match reality a bit more. One legal entity might run an LIR, a ccTLD registry and an ENUM registry. Whether you want to identify them as a REGISTRY, a DOMAIN- REGISTRY or something else is dependent on what you want to use the org-type to tell people. Looking back into the mail archives for 2003 and 2004 I think the original purpose was to let people know how close to the End User the registration on a block of IP addresses was. If my memory is correct, the org-type was introduced after it was felt that status attribute values like "ALLOCATED-BY-IANA" or "ALLOCATED-BY-RIR" would overburden the status attribute syntax unnecessarily. Do people find org-type values like IANA, RIR, LIR and so on useful? If not, maybe we just need two values: REGISTRY for IANA, RIRs, LIRs, TLDs and Tier 1 ENUM operators and NON-REGISTRY for everyone else. However, if people really find the hierarchical distinctions in the current org-type values useful, maybe we need some additional granularity for the different kinds of domain registries? If the extra granularity is useful, perhaps we need to allow organisations to have multiple org-type values? That's probably preferable to having multiple objects for a single organisation. Thoughts? -- leo vegoda Registration Services Manager RIPE NCC

2 1

Data Protection Task Force - Ref: RIPE53 DB-WG Draft Agenda V3. item C
by Wilfried Woeber, UniVie/ACOnet 04 Oct '06

04 Oct '06

Dear Community, the logistical infrastructure for the Data Protection Task Force has been set up by the NCC. It is available at http://www.ripe.net/ripe/tf/index.html We are trying to get together a reasonably diverse mix of people for this task force, representing the various roles, activities and types of interest. The TF will be presented and discussed on Fr. morning in the DB-WG session where we will try to collect the initial population. If you can't make it to the DB-WG meeting, please indicate your interest by personal mail to Jochem de Ruig and myself. Please read up on the TF's mandate, the goals and logistics, and consider stepping forward to *actively* contribute! Thank you. See you Friday morning, Wilfried.

2 1