From khoeper@motorola.com Fri Apr 17 09:45:04 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACA0D3A69DF for ; Fri, 17 Apr 2009 09:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84D2ia0KKEYA for ; Fri, 17 Apr 2009 09:45:03 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id BCD4F3A6E09 for ; Fri, 17 Apr 2009 09:45:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1239986775!32324176!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23242 invoked from network); 17 Apr 2009 16:46:15 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Apr 2009 16:46:15 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n3HGkEv0000485 for ; Fri, 17 Apr 2009 09:46:14 -0700 (MST) Received: from il27vts03 (il27vts03.cig.mot.com [10.17.196.87]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id n3HGeYri028686 for ; Fri, 17 Apr 2009 11:40:35 -0500 (CDT) Received: from de01exm66.ds.mot.com (de01exm66.am.mot.com [10.176.8.17]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id n3HGeY46028674 for ; Fri, 17 Apr 2009 11:40:34 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BF7B.26FF21DF" Date: Fri, 17 Apr 2009 12:40:01 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: editor for Thread-Index: Acm/eycSwVU2hKEIRoOjX9MDQ52NhA== From: "Hoeper Katrin-QWKN37" To: X-CFilter-Loop: Reflected Subject: [Emu] editor for X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 16:45:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BF7B.26FF21DF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey all, =20 At the last IETF meeting, the question was raised whether (http://tools.ietf.org/html/draft-clancy-emu-aaapay-01) should become a WG item. No decision was reached. However, it was pointed out that since the author Charles Clancy won't be able to continue this work an editor is needed. =20 I volunteer to become the editor of the draft, but am only interested if there is enough interest in the WG to make this draft a WG item. =20 I personally think the draft should be a WG item because it compliments the channel binding draft (http://tools.ietf.org/html/draft-ietf-emu-chbind-01) (co-authored by Charles & I) by defining a method to transport AAA payloads as needed for channel binding. Originally, both drafts were combined and later separated to emphasize that the payload transport can be used for other functions than the channel binding as well. =20 Looking forward to your feedback, =20 Katrin =20 =20 =20 ------_=_NextPart_001_01C9BF7B.26FF21DF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey all,

 

At the last IETF meeting, the question was raised = whether <draft-clancy-emu-aaapay-01> (http://too= ls.ietf.org/html/draft-clancy-emu-aaapay-01) should become a WG item.

No decision was reached. However, it was pointed out = that since the author Charles Clancy won’t be able to continue this = work an editor is needed.

 

I volunteer to become the editor of the draft, but am = only interested if there is enough interest in the WG to make this draft a WG = item.

 

I personally think the draft should be a WG item = because it compliments the channel binding draft (http://tools= .ietf.org/html/draft-ietf-emu-chbind-01) (co-authored by Charles & I) by defining a method to transport AAA = payloads as needed for channel binding. Originally, both drafts were combined and = later separated to emphasize that the payload transport can be used for other functions = than the channel binding as well.

 

Looking forward to your = feedback,

 

Katrin

 

 

 

------_=_NextPart_001_01C9BF7B.26FF21DF-- From gwz@net-zen.net Sat Apr 25 20:50:01 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39523A6CA7 for ; Sat, 25 Apr 2009 20:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xlk8nLmtPN86 for ; Sat, 25 Apr 2009 20:50:00 -0700 (PDT) Received: from smtpout10.prod.mesa1.secureserver.net (smtpout10-01.prod.mesa1.secureserver.net [64.202.165.235]) by core3.amsl.com (Postfix) with SMTP id 9373F3A6BD9 for ; Sat, 25 Apr 2009 20:50:00 -0700 (PDT) Received: (qmail 32085 invoked from network); 26 Apr 2009 03:51:19 -0000 Received: from unknown (124.120.229.242) by smtpout10.prod.mesa1.secureserver.net (64.202.165.235) with ESMTP; 26 Apr 2009 03:51:18 -0000 From: "Glen Zorn" To: Date: Sun, 26 Apr 2009 10:51:08 +0700 Organization: Network Zen Message-ID: <000901c9c622$3e70d720$bb528560$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnFlJm2s39lHrRDQZ6a+ffGFcz6QwAjY0BQ Content-Language: en-us Subject: [Emu] comments on draft-ietf-emu-eaptunnel-req-02.txt, part 1 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Apr 2009 03:50:02 -0000 General comments: There are several instances of the pernicious practice of treating references to references as if they were something other than pointers; among the most glaring of which are found in 4.2.1.1.3: "NIST publication [NIST SP 800-57p3] can be consulted for a list of acceptable TLS v1.0, v1.1 and v 1.2 cipher suites and NIST publication [NIST SP 800-108] for additional information on secure key derivation." Do these NIST publications have names? If so, please use them (or an appropriately shortened version thereof), along with providing a pointer to the reference itself. Hyphenation needs to be checked; for example, "certificate based authentication" makes no sense, but "certificate-based authentication" does. Section 3.1, first paragraph, last two sentences say: The tunnel method MUST support this use case. However, it MUST NOT expose the username and password to untrusted parties and it MUST provide protection against man-in-the-middle and dictionary attacks. The combination of the tunnel authentication and password authentication MUST enable mutual authentication. By whom (or what) are the "untrusted patties" referred to not trusted? For example, the AAA proxies in a visited network are certainly trusted _by that network_ (and by inference, the home network) but they may not be trusted (at least as much) as similar entities in the home network _by the user_. Some clarification of the trust model seems to be necessary here, especially given the specification of absolute requirements in the text. Same section, last paragraph, says: Since EAP authentication occurs before network access is granted the tunnel method SHOULD enable an inner exchange to provide support for minimal password management tasks including password change, "new PIN mode", and "next token mode" required by some systems. "New token mode" and "new PIN mode" refer to the proprietary SecureID system from RSA. I don't know why we should be giving RSA free advertising ;-), nor why their system deserves explicit mention. Suggestion: CHANGE: change, "new PIN mode", and "next token mode" required by some systems. TO change and other "housekeeping" functions required by some systems. This might also be a good place to mention that certain data related to authorization may need to be communicated to the peer; it is forbidden to do this in an EAP Success message, but there is no such constraint (yet) upon the TLS tunnel. In section 3.2, first paragraph, third sentence, CHANGE special type of man-in-the-middle attacks TO special type of man-in-the-middle attack Section 3.3, last sentence: CHANGE on the method chaining. TO on method chaining. The meaning of section 3.7 isn't clear to me: what, exactly, is meant by "client" here? Is it the EAP peer, the client machine, both or neither? Is it the user? If so, then that would seem to make a tunneled method unnecessary, except possibly for transmitting other data. Section 3.8, first sentence of first paragraph says: The tunnel method MUST provide extensibility so that additional types of data can be carried inside the tunnel in the future. This statement seems awfully broad to me. Do we really mean _any_ "additional types of data" or is it "additional types of security-related data" or maybe "additional types of data related to network access"? Section 4.1.1, third paragraph says: The tunnel method MUST meet all the EAP method requirements contained in the EAP Key Management Framework [RFC5247] or its successor. The tunnel method MUST include MSK and EMSK generation. This will enable the tunnel method to properly fit into the EAP key management framework, maintaining all of the security properties and guarantees of that framework. While it is undoubtedly tempting to simply require compliance with RFC 5247, given the rather incredible amount of drivel and nonsense present in that RFC, it might be a better idea to be specific about precisely what requirements need to be satisfied. Same section, last paragraph: same comment as the last, but in spades. Just one example that leaps out: Section 4.1.1, 4th paragraph of the draft in question says "The tunnel method MUST NOT be tied to any single cryptographic algorithm." and the last paragraph says "The tunnel method MUST meet requirements pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962]. This includes: cryptographic algorithm independence..." but the subsection on algorithm independence in Section 3 of RFC 4962 says "...an EAP method MAY depend on a specific cryptographic algorithm." While this specific contradiction might be addressed by adding a sentence stating that conflicts are resolved in favor of this draft other, more subtle problems might not. ~gwz Play assigns meaning to human activity--work erases it. -- P.L. Wilson From klaas@cisco.com Tue Apr 28 01:25:05 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BEC3A6B93 for ; Tue, 28 Apr 2009 01:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SkkB-4xR3Lsw for ; Tue, 28 Apr 2009 01:25:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 47BE83A6A3C for ; Tue, 28 Apr 2009 01:25:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,259,1238976000"; d="scan'208";a="39285297" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2009 08:26:22 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3S8QMHN025817; Tue, 28 Apr 2009 10:26:22 +0200 Received: from ams-kwiereng-8717.cisco.com (ams-kwiereng-8717.cisco.com [10.55.220.248]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3S8QMcQ000374; Tue, 28 Apr 2009 08:26:22 GMT Message-ID: <49F6BDAE.2010101@cisco.com> Date: Tue, 28 Apr 2009 10:26:22 +0200 From: Klaas Wierenga User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: khoeper@motorola.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4074; t=1240907182; x=1241771182; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=klaas@cisco.com; z=From:=20Klaas=20Wierenga=20 |Subject:=20review=20of=20chbind-01 |Sender:=20; bh=MNtcWDfwpIhcA/Rq54WgBAoOSjd3/Z/1vLHDteGqyDI=; b=igCy3VW3/Mt7XBzub8YuRVFE50chc9Pb7pLr/biDLbufPDUZOH3KBkl9gf 4FBkmgclQnOmyksNwFUW0e0v5PeDlAl4lCSwTRIKt3PnbDVbJyaLwhmdFljb bRSBLjnQKB; Authentication-Results: ams-dkim-1; header.From=klaas@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Mailman-Approved-At: Tue, 28 Apr 2009 07:48:26 -0700 Cc: emu@ietf.org Subject: [Emu] review of chbind-01 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 08:34:16 -0000 Hi Katrin, I have reviewed your draft and I think the content is in principle in pretty good shape, see my comments further below. I have however a more fundamental concern that I would like to hear your (and others') opinion about. I have the feeling that the draft is too complicated because you mix two, only loosely related, problems. The way I see it there are 2 fundamental issues: 1) the NAS talks to both the peer and to the authentication server and the information given to both doesn't have to be consistent 2) the NAS gives information to authentication server (via the peer or not) and the authentication server needs to evaluate that information and make policy decisions based on that. Issue 1 is for me the one that most needs solving, and I would prefer this draft to focus on that one only. Issue 2 is not so much a technical problem as a business problem. The administrative entities controlling respectively the NAS and the AuthN server need to agree on the info they exchange and it is than up to the administrative entity to process that info (and log it for non-repudiation purposes etc.) and make policy decisions on them. Wrt to issue 1 I wonder if it is not sufficient to just "close the loop", i.e. have the NAS send the same info to both peer and AuthN server. Or alternatively, have all the info flow through the peer, that way you can be sure that peer and AuthN server have a consistent view of what the NAS offers. My concrete comments: 1, par 2: "while there may be some identity tied to that security association" What do you mean with "identity", are you talking about NAS-identifier, or something more generic? 1, par 4: "consistent with the defined network policy" I think it is not so much consistent as well as that is 'satisfies' the defined network policies 3, par 1: I think you should call out here that proxy's are an example of that, you mention it later but it helps to give the reader an idea what you are talking about. 3, examples: I don't find the examples very compelling, how about for example a NAS giving wrong billing info to the peer "5$ all you can eat, while sending per minute rates to the Auth server? 4: "...do not ensure the binding different layers..." -> "...the binding OF different layers..." 4.1: is the fact whether it is plaintext or opaque the unique difference? I would argue that it is whether it is in a separate channel or inline in the session key derivation. I think the plaintext vs opaque doesn't add anything here, later in your requirements you point out that the info sent needs to be protected, that seems enough to me. 4.2.: is it not enough to just say that the AuthN server and the peer need to get the same info? isConsistent would become isEqual, much easier to compute...... ;-) 5.1, par 1: isConsistant -> isConsistent 5.2, par 1: conistency of i1 and i2 and evaluating the policy is indeed nontrivial, but policy evaluation should imo be out of scope for this draft anyway. Policy verification is a local problem at the Auth server side, it has nothing to do withy the communication protocols. 6.2: "EAP methods MUST be able to import channel binding data from the lower layer...." I don't understand this requirement, what type of data are we talking about? 7.2: NAS-Port-Type Why a MUST? I can imagine many use cases where from a policy point of view I couldn't care less what medium type I am using 7.3: again, why a MUST? 7.3.?: I think it worthwhile including 802.11u, after all this deals with NASes communicating data about their network to the peers, that is exactly what 11u does. 9.1: There is also trust between NAS/Authenticator and AuthN server. The Authenticator relies on the Authentication server for policy decisions. 10.1, par 4: I don't think you put contractual info about roaming partners in the database, but the rules in the policy engine are rather the results of that. Cheers, Klaas