ietf
[Top] [All Lists]

Re: Gen-ART last call review of draft-ietf-emu-eaptunnel-req-08

2010-11-28 23:42:07
Hi Roni,

Sorry I missed your first message, thank you for resending it.    Comments in 
line below:

Cheers,

Joe

On Nov 27, 2010, at 11:34 PM, Roni Even wrote:

Hi,
I sent the following review on October 25th but did not see and response.
 
Roni Even
 
 
 
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, 
please see the FAQ at 
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
 
Please resolve these comments along with any other Last Call comments you may 
receive.
 
Document: draft-ietf-emu-eaptunnel-req-08
Reviewer: Roni Even
Review Date:2010–10–25
IETF LC End Date: 2010–11–10
IESG Telechat date:2010-12-2
 
Summary: This draft is almost ready for publication as an Informational RFC.
 
Major issues:
 
Minor issues:
1.       In section 2  why not reference RFC 2119 or at least  copy the 
definition from RFC 2119 for  the capitalized term.


[Joe] We followed the convention used in RFC 5209 (NEA protocol requirements), 
because this document is defining requirements rather than the protocol itself. 
 

2.       In section 3.9 when you say “if this technique is used”, by this do 
you mean certificate –less or the flow defined in the previous sentence.



[Joe] "if this technique is used" refers to certificatel-less authentication 
using the inner EAP method for client authentication without server 
authentication.   Perhaps the following sentence would be clearer:

"If an inner EAP method is used for client authentication without full server 
validation the inner method MUST provide
   resistance to dictionary attack and a cryptographic binding between the 
inner method and the tunnel method MUST be established. ..."

Does this help? 

3.       In section 4.6.3 the first paragraph defines the requirements for 
Cryptographic Binding. It looks to me like the rest of the section talks 
about a specific use case, so why is it in the requirements section and not 
in section 3.

[Joe]  The majority of section 4.6.3 discusses a possible mechanism to achieve 
cryptographic binding.  While it is not specifically a requirement I think it 
supports the requirement defined in the first paragraph.  I do not think it 
belongs in the use case section.  


 
 
 
Nits/editorial comments:
 
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf