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

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

I don't have an issue with adding appropriate text to 4934bis.  Help in
coming up with something that's appropriate would be appreciated.
 
I'm a little concerned about adding text to 4930bis unless the text is
generic enough to apply to all potential transport protocols.  A
specific addition proposal would be very helpful.
 
-Scott-


________________________________

	From: Polk, William T. [mailto:[e-mail]] 
	Sent: Wednesday, July 15, 2009 1:59 PM
	To: Sandra Murphy; Hollenbeck, Scott
	Cc: Catherine Meadows; [e-mail]; [e-mail]; Nicolas
Williams
	Subject: Re: [secdir] review of draft-hollenbeck-rfc4933bis-02
	
	
	I'm a little late to the party, but I have been quietly mulling
over this problem as well.  Now that Sandy has explicitly asked for an
AD to step in, I figured I should participate more actively.  I have
also added Nico Williams to the CC list (my apologies, Nico) since
channel bindings is really his area of expertise.
	
	I think there is a real need for channel bindings with some
applications of EPP, but may not always be strictly necessary in other
cases.  For example, the e-Automation project for the administration of
DNS root zone uses EPP but if I recall correctly most of the objects
that are transferred are digitally signed objects.  In this case,
channel bindings are perhaps less important since we aren't relying
solely on the EPP authentication mechanism.  So, in my opinion we should
encourage their use but should not require channel bindings.  
	
	However, if the application is relying on EPP in combination
with transport for security, channel bindings would provide
significantly enhanced security.  That says channel bindings deserves to
be mentioned and a little guidance on (1) implementing channel bindings
and (2) determining when channel bindings is required.  That begs a new
question of course - where does this information go?
	
	I am starting to believe that the security considerations
section of 4930bis should note that enhanced security SHOULD be achieved
through channel bindings unless the application involves digitally
signed objects, and that the TLS usage section of 4934bis (section 9)
should include a pointer to techniques for implementing channel bindings
with TLS.  I am still mulling this over, and will probably not enter any
discuss until tomorrow, but this seems the best approach.  (Hopefully
Nico will weigh in before then and keep me straight on this one...)
	
	Tim Polk
	
	
	On 7/15/09 10:51 AM, "Sandra Murphy" <[e-mail]> wrote:
	
	

		(Note to all.  I sent multiple secdir related messages
yesterday
		afternoon, and they all were mangled or ultimately not
delivered.  So this
		is a repeat that some og the recipients may already have
seen.
		Apologies for the technology failure.)
		
		
		
		On Tue, 7 Jul 2009, Scott Hollenbeck said:
		
		
		>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.
		
		Yes, I am guilty of not following up.  I was unsure of
my understanding
		of channel binding issues, none of the other reviewers
of the rfc493*
		suite made any notice of the issue, and, as you note
here, the
		issue is really in the base spec, not 4933.  I just had
no idea
		what the right process would be, if any.
		
		Subsequent discussion and review of material make me
more confident
		that there is, indeed, a channel binding issue here.
		
		The question is what to do about it.  This is an
established protocol.
		Would a security considerations section in 4930bis that
pointed out
		that there's a MITM attack possible here, because of the
lack of
		channel binding, be sufficient?  Or would pointing to
the sasl-gs2
		work as a protection be mentioned?  suggested?
mandated?
		
		I sure would love to see AD or subject matter experts
weigh in here
		on the technical and process aspects of this.
		
		--Sandy