From aland@deployingradius.com Sun Oct 2 00:14:08 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF33421F8D16 for ; Sun, 2 Oct 2011 00:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fH3kARNwBua3 for ; Sun, 2 Oct 2011 00:14:08 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 34C8621F8D15 for ; Sun, 2 Oct 2011 00:14:07 -0700 (PDT) Message-ID: <4E880FEE.9070709@deployingradius.com> Date: Sun, 02 Oct 2011 09:17:02 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <81E742DC-02A9-4FB2-B3CD-D35282DBCE58@cisco.com> <4E838011.9040204@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 07:14:08 -0000 Sam Hartman wrote: > I'm happy to make changes regarding your comments; a couple of them were > not directly actionable but I can make best guesses. Most of them were > directly actionable and I agree the changes improve the text. > I'd appreciate comments from the groups on whether we start codes at 2 > or 1. It's just a suggestion... there's no serious reason to switch. > Alan> 5.3.3. Radius Namespace > > Alan> I suggest leaving out all re-definition of RADIUS AVPs. > Alan> Instead, refer to RFC 2865 Section 5. Say that the > Alan> NS-Specific data is RADIUS attributes, in the RADIUS attribute > Alan> format. But the RADIUS packet header (code, length, > Alan> authenticator) is not included. > > I'd prefer to keep the definition in. Why? The specifications for RADIUS are publicly available. I don't see the purpose in duplicating that text. > Unfortunately, as discussed in the text, we need to be able to send > empty attributes in channel binding response. It's not clear: Some RADIUS container specifications forbid sending attributes with no value. This prohibition not withstanding, these attributes SHOULD be sent with no value in channel binding responses. Sentence (1) is wrong. RFC 2865 specifically forbids sending attributes with no value. > I understand RADIUS has no meaning for empty attributes, but I think we > have a justified meaning for expressing that. The document contains no justification for empty responses. Looking for the word "response", I can't even find text which explains what the EAP peer does with the empty response. > I think the text is correct as is. The text should be clarified that zero-length attributes are specifically forbidden by RADIUS. > It's a SHOULD because we may specify cases where you include value or > where you don't fully understand the container format. > The definition of channel binding responses indicates that by default > you SHOULD send the attribute without a value and explains why. (You > don't want to echo back all that data.) There's a lot to discuss here. The amount of "all that data" is probably small, so it might not matter to echo it. And I'm still not sure why it's being echoed. Does it serve as an ACK, that the attribute was checked by the EAP server? From the document: The EAP server receives the channel binding data and performs the validation. The EAP method provides a way to return a response; the channel binding response uses the same basic format as the channel binding data. OK.... so what does the response *mean*? For me, echoing a copy of an attribute (value and all) means that the server validated the attribute. Echoing nothing means that the server doesn't know what to do with the attribute. Echoing an attribute with an empty value means... what? Alan DeKok. From jsalowey@cisco.com Thu Oct 13 14:15:19 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27F721F8BC4 for ; Thu, 13 Oct 2011 14:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dGeS0CvkvV24 for ; Thu, 13 Oct 2011 14:15:19 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6A021F8BB7 for ; Thu, 13 Oct 2011 14:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=329; q=dns/txt; s=iport; t=1318540519; x=1319750119; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=3Cbop5JfnpUTgjz+6yPMRWW4rhVNz81Fyo2tsSBNizE=; b=doKyzkL5zCYynHaV9BGABSDfyCcA8oKOK3ueU4/ofJI5bqFw3OQW8jjx gWoO04b4j0FU1sNOzCX+BIUgHP6d7joereyn8CNBchOehDn8EfA9682xX 7RQGNg+gU+N5uFGKpYMHdC+6/oEjEeNTi3jR90nINybeBeCeHyUbeo8NJ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0IAOBTl06rRDoI/2dsb2JhbABDmXiOY4EFgWwBCh2CMp9SgSYBniyHDGEEiAGLd4UojE0 X-IronPort-AV: E=Sophos;i="4.69,342,1315180800"; d="scan'208";a="7756611" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 13 Oct 2011 21:15:19 +0000 Received: from [10.33.251.254] ([10.33.251.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9DLFHQK018102 for ; Thu, 13 Oct 2011 21:15:18 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Oct 2011 14:15:37 -0700 Message-Id: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> To: emu@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 21:15:19 -0000 THe working group last call for draft-ietf-emu-chbind-09 ends October = 21, 2011. So far we have received few comments on the list. Please = review the document and post your comments to the list. Comments = indicating that you have read the document and not found any issues are = also useful. =20 Thanks, Joe= From yoshihiro.ohba@toshiba.co.jp Mon Oct 17 03:04:14 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BD221F8B2D for ; Mon, 17 Oct 2011 03:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAV4H+qNK+bD for ; Mon, 17 Oct 2011 03:04:13 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id EE49021F8B10 for ; Mon, 17 Oct 2011 03:04:12 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p9HA4CNi022011 for ; Mon, 17 Oct 2011 19:04:12 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id p9HA4B9w001217 for emu@ietf.org; Mon, 17 Oct 2011 19:04:11 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id VAA01215; Mon, 17 Oct 2011 19:04:11 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p9HA4B3Y022630 for ; Mon, 17 Oct 2011 19:04:11 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p9HA4Gv2024094; Mon, 17 Oct 2011 19:04:16 +0900 (JST) Received: from [133.196.16.95] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LT700CLBFYYN6E0@mail.po.toshiba.co.jp> for emu@ietf.org; Mon, 17 Oct 2011 19:04:11 +0900 (JST) Date: Mon, 17 Oct 2011 19:03:58 +0900 From: Yoshihiro Ohba In-reply-to: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> To: emu@ietf.org Message-id: <4E9BFD8E.3000108@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 10:04:14 -0000 I have read emu-chbind-09. I have no major issue on the document. Especially I like the detailed background and general information about channel binding in Sections 3 and 4, great work. I have several comments. I hope they are minor. [1] As far as I understand, the method-based channel binding is not applicable to ERP. For completeness of the specification it may be good to add some text to clarify this. [2] While the document mentions transporting channel bindings within the lower layer's secure association protocol for a future alternative, it is also possible to extend EAP itself to transport channel bindings for another future alternative as well. I am just wondering why the latter alternative is not mentioned in the document. [3] Probably this was discussed in the WG, but I want to understand the motivation for the namespace in Channel Binding Encoding because it seems to be a hard requirement if the peer has to know what namespace (or protocol) is being used between an EAP authenticator and EAP server. Also, in some case, the channel binding operation may be performed with a standalone authenticator since, due to EAP's mode independence property, the peer does not know whether the authenticator it is talking to is a pass-through authenticator or a stand-alone one. What namespace should be used with a standalone authenticator? [4] The following comments are related to EAP Lower Layers Registry table: - "PANA (no pre-authentication)" is mentioned but without a reference. I suggest adding a reference to RFC 5191 for this entry. - Since there is also PANA pre-authentication (RFC 5873), I suggest adding an entry "PANA (pre-authentication) [RFC 5873]". - The entry for IEEE 802.11s does not make sense since IEEE 802.11s does not support EAP authentication AFAIK. Please check, and remove it if not needed. - IEEE 802.16m supports EAP. I suggest adding IEEE 802.16m. - IEEE 802.21a (which is under Sponsor Ballot in IEEE SA and the work is almost done) also supports EAP. I suggest adding IEEE 802.21a. (There may be some other EAP lower layers which I miss to mention.) [5] References [RFC4006] and [80211U-D4.01] are not used. Best Regards, Yoshihiro Ohba (2011/10/14 6:15), Joe Salowey wrote: > THe working group last call for draft-ietf-emu-chbind-09 ends October 21, 2011. So far we have received few comments on the list. Please review the document and post your comments to the list. Comments indicating that you have read the document and not found any issues are also useful. > > Thanks, > > Joe > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From ietf@augustcellars.com Mon Oct 17 15:08:31 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D0A11E808C for ; Mon, 17 Oct 2011 15:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iXlRxysslcI for ; Mon, 17 Oct 2011 15:08:30 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB5311E8073 for ; Mon, 17 Oct 2011 15:08:30 -0700 (PDT) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 0AEC32CA2C; Mon, 17 Oct 2011 15:08:29 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 17 Oct 2011 15:08:00 -0700 Message-ID: <001401cc8d19$3d7ad260$b8707720$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcyNGRCgSasgwXEiQuKcg/EGCRfGNg== Content-Language: en-us Cc: emu@ietf.org Subject: [Emu] Comments on the eap-tunnel-method-00 draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 22:08:31 -0000 I have gathered these comments over time and therefore some of them are not fully fleshed out. If you have any questions I will try and reconstruct my ideas at the time. Jim Version Negotiation - terminate the conversation - w or w/o a fail? Edge case - what if peer only supports a higher version than the server supports? NAK? EAP Server Name Checking - On what basis does the client accept or not accept the EAP server name? You are suggesting that it is signed by a CA controlling the intended domain, but what does this mean? Are you suggesting that the CA should have a DNS subject alt name in it for the domain in question? If no embedded EAP methods run, then no crypto check and thus no version # checking is done. Also no checking done if only one inner EAP method is used as this only sends the Result TLV and not the Crypto-Binding TLV 'serially in a sequence' is redundant - section 3.3.1 Not only does it not allow initiating multiple EAP methods in parallel, it requires that they not be running in parallel. This is a more strict condition Para #3 - can the peer return an error and treat the failure of a specific EAP method as a total failure for the overall process - or at least recommend that it should be an overall failure? Confused messages in 3.3.1 and 3.3.3 about sending intermediate results and final results at the same time. Specifically 3.3.1 says MUST NOT for one inner EAP method, but text is not reflected in section 3.3.3 Conflict between 3.3.3 and security considerations (7.5) about sending a different value in the Result TLV and the clear result in the event of not doing a Request-Action TLV from the client. Is the server required to use the client suggested result in the event it does not perform the request action - could it use a different failure message or a success message? Does it matter? Section 3.4 - Need to address the following issues: 1. what if both certificates and an inner EAP method are run - what is the Peer-Id then? 2. What if multiple inner EAP methods are run - which Peer-Id is used then? 3. What if client and machine EAP methods are run - which one to use then? (Internal what are the ids used for?) Section 3.6 - item #2 - it should be noted that not all failure indications would be transmitted. The failure/success of the last EAP method may not be sent as it gets wrapped into the Result TLV message Section 3.6.2 - (internal) - if you get a TLV rules violation - does the TLV itself need to be acknowledged? Section 3.7 - Can I assume that the identifier value is monotonically increasing and does not wrap? Section 3.7 - it might be useful to tell me how to error for a message too big or response time too long in dealing with fragmentation - are both just final errors? Or should it potentially be treated as a TLS error? Section 3.2 - possible clarification. If all TLVs in a message are marked optional and none are understood by the peer, then an EMPTY response message must still be sent to the server. Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding TLV - not what it says in section 3.3 Section 4.2.3 - NAK TLV should not be accompanied by other TLVs. Not sure I understand why. If I send an EAP plus a vendor w/ mandatory set, should not I get back a NAK on the vendor plus a result for the EAP? I might be happy to not do the vendor, but want to distinguish between you cannot do this vs you choose not to do this. Section 4.2.10 - How can I know if the server does or does not process the channel binding TLV? This may be part of my policy as a peer depending on circumstances. Section 4.2.8 - Currently says that version should be 1 while the version defined in the intro sections is 2 - would be correct if we change the EAP method. From hartmans@painless-security.com Tue Oct 18 06:56:34 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C4521F8AEA; Tue, 18 Oct 2011 06:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.71 X-Spam-Level: X-Spam-Status: No, score=-103.71 tagged_above=-999 required=5 tests=[AWL=-1.445, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp23lGRj80tM; Tue, 18 Oct 2011 06:56:34 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id EC4C321F8AE1; Tue, 18 Oct 2011 06:56:33 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6BE7420393; Tue, 18 Oct 2011 09:57:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 158AA4235; Tue, 18 Oct 2011 09:56:22 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Tue, 18 Oct 2011 09:56:22 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emu@ietf.org Subject: [Emu] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 13:56:34 -0000 [EMU copied for EAP input] Here in ABFAB, we're designing a new EAP lower layer for applications to use for authentication. We're using the GSS-API (RFC 2743) as our application integration point. Currently, our lower layer is kind of chatty. The peer sends a first message that roughly says "Hi, I'd like to authenticate." Then the authenticator sends an identity request EAP message. Then the peer sends an identity response. Then the authenticator (probably after an AAA interaction) respons with the first EAP method message. As best we can tell that round trip is unneeded. We could instead include an unsolicited identity response in our first message from the peer to authenticator and get a request with an EAP method message from the first message from the authenticator. We can't see any down side of this. There seems to be nothing in the identity request. We already have another approach for "network selection." If you want to know who your authenticator is in order to decide on an identity, we have a lower-layer specific mechanism for that. I'd appreciate any comments. From ABFAB participants, do we want to make this optimization? From EMU participants are we missing anything? From hartmans@mit.edu Tue Oct 18 07:03:06 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6A921F8B61 for ; Tue, 18 Oct 2011 07:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=-1.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUBWc2sBCB7Y for ; Tue, 18 Oct 2011 07:03:05 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A59DD21F8B1C for ; Tue, 18 Oct 2011 07:03:05 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D7BE0203C7; Tue, 18 Oct 2011 10:04:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7B92C4235; Tue, 18 Oct 2011 10:02:54 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> Date: Tue, 18 Oct 2011 10:02:54 -0400 In-Reply-To: <4E9BFD8E.3000108@toshiba.co.jp> (Yoshihiro Ohba's message of "Mon, 17 Oct 2011 19:03:58 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 14:03:06 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> [1] As far as I understand, the method-based channel Yoshihiro> binding is not applicable to ERP. For completeness of Yoshihiro> the specification it may be good to add some text to Yoshihiro> clarify this. I'd welcome suggestions. I'm not really familiar with ERP. Yoshihiro> [3] Probably this was discussed in the WG, but I want to Yoshihiro> understand the motivation for the namespace in Channel Yoshihiro> Binding Encoding because it seems to be a hard Yoshihiro> requirement if the peer has to know what namespace (or Yoshihiro> protocol) is being used between an EAP authenticator and Yoshihiro> EAP server. Also, in some case, the channel binding Yoshihiro> operation may be performed with a standalone Yoshihiro> authenticator since, due to EAP's mode independence Yoshihiro> property, the peer does not know whether the Yoshihiro> authenticator it is talking to is a pass-through Yoshihiro> authenticator or a stand-alone one. What namespace Yoshihiro> should be used with a standalone authenticator? The namespace ID simply names where the attribute comes from. If you are describing some value that is available in a RADIUS ID, then you should use the RADIUS namespace. The EAP server (which as you point out may be the authenticator) is responsible for matching up that information in whatever form it has it. For attributes available both in the diameter and RADIUS namespaces I'd expect some lower layer document to describe which one to use regardless of whether an AAA protocol is in use or which one is in use. From hartmans@mit.edu Tue Oct 18 07:26:55 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB24421F8C10 for ; Tue, 18 Oct 2011 07:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.132 X-Spam-Level: X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ad5cskTh66wB for ; Tue, 18 Oct 2011 07:26:55 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9CB21F8B68 for ; Tue, 18 Oct 2011 07:26:55 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3F97220239; Tue, 18 Oct 2011 10:28:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D913C4235; Tue, 18 Oct 2011 10:26:39 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <81E742DC-02A9-4FB2-B3CD-D35282DBCE58@cisco.com> <4E838011.9040204@deployingradius.com> <4E880FEE.9070709@deployingradius.com> Date: Tue, 18 Oct 2011 10:26:39 -0400 In-Reply-To: <4E880FEE.9070709@deployingradius.com> (Alan DeKok's message of "Sun, 02 Oct 2011 09:17:02 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 14:26:55 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> For me, echoing a copy of an attribute (value and all) means Alan> that the server validated the attribute. Echoing nothing Alan> means that the server doesn't know what to do with the Alan> attribute. Echoing an attribute with an empty value Alan> means... what? It means the server validated the attribute. I think there are several important reasons not to echo the value in the attribute. 1) Space. Some EAP methods limit the channel binding space. For all EAP methods there is value in minimizing the size of messages. 2) What does the peer do with the echoed value? What if the echoed value is different from what the peer sent? MAY the peer fail in that case? SHOULD the peer fail in that case? MUST the peer fail in that case? Why do we want to introduce complexity here? The peer clearly needs to know what attributes the server validated. I don't understand why the peer needs a copy of the attribute value it already sent except that it's convenient if you're using an existing RADIUS library. Hmm. OK, I thought there were some fairly compelling use cases related to extensibility. I was thinking for example we might provide a way to indicate why a EAP server failed to validate an attribute. For example, in a channel binding failure we might decide that we want to indicate which attributes validated and which ones did not and we might want to use the value for that. However, unmodified clients might misinterpret that, so this extensibility option isn't nearly as valuable as I thought. We can always invent a new namespace as an extensibility mechanism if we need it. So, we're left with space as the main argument and I agree it's not compelling. I propose that: 1) We send full values in responses 2) Peers MUST ignore differences between the value sent in the channel binding data and channel binding response. This gives us the option of changing the value if we ever find a reason to do so. It also prohibits some particularly bad peer implementation strategies like doing a binary comparison of the channel bindigns sent against the response. 3) Codes should define what attributes you include. For success we include attributes the server considered in making the decision that channel binding was successful. For our current failure code I think we should also include all the attributes the server looked at--we are not indicating what attributes are wrong. My rationale is that it may not be easy to tell what's wrong; it may be that some attributes are inconsistent and either of them alone could have been OK, but both together was not. 4) Indicate that if a client doesn't understand a code, it treats it as failure. Would this work? From rafa@um.es Tue Oct 18 07:51:39 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1B021F8B23; Tue, 18 Oct 2011 07:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XySwN75cGN4U; Tue, 18 Oct 2011 07:51:38 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 25B2421F8B35; Tue, 18 Oct 2011 07:51:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 979985D6BC; Tue, 18 Oct 2011 16:51:36 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nlEmI5UDe3eA; Tue, 18 Oct 2011 16:51:36 +0200 (CEST) Received: from inf-205-117.inf.um.es (inf-205-117.inf.um.es [155.54.205.117]) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPA id 8BC925D6A8; Tue, 18 Oct 2011 16:51:31 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Tue, 18 Oct 2011 16:51:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> References: To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org, emu@ietf.org Subject: Re: [Emu] [abfab] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 14:51:39 -0000 Hi Sam: El 18/10/2011, a las 15:56, Sam Hartman escribi=F3: > [EMU copied for EAP input] >=20 > Here in ABFAB, we're designing a new EAP lower layer for applications = to > use for authentication. We're using the GSS-API (RFC 2743) as our > application integration point. >=20 > Currently, our lower layer is kind of chatty. The peer sends a first > message that roughly says "Hi, I'd like to authenticate." Then the > authenticator sends an identity request EAP message. Then the peer = sends > an identity response. Then the authenticator (probably after an AAA > interaction) respons with the first EAP method message. >=20 > As best we can tell that round trip is unneeded. We could instead > include an unsolicited identity response in our first message from the > peer to authenticator and get a request with an EAP method message = from > the first message from the authenticator. According to RFC 3579 (section 2.1) that would be possible in certain = cases: "This is useful in cases where the identity is determined by another means (such as Called-Station-Id, Calling-Station-Id and/or Originating-Line-Info); where a single authentication method is required, which includes its own identity exchange; where identity hiding is desired, so that the identity is not requested until after a protected channel has been set up." Alternatively, what I believe you can also do is to allow the peer send = information (probably peer's identity) to the authenticator out of EAP = (within GSS token). This information allows AAA client to reach the = EAP/AAA server that handles the peer's credentials. Then the EAP/AAA = server can start directly the preferred EAP method for that peer. What I am trying to say corresponds with something similar to the first = figure of section 2.2 in RFC 4072. In RFC 3579 you can also find this text: "Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server." Between both choices, it seems that second one gives the EAP/AAA server = the opportunity to start directly with the selected EAP method from a = pool of them. First choice, always starts with a particular EAP method = (implemented in the Acceptor) that it may not be supported by the (home) = EAP/AAA server or not the preferred one by the server for that peer. Hope this helps. >=20 > We can't see any down side of this. There seems to be nothing in the > identity request. We already have another approach for "network > selection." If you want to know who your authenticator is in order to > decide on an identity, we have a lower-layer specific mechanism for > that. >=20 > I'd appreciate any comments. =46rom ABFAB participants, do we want to = make > this optimization? =46rom EMU participants are we missing anything? > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Tue Oct 18 08:35:53 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798CC21F869E; Tue, 18 Oct 2011 08:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EIE2UY4ywP0R; Tue, 18 Oct 2011 08:35:53 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0F85E21F8672; Tue, 18 Oct 2011 08:35:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5BA5E202C9; Tue, 18 Oct 2011 11:37:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F13704235; Tue, 18 Oct 2011 11:35:41 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> Date: Tue, 18 Oct 2011 11:35:41 -0400 In-Reply-To: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> (Rafa Marin Lopez's message of "Tue, 18 Oct 2011 16:51:31 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 18 Oct 2011 08:36:54 -0700 Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [Emu] [abfab] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 15:35:53 -0000 I think I may have been unclear in what I was proposing. I'm proposing that the peer send its identity in the first message (*) and that the server gets to respond with type 4 or greater (a specific EAP method). I'm proposing dropping the identity request, not the identity response. (*) There's a case where we ask the acceptor what its name is. In that case I think it is desirable to let the peer wait to receive the acceptor name before sending an identity. In all these cases we support identity hiding. From rafa@um.es Tue Oct 18 09:20:30 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C9F21F8BB7; Tue, 18 Oct 2011 09:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sT81e0wbPm4M; Tue, 18 Oct 2011 09:20:28 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9C121F8BBB; Tue, 18 Oct 2011 09:20:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 5E7704BCD4; Tue, 18 Oct 2011 18:20:24 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Cemlru2SxhN8; Tue, 18 Oct 2011 18:20:24 +0200 (CEST) Received: from inf-205-117.inf.um.es (inf-205-117.inf.um.es [155.54.205.117]) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPA id 2C2654B942; Tue, 18 Oct 2011 18:20:17 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Tue, 18 Oct 2011 18:20:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [Emu] [abfab] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 16:20:30 -0000 Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribi=F3: > I think I may have been unclear in what I was proposing. I'm = proposing > that the peer send its identity in the first message (*) and that the > server gets to respond with type 4 or greater (a specific EAP method). Sending its identity does not mean that it must be carried in the EAP = response/identity. In fact what I suggested is to carry the identity in = the first message but not contained in the EAP response/identity. > I'm proposing dropping the identity request, not the identity = response. As I said in my previous e-mail, you can do that but it does not = necessarily mean to transport the identity in an EAP response/identity. According to the text I pasted in my previous e-mail (below), the peer = can send its identity in the first message (but not contained in any EAP = response/identity). Then the NAS sends that identity to the EAP/AAA = server with an EAP-Message attribute (without EAP message) signifying = EAP-Start. The RADIUS server then sends "an EAP-Request for an = authentication method (Type 4 or greater) This is what I proposed in my previous e-mail. Is it not similar to what = you proposed? In RFC 3579 you can also find this text: "Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server." >=20 >=20 > (*) There's a case where we ask the acceptor what its name is. In that > case I think it is desirable to let the peer wait to receive the > acceptor name before sending an identity. >=20 > In all these cases we support identity hiding. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Tue Oct 18 09:55:35 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAEA21F8AD2; Tue, 18 Oct 2011 09:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obXNfYoSC1gh; Tue, 18 Oct 2011 09:55:35 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7A00321F8ACE; Tue, 18 Oct 2011 09:55:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8CB8820383; Tue, 18 Oct 2011 12:56:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 05EA04235; Tue, 18 Oct 2011 12:55:24 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> Date: Tue, 18 Oct 2011 12:55:23 -0400 In-Reply-To: (Rafa Marin Lopez's message of "Tue, 18 Oct 2011 18:20:16 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 18 Oct 2011 11:30:04 -0700 Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [Emu] [abfab] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 16:55:36 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: >> I think I may have been unclear in what I was proposing. I'm >> proposing that the peer send its identity in the first message >> (*) and that the server gets to respond with type 4 or greater (a >> specific EAP method). Rafa> Sending its identity does not mean that it must be carried in Rafa> the EAP response/identity. In fact what I suggested is to Rafa> carry the identity in the first message but not contained in Rafa> the EAP response/identity. OK. Why not carry it in the EAP response/identity? It seems easier than developing new encoding. However it's certainly easy enough to carry it elsewhere. So, if there is a reason to do so I'm happy to invent our own subtoken for it. do you support the general concept of an optimization here? From rafa@um.es Tue Oct 18 15:07:05 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87A61F0C40; Tue, 18 Oct 2011 15:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxJcbFcyhxwp; Tue, 18 Oct 2011 15:07:05 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 35F021F0C35; Tue, 18 Oct 2011 15:07:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 04BD65D6C8; Wed, 19 Oct 2011 00:06:48 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 7ebzrLgTi3iM; Wed, 19 Oct 2011 00:06:48 +0200 (CEST) Received: from [192.168.1.67] (16.Red-83-38-58.dynamicIP.rima-tde.net [83.38.58.16]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPSA id 49CBB5D442; Wed, 19 Oct 2011 00:06:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Wed, 19 Oct 2011 00:06:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [Emu] [abfab] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 22:07:06 -0000 Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribi=F3: >>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >=20 > Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribi=F3: >=20 >>> I think I may have been unclear in what I was proposing. I'm >>> proposing that the peer send its identity in the first message >>> (*) and that the server gets to respond with type 4 or greater (a >>> specific EAP method). >=20 > Rafa> Sending its identity does not mean that it must be carried in > Rafa> the EAP response/identity. In fact what I suggested is to > Rafa> carry the identity in the first message but not contained in > Rafa> the EAP response/identity. >=20 > OK. Why not carry it in the EAP response/identity? > It seems easier than developing new encoding. Basically EAP is a lock-step protocol where it is required to get a = request to obtain a response (in the peer side)). So the EAP peer state = machine implementing the EAP standard protocol will react after = receiving an EAP request. So I see two options: either you hack the EAP = peer state machine to return an EAP response/identity without receiving = any EAP request/identity (this "violates" the standard and so we need to = hack the EAP peer state machine) or directly at GSS-API level you create = a EAP response/identity and include the identity (which seems weird = taking into account that we have an EAP stack in charge of creating EAP = messages) Personally, I do not like either (considering the standard RFC 3748). = So, I would prefer to define a subtoken for this. >=20 > However it's certainly easy enough to carry it elsewhere. So, if there > is a reason to do so I'm happy to invent our own subtoken for it. Good. >=20 > do you support the general concept of an optimization here? Yes, I do. Certainly, we save two messages between initiator and = acceptor. Nevertheless, I am not sure how it is the real reduction in = time of this optimization in contrast with the fact that an EAP = authentication may need to reach a home EAP/AAA server and may be = involve several roundtrips to complete. Best regards. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From rafa@um.es Wed Oct 19 02:28:12 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1688021F8BB7; Wed, 19 Oct 2011 02:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9Zf-lAC06JZ; Wed, 19 Oct 2011 02:28:11 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA2E21F8BB1; Wed, 19 Oct 2011 02:28:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 2B04C5D499; Wed, 19 Oct 2011 11:28:09 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0FLn4vSzSkbg; Wed, 19 Oct 2011 11:28:08 +0200 (CEST) Received: from inf-205-117.inf.um.es (inf-205-117.inf.um.es [155.54.205.117]) (Authenticated sender: rafa) by xenon13.um.es (Postfix) with ESMTPA id 193AD5D477; Wed, 19 Oct 2011 11:28:00 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Wed, 19 Oct 2011 11:28:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [Emu] [abfab] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 09:28:12 -0000 Hi Sam: El 19/10/2011, a las 00:23, Sam Hartman escribi=F3: >>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >=20 > Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribi=F3: >=20 >>>>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >>>=20 > Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribi=F3: >>>=20 >>>>> I think I may have been unclear in what I was proposing. I'm >>>>> proposing that the peer send its identity in the first message >>>>> (*) and that the server gets to respond with type 4 or greater >>>>> (a specific EAP method). >>>=20 > Rafa> Sending its identity does not mean that it must be carried in > Rafa> the EAP response/identity. In fact what I suggested is to > Rafa> carry the identity in the first message but not contained in > Rafa> the EAP response/identity. >>>=20 >>> OK. Why not carry it in the EAP response/identity? It seems >>> easier than developing new encoding. >=20 > Rafa> Basically EAP is a lock-step protocol where it is required to > Rafa> get a request to obtain a response (in the peer side)). So = the > Rafa> EAP peer state machine implementing the EAP standard protocol > Rafa> will react after receiving an EAP request. So I see two > Rafa> options: either you hack the EAP peer state machine to return > Rafa> an EAP response/identity without receiving any EAP > Rafa> request/identity (this "violates" the standard and so we need > Rafa> to hack the EAP peer state machine)=20 >=20 > Or the initiator synthesizes a request and feeds it to the peer's = state > machine. Yes, this is another option, though I don't like either. The reason is = simple. AFAIK, the standard EAP does not say anything about a EAP = lower-layer synthesizing a request (which sounds like another type of = hack). EAP requests are sent by the authenticator. This is what the = standard says. >=20 > IN our implementation, even if the IETF decides on an an alternate > encoding for the identity, we'll end up synthesizing an identity = request > and doing something with the identity response. >=20 > With a standard EAP library that is lock-step in the manner you > describe, it's far easier to produce a synthetic identity request in = the > initiator than to hack the state machine or do anything else. =20 As I said synthesizing an EAP request is another type of hack, because = the EAP protocol does not work like that. We have a RFC 3748 and RFC = 5247 where the EAP protocol is defined. I believe it would be good if we = follow the standards. > Think of > it this way. In GSS-EAP, the identity request is generated by a party > very close to the initiator. EAP already supports the identity = request > being generated by a different party than the actual EAP messages. Why > does it matter whether the request comes from inside the peer or from = a > NAS? Regarding this, you need to think about the mode independence property = of EAP where: "As far as the EAP peer is concerned, its conversation with the EAP = authenticator, and all=20 consequences of that conversation, are identical, regardless of the = authenticator mode of operation." In other words, under peer standpoint, all EAP requests are coming from = the EAP authenticator (the peer does not know and do not care if there = is a backend EAP server or it is integrated with the authenticator).=20 >=20 >=20 > Rafa> or directly at GSS-API > Rafa> level you create a EAP response/identity and include the > Rafa> identity (which seems weird taking into account that we have > Rafa> an EAP stack in charge of creating EAP messages) >=20 > But if you don't create an EAP response/identity on the initiator you > probably do have to do it on the acceptor to trigger AAA to use EAP. I don't think you need to do that. As I explained in the previous = e-mail, in RADIUS EAP (RFC 3579) you can find this text: "Rather than sending an initial EAP-Request packet to the authenticating peer, on detecting the presence of the peer, the NAS MAY send an Access-Request packet to the RADIUS server containing an EAP-Message attribute signifying EAP-Start. The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server. EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data)." In other words, once the acceptor knows the peer's identity can send = that EAP-start message in a RADIUS Access-Challenge. Moreover it should = include the user-name in the request. With that, the RADIUS EAP server = should start the EAP method selected for that peer. >=20 > Rafa> Personally, I do not like either (considering the standard = RFC > Rafa> 3748). So, I would prefer to define a subtoken for this. >=20 > We can do that. It means faking up an identity response on the > acceptor. But that is certainly not a big deal. As explained, you do not need to fake up any identity response on the = acceptor. Just follow what RFC 3579 says. >=20 > --Sam ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From rafa@um.es Wed Oct 19 02:45:17 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B026921F8B6E; Wed, 19 Oct 2011 02:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDOp5AMf6Zro; Wed, 19 Oct 2011 02:45:16 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 7502621F8B5B; Wed, 19 Oct 2011 02:45:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 4B92B5D4B5; Wed, 19 Oct 2011 11:45:14 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DWNZu7L7iqtV; Wed, 19 Oct 2011 11:45:13 +0200 (CEST) Received: from inf-205-117.inf.um.es (inf-205-117.inf.um.es [155.54.205.117]) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPA id 797E45D6DF; Wed, 19 Oct 2011 11:45:07 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> Date: Wed, 19 Oct 2011 11:45:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> To: Rafa Marin Lopez X-Mailer: Apple Mail (2.1084) Cc: Sam Hartman , abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [Emu] [abfab] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 09:45:17 -0000 Please replace RADIUS Access-Challenge by RADIUS Access-Request in the = sentence of my previous e-mail "In other words, once the acceptor knows the peer's identity can send = that EAP-start message in a RADIUS Access-Challenge..." Best regards. El 19/10/2011, a las 11:28, Rafa Marin Lopez escribi=F3: > Hi Sam: >=20 > El 19/10/2011, a las 00:23, Sam Hartman escribi=F3: >=20 >>>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >>=20 >> Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribi=F3: >>=20 >>>>>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >>>>=20 >> Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribi=F3: >>>>=20 >>>>>> I think I may have been unclear in what I was proposing. I'm >>>>>> proposing that the peer send its identity in the first message >>>>>> (*) and that the server gets to respond with type 4 or greater >>>>>> (a specific EAP method). >>>>=20 >> Rafa> Sending its identity does not mean that it must be carried in >> Rafa> the EAP response/identity. In fact what I suggested is to >> Rafa> carry the identity in the first message but not contained in >> Rafa> the EAP response/identity. >>>>=20 >>>> OK. Why not carry it in the EAP response/identity? It seems >>>> easier than developing new encoding. >>=20 >> Rafa> Basically EAP is a lock-step protocol where it is required to >> Rafa> get a request to obtain a response (in the peer side)). So = the >> Rafa> EAP peer state machine implementing the EAP standard protocol >> Rafa> will react after receiving an EAP request. So I see two >> Rafa> options: either you hack the EAP peer state machine to return >> Rafa> an EAP response/identity without receiving any EAP >> Rafa> request/identity (this "violates" the standard and so we need >> Rafa> to hack the EAP peer state machine)=20 >>=20 >> Or the initiator synthesizes a request and feeds it to the peer's = state >> machine. >=20 > Yes, this is another option, though I don't like either. The reason is = simple. AFAIK, the standard EAP does not say anything about a EAP = lower-layer synthesizing a request (which sounds like another type of = hack). EAP requests are sent by the authenticator. This is what the = standard says. >=20 >>=20 >> IN our implementation, even if the IETF decides on an an alternate >> encoding for the identity, we'll end up synthesizing an identity = request >> and doing something with the identity response. >>=20 >> With a standard EAP library that is lock-step in the manner you >> describe, it's far easier to produce a synthetic identity request in = the >> initiator than to hack the state machine or do anything else. =20 >=20 > As I said synthesizing an EAP request is another type of hack, because = the EAP protocol does not work like that. We have a RFC 3748 and RFC = 5247 where the EAP protocol is defined. I believe it would be good if we = follow the standards. >=20 >> Think of >> it this way. In GSS-EAP, the identity request is generated by a party >> very close to the initiator. EAP already supports the identity = request >> being generated by a different party than the actual EAP messages. = Why >> does it matter whether the request comes from inside the peer or from = a >> NAS? >=20 >=20 > Regarding this, you need to think about the mode independence property = of EAP where: >=20 > "As far as the EAP peer is concerned, its conversation with the EAP = authenticator, and all=20 > consequences of that conversation, are identical, regardless of the = authenticator mode of operation." >=20 > In other words, under peer standpoint, all EAP requests are coming = from the EAP authenticator (the peer does not know and do not care if = there is a backend EAP server or it is integrated with the = authenticator).=20 >=20 >=20 >>=20 >>=20 >> Rafa> or directly at GSS-API >> Rafa> level you create a EAP response/identity and include the >> Rafa> identity (which seems weird taking into account that we have >> Rafa> an EAP stack in charge of creating EAP messages) >>=20 >> But if you don't create an EAP response/identity on the initiator you >> probably do have to do it on the acceptor to trigger AAA to use EAP. >=20 > I don't think you need to do that. As I explained in the previous = e-mail, in RADIUS EAP (RFC 3579) you can find this text: >=20 > "Rather than sending an initial EAP-Request packet to the > authenticating peer, on detecting the presence of the peer, the NAS > MAY send an Access-Request packet to the RADIUS server containing an > EAP-Message attribute signifying EAP-Start. The RADIUS server will > typically respond with an Access-Challenge containing EAP-Message > attribute(s) encapsulating an EAP-Request/Identity (Type 1). > However, an EAP-Request for an authentication method (Type 4 or > greater) can also be sent by the server. >=20 > EAP-Start is indicated by sending an EAP-Message attribute with a > length of 2 (no data)." >=20 >=20 > In other words, once the acceptor knows the peer's identity can send = that EAP-start message in a RADIUS Access-Challenge. Moreover it should = include the user-name in the request. With that, the RADIUS EAP server = should start the EAP method selected for that peer. >=20 >=20 >>=20 >> Rafa> Personally, I do not like either (considering the standard = RFC >> Rafa> 3748). So, I would prefer to define a subtoken for this. >>=20 >> We can do that. It means faking up an identity response on the >> acceptor. But that is certainly not a big deal. >=20 > As explained, you do not need to fake up any identity response on the = acceptor. Just follow what RFC 3579 says. >=20 >>=20 >> --Sam >=20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- >=20 >=20 >=20 >=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From rafa@um.es Wed Oct 19 05:34:14 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A2621F8BA0; Wed, 19 Oct 2011 05:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFKB3ky-l0cQ; Wed, 19 Oct 2011 05:34:14 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id B3DF921F8B9F; Wed, 19 Oct 2011 05:34:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 41A3C537B8; Wed, 19 Oct 2011 14:34:12 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qo6G-RvDlIu8; Wed, 19 Oct 2011 14:34:11 +0200 (CEST) Received: from inf-205-117.inf.um.es (inf-205-117.inf.um.es [155.54.205.117]) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPA id C2AC05364A; Wed, 19 Oct 2011 14:34:05 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> Date: Wed, 19 Oct 2011 14:34:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <713AFE38-AAD7-4463-A1B2-BF667CE6A096@um.es> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> To: Rafa Marin Lopez X-Mailer: Apple Mail (2.1084) Cc: Sam Hartman , abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [Emu] [abfab] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 12:34:15 -0000 Hi again: I have been thinking again about the situation created with sending an = EAP response/id without the authenticator sending EAP request/id and I = realized that it may be even worse in the authenticator side. Basically, = the authenticator will see an EAP response message which does not answer = to any EAP request sent.=20 Best regards. El 19/10/2011, a las 11:45, Rafa Marin Lopez escribi=F3: > Please replace RADIUS Access-Challenge by RADIUS Access-Request in the = sentence of my previous e-mail >=20 > "In other words, once the acceptor knows the peer's identity can send = that EAP-start message in a RADIUS Access-Challenge..." >=20 > Best regards. >=20 > El 19/10/2011, a las 11:28, Rafa Marin Lopez escribi=F3: >=20 >> Hi Sam: >>=20 >> El 19/10/2011, a las 00:23, Sam Hartman escribi=F3: >>=20 >>>>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >>>=20 >>> Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribi=F3: >>>=20 >>>>>>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >>>>>=20 >>> Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribi=F3: >>>>>=20 >>>>>>> I think I may have been unclear in what I was proposing. I'm >>>>>>> proposing that the peer send its identity in the first message >>>>>>> (*) and that the server gets to respond with type 4 or greater >>>>>>> (a specific EAP method). >>>>>=20 >>> Rafa> Sending its identity does not mean that it must be carried in >>> Rafa> the EAP response/identity. In fact what I suggested is to >>> Rafa> carry the identity in the first message but not contained in >>> Rafa> the EAP response/identity. >>>>>=20 >>>>> OK. Why not carry it in the EAP response/identity? It seems >>>>> easier than developing new encoding. >>>=20 >>> Rafa> Basically EAP is a lock-step protocol where it is required to >>> Rafa> get a request to obtain a response (in the peer side)). So = the >>> Rafa> EAP peer state machine implementing the EAP standard protocol >>> Rafa> will react after receiving an EAP request. So I see two >>> Rafa> options: either you hack the EAP peer state machine to return >>> Rafa> an EAP response/identity without receiving any EAP >>> Rafa> request/identity (this "violates" the standard and so we need >>> Rafa> to hack the EAP peer state machine)=20 >>>=20 >>> Or the initiator synthesizes a request and feeds it to the peer's = state >>> machine. >>=20 >> Yes, this is another option, though I don't like either. The reason = is simple. AFAIK, the standard EAP does not say anything about a EAP = lower-layer synthesizing a request (which sounds like another type of = hack). EAP requests are sent by the authenticator. This is what the = standard says. >>=20 >>>=20 >>> IN our implementation, even if the IETF decides on an an alternate >>> encoding for the identity, we'll end up synthesizing an identity = request >>> and doing something with the identity response. >>>=20 >>> With a standard EAP library that is lock-step in the manner you >>> describe, it's far easier to produce a synthetic identity request in = the >>> initiator than to hack the state machine or do anything else. =20 >>=20 >> As I said synthesizing an EAP request is another type of hack, = because the EAP protocol does not work like that. We have a RFC 3748 and = RFC 5247 where the EAP protocol is defined. I believe it would be good = if we follow the standards. >>=20 >>> Think of >>> it this way. In GSS-EAP, the identity request is generated by a = party >>> very close to the initiator. EAP already supports the identity = request >>> being generated by a different party than the actual EAP messages. = Why >>> does it matter whether the request comes from inside the peer or = from a >>> NAS? >>=20 >>=20 >> Regarding this, you need to think about the mode independence = property of EAP where: >>=20 >> "As far as the EAP peer is concerned, its conversation with the EAP = authenticator, and all=20 >> consequences of that conversation, are identical, regardless of the = authenticator mode of operation." >>=20 >> In other words, under peer standpoint, all EAP requests are coming = from the EAP authenticator (the peer does not know and do not care if = there is a backend EAP server or it is integrated with the = authenticator).=20 >>=20 >>=20 >>>=20 >>>=20 >>> Rafa> or directly at GSS-API >>> Rafa> level you create a EAP response/identity and include the >>> Rafa> identity (which seems weird taking into account that we have >>> Rafa> an EAP stack in charge of creating EAP messages) >>>=20 >>> But if you don't create an EAP response/identity on the initiator = you >>> probably do have to do it on the acceptor to trigger AAA to use EAP. >>=20 >> I don't think you need to do that. As I explained in the previous = e-mail, in RADIUS EAP (RFC 3579) you can find this text: >>=20 >> "Rather than sending an initial EAP-Request packet to the >> authenticating peer, on detecting the presence of the peer, the NAS >> MAY send an Access-Request packet to the RADIUS server containing an >> EAP-Message attribute signifying EAP-Start. The RADIUS server will >> typically respond with an Access-Challenge containing EAP-Message >> attribute(s) encapsulating an EAP-Request/Identity (Type 1). >> However, an EAP-Request for an authentication method (Type 4 or >> greater) can also be sent by the server. >>=20 >> EAP-Start is indicated by sending an EAP-Message attribute with a >> length of 2 (no data)." >>=20 >>=20 >> In other words, once the acceptor knows the peer's identity can send = that EAP-start message in a RADIUS Access-Challenge. Moreover it should = include the user-name in the request. With that, the RADIUS EAP server = should start the EAP method selected for that peer. >>=20 >>=20 >>>=20 >>> Rafa> Personally, I do not like either (considering the standard = RFC >>> Rafa> 3748). So, I would prefer to define a subtoken for this. >>>=20 >>> We can do that. It means faking up an identity response on the >>> acceptor. But that is certainly not a big deal. >>=20 >> As explained, you do not need to fake up any identity response on the = acceptor. Just follow what RFC 3579 says. >>=20 >>>=20 >>> --Sam >>=20 >> ------------------------------------------------------- >> Rafael Marin Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >=20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- >=20 >=20 >=20 >=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Tue Oct 18 15:24:01 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8208721F8B1D; Tue, 18 Oct 2011 15:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+jbE9DY5-u5; Tue, 18 Oct 2011 15:24:01 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E24F921F8B1C; Tue, 18 Oct 2011 15:24:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8283E202C9; Tue, 18 Oct 2011 18:25:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C78F54235; Tue, 18 Oct 2011 18:23:48 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> Date: Tue, 18 Oct 2011 18:23:48 -0400 In-Reply-To: <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> (Rafa Marin Lopez's message of "Wed, 19 Oct 2011 00:06:38 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 19 Oct 2011 07:56:03 -0700 Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [Emu] [abfab] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 22:24:01 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> Hi Sam: El 18/10/2011, a las 18:55, Sam Hartman escribió: >>>>>>> "Rafa" == Rafa Marin Lopez writes: >> Rafa> Hi Sam: El 18/10/2011, a las 17:35, Sam Hartman escribió: >> >>>> I think I may have been unclear in what I was proposing. I'm >>>> proposing that the peer send its identity in the first message >>>> (*) and that the server gets to respond with type 4 or greater >>>> (a specific EAP method). >> Rafa> Sending its identity does not mean that it must be carried in Rafa> the EAP response/identity. In fact what I suggested is to Rafa> carry the identity in the first message but not contained in Rafa> the EAP response/identity. >> >> OK. Why not carry it in the EAP response/identity? It seems >> easier than developing new encoding. Rafa> Basically EAP is a lock-step protocol where it is required to Rafa> get a request to obtain a response (in the peer side)). So the Rafa> EAP peer state machine implementing the EAP standard protocol Rafa> will react after receiving an EAP request. So I see two Rafa> options: either you hack the EAP peer state machine to return Rafa> an EAP response/identity without receiving any EAP Rafa> request/identity (this "violates" the standard and so we need Rafa> to hack the EAP peer state machine) Or the initiator synthesizes a request and feeds it to the peer's state machine. IN our implementation, even if the IETF decides on an an alternate encoding for the identity, we'll end up synthesizing an identity request and doing something with the identity response. With a standard EAP library that is lock-step in the manner you describe, it's far easier to produce a synthetic identity request in the initiator than to hack the state machine or do anything else. Think of it this way. In GSS-EAP, the identity request is generated by a party very close to the initiator. EAP already supports the identity request being generated by a different party than the actual EAP messages. Why does it matter whether the request comes from inside the peer or from a NAS? Rafa> or directly at GSS-API Rafa> level you create a EAP response/identity and include the Rafa> identity (which seems weird taking into account that we have Rafa> an EAP stack in charge of creating EAP messages) But if you don't create an EAP response/identity on the initiator you probably do have to do it on the acceptor to trigger AAA to use EAP. Rafa> Personally, I do not like either (considering the standard RFC Rafa> 3748). So, I would prefer to define a subtoken for this. We can do that. It means faking up an identity response on the acceptor. But that is certainly not a big deal. --Sam From lukeh@padl.com Tue Oct 18 16:15:37 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48E7B21F8AF2; Tue, 18 Oct 2011 16:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.39 X-Spam-Level: X-Spam-Status: No, score=-0.39 tagged_above=-999 required=5 tests=[AWL=2.209, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC1MQ6hRGIKi; Tue, 18 Oct 2011 16:15:36 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id B64CA21F8AEC; Tue, 18 Oct 2011 16:15:36 -0700 (PDT) Received: by us.padl.com with ESMTP id p9INFGdu026501; Tue, 18 Oct 2011 19:15:22 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Luke Howard In-Reply-To: Date: Wed, 19 Oct 2011 10:15:13 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <60B2C6CF-BD2E-45AC-8295-EFEB4A57676B@padl.com> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 X-Mailman-Approved-At: Wed, 19 Oct 2011 07:56:03 -0700 Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [Emu] [abfab] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 23:15:37 -0000 > With a standard EAP library that is lock-step in the manner you > describe, it's far easier to produce a synthetic identity request in = the > initiator than to hack the state machine or do anything else. Think = of Right, I actually tried to hack the state machine as described in a very = early iteration and, with the library we used, it just didn't work. -- Luke= From lukeh@padl.com Wed Oct 19 04:45:45 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4B421F8797; Wed, 19 Oct 2011 04:45:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.495 X-Spam-Level: X-Spam-Status: No, score=-1.495 tagged_above=-999 required=5 tests=[AWL=1.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwJIMY6d91ru; Wed, 19 Oct 2011 04:45:45 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7C621F84DF; Wed, 19 Oct 2011 04:45:45 -0700 (PDT) Received: by us.padl.com with ESMTP id p9JBjZKK019893; Wed, 19 Oct 2011 07:45:38 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Luke Howard In-Reply-To: <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> Date: Wed, 19 Oct 2011 22:45:35 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <83857EE9-2988-4FE3-A8E9-19D37D3FAEAF@padl.com> References: <709C6240-B6E0-43AD-8B83-60FE0E4E974E@um.es> <11106804-0D9F-4EC5-BD0E-1D35B966AF3B@um.es> <97A479D2-C633-42E4-9CAE-2868B94B7AF8@um.es> <8986EAAD-83DA-4385-A8D4-AE9BFC51217A@um.es> To: Rafa Marin Lopez X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 X-Mailman-Approved-At: Wed, 19 Oct 2011 07:56:03 -0700 Cc: abfab@ietf.org, Sam Hartman , emu@ietf.org Subject: Re: [Emu] [abfab] GSS-EAP: do we ned an identity request X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 11:45:46 -0000 Also, this is probably neither here nor there, but NegoEx provides for = server-initiated context establishment (i.e. the first token is emitted = by the acceptor). I seem to have lost the reference to this, although = NegoEx is otherwise specified in draft-zhu-negoex-04. -- Luke= From hzhou@cisco.com Wed Oct 19 12:31:36 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B0C11E80C9 for ; Wed, 19 Oct 2011 12:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHEujhR9bQUt for ; Wed, 19 Oct 2011 12:31:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A001F11E80B6 for ; Wed, 19 Oct 2011 12:31:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=8087; q=dns/txt; s=iport; t=1319052694; x=1320262294; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=o45AGoGfD+r5Rpp1VBhb7hjBAz2x/NpszWf9mMco/RI=; b=msQL+AqcDZhJyytvtK+6bIAq51YkraoO4tkrfo4P1l09iKbBEpiaUowG Uz/NRNs40ObqtWlnRoGb7Lu/ISjF6gVStN2b6+iJ0RTlxUxmARo1qHqUs AyH+kJgC9yvt2lSdoDY4/3JiZrBlUjGSnotRKXgxofahIz4utVSea8Vn/ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4HAPQkn06tJV2d/2dsb2JhbAA7Cah+AoEFgW4BAQEDAQEBAQ8BJwIBCicLBQ0BCA5fMAEBBAENBSKHXgiXQQGQF44tBIRtgy4Ek36FM4xA X-IronPort-AV: E=Sophos;i="4.69,373,1315180800"; d="scan'208";a="29601383" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 19 Oct 2011 19:31:32 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9JJVW3p027838; Wed, 19 Oct 2011 19:31:32 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 14:31:32 -0500 Received: from 64.101.219.108 ([64.101.219.108]) by XMB-RCD-202.cisco.com ([72.163.62.209]) via Exchange Front-End Server email.cisco.com ([72.163.62.204]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Oct 2011 19:31:32 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Wed, 19 Oct 2011 15:31:28 -0400 From: Hao Zhou To: Jim Schaad , Message-ID: Thread-Topic: [Emu] Comments on the eap-tunnel-method-00 draft Thread-Index: AcyNGRCgSasgwXEiQuKcg/EGCRfGNgBfKGxI In-Reply-To: <001401cc8d19$3d7ad260$b8707720$@augustcellars.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Oct 2011 19:31:32.0607 (UTC) FILETIME=[B512A0F0:01CC8E95] Cc: emu@ietf.org Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:31:36 -0000 Jim: Thanks for reviewing the draft in detail and comments provided. Please see my response inline below. On 10/17/11 6:08 PM, "Jim Schaad" wrote: > I have gathered these comments over time and therefore some of them are not > fully fleshed out. If you have any questions I will try and reconstruct my > ideas at the time. > > Jim > > > > Version Negotiation - terminate the conversation - w or w/o a fail? > Edge case - what if peer only supports a higher version than the > server supports? NAK? > [HZ] It depends. Server might want to proceed with other EAP type negotiation by proposing a different EAP type, or terminate the conversation with an EAP-Failure. I will clarify that in the next rev. > EAP Server Name Checking - On what basis does the client accept or not > accept the EAP server name? You are suggesting that it is signed by a CA > controlling the intended domain, but what does this mean? Are you > suggesting that the CA should have a DNS subject alt name in it for the > domain in question? > [HZ] It's up to client's policy, especially if the server cert is issued by a public CA. Client needs not only verify that the server cert presented is a valid cert signed by the trusted CA, but also the server name presented in the cert is matching the domain it tried to authenticate with. A FQDN in the CN or SAN would be a way to do it. > If no embedded EAP methods run, then no crypto check and thus no version # > checking is done. [HZ] That's true. >Also no checking done if only one inner EAP method is > used as this only sends the Result TLV and not the Crypto-Binding TLV > [HZ] That's not true. Crypto-binding would still be exchanged with Result TLV. Actually using of the Result TLV in lieu of IM-Result TLV is for legacy reason in EAP-FAST, which could be removed in next rev since we are designing a new EAP method. > 'serially in a sequence' is redundant - section 3.3.1 > [HZ] Ok. The text is trying to distinguish from running multiple EAP methods in parallel. > Not only does it not allow initiating multiple EAP methods in parallel, it > requires that they not be running in parallel. This is a more strict > condition > [HZ] For simplicity, otherwise implementation would need to trace when the 1st method finishes and applies the key from the authentication to the crypto-binding. Supporting them in complete sequence makes it simpler and securer, as 2nd method might not be safe to run if the crypto-binging after 1st method fails. > Para #3 - can the peer return an error and treat the failure of a specific > EAP method as a total failure for the overall process - or at least > recommend that it should be an overall failure? > [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send up some Fatal Error TLV and Result TLV to indicate the end. > Confused messages in 3.3.1 and 3.3.3 about sending intermediate results and > final results at the same time. Specifically 3.3.1 says MUST NOT for one > inner EAP method, but text is not reflected in section 3.3.3 > [HZ] I think we can change to always send IM result after each inner EAP method, if only one inner method, then Result TLV could be sent as well. See explanation above. > Conflict between 3.3.3 and security considerations (7.5) about sending a > different value in the Result TLV and the clear result in the event of not > doing a Request-Action TLV from the client. Is the server required to use > the client suggested result in the event it does not perform the request > action - could it use a different failure message or a success message? > Does it matter? > [HZ] Server is supposed to send the suggested Result code in Request-Action TLV if it refuse to do the action, this way peer will get notify about the final result and in-sync with the clear text EAP-Success/Failure packet. Probably doesn't matter what the server sends, client would set the final result base on its policy. > Section 3.4 - Need to address the following issues: > 1. what if both certificates and an inner EAP method are run - what is the > Peer-Id then? [HZ] Good question. There were some discussions on this. The new draft rev will propose to use the first authenticated peer identity. The WG can discuss more on this. > 2. What if multiple inner EAP methods are run - which Peer-Id is used then? [HZ] Same as above. > 3. What if client and machine EAP methods are run - which one to use then? > (Internal what are the ids used for?) > [HZ] Again, good question. Same as above. > Section 3.6 - item #2 - it should be noted that not all failure indications > would be transmitted. The failure/success of the last EAP method may not be > sent as it gets wrapped into the Result TLV message > [HZ] Should be fixed with the change on IM result TLV. > Section 3.6.2 - (internal) - if you get a TLV rules violation - does the TLV > itself need to be acknowledged? > [HZ] Probably no need to, as it is fatal and other side probably already terminated the tunnel. > Section 3.7 - Can I assume that the identifier value is monotonically > increasing and does not wrap? > [HZ] Yes. We shouldn't exceed the maximum number (256) for Identifier in a single EAP authentication, at least I hope not. > Section 3.7 - it might be useful to tell me how to error for a message too > big or response time too long in dealing with fragmentation - are both just > final errors? Or should it potentially be treated as a TLS error? > [HZ] Most likely it will be TLS error if one side is having trouble to receive or assemble the whole message. Additional error code could be defined to convey this. > Section 3.2 - possible clarification. If all TLVs in a message are marked > optional and none are understood by the peer, then an EMPTY response message > must still be sent to the server. > [HZ] yes. I will add that. > Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding TLV - > not what it says in section 3.3 > [HZ] It says " A Result TLV indicating failure", as it doesn't matter anymore, the whole EAP authentication will fail. Section 3.3 is talking about a successful Result TLV. > Section 4.2.3 - NAK TLV should not be accompanied by other TLVs. Not sure > I understand why. If I send an EAP plus a vendor w/ mandatory set, should > not I get back a NAK on the vendor plus a result for the EAP? > I might be happy to not do the vendor, but want to distinguish between you > cannot do this vs you choose not to do this. care about this case as long I can assume that if the mandatory bit is set > then I would always fail the overall EAP conversation.> > [HZ] Correct, I am not sure there is value sending back the other TLVs, as the authentication should be failed if the mandatory to implement is not supported. > Section 4.2.10 - How can I know if the server does or does not process the > channel binding TLV? This may be part of my policy as a peer depending on > circumstances. > [HZ] Currently, the Channel-binding TLV is an optional TLV, doesn't require acknowledgement, and is designed to be only one way, for client to send some channel binding data to the server for verification purpose. There is no feedback provided. The indication of whether the server supports channel-binding and/or validated the channel-binding could be conveyed in other TLVs to be added, if the WG agrees to be valuable. > Section 4.2.8 - Currently says that version should be 1 while the version > defined in the intro sections is 2 - would be correct if we change the EAP > method. > [HZ] It's the version number of the Crypto-binding TLV, not the EAP version number. The theory is that we could enhance the crypto-binging TLV format in the future if desired. > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From dharkins@lounge.org Wed Oct 19 12:55:30 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B2E21F8B30 for ; Wed, 19 Oct 2011 12:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQ8HYaKVevDc for ; Wed, 19 Oct 2011 12:55:29 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id C529B21F8AD8 for ; Wed, 19 Oct 2011 12:55:29 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 832FDA88810C; Wed, 19 Oct 2011 12:55:28 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 19 Oct 2011 12:55:28 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Wed, 19 Oct 2011 12:55:28 -0700 (PDT) From: "Dan Harkins" To: "Hao Zhou" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:55:30 -0000 Hi Hao, About 6 weeks ago I sent in some detailed comments, notably the request for a new TLV to pass a PKCS#10 to the server to go along with the existing TLV that sends a PKCS#7 to the peer, and for a server unauthenticated provisioning mode, and never heard from the editors of the tunnel method draft. Do you have any response to those comments? regards, Dan. On Wed, October 19, 2011 12:31 pm, Hao Zhou wrote: > Jim: > > Thanks for reviewing the draft in detail and comments provided. Please see > my response inline below. > > > On 10/17/11 6:08 PM, "Jim Schaad" wrote: > >> I have gathered these comments over time and therefore some of them are >> not >> fully fleshed out. If you have any questions I will try and reconstruct >> my >> ideas at the time. >> >> Jim >> >> >> >> Version Negotiation - terminate the conversation - w or w/o a fail? >> Edge case - what if peer only supports a higher version than the >> server supports? NAK? >> > [HZ] It depends. Server might want to proceed with other EAP type > negotiation by proposing a different EAP type, or terminate the > conversation > with an EAP-Failure. I will clarify that in the next rev. > >> EAP Server Name Checking - On what basis does the client accept or not >> accept the EAP server name? You are suggesting that it is signed by a >> CA >> controlling the intended domain, but what does this mean? Are you >> suggesting that the CA should have a DNS subject alt name in it for the >> domain in question? >> > [HZ] It's up to client's policy, especially if the server cert is issued > by > a public CA. Client needs not only verify that the server cert presented > is > a valid cert signed by the trusted CA, but also the server name presented > in > the cert is matching the domain it tried to authenticate with. A FQDN in > the > CN or SAN would be a way to do it. > >> If no embedded EAP methods run, then no crypto check and thus no version >> # >> checking is done. > [HZ] That's true. > >>Also no checking done if only one inner EAP method is >> used as this only sends the Result TLV and not the Crypto-Binding TLV >> > [HZ] That's not true. Crypto-binding would still be exchanged with Result > TLV. Actually using of the Result TLV in lieu of IM-Result TLV is for > legacy > reason in EAP-FAST, which could be removed in next rev since we are > designing a new EAP method. >> 'serially in a sequence' is redundant - section 3.3.1 >> > [HZ] Ok. The text is trying to distinguish from running multiple EAP > methods > in parallel. > >> Not only does it not allow initiating multiple EAP methods in parallel, >> it >> requires that they not be running in parallel. This is a more strict >> condition >> > [HZ] For simplicity, otherwise implementation would need to trace when the > 1st method finishes and applies the key from the authentication to the > crypto-binding. Supporting them in complete sequence makes it simpler and > securer, as 2nd method might not be safe to run if the crypto-binging > after > 1st method fails. > >> Para #3 - can the peer return an error and treat the failure of a >> specific >> EAP method as a total failure for the overall process - or at least >> recommend that it should be an overall failure? >> > [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send > up > some Fatal Error TLV and Result TLV to indicate the end. > >> Confused messages in 3.3.1 and 3.3.3 about sending intermediate results >> and >> final results at the same time. Specifically 3.3.1 says MUST NOT for >> one >> inner EAP method, but text is not reflected in section 3.3.3 >> > [HZ] I think we can change to always send IM result after each inner EAP > method, if only one inner method, then Result TLV could be sent as well. > See > explanation above. >> Conflict between 3.3.3 and security considerations (7.5) about sending a >> different value in the Result TLV and the clear result in the event of >> not >> doing a Request-Action TLV from the client. Is the server required to >> use >> the client suggested result in the event it does not perform the request >> action - could it use a different failure message or a success message? >> Does it matter? >> > [HZ] Server is supposed to send the suggested Result code in > Request-Action > TLV if it refuse to do the action, this way peer will get notify about the > final result and in-sync with the clear text EAP-Success/Failure packet. > Probably doesn't matter what the server sends, client would set the final > result base on its policy. > >> Section 3.4 - Need to address the following issues: >> 1. what if both certificates and an inner EAP method are run - what is >> the >> Peer-Id then? > [HZ] Good question. There were some discussions on this. The new draft rev > will propose to use the first authenticated peer identity. The WG can > discuss more on this. >> 2. What if multiple inner EAP methods are run - which Peer-Id is used >> then? > [HZ] Same as above. >> 3. What if client and machine EAP methods are run - which one to use >> then? >> (Internal what are the ids used for?) >> > [HZ] Again, good question. Same as above. >> Section 3.6 - item #2 - it should be noted that not all failure >> indications >> would be transmitted. The failure/success of the last EAP method may >> not be >> sent as it gets wrapped into the Result TLV message >> > [HZ] Should be fixed with the change on IM result TLV. >> Section 3.6.2 - (internal) - if you get a TLV rules violation - does the >> TLV >> itself need to be acknowledged? >> > [HZ] Probably no need to, as it is fatal and other side probably already > terminated the tunnel. > >> Section 3.7 - Can I assume that the identifier value is monotonically >> increasing and does not wrap? >> > [HZ] Yes. We shouldn't exceed the maximum number (256) for Identifier in a > single EAP authentication, at least I hope not. > >> Section 3.7 - it might be useful to tell me how to error for a message >> too >> big or response time too long in dealing with fragmentation - are both >> just >> final errors? Or should it potentially be treated as a TLS error? >> > [HZ] Most likely it will be TLS error if one side is having trouble to > receive or assemble the whole message. Additional error code could be > defined to convey this. > >> Section 3.2 - possible clarification. If all TLVs in a message are >> marked >> optional and none are understood by the peer, then an EMPTY response >> message >> must still be sent to the server. >> > [HZ] yes. I will add that. > >> Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding TLV >> - >> not what it says in section 3.3 >> > [HZ] It says " A Result TLV indicating failure", as it doesn't matter > anymore, the whole EAP authentication will fail. Section 3.3 is talking > about a successful Result TLV. > >> Section 4.2.3 - NAK TLV should not be accompanied by other TLVs. Not >> sure >> I understand why. If I send an EAP plus a vendor w/ mandatory set, >> should >> not I get back a NAK on the vendor plus a result for the EAP? >> I might be happy to not do the vendor, but want to distinguish between >> you >> cannot do this vs you choose not to do this. > really >> care about this case as long I can assume that if the mandatory bit is >> set >> then I would always fail the overall EAP conversation.> >> > [HZ] Correct, I am not sure there is value sending back the other TLVs, as > the authentication should be failed if the mandatory to implement is not > supported. > >> Section 4.2.10 - How can I know if the server does or does not process >> the >> channel binding TLV? This may be part of my policy as a peer depending >> on >> circumstances. >> > [HZ] Currently, the Channel-binding TLV is an optional TLV, doesn't > require > acknowledgement, and is designed to be only one way, for client to send > some > channel binding data to the server for verification purpose. There is no > feedback provided. The indication of whether the server supports > channel-binding and/or validated the channel-binding could be conveyed in > other TLVs to be added, if the WG agrees to be valuable. > >> Section 4.2.8 - Currently says that version should be 1 while the >> version >> defined in the intro sections is 2 - would be correct if we change the >> EAP >> method. >> > [HZ] It's the version number of the Crypto-binding TLV, not the EAP > version > number. The theory is that we could enhance the crypto-binging TLV format > in > the future if desired. >> >> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From hartmans@mit.edu Wed Oct 19 12:59:57 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66A2311E8099 for ; Wed, 19 Oct 2011 12:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.228 X-Spam-Level: X-Spam-Status: No, score=-103.228 tagged_above=-999 required=5 tests=[AWL=-0.963, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LFq2exdnoHkU for ; Wed, 19 Oct 2011 12:59:57 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0373811E8096 for ; Wed, 19 Oct 2011 12:59:56 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 8728120274; Wed, 19 Oct 2011 16:01:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 89AEC4239; Wed, 19 Oct 2011 15:59:42 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> Date: Wed, 19 Oct 2011 15:59:42 -0400 In-Reply-To: <4E9BFD8E.3000108@toshiba.co.jp> (Yoshihiro Ohba's message of "Mon, 17 Oct 2011 19:03:58 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:59:57 -0000 Hi. I've added PANA (pre-authentication). I wonder about the whole lower layer table. Why is it important to distinguish PANA with pre-auth from pana without pre-auth? Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with pre-auth? I'd appreciate it if someone who cared about network access told me what to do here:-) From hzhou@cisco.com Wed Oct 19 13:00:18 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD1211E8099 for ; Wed, 19 Oct 2011 13:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWEzRxVaA-ZF for ; Wed, 19 Oct 2011 13:00:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 583F311E8098 for ; Wed, 19 Oct 2011 13:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=9788; q=dns/txt; s=iport; t=1319054417; x=1320264017; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=TPJ/54+S96HZ+Yi9kNsF+SOnUHFtsCPuiF4E76jfNsw=; b=Ine/HdXsPCFklF/nIOg7EBSUaaazAbyENRodDyKg6KIK+XarcJ20dcwU Lo02mS0MmYoDGejuGx/7ACnqolX8mIqrvI5JKTl1zk0DU1FQZ9LIQd6vp 54oWPyjR44KntwrA+1Vb8lJtiMhLkZhFYdX/cWShxD2/0RVGW8fonjZtd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4HAOYrn06tJV2b/2dsb2JhbAA7CakCAoEFgW4BAQEDAQEBAQ8BJwIBCicLEgEIDgpVMAEBBA4FIodeCJdAAZAXji0EhG2DLgSTfoUzjEA X-IronPort-AV: E=Sophos;i="4.69,373,1315180800"; d="scan'208";a="29602520" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 19 Oct 2011 20:00:16 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9JK0Ku2029653; Wed, 19 Oct 2011 20:00:20 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 15:00:16 -0500 Received: from 64.101.219.108 ([64.101.219.108]) by XMB-RCD-202.cisco.com ([72.163.62.209]) via Exchange Front-End Server email.cisco.com ([72.163.62.136]) with Microsoft Exchange Server HTTP-DAV ; Wed, 19 Oct 2011 20:00:16 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Wed, 19 Oct 2011 16:00:15 -0400 From: Hao Zhou To: Dan Harkins Message-ID: Thread-Topic: [Emu] Comments on the eap-tunnel-method-00 draft Thread-Index: AcyOmbeyxikP96GJSk6ubR5ZI4Td4w== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Oct 2011 20:00:16.0621 (UTC) FILETIME=[B8AA49D0:01CC8E99] Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 20:00:18 -0000 Dan: Thanks for the review comments. Sorry for not responding right away. The current plan is that we will publish a new revision today with the name change and etc, and Joe will start an issue list including the comments you made, as it will require some WG discussion, and then we will make another revision once we have consensus on them. On 10/19/11 3:55 PM, "Dan Harkins" wrote: > > Hi Hao, > > About 6 weeks ago I sent in some detailed comments, notably > the request for a new TLV to pass a PKCS#10 to the server to go > along with the existing TLV that sends a PKCS#7 to the peer, and > for a server unauthenticated provisioning mode, and never heard > from the editors of the tunnel method draft. > > Do you have any response to those comments? > > regards, > > Dan. > > On Wed, October 19, 2011 12:31 pm, Hao Zhou wrote: >> Jim: >> >> Thanks for reviewing the draft in detail and comments provided. Please see >> my response inline below. >> >> >> On 10/17/11 6:08 PM, "Jim Schaad" wrote: >> >>> I have gathered these comments over time and therefore some of them are >>> not >>> fully fleshed out. If you have any questions I will try and reconstruct >>> my >>> ideas at the time. >>> >>> Jim >>> >>> >>> >>> Version Negotiation - terminate the conversation - w or w/o a fail? >>> Edge case - what if peer only supports a higher version than the >>> server supports? NAK? >>> >> [HZ] It depends. Server might want to proceed with other EAP type >> negotiation by proposing a different EAP type, or terminate the >> conversation >> with an EAP-Failure. I will clarify that in the next rev. >> >>> EAP Server Name Checking - On what basis does the client accept or not >>> accept the EAP server name? You are suggesting that it is signed by a >>> CA >>> controlling the intended domain, but what does this mean? Are you >>> suggesting that the CA should have a DNS subject alt name in it for the >>> domain in question? >>> >> [HZ] It's up to client's policy, especially if the server cert is issued >> by >> a public CA. Client needs not only verify that the server cert presented >> is >> a valid cert signed by the trusted CA, but also the server name presented >> in >> the cert is matching the domain it tried to authenticate with. A FQDN in >> the >> CN or SAN would be a way to do it. >> >>> If no embedded EAP methods run, then no crypto check and thus no version >>> # >>> checking is done. >> [HZ] That's true. >> >>> Also no checking done if only one inner EAP method is >>> used as this only sends the Result TLV and not the Crypto-Binding TLV >>> >> [HZ] That's not true. Crypto-binding would still be exchanged with Result >> TLV. Actually using of the Result TLV in lieu of IM-Result TLV is for >> legacy >> reason in EAP-FAST, which could be removed in next rev since we are >> designing a new EAP method. >>> 'serially in a sequence' is redundant - section 3.3.1 >>> >> [HZ] Ok. The text is trying to distinguish from running multiple EAP >> methods >> in parallel. >> >>> Not only does it not allow initiating multiple EAP methods in parallel, >>> it >>> requires that they not be running in parallel. This is a more strict >>> condition >>> >> [HZ] For simplicity, otherwise implementation would need to trace when the >> 1st method finishes and applies the key from the authentication to the >> crypto-binding. Supporting them in complete sequence makes it simpler and >> securer, as 2nd method might not be safe to run if the crypto-binging >> after >> 1st method fails. >> >>> Para #3 - can the peer return an error and treat the failure of a >>> specific >>> EAP method as a total failure for the overall process - or at least >>> recommend that it should be an overall failure? >>> >> [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send >> up >> some Fatal Error TLV and Result TLV to indicate the end. >> >>> Confused messages in 3.3.1 and 3.3.3 about sending intermediate results >>> and >>> final results at the same time. Specifically 3.3.1 says MUST NOT for >>> one >>> inner EAP method, but text is not reflected in section 3.3.3 >>> >> [HZ] I think we can change to always send IM result after each inner EAP >> method, if only one inner method, then Result TLV could be sent as well. >> See >> explanation above. >>> Conflict between 3.3.3 and security considerations (7.5) about sending a >>> different value in the Result TLV and the clear result in the event of >>> not >>> doing a Request-Action TLV from the client. Is the server required to >>> use >>> the client suggested result in the event it does not perform the request >>> action - could it use a different failure message or a success message? >>> Does it matter? >>> >> [HZ] Server is supposed to send the suggested Result code in >> Request-Action >> TLV if it refuse to do the action, this way peer will get notify about the >> final result and in-sync with the clear text EAP-Success/Failure packet. >> Probably doesn't matter what the server sends, client would set the final >> result base on its policy. >> >>> Section 3.4 - Need to address the following issues: >>> 1. what if both certificates and an inner EAP method are run - what is >>> the >>> Peer-Id then? >> [HZ] Good question. There were some discussions on this. The new draft rev >> will propose to use the first authenticated peer identity. The WG can >> discuss more on this. >>> 2. What if multiple inner EAP methods are run - which Peer-Id is used >>> then? >> [HZ] Same as above. >>> 3. What if client and machine EAP methods are run - which one to use >>> then? >>> (Internal what are the ids used for?) >>> >> [HZ] Again, good question. Same as above. >>> Section 3.6 - item #2 - it should be noted that not all failure >>> indications >>> would be transmitted. The failure/success of the last EAP method may >>> not be >>> sent as it gets wrapped into the Result TLV message >>> >> [HZ] Should be fixed with the change on IM result TLV. >>> Section 3.6.2 - (internal) - if you get a TLV rules violation - does the >>> TLV >>> itself need to be acknowledged? >>> >> [HZ] Probably no need to, as it is fatal and other side probably already >> terminated the tunnel. >> >>> Section 3.7 - Can I assume that the identifier value is monotonically >>> increasing and does not wrap? >>> >> [HZ] Yes. We shouldn't exceed the maximum number (256) for Identifier in a >> single EAP authentication, at least I hope not. >> >>> Section 3.7 - it might be useful to tell me how to error for a message >>> too >>> big or response time too long in dealing with fragmentation - are both >>> just >>> final errors? Or should it potentially be treated as a TLS error? >>> >> [HZ] Most likely it will be TLS error if one side is having trouble to >> receive or assemble the whole message. Additional error code could be >> defined to convey this. >> >>> Section 3.2 - possible clarification. If all TLVs in a message are >>> marked >>> optional and none are understood by the peer, then an EMPTY response >>> message >>> must still be sent to the server. >>> >> [HZ] yes. I will add that. >> >>> Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding TLV >>> - >>> not what it says in section 3.3 >>> >> [HZ] It says " A Result TLV indicating failure", as it doesn't matter >> anymore, the whole EAP authentication will fail. Section 3.3 is talking >> about a successful Result TLV. >> >>> Section 4.2.3 - NAK TLV should not be accompanied by other TLVs. Not >>> sure >>> I understand why. If I send an EAP plus a vendor w/ mandatory set, >>> should >>> not I get back a NAK on the vendor plus a result for the EAP? >>> I might be happy to not do the vendor, but want to distinguish between >>> you >>> cannot do this vs you choose not to do this. >> really >>> care about this case as long I can assume that if the mandatory bit is >>> set >>> then I would always fail the overall EAP conversation.> >>> >> [HZ] Correct, I am not sure there is value sending back the other TLVs, as >> the authentication should be failed if the mandatory to implement is not >> supported. >> >>> Section 4.2.10 - How can I know if the server does or does not process >>> the >>> channel binding TLV? This may be part of my policy as a peer depending >>> on >>> circumstances. >>> >> [HZ] Currently, the Channel-binding TLV is an optional TLV, doesn't >> require >> acknowledgement, and is designed to be only one way, for client to send >> some >> channel binding data to the server for verification purpose. There is no >> feedback provided. The indication of whether the server supports >> channel-binding and/or validated the channel-binding could be conveyed in >> other TLVs to be added, if the WG agrees to be valuable. >> >>> Section 4.2.8 - Currently says that version should be 1 while the >>> version >>> defined in the intro sections is 2 - would be correct if we change the >>> EAP >>> method. >>> >> [HZ] It's the version number of the Crypto-binding TLV, not the EAP >> version >> number. The theory is that we could enhance the crypto-binging TLV format >> in >> the future if desired. >>> >>> >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >> > > From internet-drafts@ietf.org Wed Oct 19 13:07:50 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B002C11E80A6; Wed, 19 Oct 2011 13:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeAFiTGBO32e; Wed, 19 Oct 2011 13:07:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519D221F8ABE; Wed, 19 Oct 2011 13:07:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111019200750.30668.20455.idtracker@ietfa.amsl.com> Date: Wed, 19 Oct 2011 13:07:50 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-chbind-10.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 20:07:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of th= e IETF. Title : Channel Binding Support for EAP Methods Author(s) : Sam Hartman T. Charles Clancy Katrin Hoeper Filename : draft-ietf-emu-chbind-10.txt Pages : 30 Date : 2011-10-19 This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-chbind-10.txt From hartmans@mit.edu Wed Oct 19 13:09:23 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C9B11E8098 for ; Wed, 19 Oct 2011 13:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.132 X-Spam-Level: X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ayoYu2WE2K27 for ; Wed, 19 Oct 2011 13:09:22 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF5311E808A for ; Wed, 19 Oct 2011 13:09:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6E5FF20274 for ; Wed, 19 Oct 2011 16:10:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 86C1A4239; Wed, 19 Oct 2011 16:09:08 -0400 (EDT) From: Sam Hartman To: emu@ietf.org Date: Wed, 19 Oct 2011 16:09:08 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 20:09:23 -0000 I believe I've addressed all of Alan's comments with the exception of removing the RADIUS diagram from 5.3. Thanks Alan for the comments! --Sam From dharkins@lounge.org Wed Oct 19 15:53:06 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EBFC11E80B8 for ; Wed, 19 Oct 2011 15:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAmAiMtB92L0 for ; Wed, 19 Oct 2011 15:53:05 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4E11111E808A for ; Wed, 19 Oct 2011 15:52:57 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9E015A88810C; Wed, 19 Oct 2011 15:52:49 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 19 Oct 2011 15:52:49 -0700 (PDT) Message-ID: <49c04a893d1b09695022a8ea4fd3f7a9.squirrel@www.trepanning.net> In-Reply-To: References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> Date: Wed, 19 Oct 2011 15:52:49 -0700 (PDT) From: "Dan Harkins" To: "Sam Hartman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:53:06 -0000 Hi Sam, On Wed, October 19, 2011 12:59 pm, Sam Hartman wrote: > Hi. I've added PANA (pre-authentication). > > I wonder about the whole lower layer table. > Why is it important to distinguish PANA with pre-auth from pana without > pre-auth? > > Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with > pre-auth? > > I'd appreciate it if someone who cared about network access told me what > to do here:-) You can collapse wpa, wpa2 and wpa2 with preauth. wpa and wpa2 are both actually trademarked terms of the Wi-Fi Alliance so they should probably not be in an IANA registry anyway. Regardless, though, they all do the same thing by conveying the same type of information in the same way. 802.11s specifies a password-based authentication scheme that does not use EAP so there doesn't seem to be a reason to define an "EAP lower layer" for 802.11s. 802.11r does things a little differently-- a key hierarchy is built up and keys are distributed hither and yon-- so it might be good to channel bind that stuff but 802.11r has been rolled into the 802.11 standard (there is no stand-alone reference for 802.11r, by the way) and can be dealt with as just 802.11. All the "information elements" that specify that 11r-specific stuff is being communicated are defined by 802.11's Assigned Number Authority and their communication is done in the same fashion as plain-jane 802.11 (aka wpa and wpa2). If "information elements" for 802.11r are included in the 802.11 channel binding data then it means the session is going to be used for 802.11r-type stuff. Values 4-8 in the table in section 11.1 can all be combined into a single value named "802.11" with a reference to IEEE 802.11-2007. regards, Dan. From yoshihiro.ohba@toshiba.co.jp Wed Oct 19 16:32:47 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3253A21F8AC9 for ; Wed, 19 Oct 2011 16:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8s2YtAbVe+v for ; Wed, 19 Oct 2011 16:32:46 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1B09E21F8AB9 for ; Wed, 19 Oct 2011 16:32:45 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p9JNWh5S027561; Thu, 20 Oct 2011 08:32:43 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id p9JNWgKj005896; Thu, 20 Oct 2011 08:32:42 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA05895; Thu, 20 Oct 2011 08:32:42 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p9JNWgP0022140; Thu, 20 Oct 2011 08:32:42 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p9JNX82H022802; Thu, 20 Oct 2011 08:33:08 +0900 (JST) Received: from [133.196.17.84] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LTC005TR6QH2M40@mail.po.toshiba.co.jp>; Thu, 20 Oct 2011 08:32:42 +0900 (JST) Date: Thu, 20 Oct 2011 08:32:41 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <4E9F5E19.7060401@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Cc: emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 23:32:47 -0000 Hi Sam, Please see my comments below. (2011/10/18 23:02), Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba writes: > > Yoshihiro> [1] As far as I understand, the method-based channel > Yoshihiro> binding is not applicable to ERP. For completeness of > Yoshihiro> the specification it may be good to add some text to > Yoshihiro> clarify this. > > I'd welcome suggestions. > I'm not really familiar with ERP. OK. My suggestion is to modify the following text in Section 4.2: " For many deployments, changing all the NASes is expensive and adding channel binding support to enough EAP methods to meet the goals of the deployment will be cheaper. However for deployment of new equipment, or especially deployment of a new lower layer technology, changing the NASes may be cheaper than changing EAP methods. Especially if such a deployment needed to support a large number of EAP methods, sending channel bindings in the secure association protocol might make sense. " to: " For many deployments, changing all the NASes is expensive and adding channel binding support to enough EAP methods to meet the goals of the deployment will be cheaper. However for deployment of new equipment, or especially deployment of a new lower layer technology, changing the NASes may be cheaper than changing EAP methods. Especially if such a deployment needed to support a large number of EAP methods, sending channel bindings in the secure association protocol might make sense. Sending channel bindings in the secure association protocol can work even with ERP [RFC5296] in which previously established EAP key material is used for the secure association protocol without carrying out any EAP method during re-authentication. " > > Yoshihiro> [3] Probably this was discussed in the WG, but I want to > Yoshihiro> understand the motivation for the namespace in Channel > Yoshihiro> Binding Encoding because it seems to be a hard > Yoshihiro> requirement if the peer has to know what namespace (or > Yoshihiro> protocol) is being used between an EAP authenticator and > Yoshihiro> EAP server. Also, in some case, the channel binding > Yoshihiro> operation may be performed with a standalone > Yoshihiro> authenticator since, due to EAP's mode independence > Yoshihiro> property, the peer does not know whether the > Yoshihiro> authenticator it is talking to is a pass-through > Yoshihiro> authenticator or a stand-alone one. What namespace > Yoshihiro> should be used with a standalone authenticator? > > The namespace ID simply names where the attribute comes from. If you > are describing some value that is available in a RADIUS ID, then you > should use the RADIUS namespace. The EAP server (which as you point out > may be the authenticator) is responsible for matching up that > information in whatever form it has it. > > For attributes available both in the diameter and RADIUS namespaces I'd > expect some lower layer document to describe which one to use regardless > of whether an AAA protocol is in use or which one is in use. > So it seems there is a requirement for lower-layer protocols or profiles to describe about the channel binding namespace. Shouldn't such a requirement be explicitly mentioned in this document? Yoshihiro Ohba From ietf@augustcellars.com Wed Oct 19 16:55:28 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0350D11E80AF for ; Wed, 19 Oct 2011 16:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJ1jSNwRFReR for ; Wed, 19 Oct 2011 16:55:26 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 74EF121F845B for ; Wed, 19 Oct 2011 16:55:26 -0700 (PDT) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 2DB582CA08; Wed, 19 Oct 2011 16:55:26 -0700 (PDT) From: "Jim Schaad" To: "'Hao Zhou'" , , "Sam Hartman" References: <001401cc8d19$3d7ad260$b8707720$@augustcellars.com> In-Reply-To: Date: Wed, 19 Oct 2011 16:54:59 -0700 Message-ID: <016f01cc8eba$82f4bc00$88de3400$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHrnjAPJJjB8NXO0W/H1Z8pisL1y5VGMmWQ Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 23:55:28 -0000 > -----Original Message----- > From: Hao Zhou [mailto:hzhou@cisco.com] > Sent: Wednesday, October 19, 2011 12:31 PM > To: Jim Schaad; draft-ietf-emu-eap-tunnel-method@tools.ietf.org > Cc: emu@ietf.org > Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft > > Jim: > > Thanks for reviewing the draft in detail and comments provided. Please see > my response inline below. > > > On 10/17/11 6:08 PM, "Jim Schaad" wrote: > > > I have gathered these comments over time and therefore some of them > > are not fully fleshed out. If you have any questions I will try and > > reconstruct my ideas at the time. > > > > Jim > > > > > > > > Version Negotiation - terminate the conversation - w or w/o a fail? > > Edge case - what if peer only supports a higher version than the > > server supports? NAK? > > > [HZ] It depends. Server might want to proceed with other EAP type > negotiation by proposing a different EAP type, or terminate the conversation > with an EAP-Failure. I will clarify that in the next rev. Yes - but in this case I would expect a NAK from the client - possibly proposing other methods. Is this correct? > > > EAP Server Name Checking - On what basis does the client accept or not > > accept the EAP server name? You are suggesting that it is signed by a CA > > controlling the intended domain, but what does this mean? Are you > > suggesting that the CA should have a DNS subject alt name in it for > > the domain in question? > > > [HZ] It's up to client's policy, especially if the server cert is issued by a public > CA. Client needs not only verify that the server cert presented is a valid cert > signed by the trusted CA, but also the server name presented in the cert is > matching the domain it tried to authenticate with. A FQDN in the CN or SAN > would be a way to do it. > > > If no embedded EAP methods run, then no crypto check and thus no > > version # checking is done. > [HZ] That's true. Ok - this would be in violation of the last paragraph in section 3.1 which says that the version numbers MUST be done. > > >Also no checking done if only one inner EAP method is used as this > >only sends the Result TLV and not the Crypto-Binding TLV > > > [HZ] That's not true. Crypto-binding would still be exchanged with Result TLV. > Actually using of the Result TLV in lieu of IM-Result TLV is for legacy reason in > EAP-FAST, which could be removed in next rev since we are designing a new > EAP method. Please tell me where it says this is done. All I can see is that one CAN send intermediate-result, result and crypto-binding TLVs in the same message. (Unless of course only one is sent in which case the Intermediate-Reuslt TLV MUST NOT be sent). However these is nothing that says that the Crypto-binding TLV would be sent after the first and only EAP method - or indeed after a sequence of EAP methods. > > 'serially in a sequence' is redundant - section 3.3.1 > > > [HZ] Ok. The text is trying to distinguish from running multiple EAP methods > in parallel. > > > Not only does it not allow initiating multiple EAP methods in > > parallel, it requires that they not be running in parallel. This is a > > more strict condition > > > [HZ] For simplicity, otherwise implementation would need to trace when the > 1st method finishes and applies the key from the authentication to the > crypto-binding. Supporting them in complete sequence makes it simpler and > securer, as 2nd method might not be safe to run if the crypto-binging after > 1st method fails. Do you ever expect a version to allow multiple EAP sequences to be run at the same time? If not then just the statement that they MUST be executed serially is probably sufficient. > > > Para #3 - can the peer return an error and treat the failure of a > > specific EAP method as a total failure for the overall process - or at > > least recommend that it should be an overall failure? > > > [HZ] Yes it can. It is actually described in Section 3.6.2, peer can send up some > Fatal Error TLV and Result TLV to indicate the end. Ok - either I don't see the text or my comment is not sufficiently clear. Consider: Client is running EAP-BLAH and returns inside of the EAP-BLAH method a failure. If the client wants an overall failure rather than leaving it up to the server, does it send both the Result TLV failure and the EAP-Message w/ the failure - or just the result TLV failure or is this not reasonable for the client? > > > Confused messages in 3.3.1 and 3.3.3 about sending intermediate > > results and final results at the same time. Specifically 3.3.1 says > > MUST NOT for one inner EAP method, but text is not reflected in > > section 3.3.3 > > > [HZ] I think we can change to always send IM result after each inner EAP > method, if only one inner method, then Result TLV could be sent as well. See > explanation above. > > Conflict between 3.3.3 and security considerations (7.5) about sending > > a different value in the Result TLV and the clear result in the event > > of not doing a Request-Action TLV from the client. Is the server > > required to use the client suggested result in the event it does not > > perform the request action - could it use a different failure message or a > success message? > > Does it matter? > > > [HZ] Server is supposed to send the suggested Result code in Request-Action > TLV if it refuse to do the action, this way peer will get notify about the final > result and in-sync with the clear text EAP-Success/Failure packet. > Probably doesn't matter what the server sends, client would set the final > result base on its policy. Based on my reading I would not have thought that the server was to send a SECOND (and yes different) Result TLV in this case. > > > Section 3.4 - Need to address the following issues: > > 1. what if both certificates and an inner EAP method are run - what > > is the Peer-Id then? > [HZ] Good question. There were some discussions on this. The new draft rev > will propose to use the first authenticated peer identity. The WG can discuss > more on this. > > 2. What if multiple inner EAP methods are run - which Peer-Id is used > then? > [HZ] Same as above. > > 3. What if client and machine EAP methods are run - which one to use > then? > > (Internal what are the ids used for?) > > > [HZ] Again, good question. Same as above. What are you referring to for same as above? > > Section 3.6 - item #2 - it should be noted that not all failure > > indications would be transmitted. The failure/success of the last EAP > > method may not be sent as it gets wrapped into the Result TLV message > > > [HZ] Should be fixed with the change on IM result TLV. > > Section 3.6.2 - (internal) - if you get a TLV rules violation - does > > the TLV itself need to be acknowledged? > > > [HZ] Probably no need to, as it is fatal and other side probably already > terminated the tunnel. > > > Section 3.7 - Can I assume that the identifier value is monotonically > > increasing and does not wrap? > > > [HZ] Yes. We shouldn't exceed the maximum number (256) for Identifier in a > single EAP authentication, at least I hope not. > > > Section 3.7 - it might be useful to tell me how to error for a message > > too big or response time too long in dealing with fragmentation - are > > both just final errors? Or should it potentially be treated as a TLS error? > > > [HZ] Most likely it will be TLS error if one side is having trouble to receive or > assemble the whole message. Additional error code could be defined to > convey this. > But this would be a limitation on the EAP method rather than on TLS. > > Section 3.2 - possible clarification. If all TLVs in a message are > > marked optional and none are understood by the peer, then an EMPTY > > response message must still be sent to the server. > > > [HZ] yes. I will add that. > > > Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding > > TLV - not what it says in section 3.3 > > > [HZ] It says " A Result TLV indicating failure", as it doesn't matter anymore, > the whole EAP authentication will fail. Section 3.3 is talking about a successful > Result TLV. > > > Section 4.2.3 - NAK TLV should not be accompanied by other TLVs. Not > sure > > I understand why. If I send an EAP plus a vendor w/ mandatory set, > > should not I get back a NAK on the vendor plus a result for the EAP? > > I might be happy to not do the vendor, but want to distinguish between > > you cannot do this vs you choose not to do this. > I really care about this case as long I can assume that if the > > mandatory bit is set then I would always fail the overall EAP > > conversation.> > > > [HZ] Correct, I am not sure there is value sending back the other TLVs, as the > authentication should be failed if the mandatory to implement is not > supported. > > > Section 4.2.10 - How can I know if the server does or does not process > > the channel binding TLV? This may be part of my policy as a peer > > depending on circumstances. > > > [HZ] Currently, the Channel-binding TLV is an optional TLV, doesn't require > acknowledgement, and is designed to be only one way, for client to send > some channel binding data to the server for verification purpose. There is no > feedback provided. The indication of whether the server supports channel- > binding and/or validated the channel-binding could be conveyed in other > TLVs to be added, if the WG agrees to be valuable. > Sam - do you see this as being an issue for abfab? > > Section 4.2.8 - Currently says that version should be 1 while the > > version defined in the intro sections is 2 - would be correct if we > > change the EAP method. > > > [HZ] It's the version number of the Crypto-binding TLV, not the EAP version > number. The theory is that we could enhance the crypto-binging TLV format > in the future if desired. Ok - I just misread this. Jim > > > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu From yoshihiro.ohba@toshiba.co.jp Wed Oct 19 17:05:42 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96ADD21F84CE for ; Wed, 19 Oct 2011 17:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuFnOU-Mi-T3 for ; Wed, 19 Oct 2011 17:05:42 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id C6D7E21F853A for ; Wed, 19 Oct 2011 17:05:41 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p9K05e8n017980; Thu, 20 Oct 2011 09:05:40 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id p9K05e0b022274; Thu, 20 Oct 2011 09:05:40 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id KAA22273; Thu, 20 Oct 2011 09:05:40 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p9K05em2014677; Thu, 20 Oct 2011 09:05:40 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p9K066Eb002100; Thu, 20 Oct 2011 09:06:06 +0900 (JST) Received: from [133.196.17.84] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LTC005Z389F2M50@mail.po.toshiba.co.jp>; Thu, 20 Oct 2011 09:05:40 +0900 (JST) Date: Thu, 20 Oct 2011 09:05:39 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <4E9F65D3.7060801@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Cc: emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:05:42 -0000 Hi Sam, Since authorization and accounting with the use of the pre-authentication may be different from those with the use of normal authentication, it would be good to differentiate pre-auth and without pre-auth for network access authentication protocols that support pre-authentication, PANA and 802.11 are such protocols as far as I know. BTW, I also commented about adding IEEE 802.16m and IEEE 802.21a for EAP lower-layers. Here is the references for them: IEEE 802.16m: "Standard for Local and Metropolitan Area Networks - Part 16: Air Interface for Broadband Wireless Access Systems - Advanced Air Interface", IEEE 802.16m-2011, 2011. IEEE 802.21a: "Draft Standard for Local and metropolitan area networks-Part 21: Media Independent Handover Services Amendment 2: Security Extensions to Media Independent Handover Services and Protocol", IEEE P802.21a/D04, 2011. Regards, Yoshihiro Ohba (2011/10/20 4:59), Sam Hartman wrote: > Hi. I've added PANA (pre-authentication). > > I wonder about the whole lower layer table. > Why is it important to distinguish PANA with pre-auth from pana without > pre-auth? > > Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with > pre-auth? > > I'd appreciate it if someone who cared about network access told me what > to do here:-) > From hartmans@painless-security.com Wed Oct 19 17:22:35 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BB611E80B3 for ; Wed, 19 Oct 2011 17:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.053 X-Spam-Level: X-Spam-Status: No, score=-103.053 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bW1MCVhSKFmA for ; Wed, 19 Oct 2011 17:22:35 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2992A11E80AF for ; Wed, 19 Oct 2011 17:22:34 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6701920274; Wed, 19 Oct 2011 20:23:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 46F494239; Wed, 19 Oct 2011 20:22:20 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <001401cc8d19$3d7ad260$b8707720$@augustcellars.com> <016f01cc8eba$82f4bc00$88de3400$@augustcellars.com> Date: Wed, 19 Oct 2011 20:22:20 -0400 In-Reply-To: <016f01cc8eba$82f4bc00$88de3400$@augustcellars.com> (Jim Schaad's message of "Wed, 19 Oct 2011 16:54:59 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 00:22:35 -0000 >>>>> "Jim" == Jim Schaad writes: >> > Section 4.2.10 - How can I know if the server does or does not >> process > the channel binding TLV? This may be part of my policy >> as a peer > depending on circumstances. >> > >> [HZ] Currently, the Channel-binding TLV is an optional TLV, >> doesn't require >> acknowledgement, and is designed to be only one way, for client >> to send some channel binding data to the server for verification >> purpose. There is > no >> feedback provided. The indication of whether the server supports >> channel- binding and/or validated the channel-binding could be >> conveyed in other TLVs to be added, if the WG agrees to be >> valuable. >> Jim>Sam - do you see this as being an issue for abfab? It's an issue for EMU actually. See Section 5.3 of draft-ietf-emu-chbind. Channel binding must be two-way and must follow the semantics of that section. And yes, draft-ietf-abfab-gss-eap depends on those semantics. From hzhou@cisco.com Wed Oct 19 20:15:16 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC77811E80C3 for ; Wed, 19 Oct 2011 20:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id grLqSZ5b3yrV for ; Wed, 19 Oct 2011 20:15:16 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2820711E80B2 for ; Wed, 19 Oct 2011 20:15:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=1434; q=dns/txt; s=iport; t=1319080516; x=1320290116; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=0vamDyQMP/dYOD9P8L1VbjXoQJw3xl/NXn/4dioBJRQ=; b=JhCf8TqSldk/SV+zTMtHx2oa9rdrLoFiVl5zawUMlP6XMFWIf8CwFKgt 2I8hEMspPzlg6FtlOBgRdKLVl44fuxnhC922NNh/J9HQzbvfXuvcRvfpr PsFbhuW/EZr6c2x/cZfONEh2C89/RDfhEHJXbb3kJHHstrEPGcmD5ZYQ0 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHCRn06tJV2d/2dsb2JhbABEDqh6gQWBbgEBAQEDEgEnAgE8EgEIgR0BAQQBDQUiny0BnkmIJwSTf4Uzi21T X-IronPort-AV: E=Sophos;i="4.69,376,1315180800"; d="scan'208";a="29682757" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 20 Oct 2011 03:15:15 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9K3FFNT016180; Thu, 20 Oct 2011 03:15:15 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 22:15:15 -0500 Received: from 10.21.104.99 ([10.21.104.99]) by XMB-RCD-202.cisco.com ([72.163.62.209]) via Exchange Front-End Server email.cisco.com ([128.107.191.79]) with Microsoft Exchange Server HTTP-DAV ; Thu, 20 Oct 2011 03:15:15 +0000 User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Wed, 19 Oct 2011 23:15:14 -0400 From: Hao Zhou To: Sam Hartman , Jim Schaad Message-ID: Thread-Topic: [Emu] Comments on the eap-tunnel-method-00 draft Thread-Index: AcyO1nvqInHn50B5mUuB5x8lWoyBfw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 20 Oct 2011 03:15:15.0029 (UTC) FILETIME=[7C875050:01CC8ED6] Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 03:15:17 -0000 Rereading the updated chbind draft, it has already defined the mechanism for two way communication and tunnel EAP draft just defined a TLV container to carry the Channel binding data defined in Section 5.3, so we should be ok. No change is needed on the tunnel EAP draft on this, other maybe called out Section 5.3. On 10/19/11 8:22 PM, "Sam Hartman" wrote: >>>>>> "Jim" == Jim Schaad writes: >>>> Section 4.2.10 - How can I know if the server does or does not >>> process > the channel binding TLV? This may be part of my policy >>> as a peer > depending on circumstances. >>>> >>> [HZ] Currently, the Channel-binding TLV is an optional TLV, >>> doesn't > require >>> acknowledgement, and is designed to be only one way, for client >>> to send some channel binding data to the server for verification >>> purpose. There is >> no >>> feedback provided. The indication of whether the server supports >>> channel- binding and/or validated the channel-binding could be >>> conveyed in other TLVs to be added, if the WG agrees to be >>> valuable. >>> > > Jim>Sam - do you see this as being an issue for abfab? > > > It's an issue for EMU actually. > See Section 5.3 of draft-ietf-emu-chbind. > Channel binding must be two-way and must follow the semantics of that > section. > > And yes, draft-ietf-abfab-gss-eap depends on those semantics. From glenzorn@gmail.com Wed Oct 19 20:41:28 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8740811E80BF for ; Wed, 19 Oct 2011 20:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uvi-ql7InukD for ; Wed, 19 Oct 2011 20:41:27 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id B777711E80B2 for ; Wed, 19 Oct 2011 20:41:27 -0700 (PDT) Received: by pzk34 with SMTP id 34so6241615pzk.9 for ; Wed, 19 Oct 2011 20:41:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=5agv5bl/iV0/cSRCuYywP96p1fqXMHL2u6IXLLUsWeA=; b=gYl9lEwq/kX4sEuzx9Lvu4G9xDHjIf5pLWJ/2a9m3Bwaa4GcmxYCU+lt1C2PdpAwiQ H2GbQwQ6Sx+qCzb7o6/tOlqdGtPI/eZa0/q/ug89bnvJswmi6wopZFYF+XMGBV0ySUl7 MZVaOHeQbsc7klexxK0+ziP2s512vC5fiODRY= Received: by 10.68.7.132 with SMTP id j4mr17196151pba.102.1319082027657; Wed, 19 Oct 2011 20:40:27 -0700 (PDT) Received: from [192.168.1.98] (ppp-171-96-12-2.revip8.asianet.co.th. [171.96.12.2]) by mx.google.com with ESMTPS id z3sm14186010pbu.7.2011.10.19.20.40.23 (version=SSLv3 cipher=OTHER); Wed, 19 Oct 2011 20:40:26 -0700 (PDT) Message-ID: <4E9F9821.1010005@gmail.com> Date: Thu, 20 Oct 2011 10:40:17 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 03:41:28 -0000 On 10/20/2011 3:09 AM, Sam Hartman wrote: > > > I believe I've addressed all of Alan's comments with the exception of > removing the RADIUS diagram from 5.3. Great, so what are we supposed to do now? WGLC was issued on draft-ietf-emu-chbind-09. The last call is not complete. Shall we just start over? This creation of a moving target wouldn't be so annoying if you were a newbie but you are anything but that... > Thanks Alan for the comments! > > --Sam > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Thu Oct 20 05:48:38 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99EE121F8AF1 for ; Thu, 20 Oct 2011 05:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.987 X-Spam-Level: X-Spam-Status: No, score=-102.987 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2z531ZwW36Kg for ; Thu, 20 Oct 2011 05:48:37 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C723121F8AAA for ; Thu, 20 Oct 2011 05:48:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4D3C02021E; Thu, 20 Oct 2011 08:49:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7C6AF4239; Thu, 20 Oct 2011 08:48:17 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <4E9F65D3.7060801@toshiba.co.jp> Date: Thu, 20 Oct 2011 08:48:17 -0400 In-Reply-To: <4E9F65D3.7060801@toshiba.co.jp> (Yoshihiro Ohba's message of "Thu, 20 Oct 2011 09:05:39 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 12:48:38 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> Hi Sam, Since authorization and accounting with the use Yoshihiro> of the pre-authentication may be different from those Yoshihiro> with the use of normal authentication, it would be good Yoshihiro> to differentiate pre-auth and without pre-auth for Yoshihiro> network access authentication protocols that support Yoshihiro> pre-authentication, PANA and 802.11 are such protocols as Yoshihiro> far as I know. OK, but Dan is arguing to remove them. Yoshihiro> BTW, I also commented about adding IEEE 802.16m and IEEE Yoshihiro> 802.21a for EAP lower-layers. Here is the references for Yoshihiro> them: Right. I didn't feel qualified to evaluate these. Ultimately the chairs are going to have to decide what the table entries are; I think that's beyond what I can do as an editor. From hartmans@mit.edu Thu Oct 20 05:49:16 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0636C21F8A70 for ; Thu, 20 Oct 2011 05:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmspSn-OP4v2 for ; Thu, 20 Oct 2011 05:49:15 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3151D21F8A80 for ; Thu, 20 Oct 2011 05:49:15 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4A5162021E; Thu, 20 Oct 2011 08:50:27 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A566B4239; Thu, 20 Oct 2011 08:48:59 -0400 (EDT) From: Sam Hartman To: Hao Zhou References: Date: Thu, 20 Oct 2011 08:48:59 -0400 In-Reply-To: (Hao Zhou's message of "Wed, 19 Oct 2011 23:15:14 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 12:49:16 -0000 >>>>> "Hao" == Hao Zhou writes: Hao> Rereading the updated chbind draft, it has already defined the Hao> mechanism for two way communication and tunnel EAP draft just Hao> defined a TLV container to carry the Channel binding data Hao> defined in Section 5.3, so we should be ok. No change is Hao> needed on the tunnel EAP draft on this, other maybe called out Hao> Section 5.3. And to indicate it's two-way. From yoshihiro.ohba@toshiba.co.jp Thu Oct 20 06:11:37 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2E421F8B72 for ; Thu, 20 Oct 2011 06:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNZ0tnydrwsY for ; Thu, 20 Oct 2011 06:11:37 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4C021F8B22 for ; Thu, 20 Oct 2011 06:11:36 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p9KDBZjC013928; Thu, 20 Oct 2011 22:11:35 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id p9KDBZoF005252; Thu, 20 Oct 2011 22:11:35 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id YAA05251; Thu, 20 Oct 2011 22:11:35 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p9KDBY9b019109; Thu, 20 Oct 2011 22:11:34 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p9KDC07L029777; Thu, 20 Oct 2011 22:12:00 +0900 (JST) Received: from [133.199.16.61] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LTD00BV68NACR10@mail.po.toshiba.co.jp>; Thu, 20 Oct 2011 22:11:34 +0900 (JST) Date: Thu, 20 Oct 2011 22:11:31 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <4EA01E03.50308@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <4E9F65D3.7060801@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Cc: emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:11:38 -0000 Hi Sam, (2011/10/20 21:48), Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba writes: > > Yoshihiro> Hi Sam, Since authorization and accounting with the use > Yoshihiro> of the pre-authentication may be different from those > Yoshihiro> with the use of normal authentication, it would be good > Yoshihiro> to differentiate pre-auth and without pre-auth for > Yoshihiro> network access authentication protocols that support > Yoshihiro> pre-authentication, PANA and 802.11 are such protocols as > Yoshihiro> far as I know. > OK, but Dan is arguing to remove them. I see. As long as all lower-layers are treated in a consistent manner, I am ok. Maybe it is cleaner to define pre-auth information as separate channel binding data. > > Yoshihiro> BTW, I also commented about adding IEEE 802.16m and IEEE > Yoshihiro> 802.21a for EAP lower-layers. Here is the references for > Yoshihiro> them: > > Right. I didn't feel qualified to evaluate these. > > Ultimately the chairs are going to have to decide what the table entries > are; I think that's beyond what I can do as an editor. > OK. Yoshihiro Ohba From hartmans@mit.edu Thu Oct 20 06:35:30 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F4A021F8BA8 for ; Thu, 20 Oct 2011 06:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.078 X-Spam-Level: X-Spam-Status: No, score=-103.078 tagged_above=-999 required=5 tests=[AWL=-0.813, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVi4tXgfAaw2 for ; Thu, 20 Oct 2011 06:35:30 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id F15EB21F8BA7 for ; Thu, 20 Oct 2011 06:35:29 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 087FC202FB; Thu, 20 Oct 2011 09:36:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 52C664239; Thu, 20 Oct 2011 09:35:14 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <4E9F65D3.7060801@toshiba.co.jp> <4EA01E03.50308@toshiba.co.jp> Date: Thu, 20 Oct 2011 09:35:14 -0400 In-Reply-To: <4EA01E03.50308@toshiba.co.jp> (Yoshihiro Ohba's message of "Thu, 20 Oct 2011 22:11:31 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:35:30 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> Hi Sam, Yoshihiro> (2011/10/20 21:48), Sam Hartman wrote: >>>>>>> "Yoshihiro" == Yoshihiro Ohba >>>>>>> writes: >> Yoshihiro> Hi Sam, Since authorization and accounting with the use Yoshihiro> of the pre-authentication may be different from those Yoshihiro> with the use of normal authentication, it would be good Yoshihiro> to differentiate pre-auth and without pre-auth for Yoshihiro> network access authentication protocols that support Yoshihiro> pre-authentication, PANA and 802.11 are such protocols as Yoshihiro> far as I know. >> OK, but Dan is arguing to remove them. Yoshihiro> I see. As long as all lower-layers are treated in a Yoshihiro> consistent manner, I am ok. Maybe it is cleaner to Yoshihiro> define pre-auth information as separate channel binding Yoshihiro> data. You might not want to do it that way. It seems that learning the eap-lower-layer from the NAS may influence your accounting handling (especially for pre-auth) even if the client does not specify channel binding. That's something for the WG to consider and possibly something where we need to circle back with radext. From hartmans@mit.edu Thu Oct 20 06:55:33 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCF921F8B52 for ; Thu, 20 Oct 2011 06:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.03 X-Spam-Level: X-Spam-Status: No, score=-103.03 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTESXaLQwDnB for ; Thu, 20 Oct 2011 06:55:33 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 432B221F8B47 for ; Thu, 20 Oct 2011 06:55:32 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id CE7D820274; Thu, 20 Oct 2011 09:56:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1BE7E4239; Thu, 20 Oct 2011 09:55:17 -0400 (EDT) From: Sam Hartman To: Glen Zorn References: <4E9F9821.1010005@gmail.com> Date: Thu, 20 Oct 2011 09:55:17 -0400 In-Reply-To: <4E9F9821.1010005@gmail.com> (Glen Zorn's message of "Thu, 20 Oct 2011 10:40:17 +0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emu@ietf.org Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:55:33 -0000 >>>>> "Glen" == Glen Zorn writes: Glen> On 10/20/2011 3:09 AM, Sam Hartman wrote: >> > > I believe I've addressed all of Alan's comments with the exception of >> removing the RADIUS diagram from 5.3. Glen> Great, so what are we supposed to do now? WGLC was issued on Glen> draft-ietf-emu-chbind-09. The last call is not complete. Glen> Shall we just start over? Documents are updated to reflect feedback during last calls all the time. It happens in WGs I chair; it happened with documents for which I was the AD; I've been asked to do it by ADs and other chairs. Obviously, sometimes it is done wrong. My thinking is that Alan's comments had been outstanding for a while, seemed fairly obvious and with the exception of the question about encoding of responses were non-contraversial. None of them seemed to require a second last call. By submitting 10 I've made a version with the changes folded in available for review. What I did is clearly permitted by the process. The chairs may of course decide I made an error and that one of Alan's comments didn't have sufficient consus. They can ask me to (or do it themselves) resubmit 09 as 11, ask me to remove some text, or give more specific guidance. We may also discover that I incorrectly applied Alan's comment. You still had the options you had before. You can review 09 if you like and send comments on 09. You can reply to Alan's comments and respond to them. You have some additional options now. If you haven't started reviewing yet you can start with 10. If you'd like you can review the diff between 10 and 9. You can review 9 and 10 separately if you have a lot of free time on your hands. You can ignore the whole thing. You get a chance to see Alan's context in the text. You can better appreciate them and if you find a problem bring it up. If you have trouble finding 09 or a diff between 09 and 10 let me know; I bet we can find one if we work together. If you have an objection to text in 9, text in 10, changes between the two bring it up. Objections of this form without an objection to actual text are not constructive. From hartmans@mit.edu Thu Oct 20 06:58:51 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4AC21F8BB2 for ; Thu, 20 Oct 2011 06:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.987 X-Spam-Level: X-Spam-Status: No, score=-102.987 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwD8GPhTxqBT for ; Thu, 20 Oct 2011 06:58:51 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0714621F8BB1 for ; Thu, 20 Oct 2011 06:58:51 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1380E20274; Thu, 20 Oct 2011 10:00:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 601744239; Thu, 20 Oct 2011 09:58:35 -0400 (EDT) From: Sam Hartman To: Yoshihiro Ohba References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <4E9F5E19.7060401@toshiba.co.jp> Date: Thu, 20 Oct 2011 09:58:35 -0400 In-Reply-To: <4E9F5E19.7060401@toshiba.co.jp> (Yoshihiro Ohba's message of "Thu, 20 Oct 2011 08:32:41 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 13:58:51 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> Hi Sam, Please see my comments below. Yoshihiro> sense. Sending channel bindings in the secure Yoshihiro> association protocol can work even with ERP [RFC5296] in Yoshihiro> which previously established EAP key material is used for Yoshihiro> the secure association protocol without carrying out any Yoshihiro> EAP method during re-authentication. " I like this text. Objections to including it? From hzhou@cisco.com Thu Oct 20 07:49:22 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1ED21F8B75 for ; Thu, 20 Oct 2011 07:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXDVdFw3-+c6 for ; Thu, 20 Oct 2011 07:49:21 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 80CAD21F8B66 for ; Thu, 20 Oct 2011 07:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=29195; q=dns/txt; s=iport; t=1319122160; x=1320331760; h=mime-version:subject:date:message-id:references:from:to: cc; bh=0+1Mh3w0LeI8dMfNFBccs+sCfvKDhXR848zCiglug2c=; b=MbJxNLgxRPziBJaXsqOYKdiOaq07CXBRKVlgj6dgBRhNyIOwJZivzPht NxCjSOvY4MG2cZmIqLWABCMKAucRyYOwGWbLjuF6XEWouPLGLM4taFw8B cNkV1a5lQj+23PYonRtAgtqw4UShs03unAVs9DnzyEjxWf6abwjsADFcf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQAALk0oE6tJXG9/2dsb2JhbAA6CZlYjz6BBYFuAQEBAwEBAQEPAQcCEQMXJwsMBAIBCA4DBAEBAQoGEAcBBgEmHwkIAgQBEggah14Ilz0BkBeOFwSEe4JNYQSHUzCRMIxC X-IronPort-AV: E=Sophos;i="4.69,379,1315180800"; d="scan'208,217";a="29802202" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 20 Oct 2011 14:49:04 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9KEn4dN013412; Thu, 20 Oct 2011 14:49:04 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 09:49:04 -0500 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_01CC8F37.6943E2C0" Date: Thu, 20 Oct 2011 09:49:03 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Comments on the eap-tunnel-method-00 draft Thread-Index: AQHrnjAPJJjB8NXO0W/H1Z8pisL1y5VGMmWQgAD1HXg= References: <001401cc8d19$3d7ad260$b8707720$@augustcellars.com> <016f01cc8eba$82f4bc00$88de3400$@augustcellars.com> From: "Hao Zhou (hzhou)" To: "Jim Schaad" , , "Sam Hartman" X-OriginalArrivalTime: 20 Oct 2011 14:49:04.0379 (UTC) FILETIME=[698E04B0:01CC8F37] Cc: emu@ietf.org Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:49:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8F37.6943E2C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jim: Please see inline. -----Original Message----- From: Jim Schaad [mailto:ietf@augustcellars.com] Sent: Wed 10/19/2011 7:54 PM To: Hao Zhou (hzhou); draft-ietf-emu-eap-tunnel-method@tools.ietf.org; = Sam Hartman Cc: emu@ietf.org Subject: RE: [Emu] Comments on the eap-tunnel-method-00 draft =20 > -----Original Message----- > From: Hao Zhou [mailto:hzhou@cisco.com] > Sent: Wednesday, October 19, 2011 12:31 PM > To: Jim Schaad; draft-ietf-emu-eap-tunnel-method@tools.ietf.org > Cc: emu@ietf.org > Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft >=20 > Jim: >=20 > Thanks for reviewing the draft in detail and comments provided. Please = see > my response inline below. >=20 >=20 > On 10/17/11 6:08 PM, "Jim Schaad" wrote: >=20 > > I have gathered these comments over time and therefore some of them > > are not fully fleshed out. If you have any questions I will try and > > reconstruct my ideas at the time. > > > > Jim > > > > > > > > Version Negotiation - terminate the conversation - w or w/o a fail? > > Edge case - what if peer only supports a higher version than the > > server supports? NAK? > > > [HZ] It depends. Server might want to proceed with other EAP type > negotiation by proposing a different EAP type, or terminate the conversation > with an EAP-Failure. I will clarify that in the next rev. Yes - but in this case I would expect a NAK from the client - possibly proposing other methods. Is this correct? [HZ] Yes, a NAK with other proposed EAP method if available. Will = clarify in next rev. >=20 > > EAP Server Name Checking - On what basis does the client accept or = not > > accept the EAP server name? You are suggesting that it is signed = by a CA > > controlling the intended domain, but what does this mean? Are you > > suggesting that the CA should have a DNS subject alt name in it for > > the domain in question? > > > [HZ] It's up to client's policy, especially if the server cert is = issued by a public > CA. Client needs not only verify that the server cert presented is a = valid cert > signed by the trusted CA, but also the server name presented in the = cert is > matching the domain it tried to authenticate with. A FQDN in the CN or = SAN > would be a way to do it. >=20 > > If no embedded EAP methods run, then no crypto check and thus no > > version # checking is done. > [HZ] That's true. Ok - this would be in violation of the last paragraph in section 3.1 = which says that the version numbers MUST be done. [HZ] Good point. Seems like we need to crypto-binding every time if we = want to protect the version number, EAP type, and outer TLVs. Will = discuss and fix in next rev. >=20 > >Also no checking done if only one inner EAP method is used as this > >only sends the Result TLV and not the Crypto-Binding TLV > > > [HZ] That's not true. Crypto-binding would still be exchanged with = Result TLV. > Actually using of the Result TLV in lieu of IM-Result TLV is for = legacy reason in > EAP-FAST, which could be removed in next rev since we are designing a = new > EAP method. Please tell me where it says this is done. All I can see is that one = CAN send intermediate-result, result and crypto-binding TLVs in the same message. (Unless of course only one is sent in which case the Intermediate-Reuslt TLV MUST NOT be sent). However these is nothing = that says that the Crypto-binding TLV would be sent after the first and only = EAP method - or indeed after a sequence of EAP methods. [HZ] It is described in Section 4.2.8,=20 "The Crypto-Binding TLV MUST be included with the Intermediate-Result TLV to perform Cryptographic Binding after each successful EAP method in a sequence of EAP methods. The Crypto-Binding TLV can be issued at other times as well." We will clarify to make it clear that it MUST be done after each = successful EAP method even if it's only one in the sequence. > > 'serially in a sequence' is redundant - section 3.3.1 > > > [HZ] Ok. The text is trying to distinguish from running multiple EAP methods > in parallel. >=20 > > Not only does it not allow initiating multiple EAP methods in > > parallel, it requires that they not be running in parallel. This is = a > > more strict condition > > > [HZ] For simplicity, otherwise implementation would need to trace when = the > 1st method finishes and applies the key from the authentication to the > crypto-binding. Supporting them in complete sequence makes it simpler = and > securer, as 2nd method might not be safe to run if the crypto-binging after > 1st method fails. Do you ever expect a version to allow multiple EAP sequences to be run = at the same time? If not then just the statement that they MUST be = executed serially is probably sufficient. [HZ] Ok. >=20 > > Para #3 - can the peer return an error and treat the failure of a > > specific EAP method as a total failure for the overall process - or = at > > least recommend that it should be an overall failure? > > > [HZ] Yes it can. It is actually described in Section 3.6.2, peer can = send up some > Fatal Error TLV and Result TLV to indicate the end. Ok - either I don't see the text or my comment is not sufficiently = clear. Consider: Client is running EAP-BLAH and returns inside of the EAP-BLAH method a failure.=20 If the client wants an overall failure rather than leaving it up to the server, does it send both the Result TLV failure and the EAP-Message w/ = the failure - or just the result TLV failure or is this not reasonable for = the client? [HZ] I would send both the EAP message failure and Result TLV failure, = this way the server would have the indication that not only the EAP = method failed, but also peer wants to fail the whole EAP. More = information client sends to the server is probably better. >=20 > > Confused messages in 3.3.1 and 3.3.3 about sending intermediate > > results and final results at the same time. Specifically 3.3.1 says > > MUST NOT for one inner EAP method, but text is not reflected in > > section 3.3.3 > > > [HZ] I think we can change to always send IM result after each inner = EAP > method, if only one inner method, then Result TLV could be sent as = well. See > explanation above. > > Conflict between 3.3.3 and security considerations (7.5) about = sending > > a different value in the Result TLV and the clear result in the = event > > of not doing a Request-Action TLV from the client. Is the server > > required to use the client suggested result in the event it does not > > perform the request action - could it use a different failure = message or a > success message? > > Does it matter? > > > [HZ] Server is supposed to send the suggested Result code in Request-Action > TLV if it refuse to do the action, this way peer will get notify about = the final > result and in-sync with the clear text EAP-Success/Failure packet. > Probably doesn't matter what the server sends, client would set the = final > result base on its policy. Based on my reading I would not have thought that the server was to send = a SECOND (and yes different) Result TLV in this case. [HZ] You are right. The current spec says server just send clear text = EAP-Success and Failure if it ignores the Request-Action. To answer your original question, it's better that server use the one = suggested by the client, as the client's state machine would be in the = state of expecting the same clear text EAP success or failure. I don't = know how many implementations actually reject the clear text EAP success = or failure if it doesn't match the protected result, but it's safer for = them to be in sync. Of course, EAP-Failure probably doesn't matter as = the physical link might be severed afterward.=20 >=20 > > Section 3.4 - Need to address the following issues: > > 1. what if both certificates and an inner EAP method are run - what > > is the Peer-Id then? > [HZ] Good question. There were some discussions on this. The new draft = rev > will propose to use the first authenticated peer identity. The WG can discuss > more on this. > > 2. What if multiple inner EAP methods are run - which Peer-Id is = used > then? > [HZ] Same as above. > > 3. What if client and machine EAP methods are run - which one to = use > then? > > (Internal what are the ids used for?) > > > [HZ] Again, good question. Same as above. What are you referring to for same as above? [HZ] Question 1 and 2 in this section. basically, they are the same = question, multiple identities authenticated, what to use for Peer-ID. > > Section 3.6 - item #2 - it should be noted that not all failure > > indications would be transmitted. The failure/success of the last = EAP > > method may not be sent as it gets wrapped into the Result TLV = message > > > [HZ] Should be fixed with the change on IM result TLV. > > Section 3.6.2 - (internal) - if you get a TLV rules violation - does > > the TLV itself need to be acknowledged? > > > [HZ] Probably no need to, as it is fatal and other side probably = already > terminated the tunnel. >=20 > > Section 3.7 - Can I assume that the identifier value is = monotonically > > increasing and does not wrap? > > > [HZ] Yes. We shouldn't exceed the maximum number (256) for Identifier = in a > single EAP authentication, at least I hope not. >=20 > > Section 3.7 - it might be useful to tell me how to error for a = message > > too big or response time too long in dealing with fragmentation - = are > > both just final errors? Or should it potentially be treated as a TLS error? > > > [HZ] Most likely it will be TLS error if one side is having trouble to receive or > assemble the whole message. Additional error code could be defined to > convey this. >=20 But this would be a limitation on the EAP method rather than on TLS. [HZ] It's actually an implementation or device limitation. EAP is not = designed to carry large bulk of data, so I hope we don't run into too = large fragmentation issues. > > Section 3.2 - possible clarification. If all TLVs in a message are > > marked optional and none are understood by the peer, then an EMPTY > > response message must still be sent to the server. > > > [HZ] yes. I will add that. >=20 > > Section 4.2.2 - Result TLV MUST NOT be accompanied by Crypto-binding > > TLV - not what it says in section 3.3 > > > [HZ] It says " A Result TLV indicating failure", as it doesn't matter anymore, > the whole EAP authentication will fail. Section 3.3 is talking about a successful > Result TLV. >=20 > > Section 4.2.3 - NAK TLV should not be accompanied by other TLVs. = Not > sure > > I understand why. If I send an EAP plus a vendor w/ mandatory set, > > should not I get back a NAK on the vendor plus a result for the EAP? > > I might be happy to not do the vendor, but want to distinguish = between > > you cannot do this vs you choose not to do this. > I really care about this case as long I can assume that if the > > mandatory bit is set then I would always fail the overall EAP > > conversation.> > > > [HZ] Correct, I am not sure there is value sending back the other = TLVs, as the > authentication should be failed if the mandatory to implement is not > supported. >=20 > > Section 4.2.10 - How can I know if the server does or does not = process > > the channel binding TLV? This may be part of my policy as a peer > > depending on circumstances. > > > [HZ] Currently, the Channel-binding TLV is an optional TLV, doesn't require > acknowledgement, and is designed to be only one way, for client to = send > some channel binding data to the server for verification purpose. = There is no > feedback provided. The indication of whether the server supports = channel- > binding and/or validated the channel-binding could be conveyed in = other > TLVs to be added, if the WG agrees to be valuable. >=20 Sam - do you see this as being an issue for abfab? [HZ] I have addressed this in another email thread. Will clarify it's = bidirectional as defined in ChBind draft section 5.3. > > Section 4.2.8 - Currently says that version should be 1 while the > > version defined in the intro sections is 2 - would be correct if we > > change the EAP method. > > > [HZ] It's the version number of the Crypto-binding TLV, not the EAP version > number. The theory is that we could enhance the crypto-binging TLV = format > in the future if desired. Ok - I just misread this. Jim > > > > > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu ------_=_NextPart_001_01CC8F37.6943E2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Emu] Comments on the eap-tunnel-method-00 draft

Jim:

Please see inline.


-----Original Message-----
From: Jim Schaad [mailto:ietf@augustcellars.com]=
Sent: Wed 10/19/2011 7:54 PM
To: Hao Zhou (hzhou); draft-ietf-emu-eap-tunnel-method@tools.ietf.org; = Sam Hartman
Cc: emu@ietf.org
Subject: RE: [Emu] Comments on the eap-tunnel-method-00 draft



> -----Original Message-----
> From: Hao Zhou [mailto:hzhou@cisco.com]
> Sent: Wednesday, October 19, 2011 12:31 PM
> To: Jim Schaad; draft-ietf-emu-eap-tunnel-method@tools.ietf.org
> Cc: emu@ietf.org
> Subject: Re: [Emu] Comments on the eap-tunnel-method-00 draft
>
> Jim:
>
> Thanks for reviewing the draft in detail and comments provided. = Please see
> my response inline below.
>
>
> On 10/17/11 6:08 PM, "Jim Schaad" = <ietf@augustcellars.com> wrote:
>
> > I have gathered these comments over time and therefore some of = them
> > are not fully fleshed out.  If you have any questions I = will try and
> > reconstruct my ideas at the time.
> >
> > Jim
> >
> >
> >
> > Version Negotiation - terminate the conversation - w or w/o a = fail?
> > Edge case - what if peer only supports a higher version than = the
> > server supports?  NAK?
> >
> [HZ] It depends. Server might want to proceed with other EAP = type
> negotiation by proposing a different EAP type, or terminate the
conversation
> with an EAP-Failure. I will clarify that in the next rev.

Yes - but in this case I would expect a NAK from the client - = possibly
proposing other methods.  Is this correct?
[HZ] Yes, a NAK with other proposed EAP method if available. Will = clarify in next rev.

>
> > EAP Server Name Checking - On what basis does the client = accept or not
> > accept the EAP server name?    You are = suggesting that it is signed by a
CA
> > controlling the intended domain, but what does this = mean?   Are you
> > suggesting that the CA should have a DNS subject alt name in = it for
> > the domain in question?
> >
> [HZ] It's up to client's policy, especially if the server cert is = issued
by a public
> CA. Client needs not only verify that the server cert presented is = a valid
cert
> signed by the trusted CA, but also the server name presented in the = cert
is
> matching the domain it tried to authenticate with. A FQDN in the CN = or SAN
> would be a way to do it.
>
> > If no embedded EAP methods run, then no crypto check and thus = no
> > version # checking is done.
> [HZ] That's true.

Ok - this would be in violation of the last paragraph in section 3.1 = which
says that the version numbers MUST be done.

[HZ] Good point. Seems like we need to crypto-binding every time if we = want to protect the version number, EAP type, and outer TLVs.  Will = discuss and fix in next rev.

>
> >Also no checking done if only one inner EAP method is  = used as this
> >only sends the Result TLV and not the Crypto-Binding TLV
> >
> [HZ] That's not true. Crypto-binding would still be exchanged with = Result
TLV.
> Actually using of the Result TLV in lieu of IM-Result TLV is for = legacy
reason in
> EAP-FAST, which could be removed in next rev since we are designing = a new
> EAP method.

Please tell me where it says this is done.  All I can see is that = one CAN
send intermediate-result, result and crypto-binding TLVs in the same
message.  (Unless of course only one is sent in which case the
Intermediate-Reuslt TLV MUST NOT be sent).   However these is = nothing that
says that the Crypto-binding TLV would be sent after the first and only = EAP
method - or indeed after a sequence of EAP methods.

[HZ] It is described in Section 4.2.8,
"The Crypto-Binding TLV MUST be included with the = Intermediate-Result
   TLV to perform Cryptographic Binding after each successful = EAP method
   in a sequence of EAP methods.  The Crypto-Binding TLV = can be issued
   at other times as well."

We will clarify to make it clear that it MUST be done after each = successful EAP method even if it's only one in the sequence.


> > 'serially in a sequence' is redundant - section 3.3.1
> >
> [HZ] Ok. The text is trying to distinguish from running multiple = EAP
methods
> in parallel.
>
> > Not only does it not allow initiating multiple EAP methods = in
> > parallel, it requires that they not be running in = parallel.  This is a
> > more strict condition
> >
> [HZ] For simplicity, otherwise implementation would need to trace = when the
> 1st method finishes and applies the key from the authentication to = the
> crypto-binding. Supporting them in complete sequence makes it = simpler and
> securer, as 2nd method might not be safe to run if the = crypto-binging
after
> 1st method fails.

Do you ever expect a version to allow multiple EAP sequences to be run = at
the same time?  If not then just the statement that they MUST be = executed
serially is probably sufficient.

[HZ] Ok.
>
> > Para #3 - can the peer return an error and treat the failure = of a
> > specific EAP method as a total failure for the overall process = - or at
> > least recommend that it should be an overall failure?
> >
> [HZ] Yes it can. It is actually described in Section 3.6.2, peer = can send
up some
> Fatal Error TLV and Result TLV to indicate the end.

Ok - either I don't see the text or my comment is not sufficiently = clear.

Consider:
Client is running EAP-BLAH and returns inside of the EAP-BLAH method = a
failure.
If the client wants an overall failure rather than leaving it up to = the
server, does it send both the Result TLV failure and the EAP-Message w/ = the
failure - or just the result TLV failure or is this not reasonable for = the
client?
[HZ] I would send both the EAP message failure and Result TLV failure, = this way the server would have the indication that not only the EAP = method failed, but also peer wants to fail the whole EAP. More = information client sends to the server is probably better.
>
> > Confused messages in 3.3.1 and 3.3.3 about sending = intermediate
> > results and final results at the same time.  Specifically = 3.3.1 says
> > MUST NOT for one inner EAP method,  but text is not = reflected in
> > section 3.3.3
> >
> [HZ] I think we can change to always send IM result after each = inner EAP
> method, if only one inner method, then Result TLV could be sent as = well.
See
> explanation above.


> > Conflict between 3.3.3 and security considerations (7.5) about = sending
> > a different value in the Result TLV and the clear result in = the event
> > of not doing a Request-Action TLV from the client.  Is = the server
> > required to use the client suggested result in the event it = does not
> > perform the request action - could it use a different failure = message or
a
> success message?
> > Does it matter?
> >
> [HZ] Server is supposed to send the suggested Result code in
Request-Action
> TLV if it refuse to do the action, this way peer will get notify = about the
final
> result and in-sync with the clear text EAP-Success/Failure = packet.
> Probably doesn't matter what the server sends, client would set the = final
> result base on its policy.

Based on my reading I would not have thought that the server was to send = a
SECOND (and yes different) Result TLV in this case.

[HZ] You are right. The current spec says server just send clear text = EAP-Success and Failure if it ignores the Request-Action.
To answer your original question, it's better that server use the one = suggested by the client, as the client's state machine would be in the = state of expecting the same clear text EAP success or failure. I don't = know how many implementations actually reject the clear text EAP success = or failure if it doesn't match the protected result, but it's safer for = them to be in sync. Of course, EAP-Failure probably doesn't matter as = the physical link might be severed afterward.

>
> > Section 3.4 - Need to address the following issues:
> > 1.  what if both certificates and an inner EAP method are = run - what
> > is the Peer-Id then?
> [HZ] Good question. There were some discussions on this. The new = draft rev
> will propose to use the first authenticated peer identity. The WG = can
discuss
> more on this.
> > 2.  What if multiple inner EAP methods are run - which = Peer-Id is used
> then?
> [HZ] Same as above.
> > 3.  What if client and machine EAP methods are run - = which one to use
> then?
> > (Internal what are the ids used for?)
> >
> [HZ] Again, good question. Same as above.

What are you referring to for same as above?
[HZ] Question 1 and 2 in this section. basically, they are the same = question, multiple identities authenticated, what to use for = Peer-ID.


> > Section 3.6 - item #2 - it should be noted that not all = failure
> > indications would be transmitted.  The failure/success of = the last EAP
> > method may not be sent as it gets wrapped into the Result TLV = message
> >
> [HZ] Should be fixed with the change on IM result TLV.

> > Section 3.6.2 - (internal) - if you get a TLV rules violation = - does
> > the TLV itself need to be acknowledged?
> >
> [HZ] Probably no need to, as it is fatal and other side probably = already
> terminated the tunnel.

>
> > Section 3.7 - Can I assume that the identifier value is = monotonically
> > increasing and does not wrap?
> >
> [HZ] Yes. We shouldn't exceed the maximum number (256) for = Identifier in a
> single EAP authentication, at least I hope not.

>
> > Section 3.7 - it might be useful to tell me how to error for a = message
> > too big or response time too long in dealing with = fragmentation - are
> > both just final errors? Or should it potentially be treated as = a TLS
error?
> >
> [HZ] Most likely it will be TLS error if one side is having trouble = to
receive or
> assemble the whole message. Additional error code could be defined = to
> convey this.
>

But this would be a limitation on the EAP method rather than on TLS.
[HZ] It's actually an implementation or device limitation. EAP is not = designed to carry large bulk of data, so I hope we don't run into too = large fragmentation issues.

> > Section 3.2 - possible clarification.  If all TLVs in a = message are
> > marked optional and none are understood by the peer, then an = EMPTY
> > response message must still be sent to the server.
> >
> [HZ] yes. I will add that.

>
> > Section 4.2.2 - Result TLV MUST NOT be accompanied by = Crypto-binding
> > TLV - not what it says in section 3.3
> >
> [HZ] It says " A Result TLV indicating failure", as it = doesn't matter
anymore,
> the whole EAP authentication will fail. Section 3.3 is talking = about a
successful
> Result TLV.

>
> > Section 4.2.3 - NAK TLV should not be accompanied by other = TLVs.   Not
> sure
> > I understand why.  If I send an EAP plus a vendor w/ = mandatory set,
> > should not I get back a NAK on the vendor plus a result for = the EAP?
> > I might be happy to not do the vendor, but want to distinguish = between
> > you cannot do this vs you choose not to do this.  <Not = fully sure that
> > I really care about this case as long I can assume that if = the
> > mandatory bit is set then I would always fail the overall = EAP
> > conversation.>
> >
> [HZ] Correct, I am not sure there is value sending back the other = TLVs, as
the
> authentication should be failed if the mandatory to implement is = not
> supported.

>
> > Section 4.2.10 - How can I know if the server does or does not = process
> > the channel binding TLV?  This may be part of my policy = as a peer
> > depending on circumstances.
> >
> [HZ] Currently, the Channel-binding TLV is an optional TLV, = doesn't
require
> acknowledgement, and is designed to be only one way, for client to = send
> some channel binding data to the server for verification purpose. = There is
no
> feedback provided. The indication of whether the server supports = channel-
> binding and/or validated the channel-binding could be conveyed in = other
> TLVs to be added, if the WG agrees to be valuable.
>

Sam - do you see this as being an issue for abfab?
[HZ] I have addressed this in another email thread. Will clarify it's = bidirectional as defined in ChBind draft section 5.3.

> > Section 4.2.8 -  Currently says that version should be 1 = while the
> > version defined in the intro sections is 2 - would be correct = if we
> > change the EAP method.
> >
> [HZ] It's the version number of the Crypto-binding TLV, not the = EAP
version
> number. The theory is that we could enhance the crypto-binging TLV = format
> in the future if desired.

Ok - I just misread this.

Jim

> >
> >
> >
> > _______________________________________________
> > Emu mailing list
> > Emu@ietf.org
> > https://www.ietf.org/m= ailman/listinfo/emu

------_=_NextPart_001_01CC8F37.6943E2C0-- From internet-drafts@ietf.org Thu Oct 20 09:32:22 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F9421F8CAF; Thu, 20 Oct 2011 09:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVg7tYwfu-k0; Thu, 20 Oct 2011 09:32:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42EB121F8C9B; Thu, 20 Oct 2011 09:32:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111020163222.10488.79396.idtracker@ietfa.amsl.com> Date: Thu, 20 Oct 2011 09:32:22 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-eap-tunnel-method-01.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:32:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of th= e IETF. Title : Tunnel EAP Method (TEAP) Version 1 Author(s) : Hao Zhou Nancy Cam-Winget Joseph Salowey Stephen Hanna Filename : draft-ietf-emu-eap-tunnel-method-01.txt Pages : 88 Date : 2011-10-20 This document defines the Tunnel Extensible Authentication Protocol (TEAP) protocol version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-tunnel-method-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-eap-tunnel-method-01.txt From glenzorn@gmail.com Fri Oct 21 01:57:44 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AF221F8B59 for ; Fri, 21 Oct 2011 01:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8YlGTwxYitD for ; Fri, 21 Oct 2011 01:57:44 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 32F2E21F8B57 for ; Fri, 21 Oct 2011 01:57:44 -0700 (PDT) Received: by ywt2 with SMTP id 2so165503ywt.31 for ; Fri, 21 Oct 2011 01:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZTIE62ImxcH60ahsqOuSgGqLtKtYwpRPfNNWyOhD790=; b=ntjUzZ2qVlxsqf34lORyxAqPm0IJIgeZeXTL+OuTjaSzCBvh7qb7tpGSLdGL57bckR 9IC/HEaTYEinQ1FQ+vdPnCeogYkjUC48+o9Y0x7Qf0AqTtS0nYtoS4hmY5Hv230Ohd7C 0EaE/LPH1SIq47JFXmFRlr44V+2I3rGLYm0Ms= Received: by 10.68.58.130 with SMTP id r2mr20600931pbq.37.1319187463670; Fri, 21 Oct 2011 01:57:43 -0700 (PDT) Received: from [192.168.1.98] (ppp-58-11-248-119.revip2.asianet.co.th. [58.11.248.119]) by mx.google.com with ESMTPS id w4sm28330541pbf.6.2011.10.21.01.57.39 (version=SSLv3 cipher=OTHER); Fri, 21 Oct 2011 01:57:42 -0700 (PDT) Message-ID: <4EA13400.5010501@gmail.com> Date: Fri, 21 Oct 2011 15:57:36 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sam Hartman References: <4E9F9821.1010005@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 08:57:44 -0000 On 10/20/2011 8:55 PM, Sam Hartman wrote: >>>>>> "Glen" == Glen Zorn writes: > > Glen> On 10/20/2011 3:09 AM, Sam Hartman wrote: > >> >> >> I believe I've addressed all of Alan's comments with the exception of > >> removing the RADIUS diagram from 5.3. > > Glen> Great, so what are we supposed to do now? WGLC was issued on > Glen> draft-ietf-emu-chbind-09. The last call is not complete. > Glen> Shall we just start over? > > Documents are updated to reflect feedback during last calls all the > time. It happens in WGs I chair; it happened with documents for which I > was the AD; I've been asked to do it by ADs and other chairs. Drivers run red lights all the time, too. > Obviously, sometimes it is done wrong. > > My thinking is that Alan's comments had been outstanding for a while, > seemed fairly obvious and with the exception of the question about > encoding of responses were non-contraversial. Thank you for your authoritative reading of WG consensus. If the problems (and their solutions were so obvious, why were they present in the draft at all? In fact, they become "non-controversial" at the end of last call, not in the middle. > > None of them seemed to require a second last call. > By submitting 10 I've made a version with the changes folded in > available for review. > > What I did is clearly permitted by the process. I could have sworn that the process WRT a WG Draft was that it was changed only by direction of the Chair(s) as a result of the determination of WG consensus, rather than at the whim of the editor. Maybe a different process? > The chairs may of > course decide I made an error and that one of Alan's comments didn't > have sufficient consus. They can ask me to (or do it themselves) > resubmit 09 as 11, ask me to remove some text, or give more specific > guidance. We may also discover that I incorrectly applied Alan's > comment. > > You still had the options you had before. You can review 09 if you like > and send comments on 09. You can reply to Alan's comments and respond to > them. > > You have some additional options now. If you haven't started reviewing > yet you can start with 10. If you'd like you can review the diff > between 10 and 9. You can review 9 and 10 separately if you have a lot > of free time on your hands. You can ignore the whole thing. You get a > chance to see Alan's context in the text. You can better appreciate them > and if you find a problem bring it up. > > If you have trouble finding 09 or a diff between 09 and 10 let me know; > I bet we can find one if we work together. > > > If you have an objection to text in 9, text in 10, changes between the > two bring it up. Objections of this form without an objection to actual > text are not constructive. Apparently I was unclear: the specific text to which I am objecting is -10. All of it. From dnelson@elbrys.com Fri Oct 21 06:23:01 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD49D21F8C77 for ; Fri, 21 Oct 2011 06:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPDlhy6vkb8S for ; Fri, 21 Oct 2011 06:23:01 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by ietfa.amsl.com (Postfix) with SMTP id D26C321F8C4E for ; Fri, 21 Oct 2011 06:23:00 -0700 (PDT) Received: from mail-vx0-f179.google.com ([209.85.220.179]) (using TLSv1) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP; Fri, 21 Oct 2011 06:23:00 PDT Received: by mail-vx0-f179.google.com with SMTP id fl13so3218919vcb.10 for ; Fri, 21 Oct 2011 06:22:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.36.234 with SMTP id t10mr14111326vdj.115.1319203368570; Fri, 21 Oct 2011 06:22:48 -0700 (PDT) Received: by 10.52.101.161 with HTTP; Fri, 21 Oct 2011 06:22:48 -0700 (PDT) In-Reply-To: <4EA13400.5010501@gmail.com> References: <4E9F9821.1010005@gmail.com> <4EA13400.5010501@gmail.com> Date: Fri, 21 Oct 2011 09:22:48 -0400 Message-ID: From: Dave Nelson To: emu@ietf.org Content-Type: multipart/alternative; boundary=20cf307813fc2b8ef804afcef8eb Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 13:23:01 -0000 --20cf307813fc2b8ef804afcef8eb Content-Type: text/plain; charset=ISO-8859-1 On Fri, Oct 21, 2011 at 4:57 AM, Glen Zorn wrote: > > Apparently I was unclear: the specific text to which I am objecting is > -10. All of it. > Ooo. Someone woke up exceptionally grumpy this morning. Regards, Dave David B. Nelson Sr. Software Architect Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --20cf307813fc2b8ef804afcef8eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Oct 21, 2011 at 4:57 AM, Glen Zorn <glenzorn@gmail.com> wrote:

Apparently I was unclear: the specific text to which I am objecting is
-10. =A0All of it.

Ooo.=A0 Someone woke up excepti= onally grumpy this morning.
=A0
Regards,

Dave
<= br>David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
--20cf307813fc2b8ef804afcef8eb-- From aland@deployingradius.com Fri Oct 21 07:02:19 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB08111E8088 for ; Fri, 21 Oct 2011 07:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxETqH3B4e64 for ; Fri, 21 Oct 2011 07:02:19 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE2A11E8082 for ; Fri, 21 Oct 2011 07:02:19 -0700 (PDT) Message-ID: <4EA17B54.4040704@deployingradius.com> Date: Fri, 21 Oct 2011 16:01:56 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Glen Zorn References: <4E9F9821.1010005@gmail.com> <4EA13400.5010501@gmail.com> In-Reply-To: <4EA13400.5010501@gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 14:02:19 -0000 Glen Zorn wrote: > Thank you for your authoritative reading of WG consensus. If the > problems (and their solutions were so obvious, why were they present in > the draft at all? No draft is perfect on first writing. Even the IESG may offer feedback to improve a document. > I could have sworn that the process WRT a WG Draft was that it was > changed only by direction of the Chair(s) as a result of the > determination of WG consensus, rather than at the whim of the editor. > Maybe a different process? I have no problem with a document being updated in WGLC due to feedback on the list. This has happened with other WG's, too. > Apparently I was unclear: the specific text to which I am objecting is > -10. All of it. Curious. Alan DeKok. From hzhou@cisco.com Fri Oct 21 12:12:44 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F42221F8B92 for ; Fri, 21 Oct 2011 12:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+8NdHZ98P6f for ; Fri, 21 Oct 2011 12:12:36 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8A92921F8B1C for ; Fri, 21 Oct 2011 12:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=1070; q=dns/txt; s=iport; t=1319224356; x=1320433956; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=skxI6rDjh1M1ToJ8UGVFlao7ZgHWSoRzahKDynD3tmg=; b=GLeeB2xrLTzPYB8AYuSfJOZZaAoAn5JZb+qknn9JYkNip2yJstZo9Nur xmq3+uJN/54s/aW3Au01giKCCXUOsuHgsFJMy7R4X2Y5lAPaZjAhXtvJc WwjsG9GPEgRhwvkMLsgn+BrCZ8pSI34M7kjZwQj/EZTDGdnzBICbAXwrz 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEGAELDoU6tJXG+/2dsb2JhbABDDqkPAoEFgW4BAQEDAQEBAQ8BJwIBMR0BCG0wAQEEARIih14IlS8BnjMEiEAElAGFNYtuUw X-IronPort-AV: E=Sophos;i="4.69,387,1315180800"; d="scan'208";a="30151950" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 21 Oct 2011 19:12:32 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9LJCW9b007661; Fri, 21 Oct 2011 19:12:32 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 14:12:32 -0500 Received: from 64.101.219.108 ([64.101.219.108]) by XMB-RCD-202.cisco.com ([72.163.62.209]) via Exchange Front-End Server email.cisco.com ([72.163.63.13]) with Microsoft Exchange Server HTTP-DAV ; Fri, 21 Oct 2011 19:12:31 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 21 Oct 2011 15:12:30 -0400 From: Hao Zhou To: Sam Hartman , Message-ID: Thread-Topic: [Emu] Submitted 10 Thread-Index: AcyQJWDaf6P+zQJE7Eqxn0N0bnmUIw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Oct 2011 19:12:32.0016 (UTC) FILETIME=[620DC100:01CC9025] Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:12:44 -0000 Sam: My review comments: 1. Section 3, paragraph 1, should " far removed" be "far remoted"? 2. Section 3, bottom of Page 6, should "virtual Lads (VLANs)" be "virtual LANs (VLANs)"? 3. Section 5.1, page 14, paragraph 2, should "I2" be "i2"? 4. So, client sends channel-binding data automatically or by its configuration, not per server request? It seems inefficient for peer send a big chunk of i1 without knowing whether the server supports channel binding or what information is needs. Might be better if server can request it and specific information before the peer sends it. 5. Section 7, should the title be Channel-binding AVP instead, as it talks all about AVP, not TLV? On 10/19/11 4:09 PM, "Sam Hartman" wrote: > > > I believe I've addressed all of Alan's comments with the exception of > removing the RADIUS diagram from 5.3. > Thanks Alan for the comments! > > --Sam > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Fri Oct 21 12:34:16 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB8621F8BA8 for ; Fri, 21 Oct 2011 12:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.095 X-Spam-Level: X-Spam-Status: No, score=-103.095 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnOxdlu6fyYT for ; Fri, 21 Oct 2011 12:34:15 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF6621F8B40 for ; Fri, 21 Oct 2011 12:34:10 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 26FD3204AB; Fri, 21 Oct 2011 15:35:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 13B7D4239; Fri, 21 Oct 2011 15:33:51 -0400 (EDT) From: Sam Hartman To: Hao Zhou References: Date: Fri, 21 Oct 2011 15:33:51 -0400 In-Reply-To: (Hao Zhou's message of "Fri, 21 Oct 2011 15:12:30 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:34:16 -0000 I'll respond to the question of channel binding support now. I think the current text permits an EAP method to not send channel binding if it knows the server fails to support it. If your method can discover that and optimistically avoid sending channel binding that's fine. I think we discussed the flow in a fair bit of detail and I think we have consensus on the current flow including the lack of server telling the peer which channel binding attributes it supports. As an individual, I do not support opening that up again, although if there is WG consensus to make a change we should do so. From aland@deployingradius.com Fri Oct 21 12:36:43 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4C221F86A0 for ; Fri, 21 Oct 2011 12:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.278 X-Spam-Level: X-Spam-Status: No, score=-102.278 tagged_above=-999 required=5 tests=[AWL=0.322, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izrf8205wQIQ for ; Fri, 21 Oct 2011 12:36:43 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id B43E421F862F for ; Fri, 21 Oct 2011 12:36:39 -0700 (PDT) Message-ID: <4EA1C9B1.4040706@deployingradius.com> Date: Fri, 21 Oct 2011 21:36:17 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:36:44 -0000 Sam Hartman wrote: > I think we discussed the flow in a fair bit of detail and I think we > have consensus on the current flow including the lack of server telling > the peer which channel binding attributes it supports. As an > individual, I do not support opening that up again, although if there is > WG consensus to make a change we should do so. I think there's been a lot of discussion on the document. We need to get closure quickly. This means not re-opening issues which were previously discussed and decided. Alan DeKok. From dharkins@lounge.org Fri Oct 21 12:55:19 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDA8A1F0C36 for ; Fri, 21 Oct 2011 12:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6KiKIBxkP0f for ; Fri, 21 Oct 2011 12:55:19 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD821F0C35 for ; Fri, 21 Oct 2011 12:55:19 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2E1A11022404C; Fri, 21 Oct 2011 12:55:19 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 21 Oct 2011 12:55:19 -0700 (PDT) Message-ID: In-Reply-To: References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <4E9F65D3.7060801@toshiba.co.jp> Date: Fri, 21 Oct 2011 12:55:19 -0700 (PDT) From: "Dan Harkins" To: "Sam Hartman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:55:20 -0000 On Thu, October 20, 2011 5:48 am, Sam Hartman wrote: > Ultimately the chairs are going to have to decide what the table entries > are; I think that's beyond what I can do as an editor. Why the chairs? I know for a fact that there is at least one person that is active in EMU that also regularly attends 802.11 meetings (and neither of the chairs are that person). Maybe we could listen that person's opinion, at least on the 802.11 entries in the table. regards, Dan. From hzhou@cisco.com Fri Oct 21 12:55:57 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F861F0C36 for ; Fri, 21 Oct 2011 12:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSJt-SWkmrz6 for ; Fri, 21 Oct 2011 12:55:56 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B0EFD1F0C3E for ; Fri, 21 Oct 2011 12:55:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=777; q=dns/txt; s=iport; t=1319226956; x=1320436556; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=i7ywCFWyCbQJ92osTJBjpjQ6z93sG77kK9vhRLBTy5k=; b=IXsc/9t3bDNRdlZeVJo5n2kCcrzQPfyESd87l3JEEDf1a/GtI1mU09XD vJMtCxU53epWlXBEue24pmcSgqS0okb3+8yHw8phfdc1u2mAol75gZLLp vVIjdGjyxj4qyriSoNLYbeLrNvbXQ4TRrPW3Fs+uwOMzzwcJRZ2QG5Rvf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYHAF/MoU6tJV2d/2dsb2JhbABDDokvn2ACgQWBbgEBAQMBEgEnAgE8BQ0BCBiBBQEBBAENBSKHXpVDAZ43iEAElAGFNYtuUw X-IronPort-AV: E=Sophos;i="4.69,388,1315180800"; d="scan'208";a="30160539" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 21 Oct 2011 19:55:56 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p9LJtujF019310; Fri, 21 Oct 2011 19:55:56 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 14:55:56 -0500 Received: from 64.101.219.108 ([64.101.219.108]) by XMB-RCD-202.cisco.com ([72.163.62.209]) via Exchange Front-End Server email.cisco.com ([72.163.63.12]) with Microsoft Exchange Server HTTP-DAV ; Fri, 21 Oct 2011 19:55:55 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 21 Oct 2011 15:55:54 -0400 From: Hao Zhou To: Alan DeKok , Sam Hartman Message-ID: Thread-Topic: [Emu] Submitted 10 Thread-Index: AcyQK3D1PdKhXSdl1kSp56dHSG4r8w== In-Reply-To: <4EA1C9B1.4040706@deployingradius.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Oct 2011 19:55:56.0299 (UTC) FILETIME=[7253CDB0:01CC902B] Cc: emu@ietf.org Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 19:55:57 -0000 I wasn't aware of previous discussion and decision on this already. Sorry for bringing this up. Proceed with the current draft. On 10/21/11 3:36 PM, "Alan DeKok" wrote: > Sam Hartman wrote: >> I think we discussed the flow in a fair bit of detail and I think we >> have consensus on the current flow including the lack of server telling >> the peer which channel binding attributes it supports. As an >> individual, I do not support opening that up again, although if there is >> WG consensus to make a change we should do so. > > I think there's been a lot of discussion on the document. We need to > get closure quickly. This means not re-opening issues which were > previously discussed and decided. > > Alan DeKok. From ietf@augustcellars.com Fri Oct 21 13:14:06 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7298511E809B for ; Fri, 21 Oct 2011 13:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INCB8q+CHhSh for ; Fri, 21 Oct 2011 13:14:05 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id D24CB11E808E for ; Fri, 21 Oct 2011 13:14:05 -0700 (PDT) Received: from Tobias (173-8-216-38-Oregon.hfc.comcastbusiness.net [173.8.216.38]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 9B1F42CA47; Fri, 21 Oct 2011 13:14:05 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "'Hao Zhou'" References: In-Reply-To: Date: Fri, 21 Oct 2011 13:13:37 -0700 Message-ID: <002301cc902d$ec872670$c5957350$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK7WzYYx8Y0lm/TuiPR1wDI3rlwcQLPbqYgk5Mpj4A= Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 20:14:06 -0000 I want to make sure that we have distinguished between the two statements 1. The server says that I don't support these specific attributes and 2. The server does not tell me that it did or did not do matching of some attributes. The first I think is totally optional, but the second is necessary for the tunnel draft and should be made explicit in this draft as something that needs to be done. I will be reading this document with this in mind. Jim > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Sam Hartman > Sent: Friday, October 21, 2011 12:34 PM > To: Hao Zhou > Cc: Sam Hartman; emu@ietf.org > Subject: Re: [Emu] Submitted 10 > > I'll respond to the question of channel binding support now. I think the > current text permits an EAP method to not send channel binding if it knows > the server fails to support it. If your method can discover that and > optimistically avoid sending channel binding that's fine. > > I think we discussed the flow in a fair bit of detail and I think we have > consensus on the current flow including the lack of server telling the peer > which channel binding attributes it supports. As an individual, I do not > support opening that up again, although if there is WG consensus to make a > change we should do so. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hzhou@cisco.com Fri Oct 21 13:20:46 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1577621F8770 for ; Fri, 21 Oct 2011 13:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juDah4KHoTeo for ; Fri, 21 Oct 2011 13:20:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B9DD521F86F6 for ; Fri, 21 Oct 2011 13:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hzhou@cisco.com; l=1810; q=dns/txt; s=iport; t=1319228444; x=1320438044; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=CUmhRBoKaSILpWTW//zkK4XmfPPfGC5bazQxIN4pHqM=; b=Y9UhlE6yDVlBj8hm9sTfkd2hSNCc+pYovCzniSFgoQ6FoS3psQ5cBLdf rqAH73/ECUMZxV1CGxK0s5QhK9NlODzG2r5kFvhKrgtIWxObgzhwpg3wu +385/UN7oPc5eLqwFDHVJv5LhjhoSdhaTFqftXoDrxGVgsQebmKEeHqtV U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcBAMLToU6tJV2a/2dsb2JhbABDDplSjz0CgQWBbgEBAQMBAQEBDwEnAgExCwUHBgEIDgMEAQEoLh8JCAIEAQ0FIodeCJVAAZ40BIhABJQBhTWLblM X-IronPort-AV: E=Sophos;i="4.69,388,1315180800"; d="scan'208";a="30167693" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 21 Oct 2011 20:20:44 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9LKKiJs005447; Fri, 21 Oct 2011 20:20:44 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 21 Oct 2011 15:20:44 -0500 Received: from 64.101.219.108 ([64.101.219.108]) by XMB-RCD-202.cisco.com ([72.163.62.209]) via Exchange Front-End Server email.cisco.com ([72.163.63.12]) with Microsoft Exchange Server HTTP-DAV ; Fri, 21 Oct 2011 20:20:43 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 21 Oct 2011 16:20:43 -0400 From: Hao Zhou To: Jim Schaad , "'Sam Hartman'" Message-ID: Thread-Topic: [Emu] Submitted 10 Thread-Index: AQK7WzYYx8Y0lm/TuiPR1wDI3rlwcQLPbqYgk5Mpj4CAAAJg+w== In-Reply-To: <002301cc902d$ec872670$c5957350$@augustcellars.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Oct 2011 20:20:44.0209 (UTC) FILETIME=[E930DA10:01CC902E] Cc: emu@ietf.org Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 20:20:46 -0000 Jim: The chbind draft already has that covered by the use of the code. Tunnel method defines the channel-binding TLV that wraps the channel data defined in chbind draft, so I think we are ok. On 10/21/11 4:13 PM, "Jim Schaad" wrote: > I want to make sure that we have distinguished between the two statements > > 1. The server says that I don't support these specific attributes and > 2. The server does not tell me that it did or did not do matching of some > attributes. > > The first I think is totally optional, but the second is necessary for the > tunnel draft and should be made explicit in this draft as something that > needs to be done. I will be reading this document with this in mind. > > Jim > > >> -----Original Message----- >> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of >> Sam Hartman >> Sent: Friday, October 21, 2011 12:34 PM >> To: Hao Zhou >> Cc: Sam Hartman; emu@ietf.org >> Subject: Re: [Emu] Submitted 10 >> >> I'll respond to the question of channel binding support now. I think the >> current text permits an EAP method to not send channel binding if it knows >> the server fails to support it. If your method can discover that and >> optimistically avoid sending channel binding that's fine. >> >> I think we discussed the flow in a fair bit of detail and I think we have >> consensus on the current flow including the lack of server telling the > peer >> which channel binding attributes it supports. As an individual, I do not >> support opening that up again, although if there is WG consensus to make a >> change we should do so. >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > From hartmans@mit.edu Fri Oct 21 13:22:11 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C85A21F89B8 for ; Fri, 21 Oct 2011 13:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.066 X-Spam-Level: X-Spam-Status: No, score=-103.066 tagged_above=-999 required=5 tests=[AWL=-0.801, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlYX-zvwG47S for ; Fri, 21 Oct 2011 13:22:11 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 335C221F87FC for ; Fri, 21 Oct 2011 13:22:11 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 99D2720465; Fri, 21 Oct 2011 16:23:17 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8F0A14239; Fri, 21 Oct 2011 16:21:48 -0400 (EDT) From: Sam Hartman To: "Dan Harkins" References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <4E9F65D3.7060801@toshiba.co.jp> Date: Fri, 21 Oct 2011 16:21:48 -0400 In-Reply-To: (Dan Harkins's message of "Fri, 21 Oct 2011 12:55:19 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 20:22:11 -0000 >>>>> "Dan" == Dan Harkins writes: Dan> On Thu, October 20, 2011 5:48 am, Sam Hartman wrote: >> Ultimately the chairs are going to have to decide what the table >> entries are; I think that's beyond what I can do as an editor. Dan> Why the chairs? Sorry. what I meant here is that the chairs should tell me what to put in the doc. Why the chairs? It's their job to judge consensus. Obviously, they should do that by reading the messages here and telling me what the consensus is. From hartmans@mit.edu Fri Oct 21 13:30:18 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73081F0C60 for ; Fri, 21 Oct 2011 13:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.04 X-Spam-Level: X-Spam-Status: No, score=-103.04 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE7wWbF4ALG0 for ; Fri, 21 Oct 2011 13:30:18 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6113D1F0C35 for ; Fri, 21 Oct 2011 13:30:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C07B7204AB; Fri, 21 Oct 2011 16:31:28 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B404C4239; Fri, 21 Oct 2011 16:29:59 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <002301cc902d$ec872670$c5957350$@augustcellars.com> Date: Fri, 21 Oct 2011 16:29:59 -0400 In-Reply-To: <002301cc902d$ec872670$c5957350$@augustcellars.com> (Jim Schaad's message of "Fri, 21 Oct 2011 13:13:37 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Sam Hartman' , emu@ietf.org Subject: Re: [Emu] Submitted 10 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 20:30:18 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> I want to make sure that we have distinguished between the two Jim> statements 1. The server says that I don't support these Jim> specific attributes Jim> and 2. The server does not tell me that it Jim> did or did not do matching of some attributes. Jim> The first I think is totally optional, but the second is Jim> necessary for the tunnel draft and should be made explicit in Jim> this draft as something that needs to be done. I think section 5.3 clearly requires that a peer learn whether the server did do matching and if so, what attributes it successfully matched. We don't currently have a way for the server to say "these attributes didn't match." That's kind of tricky and I'd prefer that to be a future work item. I've left extensibility for it. Also, the client's request to the server is integrity protected. I believe we should require and would appreciate you checking that we do require: 1) A client supporting channel binding to a server supporting channel binding will get channel binding. An attacker cannot downgrade to no channel binding. I believe that by doing channel binding over an integrity-protected channel we get that. 2) If you do channel binding the client will learn the result and will learn which attributes it sent were considered and met whatever consistency check the server did. This is a little vaguely worded because there's a lot of latitude for server policy. From hartmans@mit.edu Sun Oct 23 10:33:12 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48FD21F8AF7 for ; Sun, 23 Oct 2011 10:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.012 X-Spam-Level: X-Spam-Status: No, score=-103.012 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UXJrECYLVAn6 for ; Sun, 23 Oct 2011 10:33:12 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD6521F8ABE for ; Sun, 23 Oct 2011 10:33:12 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 50C5420274 for ; Sun, 23 Oct 2011 13:34:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7DAD14239; Sun, 23 Oct 2011 13:32:45 -0400 (EDT) From: Sam Hartman To: emu@ietf.org Date: Sun, 23 Oct 2011 13:32:45 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Emu] Where I think we are after the channel binding last call X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 17:33:12 -0000 Hi. Here are my notes as editor on where I think things stand: 1) waiting for chairs to confirm that we have WG consensus to address Alan's comments in the way we did 2) Waiting for the chairs to judge consensus or lead a discussion on the contents of the EAP lower layers table. We should specifically resolve the question of whether preauth should be distinguished from non-preauth. 3) Unless someone objects we should pull in the ERP text. 4) Chairs to judge overall consensus on the document. I'd be happy to submit a version next week with the ERP text and if we can get there the new lower layer table. From ietf@augustcellars.com Sun Oct 23 15:54:42 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED7921F8564 for ; Sun, 23 Oct 2011 15:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.339 X-Spam-Level: X-Spam-Status: No, score=-3.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a306DBLRZeLa for ; Sun, 23 Oct 2011 15:54:41 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE4F21F8560 for ; Sun, 23 Oct 2011 15:54:41 -0700 (PDT) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id ED5B138F0C; Sun, 23 Oct 2011 15:54:40 -0700 (PDT) From: "Jim Schaad" To: "Sam Hartman" References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <4E9F65D3.7060801@toshiba.co.jp> In-Reply-To: Date: Sun, 23 Oct 2011 15:54:14 -0700 Message-ID: <00cd01cc91d6$aff241e0$0fd6c5a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIlbePiXms37zfIYwrVm2G5VtiWqgIHK3EmAdG8dzYBw4P4ngHMzdieAo9guo6UhcKhAA== Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 22:54:42 -0000 * In section 5.1 (para 3) - The following sentence does not make sense to me. Message i2 is the information the AAA server receives from the last hop in the AAA proxy chain which is not necessarily the authenticator. Specifically I do not follow the last clause and what it is referring to. Are you stating that the element in the AAA proxy chain may not be the authenticator? If so, I would omit the clause as it seems obvious to me since you are talking about a chain. * How does authenticated vs non-authenticated information get denoted in a AAA message? Given that some information can be authenticated at an early point in the chain and some must be deferred until the last node this would need to be denoted as authenticated vs non-authenticated information. And who validated it? * s/thatwere/that were/ * section 5.2 s/have gone lost/have got lost/ * It is not clear to me if the EAP server is to reflect the values from the EAP client in the response message or if it should reflect values from the NAS/AAA path. * Is it reasonable/possible that a policy would pull some attribute from the AAA path that is not supplied by the EAP client and therefore need to reflect it to the EAP client as part of the response? Or is the set of values to be reflected back to the EAP client restricted by the set of values that it supplies? * Section 7.2 - I am afraid I don't understand what this new RADIUS attribute is supposed to be carrying. I am doubly confused since the introductory text in sections 7 and 7.1 talk about the values of i1, but my understanding is that i1 is sent from the NAS to the peer, using some unknown protocol and then from the peer to the EAP server using an EAP method and thus the reason for the RADIUS attribute is confusing. I would understand it better if we are talking about sending i2 data for things which are not already RADIUS attributes, but that does not seem to be how the text is designed. This might just be talking about the EAP method to be used, but this is also confusing since that is not something I would expect the NAS to be involved in. I might have gotten a better grasp on this, and I think that part of my problem is that I think that this could be a mis-named attribute. I now understand that this is dealing with what is the method that is being used to talk between the EAP peer and the NAS. I think it is partly misleading because this is only part of what is carrying the EAP data layer (along with a AAA layer currently) and thus is not completely true. It might be better to call it the Peer-NAS transport layer or something similar. * Section 8 - You are talking about this information as being validated by the AAA server as oppose to being validated for consistency against the i1 data by the EAP server. Is this what you are really intended? From hartmans@painless-security.com Sun Oct 23 16:13:57 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE43021F8B47 for ; Sun, 23 Oct 2011 16:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.971 X-Spam-Level: X-Spam-Status: No, score=-102.971 tagged_above=-999 required=5 tests=[AWL=-0.706, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxkrQTBWy+6A for ; Sun, 23 Oct 2011 16:13:56 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCB421F8AF7 for ; Sun, 23 Oct 2011 16:13:56 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0B61D20188; Sun, 23 Oct 2011 19:15:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EAEA84239; Sun, 23 Oct 2011 19:13:32 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <4E9F65D3.7060801@toshiba.co.jp> <00cd01cc91d6$aff241e0$0fd6c5a0$@augustcellars.com> Date: Sun, 23 Oct 2011 19:13:32 -0400 In-Reply-To: <00cd01cc91d6$aff241e0$0fd6c5a0$@augustcellars.com> (Jim Schaad's message of "Sun, 23 Oct 2011 15:54:14 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Oct 2011 23:13:57 -0000 >>>>> "Jim" == Jim Schaad writes: Responding only to things I can respond to without reading the document. I''m in the middle of another document. I'll get to the rest sometime next week. Jim> * In section 5.1 (para 3) - The following sentence does not Jim> make sense to me. Message i2 is the information the AAA server Jim> receives from the last hop in the AAA proxy chain which is not Jim> necessarily the authenticator. Jim> Specifically I do not follow the last clause and what it is Jim> referring to. Are you stating that the element in the AAA Jim> proxy chain may not be the authenticator? Yes. Jim> If so, I would omit Jim> the clause as it seems obvious to me since you are talking Jim> about a chain. I'd appreciate comments from others. Jim> * How does authenticated vs non-authenticated information get Jim> denoted in a AAA message? It doesn't. All information in an AAA message is integrity-protected hop-by-hop. How much you trust it is up to your local policy. Jim> * It is not clear to me if the EAP server is to reflect the Jim> values from the EAP client in the response message or if it Jim> should reflect values from the NAS/AAA path. EAP client. Jim> * Is it reasonable/possible that a policy would pull some Jim> attribute from the AAA path that is not supplied by the EAP Jim> client and therefore need to reflect it to the EAP client as Jim> part of the response? Or is the set of values to be reflected Jim> back to the EAP client restricted by the set of values that it Jim> supplies? In this version of the spec it's restricted to thes included by the EAP peer. I think we may need to relax that in the future, but there is significant complexity surrounding some issues there. So, clients MUST ignore unknown attributes but right now we don't send them. Jim> * Section 7.2 - I am afraid I don't understand what this new Jim> RADIUS attribute is supposed to be carrying. It describes the protocol between the peer and the NAS. It's sent in the channel binding and potentially over the AAA path. I think the name is correct: RFC 3748 (EAP) does call that a lower layer. Jim> * Section 8 - You are talking about this information as being Jim> validated by the AAA server as oppose to being validated for Jim> consistency against the i1 data by the EAP server. Is this Jim> what you are really intended? I'm not intending to make that distinction in section 8. No, we're talking about the same validation as in section 5. I think this may be terminology rot; will check when I reconcile your comments against the document. From jsalowey@cisco.com Sun Oct 23 21:20:25 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0499821F8B4A for ; Sun, 23 Oct 2011 21:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgySrvHm-c6m for ; Sun, 23 Oct 2011 21:20:24 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 24F0921F8B3E for ; Sun, 23 Oct 2011 21:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=2753; q=dns/txt; s=iport; t=1319430024; x=1320639624; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=9hOS2WzxaL6IEzR784gV5ZReUo8LD5xs06E1AgPRiUk=; b=iQSEymdNZNw5RHNBqxpo7dcgVC2WshJILg1EFNXPmbgjUWkY43QqQXDu JCPqbjRLllppB299ne6+Mu4gaaqE7kw1MCFQJr2PFY9i2pOpmWZuSkYk3 NrvVgB9t0KbMLiTWTSzF2FFD+p4DWc10Ei2jDJFvy4QnXa/09yLKH+/YO I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEnnpE6rRDoI/2dsb2JhbABDqQ2BBYFuAQEBAwEBAQEPASc0CwULBQYOChgWJzAGExERh14IlicBnS0EhTGCLmEEiAaMA4UsjE8 X-IronPort-AV: E=Sophos;i="4.69,396,1315180800"; d="scan'208";a="9749308" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 24 Oct 2011 04:20:23 +0000 Received: from [10.33.251.254] ([10.33.251.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9O4KJ6p029919; Mon, 24 Oct 2011 04:20:21 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey X-Priority: 3 (Normal) In-Reply-To: <49c04a893d1b09695022a8ea4fd3f7a9.squirrel@www.trepanning.net> Date: Sun, 23 Oct 2011 21:20:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <49c04a893d1b09695022a8ea4fd3f7a9.squirrel@www.trepanning.net> To: Dan Harkins X-Mailer: Apple Mail (2.1084) Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 04:20:25 -0000 On Oct 19, 2011, at 3:52 PM, Dan Harkins wrote: >=20 > Hi Sam, >=20 > On Wed, October 19, 2011 12:59 pm, Sam Hartman wrote: >> Hi. I've added PANA (pre-authentication). >>=20 >> I wonder about the whole lower layer table. >> Why is it important to distinguish PANA with pre-auth from pana = without >> pre-auth? >>=20 >> Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with >> pre-auth? >>=20 >> I'd appreciate it if someone who cared about network access told me = what >> to do here:-) >=20 > You can collapse wpa, wpa2 and wpa2 with preauth. wpa and wpa2 are = both > actually trademarked terms of the Wi-Fi Alliance so they should = probably > not be in an IANA registry anyway. Regardless, though, they all do the > same thing by conveying the same type of information in the same way. >=20 [Joe] I agree with removing WPA references. This really about the l2 = ciphering, not EAP. It may be useful to have this in an attribute, but = I don't think it belongs in this one. =20 I'm lean towards including the pre-auth case since I believe it is = different enough from the non-pre-auth case. It seems that different = parties may be involved in the conversation. =20 > 802.11s specifies a password-based authentication scheme that does = not > use EAP so there doesn't seem to be a reason to define an "EAP lower > layer" for 802.11s. >=20 [Joe] Agree > 802.11r does things a little differently-- a key hierarchy is built = up > and keys are distributed hither and yon-- so it might be good to = channel > bind that stuff but 802.11r has been rolled into the 802.11 standard > (there is no stand-alone reference for 802.11r, by the way) and can be > dealt with as just 802.11. All the "information elements" that specify > that 11r-specific stuff is being communicated are defined by 802.11's > Assigned Number Authority and their communication is done in the same > fashion as plain-jane 802.11 (aka wpa and wpa2). If "information > elements" for 802.11r are included in the 802.11 channel binding data > then it means the session is going to be used for 802.11r-type stuff. >=20 [Joe] I think the authentication procedures are the same whether you = use 11r or not. The differences are after authentication so I agree = this does not belong in this attribute. =20 > Values 4-8 in the table in section 11.1 can all be combined into a > single value named "802.11" with a reference to IEEE 802.11-2007. >=20 [Joe] I'm leaning to towards 802.11 and 802.1-pre-auth. =20 > regards, >=20 > Dan. >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From dharkins@lounge.org Mon Oct 24 11:57:51 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A05C21F8BF0 for ; Mon, 24 Oct 2011 11:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWFNt6wUX1i2 for ; Mon, 24 Oct 2011 11:57:50 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A509621F8BD7 for ; Mon, 24 Oct 2011 11:57:50 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 61C8CA88810C; Mon, 24 Oct 2011 11:57:50 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 24 Oct 2011 11:57:50 -0700 (PDT) Message-ID: <19b5003655cdb35815f9b8ebf0ec40db.squirrel@www.trepanning.net> In-Reply-To: References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <49c04a893d1b09695022a8ea4fd3f7a9.squirrel@www.trepanning.net> Date: Mon, 24 Oct 2011 11:57:50 -0700 (PDT) From: "Dan Harkins" To: "Joe Salowey" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 18:57:51 -0000 Hi Joe, On Sun, October 23, 2011 9:20 pm, Joe Salowey wrote: > > On Oct 19, 2011, at 3:52 PM, Dan Harkins wrote: > >> >> Hi Sam, >> >> On Wed, October 19, 2011 12:59 pm, Sam Hartman wrote: >>> Hi. I've added PANA (pre-authentication). >>> >>> I wonder about the whole lower layer table. >>> Why is it important to distinguish PANA with pre-auth from pana without >>> pre-auth? >>> >>> Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with >>> pre-auth? >>> >>> I'd appreciate it if someone who cared about network access told me >>> what >>> to do here:-) >> >> You can collapse wpa, wpa2 and wpa2 with preauth. wpa and wpa2 are both >> actually trademarked terms of the Wi-Fi Alliance so they should probably >> not be in an IANA registry anyway. Regardless, though, they all do the >> same thing by conveying the same type of information in the same way. >> > > [Joe] I agree with removing WPA references. This really about the l2 > ciphering, not EAP. It may be useful to have this in an attribute, but I > don't think it belongs in this one. The AP will be putting that attribute (possibly a list of them if it supports more than 1 cipher) in its beacons and probe responses and the client will be putting that attribute (the one it selects from the list) in its associate request. These attributes are already defined by 802.11's number authority, ANA, so it might be a good idea to just use the ANA-defined attribute in the 802.11 channel binding data. > I'm lean towards including the pre-auth case since I believe it is > different enough from the non-pre-auth case. It seems that different > parties may be involved in the conversation. Yes, you're right. Pre-auth and non-pre-auth use different ether-types to transmit their EAPoL-encapsulated EAP messages so the "eap lower layer" really is different. It's probably a good idea to retain this difference. regards, Dan. From hartmans@mit.edu Tue Oct 25 03:49:29 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B98D21F8B85 for ; Tue, 25 Oct 2011 03:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.989 X-Spam-Level: X-Spam-Status: No, score=-102.989 tagged_above=-999 required=5 tests=[AWL=-0.724, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttwumE32xxgz for ; Tue, 25 Oct 2011 03:49:28 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A924F21F8B78 for ; Tue, 25 Oct 2011 03:49:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2E2A620188; Tue, 25 Oct 2011 06:50:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 694FB4239; Tue, 25 Oct 2011 06:49:25 -0400 (EDT) From: Sam Hartman To: "Dan Harkins" References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <49c04a893d1b09695022a8ea4fd3f7a9.squirrel@www.trepanning.net> <19b5003655cdb35815f9b8ebf0ec40db.squirrel@www.trepanning.net> Date: Tue, 25 Oct 2011 06:49:25 -0400 In-Reply-To: <19b5003655cdb35815f9b8ebf0ec40db.squirrel@www.trepanning.net> (Dan Harkins's message of "Mon, 24 Oct 2011 11:57:50 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 10:49:29 -0000 So, chairs, can I go forward with Joe's suggestions, include the ERP text and attempt to resolve Jim's comments if I can manage to find time before the cutoff? From jsalowey@cisco.com Fri Oct 28 08:19:14 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9524421F8509 for ; Fri, 28 Oct 2011 08:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.599 X-Spam-Level: X-Spam-Status: No, score=-105.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUei1PR-kwt6 for ; Fri, 28 Oct 2011 08:19:13 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A07CD21F84F9 for ; Fri, 28 Oct 2011 08:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1716; q=dns/txt; s=iport; t=1319815153; x=1321024753; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=/XLVIUD7lrvOPnoscf9bWZ6h4ck/7iTglZCksQbZdHE=; b=h0vHX/3TfJDs9h25ZcwF6z0edM7T+y/MO7YTjuhbfi/9ArycwDzZU6qK TKm7/c6tuxqfHg3aHKURIIpNdpT6vk4yaROQn0RTti0X9FwJjTvf+hUpL pSK1DUYSdisswKWDrzcEjra7b8ETcx2UXxAy0n4aPqyWuoTPfuKuKpgGw 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANTHqk6rRDoJ/2dsb2JhbABDqV+BBYFyAQEBAQIBAQEBDwEnNAsFCwsYLicwBhMih2AIlVMBnhUEiCJhBIgGjAeFLYxS X-IronPort-AV: E=Sophos;i="4.69,418,1315180800"; d="scan'208";a="10936234" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 28 Oct 2011 15:19:05 +0000 Received: from [10.33.251.254] ([10.33.251.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9SFIxi1030129; Fri, 28 Oct 2011 15:19:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4E9F65D3.7060801@toshiba.co.jp> Date: Fri, 28 Oct 2011 08:19:29 -0700 Content-Transfer-Encoding: 7bit Message-Id: <0D6D44B8-6D1A-4410-8355-61225488A912@cisco.com> References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <4E9F65D3.7060801@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1084) Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 15:19:14 -0000 On Oct 19, 2011, at 5:05 PM, Yoshihiro Ohba wrote: > Hi Sam, > > Since authorization and accounting with the use of the > pre-authentication may be different from those with the use of normal > authentication, it would be good to differentiate pre-auth and without > pre-auth for network access authentication protocols that support > pre-authentication, PANA and 802.11 are such protocols as far as I know. > > BTW, I also commented about adding IEEE 802.16m and IEEE 802.21a for > EAP lower-layers. Here is the references for them: > > IEEE 802.16m: "Standard for Local and Metropolitan Area Networks - > Part 16: Air Interface for Broadband Wireless Access Systems - > Advanced Air Interface", IEEE 802.16m-2011, 2011. > [Joe] How does 802.16m differ from 802.16e? > IEEE 802.21a: "Draft Standard for Local and metropolitan area > networks-Part 21: Media Independent Handover Services Amendment 2: > Security Extensions to Media Independent Handover Services and > Protocol", IEEE P802.21a/D04, 2011. > [Joe] I'd rather not include draft specifications in this document. > Regards, > Yoshihiro Ohba > > > (2011/10/20 4:59), Sam Hartman wrote: >> Hi. I've added PANA (pre-authentication). >> >> I wonder about the whole lower layer table. >> Why is it important to distinguish PANA with pre-auth from pana without >> pre-auth? >> >> Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with >> pre-auth? >> >> I'd appreciate it if someone who cared about network access told me what >> to do here:-) >> > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From jsalowey@cisco.com Fri Oct 28 09:49:58 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A3021F862F for ; Fri, 28 Oct 2011 09:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.932 X-Spam-Level: X-Spam-Status: No, score=-105.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZncYkDHOWFSL for ; Fri, 28 Oct 2011 09:49:57 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B726D21F861E for ; Fri, 28 Oct 2011 09:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=926; q=dns/txt; s=iport; t=1319820597; x=1321030197; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rMIWgVNFGvMEiNCn7xAaeOJUx7hxqwwr9I3Wegs21l4=; b=nHId6TZOsOLLyI03MtTtgmVxzlRNs7YEzIwJCF38h2nA8CpysyL7OrjS WEOCD4C7H4ZRqsm5id7jthq9Sc9K0GemDgXqmHKP+ixYDglc8PfUymVR3 tSrldAG1d+POlQPZtsPPbqTPRsDYUn3rsdU7N6CA/M5C/5j3A4Qua72JW w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAALcqk6rRDoI/2dsb2JhbAA5Cg6pV4EFgXIBAQEBAgESASc/BQsLRlcGNYdglUwBnhSFVIJOYQSIBowIhS2Le1c X-IronPort-AV: E=Sophos;i="4.69,419,1315180800"; d="scan'208";a="10978445" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 28 Oct 2011 16:49:57 +0000 Received: from [10.33.251.254] ([10.33.251.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9SGnugK030367; Fri, 28 Oct 2011 16:49:57 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: Date: Fri, 28 Oct 2011 09:50:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1138BAD8-A473-453B-B99C-14D89CBF9B04@cisco.com> References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <49c04a893d1b09695022a8ea4fd3f7a9.squirrel@www.trepanning.net> <19b5003655cdb35815f9b8ebf0ec40db.squirrel@www.trepanning.net> To: Sam Hartman X-Mailer: Apple Mail (2.1084) Cc: emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 16:49:58 -0000 There have not been any more comments on the list so please prepare a = new draft if you have time before the cutoff. I would also like to have = a discussion of this draft and last call changes in the EMU meeting in = Taiwan. =20 One additional issue I found was in section 9 the NAS-Identifier text = references Calling-Station-Id which is no longer referenced in the = document, in addition I don't think the rest of the text is accurate. = Here is a suggested revision: NAS-Identifier: This is an identifier populated by the NAS to identify = the NAS to the AAA server. It SHOULD be validated for consistency with = the local database in an enterprise deployment.=20 Joe On Oct 25, 2011, at 3:49 AM, Sam Hartman wrote: > So, chairs, can I go forward with Joe's suggestions, include the ERP > text and attempt to resolve Jim's comments if I can manage to find = time > before the cutoff? From internet-drafts@ietf.org Sun Oct 30 17:34:16 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7181811E8097; Sun, 30 Oct 2011 17:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVTWzVW95kzZ; Sun, 30 Oct 2011 17:34:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE0011E8093; Sun, 30 Oct 2011 17:34:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031003415.21764.6668.idtracker@ietfa.amsl.com> Date: Sun, 30 Oct 2011 17:34:15 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-chbind-11.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 00:34:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of th= e IETF. Title : Channel Binding Support for EAP Methods Author(s) : Sam Hartman T. Charles Clancy Katrin Hoeper Filename : draft-ietf-emu-chbind-11.txt Pages : 30 Date : 2011-10-30 This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-chbind-11.txt From yoshihiro.ohba@toshiba.co.jp Sun Oct 30 18:09:27 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8001021F84FD for ; Sun, 30 Oct 2011 18:09:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Yoqppm7u4iv for ; Sun, 30 Oct 2011 18:09:26 -0700 (PDT) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 88C9921F84D9 for ; Sun, 30 Oct 2011 18:09:26 -0700 (PDT) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id p9V19GrR020904; Mon, 31 Oct 2011 10:09:16 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id p9V19GSg010407; Mon, 31 Oct 2011 10:09:16 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id LAA10406; Mon, 31 Oct 2011 10:09:16 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id p9V19GFR008594; Mon, 31 Oct 2011 10:09:16 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id p9V19AXj017708; Mon, 31 Oct 2011 10:09:10 +0900 (JST) Received: from [133.196.17.85] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPA id <0LTW001JZOJF3M60@mail.po.toshiba.co.jp>; Mon, 31 Oct 2011 10:09:16 +0900 (JST) Date: Mon, 31 Oct 2011 10:09:08 +0900 From: Yoshihiro Ohba In-reply-to: <0D6D44B8-6D1A-4410-8355-61225488A912@cisco.com> To: Joe Salowey Message-id: <4EADF534.1060300@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit References: <03FF2E07-2DD4-4C71-B89B-DB62FC6AD286@cisco.com> <4E9BFD8E.3000108@toshiba.co.jp> <4E9F65D3.7060801@toshiba.co.jp> <0D6D44B8-6D1A-4410-8355-61225488A912@cisco.com> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] REMINDER: WGLC for draft-ietf-emu-chbind-09 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 01:09:27 -0000 Hi Joe, (2011/10/29 0:19), Joe Salowey wrote: >> >> BTW, I also commented about adding IEEE 802.16m and IEEE 802.21a for >> EAP lower-layers. Here is the references for them: >> >> IEEE 802.16m: "Standard for Local and Metropolitan Area Networks - >> Part 16: Air Interface for Broadband Wireless Access Systems - >> Advanced Air Interface", IEEE 802.16m-2011, 2011. >> > > > [Joe] How does 802.16m differ from 802.16e? As far as I understand, PHY and frame encodings are different. I am not sure if those differences are significant from EAP channel binding perspective. > >> IEEE 802.21a: "Draft Standard for Local and metropolitan area >> networks-Part 21: Media Independent Handover Services Amendment 2: >> Security Extensions to Media Independent Handover Services and >> Protocol", IEEE P802.21a/D04, 2011. >> > > [Joe] I'd rather not include draft specifications in this document. > Fair enough. As soon as 802.21a specification is published, I will let you know. Thanks, Yoshihiro Ohba >> Regards, >> Yoshihiro Ohba >> >> >> (2011/10/20 4:59), Sam Hartman wrote: >>> Hi. I've added PANA (pre-authentication). >>> >>> I wonder about the whole lower layer table. >>> Why is it important to distinguish PANA with pre-auth from pana without >>> pre-auth? >>> >>> Why is it important to distinguish 802.11 wpa, wpa2 and wpa2 with >>> pre-auth? >>> >>> I'd appreciate it if someone who cared about network access told me what >>> to do here:-) >>> >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > > From jsalowey@cisco.com Sun Oct 30 22:07:21 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCBF21F8C81 for ; Sun, 30 Oct 2011 22:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.199 X-Spam-Level: X-Spam-Status: No, score=-106.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2kl9BeIQ1Qs for ; Sun, 30 Oct 2011 22:07:21 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3DB21F8C75 for ; Sun, 30 Oct 2011 22:07:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=135; q=dns/txt; s=iport; t=1320037641; x=1321247241; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=7HOWVNDfoEC+qp9kRSrvIHeYXL9Cprr6LYpPfbrMPuE=; b=AN10sJ6UOCC9UaR/TwwvyPnnQ0VS4d65PnIZ12SS2litdJ0YPYGx+i6w XnUGPlD/GaWwHfG+44TBYzRxH8hrT7NqDCdKL3o/HHt/Xoe6T4PyyzlVC +9xd4Dg4279aP4G2XPKJbe5zlF1SBik0oFbxAvEOfEemIbU2jMjLc2lio 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0GADUsrk6rRDoH/2dsb2JhbABDmiSPEIEFggsBJ4IynCGBJgGdRoghYQSIBowIhS2MUg X-IronPort-AV: E=Sophos;i="4.69,429,1315180800"; d="scan'208";a="11289562" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 31 Oct 2011 05:07:21 +0000 Received: from [10.33.251.254] ([10.33.251.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9V57KuQ011834 for ; Mon, 31 Oct 2011 05:07:20 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 30 Oct 2011 22:07:50 -0700 Message-Id: <8DC57D1E-A77C-4D4E-85AF-5EF13C25A968@cisco.com> To: emu@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Emu] IETF 82 Agenda Items X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 05:07:21 -0000 EMU is schedule for Tuesday, November 15 from 9:00-11:30. Please send = requests for agenda time to the chairs. Thanks, Joe=