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

[Bill Manning <bmanning@isi.edu>]

 then perhaps the wording should be modified. Currently the statements
are "The protocol -OR- another layered protocol".  If there is no way
for the protocol to distinguish if the "other layered protocol" has 
done the work, then it MUST do it on its own.


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


-- 
--bill