Re: [secdir] review of draft-hollenbeck-rfc4933bis-02

["Hollenbeck, Scott" <[e-mail]>]

I made this statement in my response to Sandy:
 
"I would need more specific information to know if there's something to
be done with this comment. Reliance on security mechanisms provided at
the transport layer has been part of this specification since day one. I
am not aware of any implementation issues."
 
There was no follow-up, so I remain a little unsure of how to address
the comment.  Similarly, I need a clarification to know if the text
change suggested below is best made in 4933bis.
 
There's a separate document that addresses EPP transport over TCP.  If
the channel binding issue is primarily an issue with TCP (is it?), I'd
prefer to address it in the TCP mapping document (4934bis).  If it's
more focused on the application-layer exchange of authorization
information I'm OK with making the text change suggested below in
4933bis.  I should note that the same text exists in 4931bis so I'd need
to change it there as well.
 
So - where is the most appropriate place to add text?
 
-Scott-


________________________________

	From: Catherine Meadows [mailto:[e-mail]] 
	Sent: Monday, July 06, 2009 11:53 AM
	To: [e-mail]; [e-mail]; Hollenbeck, Scott
	Cc: Catherine Meadows
	Subject: review of draft-hollenbeck-rfc4933bis-02
	
	
	I have reviewed this document as part of the security 
	directorate's ongoing effort to review all IETF documents 
	being processed by the IESG. 
	These comments were written primarily for the benefit of the 
	security area directors.  Document editors and WG chairs 
	should treat these comments just like any other last call
comments. 

	Quote from last review:
	

	"The draft updates RFC 4933, the EPP Contacts Mapping spec.  
	The updates listed are relatively minor - updates to 
	references and a few minor updates to text."

	Version 1 has reviewed recently (June 10, by Sandy Murphy) and
the author already
	made the changes that were agreed upon in following discussion.

	Everything mostly looks OK to me, but there is one issue that
never got completely resolved
	as far as I can tell from what I saw online.  This is the
question of channel binding issues as described
	RFC 4953.  I'm having trouble accessing that document right now,
but apparently the issue is that
	low-level authentication mechanisms will not provide any
distinction between channels at a higher level.
	This can make it possible for someone with access to the
authentication mechanisms to spoof different channels.
	In particular, if the EPP authorization information is protected
with lower-level authentication mechanisms this could
	be the case.  Unless there is good reason to believe that this
sort of attack is impossible (in which case it would
	be a good idea to say why) it might be good 
	that 


			Both client and server MUST ensure that
authorization
			

			   information is stored and exchanged with
high-grade encryption
			

			   mechanisms to provide privacy services.


	be changed to

	Both client and server MUST ensure that authorization
	   information is stored and exchanged with high-grade
encryption
	   mechanisms to provide privacy and authentication services at
the appropriate level
	of granularity.


	
	Catherine Meadows
	Naval Research Laboratory
	Code 5543
	4555 Overlook Ave., S.W.
	Washington DC, 20375
	phone: [phone]
	fax: [phone]
	email: [e-mail]