March 2002 - 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

MD5 proposal
by Andrei Robachevsky 10 Apr '02

10 Apr '02

Dear Colleagues, You may remember that at the RIPE-41 it was agreed to improve the security of password(passphrase) based auth-schemes by introducing the MD5 hash algorithm for password encryption. Please find enclosed the MD5 proposal for your comments and suggestions. Regards, Andrei Robachevsky DB Group Manager RIPE NCC Improving security of password (passphrase) based auth schemes (MD5 proposal) -============================================================================- Introduction ------------ Currently the RIPE Database implements the only password based "auth" scheme, which is "CRYPT-PW" scheme. This scheme uses an encryption process which is similar to that used to make and check login passwords in UNIX. A password is chosen by the user; this is encrypted using DEC crypt(3) and put in the database. The encrypted password can be seen by everyone. The user sends the clear password in the same mail as the request to change an object using "password:" pseudo-attribute. Motivation ---------- The main flaw of the CRYPT-PW scheme is that password is limited to 8 characters, which makes exhaustive searches of the key space possible given that crypted password is publicly available. Also the DES algorithm itself has a few quirks which lower the security of the scheme. Allowing longer keys and using more secure encryption algorithm could improve security of password-based auth scheme. Proposal -------- A new "auth:" scheme is introduced based on MD5 hash algorithm. The format of the new "auth" scheme is: auth: MD5-PW <digest> where <digest> is a 128-bit MD5 digest. For example: auth: MD5-PW 4aabd3dbc0746c8a4b5467f99a4f8524 When submitting an update to the database that needs to be authorised using this scheme, a "password:" pseudo-attribute must be used to submit a key (passphrase). Line continuation is not allowed for this attribute, so the whole key should fit on one line. If the key gets split across multiple lines this will be treated as syntax error. If the mntner that defines authorisation information for the submission has CRYPT-PW and MD5-PW "auth" schemes, the key specified by "password:" will be checked for both types.

8 14

Flap Viewer
by Fabrizio Lombardozzi 02 Apr '02

02 Apr '02

Hi ris-users, my name is Fabrizio Lombardozzi, I've developed a system to monitor inter-AS routing instabilities (route flaps) at the Computer Networks Research Group, of the Roma III University, Italy. The system retrieves BGP data from RIS, and produces interactive graphs and animations using a graph drawing engine and intuitive morphing animations, with a reasonably friendly web graphic user interface (it's an applet). I will be grateful if you could give me some comments and hopefully suggestions. At the url http://www.dia.uniroma3.it/~compunet/ you will find detailed instructions to start the applet and also a gallery with screenshots and animations. Thanks in Advance Fabrizio

2 2

Re: Deprecation of the MAIL-FROM auth scheme
by Christoph Kuhles / Aquatix RIPE services 01 Apr '02

01 Apr '02

Dear Andrei & list, talking about a secure database, I wonder why the crypted password is shown when using CRYPT-PW as authentication scheme? While it might take long to get the clear-text password using brute force or dictionary attacks, it is still possible. Why not patch the whois server so it doesn't show the crypted password and hence make hijacking of objects impossible by bruteforcing a maintainer password? Best regards Christoph Kuhles Managing Director Aquatix IT-Services e.K. Monday, March 25, 2002, 1:58:10 PM, you wrote: AR> Please find enclosed the migration plan to a more secure database.

1 0

Re: Deprecation of the MAIL-FROM auth scheme
by Janos Zsako 01 Apr '02

01 Apr '02

> From owner-db-wg(a)ripe.net Mon Mar 25 13:58:43 2002 > From: Andrei Robachevsky <andrei(a)ripe.net> Andrei, > In case a mntner contains only one "auth" scheme, which is MAIL-FROM, it > will be replaced with a CRYPT-PW scheme with a DES string that cannot be > matched. Why don't you add "CRYPT-PW azsLXaNunJ9Rs", which is the auth of RIPE-NCC-HM-MNT? This way the hostmaster team could easily update a mntner object when the "authorized and authenticated" maintainer shows up and asks you to perform the update ("authorized and authenticated" above refers to the procedure you have in place for dealing with such cases.) Best regards, Janos PS. Otherwise, I guess you need a special mechanism to update such "orphaned" maintainers...

1 0

Re: MD5 proposal
by Janos Zsako 01 Apr '02

01 Apr '02

> From owner-db-wg(a)ripe.net Mon Mar 25 14:29:46 2002 > From: Engin Gunduz <engin(a)ripe.net> > > Let's suppose I send in a message with > > password: Hello > > (note the three spaces). > > > > It is not clear to me where the passphrase would start. I can think of > > two valid approaches: > > 1. At the first character after the first white space (space or tab) > > following the colon (":") (in my example the passphrase would be then > > " Hello"). > > 2. At the first non-whitespace character after the colon (in which case > > the passphrase would be "Hello"). > > > > I think I would vote for the second approach which is more intuitive > > to me. BTW: how does this work with CRYPT-PW? I would think it is the > > second approach. > > Yes, the current approach is the second one. This implicitely > prohibits the use of white space as the first characters of the > password but probably this is less confusing for the users then > having the behaviour you defined in 1. > I don't think this is documented. We'll make sure it will > be in the user manual, and in reference document if > necessary. Great! Thanks. Best regards, Janos

1 0

Re: MD5 proposal
by Engin Gunduz 01 Apr '02

01 Apr '02

Hi Janos, On Mon, 25 Mar 2002, Janos Zsako wrote: > > From owner-db-wg(a)ripe.net Mon Mar 25 13:26:38 2002 > > Dear Andrei, > > > Please find enclosed the MD5 proposal for your comments and suggestions. > > Great! > > One small comment, probably need for clarification. > > > When submitting an update to the database that needs to be authorised using > > this scheme, a "password:" pseudo-attribute must be used to submit a key > > (passphrase). Line continuation is not allowed for this attribute, so the > > whole key should fit on one line. > > Let's suppose I send in a message with > password: Hello > (note the three spaces). > > It is not clear to me where the passphrase would start. I can think of > two valid approaches: > 1. At the first character after the first white space (space or tab) > following the colon (":") (in my example the passphrase would be then > " Hello"). > 2. At the first non-whitespace character after the colon (in which case > the passphrase would be "Hello"). > > I think I would vote for the second approach which is more intuitive > to me. BTW: how does this work with CRYPT-PW? I would think it is the > second approach. Yes, the current approach is the second one. This implicitely prohibits the use of white space as the first characters of the password but probably this is less confusing for the users then having the behaviour you defined in 1. > > Best regards, > Janos > > PS: I apologize if this is specified somewhere. I don't think this is documented. We'll make sure it will be in the user manual, and in reference document if necessary. Best regards, Engin Gunduz RIPE NCC Database Group

1 0

Re: MD5 proposal
by Janos Zsako 01 Apr '02

01 Apr '02

> From owner-db-wg(a)ripe.net Mon Mar 25 13:26:38 2002 Dear Andrei, > Please find enclosed the MD5 proposal for your comments and suggestions. Great! One small comment, probably need for clarification. > When submitting an update to the database that needs to be authorised using > this scheme, a "password:" pseudo-attribute must be used to submit a key > (passphrase). Line continuation is not allowed for this attribute, so the > whole key should fit on one line. Let's suppose I send in a message with password: Hello (note the three spaces). It is not clear to me where the passphrase would start. I can think of two valid approaches: 1. At the first character after the first white space (space or tab) following the colon (":") (in my example the passphrase would be then " Hello"). 2. At the first non-whitespace character after the colon (in which case the passphrase would be "Hello"). I think I would vote for the second approach which is more intuitive to me. BTW: how does this work with CRYPT-PW? I would think it is the second approach. Best regards, Janos PS: I apologize if this is specified somewhere.

1 0

Deprecation of the MAIL-FROM auth scheme
by Andrei Robachevsky 25 Mar '02

25 Mar '02

Dear Colleagues, Another issues that was discussed at the RIPE-41 meeting is deprecation of a MAIL-FROM authentication scheme. It was agreed that the weakness of this auth form does not allow to provide real protection to the database objects and it should be deprecated. As a matter of fact recently we had to deal with several incidents when objects were hijacked using the flaw of the MAIL-FROM. It took time and resources from the ripe-dbm to investigate the matter and restore the objects, to say nothing about possible damage to the owners of such objects should the incident has gone unnoticed. Please find enclosed the migration plan to a more secure database. Your comments are welcome. Regards, Andrei Robachevsky DB Group Manager RIPE NCC Deprecation of MAIL-FROM authentication and authorisation scheme (auth scheme) ============================================================================== Motivation ========== This authentication method checks the content of the RFC2822 From: header of an update request against the regular expression specified as <auth-info> field of the "auth:" attribute. If the regular expression matches the content of the From: header the update request is authenticated successfully. The matching is applied to the whole content of the From: header including comments if present. No attempt is made to isolate the mailbox part. This authentication scheme is very weak. Forging RFC2822 headers can be done very easily. With the existence of more secure "auth" schemes in the RIPE Database, it does not make much sense to support it any more. Currently 41% (~2700) of all mntner objects in the RIPE Database are using this weak "auth" scheme. Though NONE "auth" scheme is even weaker it is not supposed to be consciously used for object protection, but rather as notification facility. Therefore NONE "auth" scheme is outside the scope of this proposal. Transition phases ================== I Notifying mntners with MAIL-FROM auth scheme ----------------------------------------------- An announcement presenting this proposal and encouraging the owners of the mntners to remove MAIL-FROM auth scheme from their objects will be send. The distribution list will be compiled from e-mail addresses listed in "upd-to:", "mnt-nfy:" attributes of the mntners, as well as using contact information (e-mail) from "admin-c:" and "tech-c:" references. II Rejecting updates for mntner objects containing MAIL-FROM auth scheme ------------------------------------------------------------------------- An update of a mntner object will be rejected if the new version of the mntner contains MAIL-FROM auth scheme. This will be reported as a syntax error in the "auth:" attribute. III Rejecting using the MAIL-FROM auth scheme for authorisation --------------------------------------------------------------- When processing an update for an object protected by a mntner that contains MAIL-FROM auth scheme, this scheme will be ignored. That means that if mntner defines other auth schemes different from MAIL-FROM, the credentials relevant to these schemes may be used. If the only auth scheme defined is MAIL-FROM, no update can be authorised by such mntner. In case of failure the acknowledgement will indicate that MAIL-FROM "auth" scheme is not valid any more. IV Cleanup ---------- The mntners still containing "auth:" attribute with the MAIL-FROM auth scheme will be modified so that such attributes will be removed from the objects. Before this a final call will be sent to the owners of these mntners ("upd-to:", "mnt-nfy:" attributes of the mntners, as well as to the contacts from "admin-c:" and "tech-c:" references). A "remarks:" attrubute will be added with clear explanation of the situation. In case a mntner contains only one "auth" scheme, which is MAIL-FROM, it will be replaced with a CRYPT-PW scheme with a DES string that cannot be matched.

2 1

Re: Deprecation of the MAIL-FROM auth scheme
by Janos Zsako 25 Mar '02

25 Mar '02

> From owner-db-wg(a)ripe.net Mon Mar 25 13:58:43 2002 > From: Andrei Robachevsky <andrei(a)ripe.net> Andrei, > In case a mntner contains only one "auth" scheme, which is MAIL-FROM, it > will be replaced with a CRYPT-PW scheme with a DES string that cannot be > matched. Why don't you add "CRYPT-PW azsLXaNunJ9Rs", which is the auth of RIPE-NCC-HM-MNT? This way the hostmaster team could easily update a mntner object when the "authorized and authenticated" maintainer shows up and asks you to perform the update ("authorized and authenticated" above refers to the procedure you have in place for dealing with such cases.) Best regards, Janos PS. Otherwise, I guess you need a special mechanism to update such "orphaned" maintainers...

1 0