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


To: hartmans@mit.edu (Sam Hartman)
Cc: ietf-provreg@cafax.se, hartmans@mit.edu
From: Bill Manning <bmanning@isi.edu>
Date: Tue, 20 Mar 2001 07:38:07 -0800 (PST)
In-Reply-To: <200103200454.XAA13203@sweet-transvestite.mit.edu> from "Sam Hartman" at Mar 19, 2001 11:54:27 PM
Sender: owner-ietf-provreg@cafax.se
Subject: Re: 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.  

	Where, in the above quoted sections, is there a requirement
	for plaintext passwords?


% 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.

	if we change the wording in your question to:
	" ... imported from the layer providing authentication and integrity
	in order ..." then it seems to be nearly identical to #3.

	I would like to see a refinement of how the protocol is going to
	determine when/how "another layered protocol" has failed to perform
	the tasks of a) identifying "authentic" clients/servers vs. imposters.
	see #1; b) authenticating client/server systems, see #2; and 
	c) negotiation of integrity checks for clients/servers, see #3
	
	One the protocol has determined a failure has occured, how does it
	negotiate to assume for itself these tasks, and then how does the
	protocol determine that the "other layered protocol" has recovered
	and it needs to stop performing these checks since there is now
	another entity performing them on its behalf.

	Scott, any comments?

--bill

Home | Date list | Subject list