Last Call Review of draft-ietf-emu-eap-tunnel-method-07
review-ietf-emu-eap-tunnel-method-07-secdir-lc-lonvick-2013-07-25-00

Hi,

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.
Maybe:
   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]."





Regards,
Chris