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

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

No problem here - thanks for the clarification!
 
-Scott-


________________________________

	From: Catherine Meadows [mailto:[e-mail]] 
	Sent: Wednesday, July 08, 2009 12:02 PM
	To: Hollenbeck, Scott
	Cc: Catherine Meadows; [e-mail]; [e-mail]
	Subject: Re: review of draft-hollenbeck-rfc4933bis-02
	
	
	My apologies!  I should have read RFC 4953 first.  The I-D
tracker is still giving me a 404, 
	but I was able to find it on the tcpm WG website.

	What RFC 4953 discusses is a specific vulnerability in TCP,
which involves the fact that reset sequence (RST) numbers can cycle
through quickly in large windows,
	and they make the protocol vulnerable to spurious resets from
attackers in that case.  So this really is a TCP issue, and I agree that
the TCP mapping document in the appropriate place for
	this if there is an issue, which would depend on the window
size. 

	My apologies again for typing without reading first, and for
introducing such a red herring.  My interpretation of "channel binding
attack" in this context was no where near the mark.
	I now no longer believe that there are any further changes to be
made to this document.

	Also, somebody needs to fix the ID tracker.  My attempt to find
4934 wound up in a 404 too.

	Cathy

	On Jul 7, 2009, at 3:52 PM, Hollenbeck, Scott wrote:


		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]



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