Thoughts about authentication schemes

  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 at cloanto.com
To: "'Wilfried Woeber'" <Woeber at 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
--------------------------------------------------------------------------------