This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
[db-wg] Filtering auth: attributes in the whois server (was: Re: Suggestion...)
- Previous message (by thread): [db-wg] RIPE Database Access Control
- Next message (by thread): [db-wg] Filtering auth: attributes in the whois server (was: Re: Suggestion...)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Havard Eidnes
he at uninett.no
Wed Mar 7 12:07:00 CET 2012
Hi, I'm following up on the "how to get at your complete maintainer object" case which was the subject of this thread. I've had a private discussion with the people manning the ripe-dbm at ripe.net role, and this is the information which has been revealed so far: The current implementation of the filtering in the RIPE whois server is such that *all* auth: attributes are removed from all maintainer objects, as we have all seen. As a LIR in the category who only use PGP auth: lines in our maintainer object (we're one of the 16% of all maintainers who are in the category "have either not used MD5-passwords or have abolished doing so"), I may still get at my full maintainer object without using any password. However, it has been confirmed that now I *do* have to use the web interface. I have to visit http://www.ripe.net/webupdates/ and activate the "Modify object in single text area" option before looking up my maintainer object. I'll then have to cut and paste this into whatever I use to update my maintainer object (in my case: my e-mail client). So... It is confirmed: this is forcing us to use the web interface to look up our maintainer object, where we could use the whois protocol earlier, something I'm unhappy about. I suggested to the RIPE NCC that instead of following the current implementation strategy, they could have followed the following strategy: In the whois server, if a maintainer object *only* contains auth: lines using currently deemed to be secure methods (currently PGP or X.509), then reveal all the auth: lines to the whois client. Otherwise, if the maintainer object contains one or more lower-security auth: attribute (currently MD5-based passwords), filter out *all* the auth: attributes. This would not require a behavioural change from those LIRs who have "done the right thing" and abolished MD5-encrypted passwords (or never even used them), instead of punishing us by forcing us to use the web interface when updating our maintainer objects. The complication that the RIPE NCC sees with this solution is that this would make it more difficult to explain what procedures need to be followed to update a maintainer object. My claim is that whois + e-mail if you do the right thing (only use PGP or X.509) and use web-updates if you do the wrong thing and use MD5 passwords is no more difficult to explain than the current situation, and as a bonus it does not punish LIRs who have already done the right thing and abolished MD5-based passwords. The RIPE NCC also basically said "this is what the community agreed to at the RIPE-63 meeting", and that if a change should come, the community should agree to it. Therefore I am bringing this matter to the RIPE database working group for discussion. My proposal is the alternative implementation strategy quoted above. Best regards, - Håvard
- Previous message (by thread): [db-wg] RIPE Database Access Control
- Next message (by thread): [db-wg] Filtering auth: attributes in the whois server (was: Re: Suggestion...)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]