RE: security in draft-ietf-provreg-epp-0.txt

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

I suspect that negotiation failures in lower layered protocols should be
managed and contained in the layer(s) at which they occur.  If a fatal error
occurs in a lower layer, the provreg base protocol layer shouldn't be
instantiated.  Thus, if it is instantiated it can assume that all lower
layer processing has been completed successfully.

<Scott/>

-----Original Message-----
From: Bill Manning
To: hartmans@mit.edu
Cc: ietf-provreg@cafax.se; hartmans@mit.edu
Sent: 3/20/01 10:38 AM
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