Skip to main content

Last Call Review of draft-ietf-emu-eap-tunnel-method-07

Request Review of draft-ietf-emu-eap-tunnel-method
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-07-30
Requested 2013-07-18
Authors Hao Zhou , Nancy Cam-Winget , Joseph A. Salowey , Steve Hanna
I-D last updated 2013-07-25
Completed reviews Genart Last Call review of -07 by Meral Shirazipour (diff)
Secdir Last Call review of -07 by Chris M. Lonvick (diff)
Assignment Reviewer Chris M. Lonvick
State Completed
Review review-ietf-emu-eap-tunnel-method-07-secdir-lc-lonvick-2013-07-25
Reviewed revision 07 (document currently at 10)
Result Has issues
Completed 2013-07-25

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.

Overall the document is well written and I found it to be complete. 

Since the document is a bit on the long side, I focused on sections 1 

through 3, and 7.  I scanned sections 4, 5, and 6.  I did not review the 

Appendixes.  I did have a couple of issues that I want to raise:

In Section 3.6.1, point #2 says that the TEAP packet is to be "ignored" if 

the other fields are "wrong".

- What does "wrong" mean?

- Also, I'd like to see some more clarification of what is expected 

from the carrier protocol if the TEAP packet is "ignored".  Wouldn't the 

carrier protocol just attempt redelivery if it doesn't get some sort of 

acknowldegement of the delivery of the TEAP packet?

Section 3.8 (second paragraph) says:
  >  TEAP implementations SHOULD have
  > a configuration where authentication fails if mutual authentication
  > cannot be achieved.

My personal feeling is that the SHOULD should be replaced with a MUST, but 

I acknowledge that is an implementation detail.  I then went looking for a 

discussion of this in the Security Considerations section and found 7.1 on 

"Mutual Authentication and Integrity Protection".  However I couldn't find 

anything in that section on Mutual Authentication.  Would you please add 

some discussion to that section on the problems that could arise if an 

implementation does not have mutual authentication?

I also found a few nits that you may want to look at.

You mostly use "Type-Length-Value" but you have one instance of "Type 

Length Value".

Section 3.1 says,
   > MUST use a version field set to 1.

Throughout section 4 you sometimes use "set to 1", and sometimes use "set 

to zero (0)", and in a few cases "set to (1)".  This inconsistency just 

set my OCD value to one (1).  ;-)

Section 3.3
   > If the server ignores the
   > request, it proceeds with termination of the tunnel and send the
   > clear text EAP Success or Failure message based on the Status field
   > of the peer's Request-Action TLV.
   If the server ignores the
   request, it proceeds with termination of the tunnel and sends the
or "will send".

Typo in section 3.8.4
   > after it has succ;essfully authenticated the server and established

Section 7
   > greater.  The threat model used for the security evaluation of TEAP
   > is defined in the EAP [RFC3748].

Maybe just "defined in EAP [RFC3748].", or "defined in the security 

consideration section in EAP [[RFC3748]."