Subject: [Gen-art] Gen-ART last call review of draft-ietf-emu-eaptunnel-req-08

From: "Roni Even" <[email-masked]>
Date: Sun, 28 Nov 2010 09:34:45 +0200

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.

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.

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. 

Nits/editorial comments:

---

From: Joe Salowey <[email-masked]>
Date: Sun, 28 Nov 2010 21:42:01 -0800

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:

> 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.
>  
> Review Date:2010–10–25
> IETF LC End Date: 2010–11–10
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: "Roni Even" <[email-masked]>
Date: Tue, 30 Nov 2010 01:00:39 +0200

Hi Joe,
Thanks
Inline
Roni

> -----Original Message-----
> From: Joe Salowey [mailto:[email-masked]]
> Sent: Monday, November 29, 2010 7:42 AM
> To: Roni Even
> Cc: 'General Area Review Team'; draft-ietf-emu-eaptunnel-
> [email-masked]; 'IETF-Discussion list'
> Subject: Re: Gen-ART last call review of draft-ietf-emu-eaptunnel-req-
> 08
> 
> Hi Roni,
> 
> > 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.

Roni - Ok so just some questions about the current text for example in
section 3 you have
" The candidate tunnel method needs to  support all of the use cases that
are marked below as "MUST"." 
What do you mean by needs to - is this mandatory to support these use cases?
Also in section 6.2 last paragraph is it "must" or "MUST"

> 
> > 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?

Roni: yes.

> 
> > 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.
> 
> 
Roni: OK, it was just that the second and third paragraph looked like to me
like an example since the second paragraph starts with " Cryptographic
bindings are typically achieved" so it looked like one use case to address
the requirement in the first paragraph.

---

From: Joe Salowey <[email-masked]>
Date: Tue, 30 Nov 2010 09:50:59 -0800

> Also in section 6.2 last paragraph is it "must" or "MUST"

[Joe] Yes, it is mandatory to support these use cases, we can update the text.  In 6.2 it is "MUST".