[secdir] SECDIR review of draft-ietf-emu-eap-tunnel-method-07.txt

Chris Lonvick <clonvick@cisco.com> Wed, 24 July 2013 16:44 UTC

Return-Path: <clonvick@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9A5B211E8108; Wed, 24 Jul 2013 09:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Lno0z1IuC2Bu; Wed, 24 Jul 2013 09:44:26 -0700 (PDT)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id CDE6D11E8111; Wed, 24 Jul 2013 09:44:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2845; q=dns/txt; s=iport; t=1374684257; x=1375893857; h=date:from:to:subject:message-id:mime-version; bh=++0mm/PWml8EqoODVkc+2Wu4y4H8Z16+28EdnufAa2w=; b=kwH13nsJf5E95uQ/NrtesUsXVJ9vQJPxpeAKrBXSv4n2Pvj/M2CKXRgO z/E/Vd/LmhkzdHUTbuCrSQ2GUAOpjf1QkTJH2l9oo3KikIxsmbMqdHrQW xeg0ADC0/cikKe/V35xQEjbY/pYJ9cCW4pEZgql11Vs3q1VVGzM5Zxxhg M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiAFAPAC8FGrRDoJ/2dsb2JhbABagwa/fRZ0gmMCLYFRiCG5E5QEA4kqoAKDNA
X-IronPort-AV: E=Sophos;i="4.89,736,1367971200"; d="scan'208";a="87060735"
Received: from mtv-core-4.cisco.com ([]) by mtv-iport-4.cisco.com with ESMTP; 24 Jul 2013 16:44:15 +0000
Received: from sjc-xdm-112 (sjc-xdm-112.cisco.com []) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6OGiE4h016952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 16:44:14 GMT
Date: Wed, 24 Jul 2013 09:44:14 -0700
From: Chris Lonvick <clonvick@cisco.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-emu-eap-tunnel-method.all@tools.ietf.org
Message-ID: <alpine.LRH.2.00.1307240920570.20598@sjc-xdm-112.cisco.com>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Subject: [secdir] SECDIR review of draft-ietf-emu-eap-tunnel-method-07.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Jul 2013 16:44:33 -0000


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