[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: ietf-provreg@cafax.se
CC: hartmans@mit.edu
From: Sam Hartman <hartmans@mit.edu>
Date: Mon, 19 Mar 2001 23:54:27 -0500 (EST)
Sender: owner-ietf-provreg@cafax.se
Subject: security in draft-ietf-provreg-epp-0.txt


Hi.  I've been looking at the security implications of the current EPP
draft and I am concerned that plaintext logins are not an appropriate
authentication mechanism for this protocol.  Per section 3.2 of
draft-ietf-provreg-grrp-req-0:

 3.2 Identification and Authentication

   [1] The protocol or another layered protocol MUST provide services to
   identify registrar clients and registry servers before granting access
   to other protocol services.

   [2] The protocol or another layered protocol MUST provide services to
   authenticate registrar clients and registry servers before granting
   access to other protocol services.

   [3] The protocol or another layered protocol MUST provide services to
   negotiate an authentication mechanism acceptable to both client and
   server.


First of all, having a login element that  requires plaintext
passwords  is not standard practice in new IETF protocols.  The BEEP
framework relies on SASL which can use plaintext passwords or other
negotiated mechanisms.  Many protocols use TLS, but when they do they
allow TLS to provide both client and server authentication ; this is
true for HTTP, and for LDAP and IMAP using TLS with the SASL external
mechanism.   

Older protocols are even beting retrofitted to allow authentication
other than plaintext passwords.  SMTP  supports SASL; SMNP3 supports
security frameworks that allow arbitrary authentication.  

In all these cases, information is carried from the layer providing
the security services to the application layer.  It is not enough to
simply say that the EPP protocol will be layered within some protocol
that provides security negotiation.  That protocol might provide
authentication and authentication negotiation  but then the user still
has to login at the EPP layer under the current spec.  Thus, the
client cannot negotiate  a mechanism because whatever mechanism it
uses at the security layering protocol, it then has to in addition
use the EPP plaintext password.

At a minimum, EPP must provide a way to specify that authentication
should be imported from the layer providing security in order to meet
requirement 3 above.

However, I think  that EPP would be significantly improved if it
actually had security mechansims like SASL or TLS within the base
protocol.  One easy way to do this would be to make EPP be a BEEP
profile.


Home | Date list | Subject list