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

[Catherine Meadows <[e-mail]>]

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]