Database development plans
Dear colleagues, Please find below a list of the projects that we included in our development plan. We would appreciate if you could indicate importance and usefullness of specific projects so we can adjust their priorities. Several more detailed proposals will follow. Here I just included brief description of the projects not to enter premature implementation discussion. Regards, Andrei Robachevsky DB Group Manager RIPE NCC 1. Authorisation checks across multiple databases Migration to v3/RPSL made creating objects in the routing registry a much more complex process due to the introduction of the Routing Policy System Security (RFC 2725). The real problem was with so called "foreign" route objects that either announce non-RIPE address space or are originated from non-RIPE ASN. As there were no corresponding objects in the RIPE database such transactions failed. A workaround is in place now that requires duplication of objects in the RIPE RR and as a result - low security level. The proposed solution is to get this information from sources that contain authoritative information about network objects that are supposed to authorise the transaction. For example, when creating a route from APNIC's address space, but originated from a RIPE ASN, authorisation information will be requested from both RIPE and APNIC sources. 2. Real-time (interactive) updates Currently only e-mail updates are supported by the RIPE Database which complicates automation of the update process at the clients side. The facility that will allow connection oriented interactive, or real-time updates, will simplify development of the client tools and make synchronising of LIR's address management database an easier task. Once implemented this project will present a facility for other tools, such as web-based update interface, or a standalone syntax checker. 3. Automatic cleanup of unreferenced person objects You may find the initial proposals: http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00079.html http://www.ripe.net/ripe/mail-archives/db-wg/20010701-20020101/msg00092.html The problem statement and the solution remains almost the same, with some modifications: - cleanup process is based on internal DB data, rather than object attributes or meta-attributes - "holders" of the objects to be deleted are notified n days before using standard DB notification mechanisms. 4. Further development of the database software - Improving error reporting - Improving server performance - Software portability and configuration 5. Improve database security These ideas were discussed at the RIPE-41, the detailed proposals will follow - Deprecate MAIL-FROM as a weak auth scheme that doesn't serve todays's security requirements. This will be done in several phases starting form not allowing updating mntner objects containing this scheme, and ending with not allowing updates to be authorised with MAIL-FROM. - Implement authentication scheme using MD5 as a more secure mechanism compared to crypt. Passphrases can be used instead of 8 character passwords and MD5 fingerprint will be presented in the auth value. - Implement inverse queries on auth, encryption, signature for PGP keys only (key-cert's).
5. Improve database security
These ideas were discussed at the RIPE-41, the detailed proposals will follow - Deprecate MAIL-FROM as a weak auth scheme that doesn't serve todays's security requirements. This will be done in several phases starting form not allowing updating mntner objects containing this scheme, and ending with not allowing updates to be authorised with MAIL-FROM. - Implement authentication scheme using MD5 as a more secure mechanism compared to crypt. Passphrases can be used instead of 8 character passwords and MD5 fingerprint will be presented in the auth value. - Implement inverse queries on auth, encryption, signature for PGP keys only (key-cert's).
As an alternative to deprecating MAIL-FROM, have you considered sending a response to updates with a random cookie in it and requiring a confirmation message with the cookie? In regards to the MD5 fingerprint, would this be a straight MD5 hash, or something like the FreeBSD MD5-based password hash (which I believe supports passwords longer than 8 chars)? Also, would the hash continue to be openly published? It would seem you would still have to deal with potential dictionary attacks. I understand the Perl-based RIPE server would use a "*" in place of the actual crypt-pw and I've been considering adding support for this in IRRd. Also, I would suggest reading the following paper regarding the strength of traditional Unix crypt, FreeBSD's MD5-based crypt, and OpenBSD's Blowfish- based bcrypt -- http://www.usenix.org/events/usenix99/provos.html Regards, Larry Blunk Merit
Larry, On Tue, Jan 29, 2002 at 05:31:30PM -0500, Larry J. Blunk wrote:
As an alternative to deprecating MAIL-FROM, have you considered sending a response to updates with a random cookie in it and requiring a confirmation message with the cookie?
I like this suggestion.
In regards to the MD5 fingerprint, would this be a straight MD5 hash, or something like the FreeBSD MD5-based password hash (which I believe supports passwords longer than 8 chars)? Also, would the hash continue to be openly published? It would seem you would still have to deal with potential dictionary attacks. I understand the Perl-based RIPE server would use a "*" in place of the actual crypt-pw and I've been considering adding support for this in IRRd.
In my ISI/RPSL/6bone version of the perl server (=not the official RIPE version of the perl software) the crypt-pw is indeed not shown upon query or in the downloadable database files. I hope this helps, David K. ---
At 15:08 -0800 29/1/02, David Kessens wrote:
Larry,
On Tue, Jan 29, 2002 at 05:31:30PM -0500, Larry J. Blunk wrote:
As an alternative to deprecating MAIL-FROM, have you considered sending a response to updates with a random cookie in it and requiring a confirmation message with the cookie?
I like this suggestion.
I think this is both complicated (for the user) and messy (for the server) while not addressing the real issue. MAIL-FROM authentication is just "no authentication", no matter how you look at it. Cookies are really easy to intercept and with rate of updates a server like the RIPE whois server has, keeping track of thousands of cookies doesn't seem to see a reasonable solution if you take into account the additional protection it offers. Also remember that people with automatic scripts to handle their objects would need to adopt them to the new model.
In regards to the MD5 fingerprint, would this be a straight MD5 hash, or something like the FreeBSD MD5-based password hash (which I believe supports passwords longer than 8 chars)? Also, would the hash continue to be openly published? It would seem you would still have to deal with potential dictionary attacks. I understand the Perl-based RIPE server would use a "*" in place of the actual crypt-pw and I've been considering adding support for this in IRRd.
In my ISI/RPSL/6bone version of the perl server (=not the official RIPE version of the perl software) the crypt-pw is indeed not shown upon query or in the downloadable database files.
This is clearly a community decision. I would suggest that if MD5 is implemented as an additional method, strings bigger than 8 characters are a necessity (and it is really easy to do so with MD5). The extra length makes it really difficult to have dictionary attacks if properly used (I mean you can use a file with the complete works of shakespeare when generating the MD5 hash) Joao
I hope this helps,
David K. ---
--
At 15:08 -0800 29/1/02, David Kessens wrote:
Larry,
On Tue, Jan 29, 2002 at 05:31:30PM -0500, Larry J. Blunk wrote:
As an alternative to deprecating MAIL-FROM, have you considered sendin
g
a response to updates with a random cookie in it and requiring a confirmation message with the cookie?
I like this suggestion.
I think this is both complicated (for the user) and messy (for the server) while not addressing the real issue. MAIL-FROM authentication is just "no authentication", no matter how you look at it. Cookies are really easy to intercept and with rate of updates a server like the RIPE whois server has, keeping track of thousands of cookies doesn't seem to see a reasonable solution if you take into account the additional protection it offers. Also remember that people with automatic scripts to handle their objects would need to adopt them to the new model.
I still feel that MAIL-FROM with cookie confirmation is considerably better than "no authentication". I don't see how a cookie is really any easier to intercept than a password or secret string sent in the clear. It also doesn't suffer from potential dictionary cracking attacks. While it is clear that user's will find it more complicated than the current MAIL-FROM, I could still envisage some preferring it over passwords/PGP-KEYs. I checked out majordomo's cookie confirmation code and found that the cookie generation uses a hash of a secret string, the user's email address, and the requested command. Thus the server does not need to keep any cookie state. One could include a timestamp in the cookie hash generation and confirmation message to help guard against replay's. Finally, I would imagine that those who are using automatic scripts would migrate to passwords or (preferably) PGP.
In regards to the MD5 fingerprint, would this be a straight MD5 hash,
or
something like the FreeBSD MD5-based password hash (which I believe suppo rts passwords longer than 8 chars)? Also, would the hash continue to be openly published? It would seem you would still have to deal with potential dictionary attacks. I understand the Perl-based RIPE server would use a "*" in place of the actual crypt-pw and I've been considering adding support for this in IRRd.
In my ISI/RPSL/6bone version of the perl server (=not the official RIPE version of the perl software) the crypt-pw is indeed not shown upon query or in the downloadable database files.
This is clearly a community decision. I would suggest that if MD5 is implemented as an additional method, strings bigger than 8 characters are a necessity (and it is really easy to do so with MD5). The extra length makes it really difficult to have dictionary attacks if properly used (I mean you can use a file with the complete works of shakespeare when generating the MD5 hash)
Having a hash/signature generator that checks for password goodness would definitely be a big help. In addition to a minimum of 8 characters, I'd also suggest mandating some number of non-alphanumeric characters. Regards, Larry
participants (4)
-
Andrei Robachevsky -
David Kessens -
Joao Luis Silva Damas -
Larry J. Blunk