Dear Michael, Thank you very much for the suggestion and the write-up on what the use of the proposed mechanisms c/would be. First of all, cc:ing the WG list is to distribute your comments, as they are very appropriate and useful for the on-going discussions on improving security in the registry operations. Secondly I'd like to (briefly) address a couple of comments: The WG has already been chartered to work on a more up-to-date document as to which security mechanisms should be recommended. The common understanding is that anything weaker than digital signatures should be strongly dicouraged, exactly for the reasons you were giving. Still has to find it's way into a document. All the other mechanism should be phased out in due time - at least for any objectof "value". The other aspect, as to *which* particular mechanism or product should be used, is up for discussion and for consensus amongst the users of the RIPE DataBase. Initially, the recommendation from the TaskFore on DB Security was to go for PGP as the *first* mechanism to implement. At the same time we understood that PGP w/sh/could not be the *only* mechanism in the long run. Meanwhile the DB software re-implementation is close to being completed, GNU Privacy Guard has become available, and I'm sure things like S/MIME should be looked at. Actually, this might be a reason to revive the TF-SEC later this year? Please continue to participate in this discussion, and whenever you can, to pop in during one of the DB working group meetings. Regards, Wilfried. ______________________________________________________________________ From: mcb@cloanto.com To: "'Wilfried Woeber'" <Woeber@CC.UniVie.ac.at> Subject: Thoughts about authentication schemes Date: Fri, 12 May 2000 07:41:44 -0700 Hello, I just had an exchange of ideas with Marek Bukowy of RIPE Database Administration, and he suggested that I submit this to your attention before the RIPE 36 meeting. Basically, I was setting up CLOANTO-MNT, and looking at the authentication options I somehow wondered why there isn't something like a "MAIL-TO". As the recent case of fraud suffered by Network Solutions shows, MAIL-FROM can too easily be circumvented. This week even our company in Italy had to file criminal charges against an entity who forged email headers, using one of our domain names. This was a case of "spamming", but it could just as easily have been an episode of MAIL-FROM fraud. So I looked at CRYPT-PW, and searching for a tool to generate the encrypted password I quickly found out that an 8-character password, as is used by RIPE, can be un-encrypted in a matter of days, if not hours. Now, as documents like ripe-157 express (e.g. "It is very difficult to keep the information confidential and thus the RIPE NCC cannot take this responsibility."), RIPE is concerned about both security and responsibilities, and here we have a case where it is known that two authentication schemes are not secure, and thus somebody might even object that, given today's standards and knowledge, maybe their status of being qualified to serve as "authentication" could be challenged. True, there now is PGP, which IMHO is technically uncompromising for this purpose. In theory it has legal limitations in a few countries, but not any I am aware of in the RIPE area. PGP however can be pretty... complex to set up compared to an email-only authentication scheme. Not that I see PGP as being unreasonably complex, but apparently, if people still prefer MAIL-FROM or CRYPT-PW, they must have their practical reasons for doing so. PGP also expresses a "political" choice in a field where other "official" standards would tend towards S/MIME, X.509, etc. For this reason I would like to go back, with my consideration, to a possibly new, simple, yet more secure authentication method (compared to MAIL-FROM) which does not use any encryption, and which can therefore be quickly used with any email client. As such, maybe it could be one choice more to offer, and in the long term it could maybe become part of a more robust set of minimum standards. The way I thought of "MAIL-TO" is basically like MAIL-FROM, but the server (e.g. you), after receiving a request from one of the authorized "MAIL-TO" addresses, would send back to the same address a "magic number" (or alphanumeric data) to the sender, who would have to reply (quoting this data anywhere in the email body, even possibly with "> " etc. at the beginning of each line), and only after the reply the request would be accepted. This data would have both a unique part (no risk of duplicates) and a pseudo-random one (no practical way to guess it). In this way, "MAIL-TO" would formally verify that the sender has access to the given email address, in such a way as has been adopted in everyday practice for years by companies such as VeriSign and Thawte for the distribution of email and web certificates. It is true that a possible "MAIL-TO" scheme would be open to sniffing, but MAIL-FROM and CRYPT-PW also are, and the data which is transmitted is not sensitive by definition, as RIPE itself says it prefers not to take responsibility for securing sensitive data, and the data usually ends up in a whois database anyway. Also, "MAIL-TO" would indeed require one more step than "MAIL-FROM". This is in my opinion the small price to pay if one prefers not to use full encryption or digital signing. Yes, I think it would be only one more step, because in my experience, where MAIL-FROM is implemented, two or three steps (not one) are already required, because the second part of the system involves that a preset address receives a notification of the change request. This is not subject to confirmation (as would be in "MAIL-TO"), but it is nevertheless a second step, and it requires attention and readiness for a possible third step ("CANCEL" action) in case an abuse is detected. So on one hand we have one step more (or zero steps more in case of abuse), but on the other hand we get peace of mind. The reply mechanism could even be implemented in an automatic way on the side of the data submitter. Well, this now got a bit more lengthy than I intended it to be, sorry about that! It's just that I felt the need for such an option, and I would not like to see what happened to Network Solutions also happen to you, or to one of the national NICs who adopt your guidelines, especially knowing that forging email headers happens everyday, and that it has already happened in a major case involving a major registration authority. Thanks for caring, and I wish you a nice time in Budapest! Regards, Michael C. Battilana --------------------------------------------------------------------------------