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
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 | |
Request | Last Call review on draft-ietf-emu-eap-tunnel-method by Security Area Directorate Assigned | |
Reviewed revision | 07 (document currently at 10) | |
Result | Has issues | |
Completed | 2013-07-25 |
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