From emu-bounces@ietf.org Sun Feb 1 13:33:18 2009 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69F33A68D7; Sun, 1 Feb 2009 13:33:18 -0800 (PST) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0A23A69CD; Sun, 1 Feb 2009 13:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4Abh18BZizk; Sun, 1 Feb 2009 13:33:16 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id A69163A68D7; Sun, 1 Feb 2009 13:33:16 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 1BC711986FA; Sun, 1 Feb 2009 23:32:57 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id BD9C51986EE; Sun, 1 Feb 2009 23:32:56 +0200 (EET) Message-ID: <498614C4.20800@piuha.net> Date: Sun, 01 Feb 2009 23:31:48 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: emu@ietf.org References: <20090201204629.D5F093A6974@core3.amsl.com> In-Reply-To: <20090201204629.D5F093A6974@core3.amsl.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: iesg@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Speaking as an individual, I'm fine with this. It is important to document the EAP methods as they actually exist in wide deployment. That being said, we should also recognize the problems that codepoint overloading causes (even if the overloading issues are somewhat mitigated by the context ie tunnel in this case). And we should definitely NOT follow the same type of overloading in future work. Obviously not in IETF work, but I also hope that the main vendors have gotten the message that it is a bad idea. Jari _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Sun Feb 1 14:33:26 2009 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F8E828C182; Sun, 1 Feb 2009 14:33:26 -0800 (PST) X-Original-To: emu@ietf.org Delivered-To: emu@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id D5F093A6974; Sun, 1 Feb 2009 12:46:29 -0800 (PST) From: The IESG To: emu@ietf.org Mime-Version: 1.0 Message-Id: <20090201204629.D5F093A6974@core3.amsl.com> Date: Sun, 1 Feb 2009 12:46:29 -0800 (PST) X-Mailman-Approved-At: Sun, 01 Feb 2009 14:33:25 -0800 Cc: iesg@ietf.org Subject: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: iesg@ietf.org List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Dear EMU WG: These two documents are in the RFC Editor queue: draft-cam-winget-eap-fast-provisioning-10.txt draft-zhou-emu-fast-gtc-05.txt The IESG has received a very late comment about these documents, and we seek your input on the proposed resolution. The late comment raises a potential interoperability concern with existing implementations of EAP-MSCHAPv2 and EAP-GTC. The draft-cam-winget-eap-fast-provisioning-10.txt document specifies a very specific way to generate the challenges used in EAP-MSCHAPv2 that provides binding between the EAP-FAST tunnel and the EAP-MSCHAPv2 exchanges. The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which is uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. EAP-FAST-GTC employs a subset of the EAP-GTC formatting. The IESG recognizes the difficulties caused by re-use of an EAP Type. Further, the IESG recognizes the concern about implementations that might not easily adapt to additional requirements. However, the IESG also recognizes the significant value in documenting EAP methods that are implemented and deployed in the Internet today. The IESG believes that the right thing to do in this situation is to proceed with the publication of these documents. However, the IESG also sees value in warning future EAP method designers about this experience so that this pain might be avoided in the future. The IESG is considering the additional informative paragraph in the IANA considerations section of both documents that says: IESG Note: EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this is intended to promote interoperability, even though the use of the EAP-MSCHAPv2 and EAP-FAST-GTC EAP methods might be difficult in some software environments. If EAP-FAST were to be designed today, these difficulties could be avoided by the assignment of new EAP Type codes. Please provide comments on the proposed way forward. On behalf of the IESG, Russ _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Feb 2 10:21:00 2009 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67F7E3A6B93; Mon, 2 Feb 2009 10:21:00 -0800 (PST) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353803A6BBB; Mon, 2 Feb 2009 10:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKlJZM9NXF43; Mon, 2 Feb 2009 10:20:57 -0800 (PST) Received: from spaceymail-a3.g.dreamhost.com (lax-green-bigip-5.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 56ED63A6B2D; Mon, 2 Feb 2009 10:20:57 -0800 (PST) Received: from [192.168.1.49] (c-71-199-7-236.hsd1.ut.comcast.net [71.199.7.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by spaceymail-a3.g.dreamhost.com (Postfix) with ESMTP id DE5F7194EA9; Mon, 2 Feb 2009 10:20:37 -0800 (PST) Message-ID: <4987380B.7050008@open1x.org> Date: Mon, 02 Feb 2009 11:14:35 -0700 From: Chris Hessing User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: emu@ietf.org References: <20090201204629.D5F093A6974@core3.amsl.com> <498614C4.20800@piuha.net> In-Reply-To: <498614C4.20800@piuha.net> Cc: iesg@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Jari Arkko wrote: > Speaking as an individual, I'm fine with this. It is important to > document the EAP methods as they actually exist in wide deployment. > That being said, we should also recognize the problems that codepoint > overloading causes (even if the overloading issues are somewhat > mitigated by the context ie tunnel in this case). > > And we should definitely NOT follow the same type of overloading in > future work. Obviously not in IETF work, but I also hope that the main > vendors have gotten the message that it is a bad idea. > > Jari > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu While I strongly disagree with overloading of EAP types, I have to agree with Jari. I would like to see the IETF take a strong stance on not allowing overloading of EAP types in the future. However, at this point there are probably too many implementations to try to change, so it seems documentation of existing behavior may be the only reasonable course of action. That said, I would still like to see the provisioning document call out the security issues related to the use of anonymous provisioning. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Feb 2 18:57:48 2009 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2B33A6BE4; Mon, 2 Feb 2009 18:57:48 -0800 (PST) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF1183A6BDE for ; Mon, 2 Feb 2009 18:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urNeMGxxz-72 for ; Mon, 2 Feb 2009 18:57:46 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id A70E23A6BDD for ; Mon, 2 Feb 2009 18:57:46 -0800 (PST) Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA03.westchester.pa.mail.comcast.net with comcast id BCw11b03617dt5G53ExTE3; Tue, 03 Feb 2009 02:57:27 +0000 Received: from gwzPC ([124.120.224.111]) by OMTA13.westchester.pa.mail.comcast.net with comcast id BEwq1b00Y2QpjrQ3ZEwzLx; Tue, 03 Feb 2009 02:57:22 +0000 From: "Glen Zorn" To: "'Russ Housley'" References: <20090201204629.D5F093A6974@core3.amsl.com> In-Reply-To: <20090201204629.D5F093A6974@core3.amsl.com> Date: Tue, 3 Feb 2009 09:56:46 +0700 Message-ID: <012a01c985ab$210b2490$63216db0$@net> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-Index: AcmEvRAQ0y6B4oIXTimmQwZpaLUAnQA6M8pQ Cc: iesg@ietf.org, emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org > Dear EMU WG: > > These two documents are in the RFC Editor queue: > > draft-cam-winget-eap-fast-provisioning-10.txt > draft-zhou-emu-fast-gtc-05.txt > > The IESG has received a very late comment about these documents, and > we seek your input on the proposed resolution. > > The late comment raises a potential interoperability concern with > existing implementations of EAP-MSCHAPv2 and EAP-GTC. > > The draft-cam-winget-eap-fast-provisioning-10.txt document specifies > a very specific way to generate the challenges used in EAP-MSCHAPv2 > that provides binding between the EAP-FAST tunnel and the EAP-MSCHAPv2 > exchanges. > > The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which is > uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. EAP-FAST- > GTC > employs a subset of the EAP-GTC formatting. > > The IESG recognizes the difficulties caused by re-use of an EAP Type. > Further, the IESG recognizes the concern about implementations that > might not easily adapt to additional requirements. However, the IESG > also recognizes the significant value in documenting EAP methods that > are implemented and deployed in the Internet today. > > The IESG believes that the right thing to do in this situation is to > proceed with the publication of these documents. However, the IESG > also > sees value in warning future EAP method designers about this experience > so that this pain might be avoided in the future. > > The IESG is considering the additional informative paragraph in the > IANA > considerations section of both documents that says: > > IESG Note: EAP-FAST has been implemented by many vendors and it is > used in the Internet. Publication of this is intended to promote > interoperability, even though the use of the EAP-MSCHAPv2 and > EAP-FAST-GTC EAP methods might be difficult in some software > environments. If EAP-FAST were to be designed today, these > difficulties could be avoided by the assignment of new EAP Type > codes. > > Please provide comments on the proposed way forward. I am strongly opposed to the publication of these documents as RFCs in their current form. Not only is the "fast provisioning" for EAP-FAST what can only be characterized as a security disaster, but EAP-FAST-GTC has nothing whatsoever to do with the EAP-GTC type. EAP-GTC was "defined for use with various Token Card implementations which require user input" but EAP-FAST-GTC is used solely to transfer a username/password combination, the password in plaintext. It's hard to see what this has to do with actual token cards & appears to be a lazy misuse of an existing type. Furthermore, it's even harder to see how rewarding this kind of nonsense with publication will serve as a warning of any kind; I would expect that the action of publication (with or without IESG note) would be more likely taken as notice that one can do whatever one please without fear. > On behalf of the IESG, > Russ > > _______________________________________________ > 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 emu-bounces@ietf.org Tue Feb 3 03:54:40 2009 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B22993A6C22; Tue, 3 Feb 2009 03:54:40 -0800 (PST) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22D9B3A6C22 for ; Tue, 3 Feb 2009 03:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.243 X-Spam-Level: X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=-0.244, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEZhfI2RiolC for ; Tue, 3 Feb 2009 03:54:38 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 05A3C3A6C28 for ; Tue, 3 Feb 2009 03:54:37 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n13BsD1k020833; Tue, 3 Feb 2009 13:54:15 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Feb 2009 13:54:03 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 3 Feb 2009 13:54:03 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 3 Feb 2009 12:54:02 +0100 From: To: , Date: Tue, 3 Feb 2009 12:53:58 +0100 Thread-Topic: [Emu] Potential Issues with EAP-FAST Thread-Index: Acl9rw4K1I+mwYdeTuieBpgv7cEkugIRNbyw Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E78B743A@NOK-EUMSG-01.mgdnok.nokia.com> References: <497A4B3F.3020600@open1x.org> In-Reply-To: <497A4B3F.3020600@open1x.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2009 11:54:03.0333 (UTC) FILETIME=[1BE6CF50:01C985F6] X-Nokia-AV: Clean Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org Chris Hessing wrote: > For anonymous provisioning, it also seems there is a pretty large > security hole. It is smaller than the security issues with LEAP, > but is still rather large. > > With anonymous provisioning the supplicant has to implicitly trust > the authentication server it is talking to. The only piece of > information the supplicant has that it can use to attempt to verify > the server is the A-ID that is provided. But, in a provisioning > mode the supplicant doesn't really have a way to verify that the > A-ID is valid. As a result, the supplicant will continue on with > the provisioning and provide the server with its credentials. The supplicant also verifies the MS-CHAPv2 Success packet, which contains a MAC -- so there is mutual authentication (some kind of), and the provisioning exchange won't finish successfully unless the attacker can spoof this MAC. The attacker doesn't know the password (and an't compute the MAC himself), and deriving the challenges from the TLS key block means the attacker can't just "cut-and-paste" MS-CHAPv2 messages from the real authentication server. It's true that the bad guy gets the MS-CHAPv2 response, and can do an off-line dictionary attack. This is described in Section 6.2, which also suggests some possible countermeasures (not perfect, but something). But if your password is reasonably strong, it seems this can be reasonably OK (unless I'm missing something here)... > In the best case scenario, the supplicant is configured to only > allow the user of MS-CHAPv2 for provisioning, so "all" the bad guy > gets is the resulting MS-CHAPv2 hash which can then be attacked > directly and off-line. In the worst case the supplicant allows GTC > to be used for provisioning and the clear text credentials are > handed over to the attacker. The specification doesn't allow using GTC when doing anonymous provisioning, so the worst case doesn't happen if you follow the spec. Best regards, Pasi _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Feb 3 08:13:51 2009 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 836D928C126; Tue, 3 Feb 2009 08:13:51 -0800 (PST) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B9528C126; Tue, 3 Feb 2009 08:13:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRoCJ41SOH-J; Tue, 3 Feb 2009 08:13:49 -0800 (PST) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by core3.amsl.com (Postfix) with ESMTP id 21A1628C0DF; Tue, 3 Feb 2009 08:13:49 -0800 (PST) Received: by wa-out-1112.google.com with SMTP id m33so1087215wag.5 for ; Tue, 03 Feb 2009 08:13:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EpN7LlA1wkRtvp8Tl1PS9SIC5Z8hyuRyPdHxVgtPvsg=; b=oN2pXex4J9amhnePKAzy+O9A3uH89ojZGnVcZElRmQr8zDttK5Os2QWywCu5c+l06D nix5fpW8YE5aRstoQwhuIFe7aTyxsvmN0Gl774v8e23KX+hljQYvA0RzdDwQ9L3n7JMA Ats0V81RW8rcvj+a4siKCbxxudaFT0GlyMpq8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iaCQTzIZLiNMW8fGsTyWzD36HGyYLaTBCTRRlFIlm9p2zGR4m8w0bflOAU7y9tXkua GhVtrMTF6ECi8+703OFspukycJWt5RYaGaH2UDUJu4/YX/x/tuK+bQ0gLDw9CAzo62Jn 9U7hltLiBLNtss+nM0L8SSKfEVH7SafZzG/0g= MIME-Version: 1.0 Received: by 10.114.194.1 with SMTP id r1mr3767208waf.149.1233677609315; Tue, 03 Feb 2009 08:13:29 -0800 (PST) In-Reply-To: <012a01c985ab$210b2490$63216db0$@net> References: <20090201204629.D5F093A6974@core3.amsl.com> <012a01c985ab$210b2490$63216db0$@net> Date: Tue, 3 Feb 2009 08:13:29 -0800 Message-ID: <5bfe7a820902030813j36702991g6d24252bb63b7d34@mail.gmail.com> From: Dorothy Stanley To: Glen Zorn Cc: Russ Housley , iesg@ietf.org, emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0154368352==" Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org --===============0154368352== Content-Type: multipart/alternative; boundary=00163646c1daabaed7046205f3a5 --00163646c1daabaed7046205f3a5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The interoperability concern with existing EAP-MSCHAPv2 and EAP-GTC implementations and incorrect re-use of EAP Types must be addressed/corrected prior to publication. One solution is to (a) Get a new, correct type number for use by the method in the published document, and change the name of the method (could use "name-CR" for "corrected/revision", or similar). This eliminates the interoperability concern with existing methods, and uniquely identifies the IETF published method. and (b) Add descriptive text in the document to explain the difference between this IETF published method and similar deployed methods - to meet the desire to document deployed methods. Dorothy Stanley On Mon, Feb 2, 2009 at 6:56 PM, Glen Zorn wrote: > > > Dear EMU WG: > > > > These two documents are in the RFC Editor queue: > > > > draft-cam-winget-eap-fast-provisioning-10.txt > > draft-zhou-emu-fast-gtc-05.txt > > > > The IESG has received a very late comment about these documents, and > > we seek your input on the proposed resolution. > > > > The late comment raises a potential interoperability concern with > > existing implementations of EAP-MSCHAPv2 and EAP-GTC. > > > > The draft-cam-winget-eap-fast-provisioning-10.txt document specifies > > a very specific way to generate the challenges used in EAP-MSCHAPv2 > > that provides binding between the EAP-FAST tunnel and the EAP-MSCHAPv2 > > exchanges. > > > > The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which is > > uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. EAP-FAST- > > GTC > > employs a subset of the EAP-GTC formatting. > > > > The IESG recognizes the difficulties caused by re-use of an EAP Type. > > Further, the IESG recognizes the concern about implementations that > > might not easily adapt to additional requirements. However, the IESG > > also recognizes the significant value in documenting EAP methods that > > are implemented and deployed in the Internet today. > > > > The IESG believes that the right thing to do in this situation is to > > proceed with the publication of these documents. However, the IESG > > also > > sees value in warning future EAP method designers about this experience > > so that this pain might be avoided in the future. > > > > The IESG is considering the additional informative paragraph in the > > IANA > > considerations section of both documents that says: > > > > IESG Note: EAP-FAST has been implemented by many vendors and it is > > used in the Internet. Publication of this is intended to promote > > interoperability, even though the use of the EAP-MSCHAPv2 and > > EAP-FAST-GTC EAP methods might be difficult in some software > > environments. If EAP-FAST were to be designed today, these > > difficulties could be avoided by the assignment of new EAP Type > > codes. > > > > Please provide comments on the proposed way forward. > > I am strongly opposed to the publication of these documents as RFCs in > their > current form. Not only is the "fast provisioning" for EAP-FAST what can > only be characterized as a security disaster, but EAP-FAST-GTC has nothing > whatsoever to do with the EAP-GTC type. EAP-GTC was "defined for use with > various Token Card implementations which require user input" but > EAP-FAST-GTC is used solely to transfer a username/password combination, > the > password in plaintext. It's hard to see what this has to do with actual > token cards & appears to be a lazy misuse of an existing type. > Furthermore, > it's even harder to see how rewarding this kind of nonsense with > publication > will serve as a warning of any kind; I would expect that the action of > publication (with or without IESG note) would be more likely taken as > notice > that one can do whatever one please without fear. > > > On behalf of the IESG, > > Russ > > > > _______________________________________________ > > 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 > --00163646c1daabaed7046205f3a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The interoperability concern with existing EAP-MSCHAPv2 and EAP-GTC
impl= ementations and incorrect re-use of EAP Types must be addressed/corrected p= rior to publication.

One solution is to

(a) Get a new, corr= ect type number for use by the method in the published document, and change= the name of the method
(could use "name-CR" for "corrected/revision", or simil= ar). This eliminates the interoperability concern with existing methods,and uniquely identifies the IETF published method.

and

(b) A= dd descriptive text in the document to explain the difference between this = IETF published method and similar  deployed
methods - to meet the desire to document deployed methods.

Dorothy S= tanley

On Mon, Feb 2, 2009 at 6:56 PM, Gl= en Zorn <glenz= orn@comcast.net> wrote:
<= div class=3D"Wj3C7c">
> Dear EMU WG:
>
> These two documents are in the RFC Editor queue:
>
>    draft-cam-winget-eap-fast-provisioning-10.txt
>    draft-zhou-emu-fast-gtc-05.txt
>
> The IESG has received a very late comment about these documents, and > we seek your input on the proposed resolution.
>
> The late comment raises a potential interoperability concern with
> existing implementations of EAP-MSCHAPv2 and EAP-GTC.
>
> The draft-cam-winget-eap-fast-provisioning-10.txt document specifies > a very specific way to generate the challenges used in EAP-MSCHAPv2 > that provides binding between the EAP-FAST tunnel and the EAP-MSCHAPv2=
> exchanges.
>
> The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which is > uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. EAP-FAST-<= br> > GTC
> employs a subset of the EAP-GTC formatting.
>
> The IESG recognizes the difficulties caused by re-use of an EAP Type.<= br> > Further, the IESG recognizes the concern about implementations that > might not easily adapt to additional requirements.  However, the = IESG
> also recognizes the significant value in documenting EAP methods that<= br> > are implemented and deployed in the Internet today.
>
> The IESG believes that the right thing to do in this situation is to > proceed with the publication of these documents.  However, the IE= SG
> also
> sees value in warning future EAP method designers about this experienc= e
> so that this pain might be avoided in the future.
>
> The IESG is considering the additional informative paragraph in the > IANA
> considerations section of both documents that says:
>
>     IESG Note: EAP-FAST has been implemented by many vendors= and it is
>     used in the Internet.  Publication of this is inten= ded to promote
>     interoperability, even though the use of the EAP-MSCHAPv= 2 and
>     EAP-FAST-GTC EAP methods might be difficult in some soft= ware
>     environments.  If EAP-FAST were to be designed toda= y, these
>     difficulties could be avoided by the assignment of new E= AP Type
>     codes.
>
> Please provide comments on the proposed way forward.

I am strongly opposed to the publication of these documents as = RFCs in their
current form.  Not only is the "fast provisioning" for EAP-F= AST what can
only be characterized as a security disaster, but EAP-FAST-GTC has nothing<= br> whatsoever to do with the EAP-GTC type.  EAP-GTC was "defined for= use with
various Token Card implementations which require user input" but
EAP-FAST-GTC is used solely to transfer a username/password combination, th= e
password in plaintext.  It's hard to see what this has to do with = actual
token cards & appears to be a lazy misuse of an existing type.  Fu= rthermore,
it's even harder to see how rewarding this kind of nonsense with public= ation
will serve as a warning of any kind; I would expect that the action of
publication (with or without IESG note) would be more likely taken as notic= e
that one can do whatever one please without fear.

> On behalf of the IESG,
>   Russ
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
Emu@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/emu

--00163646c1daabaed7046205f3a5-- --===============0154368352== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu --===============0154368352==-- From emu-bounces@ietf.org Tue Feb 3 09:32:40 2009 Return-Path: X-Original-To: emu-archive@megatron.ietf.org Delivered-To: ietfarch-emu-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A74C3A6C51; Tue, 3 Feb 2009 09:32:40 -0800 (PST) X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E8D73A6C48; Tue, 3 Feb 2009 09:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVoDa3KYkpvM; Tue, 3 Feb 2009 09:32:38 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by core3.amsl.com (Postfix) with ESMTP id 662673A6B2E; Tue, 3 Feb 2009 09:32:38 -0800 (PST) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay01.hostedemail.com (Postfix) with SMTP id 062C642B392; Tue, 3 Feb 2009 17:32:17 +0000 (UTC) X-SpamScore: 1 X-Spam-Summary: 2, 0, 0, 90b3062820c43adc, 80fcc780ad92201b, david@mitton.com, dstanley1389@gmail.com:glenzorn@comcast.net:housley@vigilsec.com:iesg@ietf.org:emu@ietf.org, RULES_HIT:2703, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none Received: from webmail01 (imap-ext [216.40.42.5]) (Authenticated sender: david@mitton.com) by omf02.hostedemail.com (Postfix) with ESMTP; Tue, 3 Feb 2009 17:32:16 +0000 (UTC) Date: Tue, 3 Feb 2009 17:32:16 +0000 (GMT) From: David Mitton To: dstanley1389@gmail.com Message-ID: <1668467045.107361.1233682336329.JavaMail.mail@webmail01> MIME-Version: 1.0 X-session-marker: 6461766964406D6974746F6E2E636F6D Cc: housley@vigilsec.com, iesg@ietf.org, emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: david@mitton.com List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0242909696==" Sender: emu-bounces@ietf.org Errors-To: emu-bounces@ietf.org --===============0242909696== Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'm sorry,  I haven't responded earlier either, but I would like to= pile on with some of my comments.

When I read the Cisco EAP-FAST GTC description and was similarly shocked= by the nature of the changes, and how poorly they technically met their ow= n rationale.

Encoding the "REQ=3D" and "RESP=3D" into Request and Response text,= is absolutely useless, since the data flow is unidirectional and know= n to the requester/responder peers.

And then claiming that is more efficent because the username and OTP are= combined in one response, really ignores the issue that GTC doesn't define= what the appropriate response is.  And they did nothing to clue the c= lient as to what is being requested, or the format of the response.

Given that, a Client can only strip the useless cybercrud, and continue = with the normal GTC state machine which is let the user type something in a= nd send it.

A more robust OTP implementation may have several different inputs that = it wants from the user besides for username and OTP.  (BTW; username c= ould be derived from the EAP Identity)   There are possible next = token challenges,  new PIN assignment (user or system generated) = and followup re-authentications.   Their protocol did nothing to= codify a standard for interoperation where a sequence of requests wer= e enumerated or named, and response items were described. 

I'm all for documenting practice, but this design/implementation doesn't= really seem to solve anything and just creates more confusion.

Dave Mitton


Feb 3, 2009 11:13:36 AM, dstanley1389@gmail.com wrote:

The interoper= ability concern with existing EAP-MSCHAPv2 and EAP-GTC
implementations a= nd incorrect re-use of EAP Types must be addressed/corrected prior to publi= cation.

One solution is to

(a) Get a new, correct type numb= er for use by the method in the published document, and change the name of = the method
(could use "name-CR" for "corrected/revision", or similar). T= his eliminates the interoperability concern with existing methods,
and u= niquely identifies the IETF published method.

and

(b) Add des= criptive text in the document to explain the difference between this IETF p= ublished method and similar  deployed
methods - to meet the desire = to document deployed methods.

Dorothy Stanley

On Mon, Feb 2, 2009 at 6:56 PM, Glen Zorn <glenzor= n@comcast.net> wrote:

> Dear EMU WG:
>
> These two documen= ts are in the RFC Editor queue:
>
>    draft-cam-wing= et-eap-fast-provisioning-10.txt
>    draft-zhou-emu-fast-gt= c-05.txt
>
> The IESG has received a very late comment about th= ese documents, and
> we seek your input on the proposed resolution.>
> The late comment raises a potential interoperability concern= with
> existing implementations of EAP-MSCHAPv2 and EAP-GTC.
>=
> The draft-cam-winget-eap-fast-provisioning-10.txt document specifi= es
> a very specific way to generate the challenges used in EAP-MSCHA= Pv2
> that provides binding between the EAP-FAST tunnel and the EAP-M= SCHAPv2
> exchanges.
>
> The draft-zhou-emu-fast-gtc-05.t= xt describes EAP-FAST-GTC, which is
> uses EAP Type 6, originally all= ocated to EAP-GTC [RFC3748]. EAP-FAST-
> GTC
> employs a subset= of the EAP-GTC formatting.
>
> The IESG recognizes the difficu= lties caused by re-use of an EAP Type.
> Further, the IESG recognizes= the concern about implementations that
> might not easily adapt to a= dditional requirements.  However, the IESG
> also recognizes the= significant value in documenting EAP methods that
> are implemented = and deployed in the Internet today.
>
> The IESG believes that = the right thing to do in this situation is to
> proceed with the publ= ication of these documents.  However, the IESG
> also
> se= es value in warning future EAP method designers about this experience
&g= t; so that this pain might be avoided in the future.
>
> The IE= SG is considering the additional informative paragraph in the
> IANA<= BR>> considerations section of both documents that says:
>
>=     IESG Note: EAP-FAST has been implemented by many vendors and= it is
>     used in the Internet.  Publication of thi= s is intended to promote
>     interoperability, even thoug= h the use of the EAP-MSCHAPv2 and
>     EAP-FAST-GTC EAP me= thods might be difficult in some software
>     environment= s.  If EAP-FAST were to be designed today, these
>    = difficulties could be avoided by the assignment of new EAP Type
> &n= bsp;   codes.
>
> Please provide comments on the proposed = way forward.

I am strongly opposed to the publication of= these documents as RFCs in their
current form.  Not only is the "f= ast provisioning" for EAP-FAST what can
only be characterized as a secur= ity disaster, but EAP-FAST-GTC has nothing
whatsoever to do with the EAP= -GTC type.  EAP-GTC was "defined for use with
various Token Card im= plementations which require user input" but
EAP-FAST-GTC is used solely = to transfer a username/password combination, the
password in plaintext. =  It's hard to see what this has to do with actual
token cards &= appears to be a lazy misuse of an existing type.  Furthermore,
it'= s even harder to see how rewarding this kind of nonsense with publicationwill serve as a warning of any kind; I would expect that the action ofpublication (with or without IESG note) would be more likely taken as noti= ce
that one can do whatever one please without fear.

> On behalf of the IESG,
>   Russ
= >
> _______________________________________________
> Emu ma= iling list
> Emu@ietf= .org
> https://www.ietf.org/mailman/listinfo/emu

__________= _____________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailm= an/listinfo/emu



_______________________________________________
Emu mailing list
= Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
<= /BODY> --===============0242909696== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu --===============0242909696==-- From dharkins@lounge.org Tue Feb 3 13:00:10 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54543A6AEA; Tue, 3 Feb 2009 13:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6L2WvyrAcB6; Tue, 3 Feb 2009 13:00:09 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id D447E3A69ED; Tue, 3 Feb 2009 13:00:09 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 912EBA888108; Tue, 3 Feb 2009 12:59:50 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 3 Feb 2009 12:59:50 -0800 (PST) Message-ID: <9d4dbfb3e0ecb13a7625cc40bb9d24f7.squirrel@www.trepanning.net> In-Reply-To: <20090201204629.D5F093A6974@core3.amsl.com> References: <20090201204629.D5F093A6974@core3.amsl.com> Date: Tue, 3 Feb 2009 12:59:50 -0800 (PST) From: "Dan Harkins" To: iesg@ietf.org 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] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 21:00:10 -0000 I strongly recommend against publication of these two documents. They represent essentially proprietary hacks on established protocols. The benefit in documenting use of EAP in the Internet today is far outweighed by the damage done to existing protocol specification and implementations. They will serve only to create spagetti code and unnecessary complexity. In addition to the issues noted by others I will also point out that information is being extracted from TLS for use in (the exchange erroneously described as) "EAP-MSCHAPv2" in a way that is different than the way being proposed by the TLS WG and does not include a binding to the application. I don't believe a stable reference of these proprietary hacks is necessary because the lack of an RFC to reference them has not stopped them from being implemented. Whatever process has been used in the past to convey their specification can be used going forward. draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226 but nowhere in that RFC can I find description of the following label for an initial assignment of repository values: "allocated for management by Cisco" yet the draft instructs IANA to set aside values 11-63 for just that purpose. I think that's very inappropriate. Not only is it telling IANA to cede some of its authority to a large multinational corporation but it is decidedly *NOT* documenting existing use! If this whole exercise is to document existing use then where are the specifications for these PAC attribute types? The recommended note does nothing to stop this kind of abuse in the future because the pain you mention is not felt by the one doing the abuse. To condone one transgression is to invite one thousand more. regards, Dan. On Sun, February 1, 2009 12:46 pm, The IESG wrote: > Dear EMU WG: > > These two documents are in the RFC Editor queue: > > draft-cam-winget-eap-fast-provisioning-10.txt > draft-zhou-emu-fast-gtc-05.txt > > The IESG has received a very late comment about these documents, and > we seek your input on the proposed resolution. > > The late comment raises a potential interoperability concern with > existing implementations of EAP-MSCHAPv2 and EAP-GTC. > > The draft-cam-winget-eap-fast-provisioning-10.txt document specifies > a very specific way to generate the challenges used in EAP-MSCHAPv2 > that provides binding between the EAP-FAST tunnel and the EAP-MSCHAPv2 > exchanges. > > The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which is > uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. EAP-FAST-GTC > employs a subset of the EAP-GTC formatting. > > The IESG recognizes the difficulties caused by re-use of an EAP Type. > Further, the IESG recognizes the concern about implementations that > might not easily adapt to additional requirements. However, the IESG > also recognizes the significant value in documenting EAP methods that > are implemented and deployed in the Internet today. > > The IESG believes that the right thing to do in this situation is to > proceed with the publication of these documents. However, the IESG also > sees value in warning future EAP method designers about this experience > so that this pain might be avoided in the future. > > The IESG is considering the additional informative paragraph in the IANA > considerations section of both documents that says: > > IESG Note: EAP-FAST has been implemented by many vendors and it is > used in the Internet. Publication of this is intended to promote > interoperability, even though the use of the EAP-MSCHAPv2 and > EAP-FAST-GTC EAP methods might be difficult in some software > environments. If EAP-FAST were to be designed today, these > difficulties could be avoided by the assignment of new EAP Type > codes. > > Please provide comments on the proposed way forward. > > On behalf of the IESG, > Russ > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From hzhou@cisco.com Tue Feb 3 13:57:41 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CFE828C0FC; Tue, 3 Feb 2009 13:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJhG+GL5q1IP; Tue, 3 Feb 2009 13:57:39 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C00FD3A68A2; Tue, 3 Feb 2009 13:57:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,374,1231113600"; d="scan'208,217";a="242271505" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 03 Feb 2009 21:57:20 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n13LvG63006304; Tue, 3 Feb 2009 16:57:16 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n13LvFE3012615; Tue, 3 Feb 2009 21:57:16 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 16:57:13 -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_01C9864A.44AC2433" Date: Tue, 3 Feb 2009 16:56:29 -0500 Message-ID: <9958B444368E884DBB215F3FEF36F5B708E37AD3@xmb-rtp-212.amer.cisco.com> In-Reply-To: <1668467045.107361.1233682336329.JavaMail.mail@webmail01> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Potential Notes in EAP-FAST Documents Thread-Index: AcmGJWminpIXM8RGTDeNjvItBjlcQwAIRdng References: <1668467045.107361.1233682336329.JavaMail.mail@webmail01> From: "Hao Zhou (hzhou)" To: , X-OriginalArrivalTime: 03 Feb 2009 21:57:13.0647 (UTC) FILETIME=[5F027BF0:01C9864A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=20332; t=1233698239; x=1234562239; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20(hzhou)=22=20 |Subject:=20RE=3A=20[Emu]=20Potential=20Notes=20in=20EAP-FA ST=20Documents |Sender:=20 |To:=20,=20; bh=yYgN6M7nZX6WlUhsFFwaSnfW50Zak3VVkRFNx2B/GaQ=; b=sFlVRHyXobv4SN6niDLlqgiAUPy8NqAvYwYfqkbB7Su6wUDg3BdyRJuJUw jz9D8181ClRPDEXjKoOZvUCFFxvoC2VdcpBJ99OYbKZ6HBrBuV7s4y+ZRUvy B7N1JWmlLQ; Authentication-Results: rtp-dkim-1; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: housley@vigilsec.com, iesg@ietf.org, emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 21:57:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9864A.44AC2433 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dave and Dorothy: We don't believe there are interoperability issues, as the intended informational RFCs clearly describe the protocol and packet format over the wire for these inner methods specifically when running inside EAP-FAST. The so called "interoperability issue" raised is at most an implementation issue, only applies to certain software environments where the same inner methods are used both inside and outside EAP-FAST, and could be worked around. This is demonstrated by the numerous existing client and server implementations already deployed in the field (most of which support these inner methods both inside and outside EAP-FAST), and lack of reporting of this issue. The intent of these drafts is informational and to clearly document the existing implementations started 5 years ago. Assigning new EAP types isn't going to solve any interoperability problems, but is likely to generate new ones. If we were to redesign today, certainly we would probably take a different approach to make the software implementation easier. We are open to all of your suggestions for enhancements on the next version of EAP-FAST.=20 We believe these drafts have documented these potential points of confusion. The difference between EAP-MSCHAPVv2 inside and outside EAP-FAST is documented in draft-cam-winget-eap-fast-provisioning. As for EAP-FAST-GTC, the draft-zhou-emu-fast-gtc documents the difference it has with EAP-GTC in turns of handling password authentication. As for regular OTP or token authentication, the implementation could strip the labels and pass the rest to the regular EAP-GTC state machine. How GTC handles the token exchanges is outside the scope of this draft (under defined in RFC3748). If you do see areas of requiring more description of the differences, we are certainly open to suggestions.=20 =20 ________________________________ From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of David Mitton Sent: Tuesday, February 03, 2009 12:32 PM To: dstanley1389@gmail.com Cc: housley@vigilsec.com; iesg@ietf.org; emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents =09 =09 I'm sorry, I haven't responded earlier either, but I would like to pile on with some of my comments. When I read the Cisco EAP-FAST GTC description and was similarly shocked by the nature of the changes, and how poorly they technically met their own rationale. Encoding the "REQ=3D" and "RESP=3D" into Request and Response text, is absolutely useless, since the data flow is unidirectional and known to the requester/responder peers. And then claiming that is more efficent because the username and OTP are combined in one response, really ignores the issue that GTC doesn't define what the appropriate response is. And they did nothing to clue the client as to what is being requested, or the format of the response. Given that, a Client can only strip the useless cybercrud, and continue with the normal GTC state machine which is let the user type something in and send it. A more robust OTP implementation may have several different inputs that it wants from the user besides for username and OTP. (BTW; username could be derived from the EAP Identity) There are possible next token challenges, new PIN assignment (user or system generated) and followup re-authentications. Their protocol did nothing to codify a standard for interoperation where a sequence of requests were enumerated or named, and response items were described. =20 I'm all for documenting practice, but this design/implementation doesn't really seem to solve anything and just creates more confusion. Dave Mitton =09 Feb 3, 2009 11:13:36 AM, dstanley1389@gmail.com wrote: =09 The interoperability concern with existing EAP-MSCHAPv2 and EAP-GTC implementations and incorrect re-use of EAP Types must be addressed/corrected prior to publication.=20 =09 One solution is to=20 =09 (a) Get a new, correct type number for use by the method in the published document, and change the name of the method (could use "name-CR" for "corrected/revision", or similar). This eliminates the interoperability concern with existing methods, and uniquely identifies the IETF published method. =09 and =09 (b) Add descriptive text in the document to explain the difference between this IETF published method and similar deployed methods - to meet the desire to document deployed methods. =09 Dorothy Stanley =09 =09 On Mon, Feb 2, 2009 at 6:56 PM, Glen Zorn wrote: =09 > Dear EMU WG: > > These two documents are in the RFC Editor queue: > > draft-cam-winget-eap-fast-provisioning-10.txt > draft-zhou-emu-fast-gtc-05.txt > > The IESG has received a very late comment about these documents, and > we seek your input on the proposed resolution. > > The late comment raises a potential interoperability concern with > existing implementations of EAP-MSCHAPv2 and EAP-GTC. > > The draft-cam-winget-eap-fast-provisioning-10.txt document specifies > a very specific way to generate the challenges used in EAP-MSCHAPv2 > that provides binding between the EAP-FAST tunnel and the EAP-MSCHAPv2 > exchanges. > > The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which is > uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. EAP-FAST- > GTC > employs a subset of the EAP-GTC formatting. > > The IESG recognizes the difficulties caused by re-use of an EAP Type. > Further, the IESG recognizes the concern about implementations that > might not easily adapt to additional requirements. However, the IESG > also recognizes the significant value in documenting EAP methods that > are implemented and deployed in the Internet today. > > The IESG believes that the right thing to do in this situation is to > proceed with the publication of these documents. However, the IESG > also > sees value in warning future EAP method designers about this experience > so that this pain might be avoided in the future. > > The IESG is considering the additional informative paragraph in the > IANA > considerations section of both documents that says: > > IESG Note: EAP-FAST has been implemented by many vendors and it is > used in the Internet. Publication of this is intended to promote > interoperability, even though the use of the EAP-MSCHAPv2 and > EAP-FAST-GTC EAP methods might be difficult in some software > environments. If EAP-FAST were to be designed today, these > difficulties could be avoided by the assignment of new EAP Type > codes. > > Please provide comments on the proposed way forward. =09 =09 I am strongly opposed to the publication of these documents as RFCs in their current form. Not only is the "fast provisioning" for EAP-FAST what can only be characterized as a security disaster, but EAP-FAST-GTC has nothing whatsoever to do with the EAP-GTC type. EAP-GTC was "defined for use with various Token Card implementations which require user input" but EAP-FAST-GTC is used solely to transfer a username/password combination, the password in plaintext. It's hard to see what this has to do with actual token cards & appears to be a lazy misuse of an existing type. Furthermore, it's even harder to see how rewarding this kind of nonsense with publication will serve as a warning of any kind; I would expect that the action of publication (with or without IESG note) would be more likely taken as notice that one can do whatever one please without fear. =09 > On behalf of the IESG, > Russ > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu =09 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu =09 ________________________________ _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu =09 ------_=_NextPart_001_01C9864A.44AC2433 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Dave and Dorothy:

We don't believe there are = interoperability issues,=20 as the intended informational RFCs clearly describe the protocol and = packet=20 format over the wire for these inner methods specifically when running = inside=20 EAP-FAST. The so called "interoperability issue" raised is at most an implementation issue, = only applies=20 to certain software environments where the same inner methods are used = both=20 inside and outside EAP-FAST, and could be worked around. This is = demonstrated by=20 the numerous existing client and server implementations already deployed = in the=20 field (most of which support these inner methods both inside and outside = EAP-FAST), and lack of reporting of this issue. The intent of these = drafts is=20 informational and to clearly document the existing implementations = started 5=20 years ago. Assigning new EAP types isn't going to solve any = interoperability=20 problems, but is likely to generate new ones. If we were to redesign = today,=20 certainly we would probably take = a=20 different approach to make the software implementation easier. We are = open to=20 all of your suggestions for enhancements on the next version of = EAP-FAST.=20

We believe these drafts have documented these potential points of = confusion. The=20 difference between EAP-MSCHAPVv2 inside and outside EAP-FAST is = documented in=20 draft-cam-winget-eap-fast-provisioning. As for EAP-FAST-GTC, the=20 draft-zhou-emu-fast-gtc documents the difference it has with EAP-GTC in = turns of=20 handling password authentication. As for regular OTP or token = authentication,=20 the implementation could strip the labels and pass the rest to the = regular=20 EAP-GTC state machine. How GTC handles the token exchanges is outside = the scope=20 of this draft (under defined in RFC3748). If you do see areas of = requiring more=20 description of the differences, we are certainly open to suggestions.=20

 

From: emu-bounces@ietf.org=20 [mailto:emu-bounces@ietf.org] On Behalf Of David = Mitton
Sent:=20 Tuesday, February 03, 2009 12:32 PM
To:=20 dstanley1389@gmail.com
Cc: housley@vigilsec.com; = iesg@ietf.org;=20 emu@ietf.org
Subject: Re: [Emu] Potential Notes in EAP-FAST=20 Documents

I'm sorry,  I haven't responded earlier either, but I would = like to=20 pile on with some of my comments.

When I read the Cisco EAP-FAST GTC description and was similarly = shocked by=20 the nature of the changes, and how poorly they technically met their = own=20 rationale.

Encoding the "REQ=3D" and "RESP=3D" into Request and Response = text, is=20 absolutely useless, since the data flow is unidirectional and = known to=20 the requester/responder peers.

And then claiming that is more efficent because the username and = OTP are=20 combined in one response, really ignores the issue that GTC doesn't = define=20 what the appropriate response is.  And they did nothing to clue = the=20 client as to what is being requested, or the format of the = response.

Given that, a Client can only strip the useless cybercrud, and = continue=20 with the normal GTC state machine which is let the user type something = in and=20 send it.

A more robust OTP implementation may have several different inputs = that it=20 wants from the user besides for username and OTP.  (BTW; username = could=20 be derived from the EAP Identity)   There are possible next = token=20 challenges,  new PIN assignment (user or system generated)  = and=20 followup re-authentications.   Their protocol did nothing to = codify=20 a standard for interoperation where a sequence of requests were=20 enumerated or named, and response items were described. 

I'm all for documenting practice, but this design/implementation = doesn't=20 really seem to solve anything and just creates more confusion.

Dave Mitton


Feb 3, 2009 11:13:36 AM, dstanley1389@gmail.com wrote:

The=20 interoperability concern with existing EAP-MSCHAPv2 and=20 EAP-GTC
implementations and incorrect re-use of EAP Types must be = addressed/corrected prior to publication.

One solution is to =

(a) Get a new, correct type number for use by the method in = the=20 published document, and change the name of the method
(could use=20 "name-CR" for "corrected/revision", or similar). This eliminates the = interoperability concern with existing methods,
and uniquely = identifies=20 the IETF published method.

and

(b) Add descriptive = text in the=20 document to explain the difference between this IETF published = method and=20 similar  deployed
methods - to meet the desire to document = deployed=20 methods.

Dorothy Stanley

On Mon, Feb 2, 2009 at 6:56 PM, Glen Zorn = <glenzorn@comcast.net> wrote:

> Dear EMU WG:
>
> These = two=20 documents are in the RFC Editor queue:
>
>  =20  draft-cam-winget-eap-fast-provisioning-10.txt
>   =  draft-zhou-emu-fast-gtc-05.txt
>
> The IESG has = received=20 a very late comment about these documents, and
> we seek = your input=20 on the proposed resolution.
>
> The late comment = raises a=20 potential interoperability concern with
> existing = implementations=20 of EAP-MSCHAPv2 and EAP-GTC.
>
> The=20 draft-cam-winget-eap-fast-provisioning-10.txt document = specifies
> a=20 very specific way to generate the challenges used in = EAP-MSCHAPv2
>=20 that provides binding between the EAP-FAST tunnel and the=20 EAP-MSCHAPv2
> exchanges.
>
> The=20 draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which = is
>=20 uses EAP Type 6, originally allocated to EAP-GTC [RFC3748].=20 EAP-FAST-
> GTC
> employs a subset of the EAP-GTC=20 formatting.
>
> The IESG recognizes the difficulties = caused by=20 re-use of an EAP Type.
> Further, the IESG recognizes the = concern=20 about implementations that
> might not easily adapt to = additional=20 requirements.  However, the IESG
> also recognizes the=20 significant value in documenting EAP methods that
> are = implemented=20 and deployed in the Internet today.
>
> The IESG = believes that=20 the right thing to do in this situation is to
> proceed with = the=20 publication of these documents.  However, the IESG
>=20 also
> sees value in warning future EAP method designers = about this=20 experience
> so that this pain might be avoided in the=20 future.
>
> The IESG is considering the additional = informative=20 paragraph in the
> IANA
> considerations section of = both=20 documents that says:
>
>     IESG Note: = EAP-FAST has=20 been implemented by many vendors and it is
>     = used in=20 the Internet.  Publication of this is intended to = promote
>=20     interoperability, even though the use of the = EAP-MSCHAPv2=20 and
>     EAP-FAST-GTC EAP methods might be = difficult in=20 some software
>     environments.  If = EAP-FAST were=20 to be designed today, these
>     difficulties = could be=20 avoided by the assignment of new EAP Type
>    =20 codes.
>
> Please provide comments on the proposed way = forward.

I am strongly opposed to the = publication of=20 these documents as RFCs in their
current form.  Not only = is the=20 "fast provisioning" for EAP-FAST what can
only be characterized = as a=20 security disaster, but EAP-FAST-GTC has nothing
whatsoever to = do with=20 the EAP-GTC type.  EAP-GTC was "defined for use = with
various Token=20 Card implementations which require user input" but
EAP-FAST-GTC = is used=20 solely to transfer a username/password combination, = the
password in=20 plaintext.  It's hard to see what this has to do with = actual
token=20 cards & appears to be a lazy misuse of an existing type.=20  Furthermore,
it's even harder to see how rewarding this = kind of=20 nonsense with publication
will serve as a warning of any kind; = I would=20 expect that the action of
publication (with or without IESG = note) would=20 be more likely taken as notice
that one can do whatever one = please=20 without fear.

> On behalf of the IESG,
>   = Russ
>
>=20 _______________________________________________
> Emu = mailing=20 list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

____= ___________________________________________
Emu=20 mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu



_______________________________________________
Emu mailing=20 = list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
------_=_NextPart_001_01C9864A.44AC2433-- From ncamwing@cisco.com Tue Feb 3 14:02:54 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EA873A6C49 for ; Tue, 3 Feb 2009 14:02:54 -0800 (PST) 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, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wjo3ixHHYfsC for ; Tue, 3 Feb 2009 14:02:53 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4493A3A6C53 for ; Tue, 3 Feb 2009 14:02:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,374,1231113600"; d="scan'208";a="137294678" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 03 Feb 2009 22:02:33 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n13M2XnW022746; Tue, 3 Feb 2009 14:02:33 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n13M2ThO000008; Tue, 3 Feb 2009 22:02:33 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Feb 2009 14:02:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Feb 2009 14:02:15 -0800 Message-ID: <08A9A3213527A6428774900A80DBD8D80859CD59@xmb-sjc-222.amer.cisco.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E78B743A@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Potential Issues with EAP-FAST Thread-Index: Acl9rw4K1I+mwYdeTuieBpgv7cEkugIRNbywABW4X7A= References: <497A4B3F.3020600@open1x.org> <808FD6E27AD4884E94820BC333B2DB7727E78B743A@NOK-EUMSG-01.mgdnok.nokia.com> From: "Nancy Cam-Winget (ncamwing)" To: , , X-OriginalArrivalTime: 03 Feb 2009 22:02:29.0941 (UTC) FILETIME=[1B891E50:01C9864B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3298; t=1233698553; x=1234562553; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ncamwing@cisco.com; z=From:=20=22Nancy=20Cam-Winget=20(ncamwing)=22=20 |Subject:=20RE=3A=20[Emu]=20Potential=20Issues=20with=20EAP -FAST |Sender:=20; bh=k3g32AFLFhOu/fihueWZoz85+lgydk3NFX7Bx72QTbU=; b=kFWJFzgkfMsvggczYUFPH8owAKBtB6lKiU/pFerx1FMulwp0a8ck5FPQOF IXwLxdqZLjgBwalk0o2Q7xsF/f2q/fzsenUpwuQBTXzG3/IrNqpe4q+Yg8t5 RXotsVeDzw; Authentication-Results: sj-dkim-2; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2009 22:02:54 -0000 Thank you for the accurate description Pasi! It is also important to note that there are different modes of EAP-FAST provisioning, anonymous was provided to appease to customer requirements for an in-band solution. To minimize the security risks in the anonymous mode, additional measures were included to provide some level of mutual authentication which are described in Section 3.2.3 and its security risks are further described in Section 6.2. It is also noted in Section 3.2.2 that only EAP-MSCHAPv2 is supported in anonymous provisioning mode. But again, it is one mode that need not be used if the deployment requires stronger security. Since there seems to be interest in EAP-FAST, and some confusion in the different modes provided by the method, I could present an EAP-FAST tutorial at the next EMU session. Thanks again,=20 Nancy. -----Original Message----- From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Tuesday, February 03, 2009 3:54 AM To: chris@open1x.org; emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST Chris Hessing wrote: > For anonymous provisioning, it also seems there is a pretty large=20 > security hole. It is smaller than the security issues with LEAP, but=20 > is still rather large. > > With anonymous provisioning the supplicant has to implicitly trust the > authentication server it is talking to. The only piece of information > the supplicant has that it can use to attempt to verify the server is=20 > the A-ID that is provided. But, in a provisioning mode the supplicant > doesn't really have a way to verify that the A-ID is valid. As a=20 > result, the supplicant will continue on with the provisioning and=20 > provide the server with its credentials. The supplicant also verifies the MS-CHAPv2 Success packet, which contains a MAC -- so there is mutual authentication (some kind of), and the provisioning exchange won't finish successfully unless the attacker can spoof this MAC. The attacker doesn't know the password (and an't compute the MAC himself), and deriving the challenges from the TLS key block means the attacker can't just "cut-and-paste" MS-CHAPv2 messages from the real authentication server. It's true that the bad guy gets the MS-CHAPv2 response, and can do an off-line dictionary attack. This is described in Section 6.2, which also suggests some possible countermeasures (not perfect, but something). But if your password is reasonably strong, it seems this can be reasonably OK (unless I'm missing something here)... > In the best case scenario, the supplicant is configured to only allow=20 > the user of MS-CHAPv2 for provisioning, so "all" the bad guy gets is=20 > the resulting MS-CHAPv2 hash which can then be attacked directly and=20 > off-line. In the worst case the supplicant allows GTC to be used for=20 > provisioning and the clear text credentials are handed over to the=20 > attacker. The specification doesn't allow using GTC when doing anonymous provisioning, so the worst case doesn't happen if you follow the spec. Best regards, Pasi _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From glenzorn@comcast.net Tue Feb 3 22:09:53 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF64528C0CE for ; Tue, 3 Feb 2009 22:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjJM-MwrAhZr for ; Tue, 3 Feb 2009 22:09:50 -0800 (PST) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id AA5C63A6774 for ; Tue, 3 Feb 2009 22:09:50 -0800 (PST) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id BfS91b00B0S2fkCA8i9YSU; Wed, 04 Feb 2009 06:09:32 +0000 Received: from gwzPC ([124.120.227.232]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id Bi921b00251UzLU8Vi97kM; Wed, 04 Feb 2009 06:09:29 +0000 From: "Glen Zorn" To: "Nancy Winget" References: <1668467045.107361.1233682336329.JavaMail.mail@webmail01> <9958B444368E884DBB215F3FEF36F5B708E37AD3@xmb-rtp-212.amer.cisco.com> In-Reply-To: <9958B444368E884DBB215F3FEF36F5B708E37AD3@xmb-rtp-212.amer.cisco.com> Date: Wed, 4 Feb 2009 13:08:49 +0700 Message-ID: <001d01c9868f$1bd4b560$537e2020$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C986C9.C8338D60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmGJWminpIXM8RGTDeNjvItBjlcQwAIRdngABFVWvA= Content-Language: en-us Cc: emu@ietf.org, housley@vigilsec.com, iesg@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 06:09:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001E_01C986C9.C8338D60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Nancy Winget (ncamwing@cisco.com) writes: Dave and Dorothy: We don't believe there are interoperability issues, as the intended informational RFCs clearly describe the protocol and packet format over the wire for these inner methods specifically when running inside EAP-FAST. The so called "interoperability issue" raised is at most an implementation issue, only applies to certain software environments where the same inner methods are used both inside and outside EAP-FAST, and could be worked around. This is demonstrated by the numerous existing client and server implementations already deployed in the field (most of which support these inner methods both inside and outside EAP-FAST), and lack of reporting of this issue. The intent of these drafts is informational and to clearly document the existing implementations started 5 years ago. Assigning new EAP types isn't going to solve any interoperability problems, but is likely to generate new ones. It appears that you mistake the purpose of the IETF as being to enhance proprietary protocols. I, for one, couldn't care less if two implementations of some Cisco Systems proprietary nonsense interoperate or not; however, I do care about hijacking EAP type codes & subversion of the IETF process for essentially marketing purposes. It's hard to imagine what interoperability problems could be caused for a pair of EAP-GTC implementations by changing the type code and name of EAP-FAST-GTC to something more appropriate (say, 666 & EAP-PAP ;-). If we were to redesign today, certainly we would probably take a different approach to make the software implementation easier. We are open to all of your suggestions for enhancements on the next version of EAP-FAST. Given that you've had 5 years to get it right & failed, it's hard to believe that "suggestions for enhancements" would have much effect. We believe these drafts have documented these potential points of confusion. The difference between EAP-MSCHAPVv2 inside and outside EAP-FAST is documented in draft-cam-winget-eap-fast-provisioning. As for EAP-FAST-GTC, the draft-zhou-emu-fast-gtc documents the difference it has with EAP-GTC in turns of handling password authentication. As for regular OTP or token authentication, the implementation could strip the labels and pass the rest to the regular EAP-GTC state machine. Sorry, I'm just ignorant: can you tell me where "the regular EAP-GTC state machine" is defined? How GTC handles the token exchanges is outside the scope of this draft (under defined in RFC3748). If you do see areas of requiring more description of the differences, we are certainly open to suggestions. _____ From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of David Mitton Sent: Tuesday, February 03, 2009 12:32 PM To: dstanley1389@gmail.com Cc: housley@vigilsec.com; iesg@ietf.org; emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents I'm sorry, I haven't responded earlier either, but I would like to pile on with some of my comments. When I read the Cisco EAP-FAST GTC description and was similarly shocked by the nature of the changes, and how poorly they technically met their own rationale. Encoding the "REQ=" and "RESP=" into Request and Response text, is absolutely useless, since the data flow is unidirectional and known to the requester/responder peers. And then claiming that is more efficent because the username and OTP are combined in one response, really ignores the issue that GTC doesn't define what the appropriate response is. And they did nothing to clue the client as to what is being requested, or the format of the response. Given that, a Client can only strip the useless cybercrud, and continue with the normal GTC state machine which is let the user type something in and send it. A more robust OTP implementation may have several different inputs that it wants from the user besides for username and OTP. (BTW; username could be derived from the EAP Identity) There are possible next token challenges, new PIN assignment (user or system generated) and followup re-authentications. Their protocol did nothing to codify a standard for interoperation where a sequence of requests were enumerated or named, and response items were described. I'm all for documenting practice, but this design/implementation doesn't really seem to solve anything and just creates more confusion. Dave Mitton Feb 3, 2009 11:13:36 AM, dstanley1389@gmail.com wrote: The interoperability concern with existing EAP-MSCHAPv2 and EAP-GTC implementations and incorrect re-use of EAP Types must be addressed/corrected prior to publication. One solution is to (a) Get a new, correct type number for use by the method in the published document, and change the name of the method (could use "name-CR" for "corrected/revision", or similar). This eliminates the interoperability concern with existing methods, and uniquely identifies the IETF published method. and (b) Add descriptive text in the document to explain the difference between this IETF published method and similar deployed methods - to meet the desire to document deployed methods. Dorothy Stanley On Mon, Feb 2, 2009 at 6:56 PM, Glen Zorn wrote: > Dear EMU WG: > > These two documents are in the RFC Editor queue: > > draft-cam-winget-eap-fast-provisioning-10.txt > draft-zhou-emu-fast-gtc-05.txt > > The IESG has received a very late comment about these documents, and > we seek your input on the proposed resolution. > > The late comment raises a potential interoperability concern with > existing implementations of EAP-MSCHAPv2 and EAP-GTC. > > The draft-cam-winget-eap-fast-provisioning-10.txt document specifies > a very specific way to generate the challenges used in EAP-MSCHAPv2 > that provides binding between the EAP-FAST tunnel and the EAP-MSCHAPv2 > exchanges. > > The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which is > uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. EAP-FAST- > GTC > employs a subset of the EAP-GTC formatting. > > The IESG recognizes the difficulties caused by re-use of an EAP Type. > Further, the IESG recognizes the concern about implementations that > might not easily adapt to additional requirements. However, the IESG > also recognizes the significant value in documenting EAP methods that > are implemented and deployed in the Internet today. > > The IESG believes that the right thing to do in this situation is to > proceed with the publication of these documents. However, the IESG > also > sees value in warning future EAP method designers about this experience > so that this pain might be avoided in the future. > > The IESG is considering the additional informative paragraph in the > IANA > considerations section of both documents that says: > > IESG Note: EAP-FAST has been implemented by many vendors and it is > used in the Internet. Publication of this is intended to promote > interoperability, even though the use of the EAP-MSCHAPv2 and > EAP-FAST-GTC EAP methods might be difficult in some software > environments. If EAP-FAST were to be designed today, these > difficulties could be avoided by the assignment of new EAP Type > codes. > > Please provide comments on the proposed way forward. I am strongly opposed to the publication of these documents as RFCs in their current form. Not only is the "fast provisioning" for EAP-FAST what can only be characterized as a security disaster, but EAP-FAST-GTC has nothing whatsoever to do with the EAP-GTC type. EAP-GTC was "defined for use with various Token Card implementations which require user input" but EAP-FAST-GTC is used solely to transfer a username/password combination, the password in plaintext. It's hard to see what this has to do with actual token cards & appears to be a lazy misuse of an existing type. Furthermore, it's even harder to see how rewarding this kind of nonsense with publication will serve as a warning of any kind; I would expect that the action of publication (with or without IESG note) would be more likely taken as notice that one can do whatever one please without fear. > On behalf of the IESG, > Russ > > _______________________________________________ > 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 _____ _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ------=_NextPart_000_001E_01C986C9.C8338D60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nancy Winget (ncamwing@cisco.com) writes:

Dave and Dorothy:

We = don't believe there are interoperability issues, as the intended informational = RFCs clearly describe the protocol and packet format over the wire for these = inner methods specifically when running inside EAP-FAST. The so called "interoperability issue" raised is at most an = implementation issue, only applies to certain software environments where the same = inner methods are used both inside and outside EAP-FAST, and could be worked = around. This is demonstrated by the numerous existing client and server = implementations already deployed in the field (most of which support these inner methods = both inside and outside EAP-FAST), and lack of reporting of this issue. The = intent of these drafts is informational and to clearly document the existing implementations started 5 years ago. Assigning new EAP types isn't going = to solve any interoperability problems, but is likely to generate new = ones.

It appears that you mistake the purpose of the IETF as = being to enhance proprietary protocols.  I, for one, couldn't care less if = two implementations of some Cisco Systems proprietary nonsense interoperate = or not; however, I do care about hijacking EAP type codes & = subversion of the IETF process for essentially marketing purposes.  It's hard to = imagine what interoperability problems could be caused for a pair of EAP-GTC = implementations by changing the type code and name of EAP-FAST-GTC to something more appropriate (say, 666 & EAP-PAP ;-).

 If we were to redesign today, certainly we would probably take a different = approach to make the software implementation easier. We are open to all of your suggestions for enhancements on the next version of EAP-FAST.

Given that you've had 5 years to get it right & = failed, it's hard to believe that "suggestions for enhancements" would have = much effect.

We = believe these drafts have documented these potential points of confusion. = The difference between EAP-MSCHAPVv2 inside and outside EAP-FAST is = documented in draft-cam-winget-eap-fast-provisioning. As for EAP-FAST-GTC, the draft-zhou-emu-fast-gtc documents the difference it has with EAP-GTC in = turns of handling password authentication. As for regular OTP or token authentication, the implementation could strip the labels and pass the = rest to the regular EAP-GTC state machine.

Sorry, I'm just ignorant: can you tell me where "the regular EAP-GTC state machine" is defined?

How = GTC handles the token exchanges is outside the scope of this draft (under = defined in RFC3748). If you do see areas of requiring more description of the = differences, we are certainly open to suggestions.

 

From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of David Mitton
Sent: Tuesday, February 03, 2009 12:32 PM
To: dstanley1389@gmail.com
Cc: housley@vigilsec.com; iesg@ietf.org; emu@ietf.org
Subject: Re: [Emu] Potential Notes in EAP-FAST = Documents

I'm sorry,  I haven't responded earlier either, but I would like = to pile on with some of my comments.

When I read the Cisco EAP-FAST GTC description and was similarly = shocked by the nature of the changes, and how poorly they technically met their own rationale.

Encoding the "REQ=3D" and "RESP=3D" into = Request and Response text, is absolutely useless, since the data flow is unidirectional and known to the requester/responder = peers.

And then claiming that is more efficent because the username and OTP = are combined in one response, really ignores the issue that GTC doesn't = define what the appropriate response is.  And they did nothing to clue the = client as to what is being requested, or the format of the = response.

Given that, a Client can only strip the useless cybercrud, and = continue with the normal GTC state machine which is let the user type something in and = send it.

A more robust OTP implementation may have several different inputs = that it wants from the user besides for username and OTP.  (BTW; username = could be derived from the EAP Identity)   There are possible next token challenges,  new PIN assignment (user or system generated)  = and followup re-authentications.   Their protocol did nothing to = codify a standard for interoperation where a sequence of requests were = enumerated or named, and response items were described. 

I'm all for documenting practice, but this design/implementation = doesn't really seem to solve anything and just creates more = confusion.

Dave Mitton


Feb 3, 2009 11:13:36 AM, dstanley1389@gmail.com wrote:

The interoperability = concern with existing EAP-MSCHAPv2 and EAP-GTC
implementations and incorrect re-use of EAP Types must be = addressed/corrected prior to publication.

One solution is to

(a) Get a new, correct type number for use by the method in the = published document, and change the name of the method
(could use "name-CR" for "corrected/revision", or = similar). This eliminates the interoperability concern with existing methods,
and uniquely identifies the IETF published method.

and

(b) Add descriptive text in the document to explain the difference = between this IETF published method and similar  deployed
methods - to meet the desire to document deployed methods.

Dorothy Stanley

On Mon, Feb 2, 2009 at 6:56 PM, Glen Zorn <glenzorn@comcast.net> wrote:


> Dear EMU WG:
>
> These two documents are in the RFC Editor queue:
>
>    draft-cam-winget-eap-fast-provisioning-10.txt
>    draft-zhou-emu-fast-gtc-05.txt
>
> The IESG has received a very late comment about these documents, = and
> we seek your input on the proposed resolution.
>
> The late comment raises a potential interoperability concern = with
> existing implementations of EAP-MSCHAPv2 and EAP-GTC.
>
> The draft-cam-winget-eap-fast-provisioning-10.txt document = specifies
> a very specific way to generate the challenges used in = EAP-MSCHAPv2
> that provides binding between the EAP-FAST tunnel and the = EAP-MSCHAPv2
> exchanges.
>
> The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which = is
> uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. = EAP-FAST-
> GTC
> employs a subset of the EAP-GTC formatting.
>
> The IESG recognizes the difficulties caused by re-use of an EAP = Type.
> Further, the IESG recognizes the concern about implementations = that
> might not easily adapt to additional requirements.  However, = the IESG
> also recognizes the significant value in documenting EAP methods = that
> are implemented and deployed in the Internet today.
>
> The IESG believes that the right thing to do in this situation is = to
> proceed with the publication of these documents.  However, the = IESG
> also
> sees value in warning future EAP method designers about this = experience
> so that this pain might be avoided in the future.
>
> The IESG is considering the additional informative paragraph in = the
> IANA
> considerations section of both documents that says:
>
>     IESG Note: EAP-FAST has been implemented by many = vendors and it is
>     used in the Internet.  Publication of this is = intended to promote
>     interoperability, even though the use of the = EAP-MSCHAPv2 and
>     EAP-FAST-GTC EAP methods might be difficult in some = software
>     environments.  If EAP-FAST were to be designed = today, these
>     difficulties could be avoided by the assignment of = new EAP Type
>     codes.
>
> Please provide comments on the proposed way forward.

I am strongly opposed to the publication of these = documents as RFCs in their
current form.  Not only is the "fast provisioning" for = EAP-FAST what can
only be characterized as a security disaster, but EAP-FAST-GTC has = nothing
whatsoever to do with the EAP-GTC type.  EAP-GTC was "defined = for use with
various Token Card implementations which require user input" = but
EAP-FAST-GTC is used solely to transfer a username/password combination, = the
password in plaintext.  It's hard to see what this has to do with = actual
token cards & appears to be a lazy misuse of an existing type.  Furthermore,
it's even harder to see how rewarding this kind of nonsense with = publication
will serve as a warning of any kind; I would expect that the action = of
publication (with or without IESG note) would be more likely taken as = notice
that one can do whatever one please without fear.


> On behalf of the IESG,
>   Russ
>
> _______________________________________________
> 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

 


_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

------=_NextPart_000_001E_01C986C9.C8338D60-- From bernard_aboba@hotmail.com Wed Feb 4 11:25:50 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FC9E28C1E1 for ; Wed, 4 Feb 2009 11:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qswEi2ou3Ewb for ; Wed, 4 Feb 2009 11:25:48 -0800 (PST) Received: from blu0-omc3-s22.blu0.hotmail.com (blu0-omc3-s22.blu0.hotmail.com [65.55.116.97]) by core3.amsl.com (Postfix) with ESMTP id 3E15F28C18F for ; Wed, 4 Feb 2009 11:25:48 -0800 (PST) Received: from BLU137-W53 ([65.55.116.72]) by blu0-omc3-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Feb 2009 11:25:28 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_1dfb457c-f640-4ff5-8939-fdd755662bc8_" X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: Date: Wed, 4 Feb 2009 11:25:28 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 04 Feb 2009 19:25:28.0876 (UTC) FILETIME=[568E6EC0:01C986FE] Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 19:25:50 -0000 --_1dfb457c-f640-4ff5-8939-fdd755662bc8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable " IESG Note: EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this is intended to promote interoperability=2C even though the use of the EAP-MSCHAPv2 and EAP-FAST-GTC EAP methods might be difficult in some software environments. If EAP-FAST were to be designed today=2C these difficulties could be avoided by the assignment of new EAP Type codes." Although I concur with the assessments of Glen Zorn=2C Dan Harkins=2C David Mitton and Dorothy Stanley in many respects=2C I would suggest that those concerns are outweighed by the IETF's mission to make information on deployed protocols available to the community. As a result=2C I=20 believe that the documents should be published=2C provided that the following concerns can be addressed: a. Name confusion. The use of the term "EAP-FAST-GTC" instead of EAP-GTC helps clarify that the two protocols are significantly different. Similarly=2C the use of the term "EAP-FAST-MS-CHAPv2" would help clarify differences between the implementations of EAP MS-CHAPv2=2C which I believe go beyond just the use of the challenge field (e.g. internationalization support).=20 b. EAP architecture changes. Suggesting that EAP methods behave differently when run within a TLS tunnel negotiating a particular ciphersuite represents a major change to the EAP architecture as well as to tunneling methods other than EAP-FAST. This=20 suggestion=2C if made at all=2C needs to be restricted solely to use within EAP-FAST.=20 c. EAP negotiation issues. Neither the IESG note nor the text explicitly states what is wrong with using an EAP Type=20 Code for incompatible versions of an EAP method that does not support version negotiation. Indeed=2C it would appear that some members of the IESG think that method overloading is required by EAP tunneling methods desiring to incorporate support for cryptographic binding. Saying that this "might be difficult in some software environments" isn't a good characterization.=20 Would the IESG use the same words to describe the reuse of IP protocol numbers within an IP tunnel? I doubt it.=20 Glen Zorn said: I am strongly opposed to the publication of these documents as RFCs in thei= r current form. Not only is the "fast provisioning" for EAP-FAST what can only be characterized as a security disaster=2C but EAP-FAST-GTC has nothin= g whatsoever to do with the EAP-GTC type. EAP-GTC was "defined for use with various Token Card implementations which require user input" but EAP-FAST-GTC is used solely to transfer a username/password combination=2C = the password in plaintext. It's hard to see what this has to do with actual token cards & appears to be a lazy misuse of an existing type. Furthermore= =2C it's even harder to see how rewarding this kind of nonsense with publicatio= n will serve as a warning of any kind=3B I would expect that the action of publication (with or without IESG note) would be more likely taken as notic= e that one can do whatever one please without fear David Mitton said: I'm sorry=2C I haven't responded earlier either=2C but I would like to pil= e on with some of my comments. When I read the Cisco EAP-FAST GTC description and was similarly shocked by the nature of the changes=2C and how poorly they technically met their own rationale. Encoding the "REQ=3D" and "RESP=3D" into Request and Response text=2C is absolutely useless=2C since the data flow is unidirectional and known to the requester/responder peers. And then claiming that is more efficent because the username and OTP are combined in one response=2C really ignores the issue that GTC doesn't define what the appropriate response is. And they did nothing to clue the client as to what is being requested=2C or the format of the response. Given that=2C a Client can only strip the useless cybercrud=2C and continue with the normal GTC state machine which is let the user type something in and send it. A more robust OTP implementation may have several different inputs that it wants from the user besides for username and OTP. (BTW=3B username could be derived from the EAP Identity) There are possible next token challenges=2C new PIN assignment (user or system generated)=20 and followup re-authentications. Their protocol did nothing to codify a standard for interoperation where a sequence of requests were enumerated or named=2C and response items were described. =20 I'm all for documenting practice=2C but this design/implementation doesn't really seem to solve anything and just creates more confusion. Dave Mitton Dan Harkins said: I strongly recommend against publication of these two documents. They represent essentially proprietary hacks on established protocols. The benefit in documenting use of EAP in the Internet today is far outweighed by the damage done to existing protocol specification and implementations. They will serve only to create spagetti code and unnecessary complexity. In addition to the issues noted by others I will also point out that information is being extracted from TLS for use in (the exchange erroneously described as) "EAP-MSCHAPv2" in a way that is different than the way being proposed by the TLS WG and does not include a binding to the application. I don't believe a stable reference of these proprietary hacks is necessary because the lack of an RFC to reference them has not stopped them from being implemented. Whatever process has been used in the past to convey their specification can be used going forward. draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226 but nowhere in that RFC can I find description of the following label for an initial assignment of repository values: "allocated for management by Cisco" yet the draft instructs IANA to set aside values 11-63 for just that purpose. I think that's very inappropriate. Not only is it telling IANA to cede some of its authority to a large multinational corporation but it is decidedly *NOT* documenting existing use! If this whole exercise is to document existing use then where are the specifications for these PAC attribute types? The recommended note does nothing to stop this kind of abuse in the future because the pain you mention is not felt by the one doing the abuse. To condone one transgression is to invite one thousand more. regards=2C Dan. --_1dfb457c-f640-4ff5-8939-fdd755662bc8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable "
    IESG Note: EAP-FAST has been implemented by many vendors and =
it is
    used in the Internet.  Publication of this is intended to prom=
ote
    interoperability=2C even though the use of the EAP-MSCHAPv2 and<=
br>    EAP-FAST-GTC EAP methods might be difficult in some software
    =
environments.  If EAP-FAST were to be designed today=2C these
    diffic=
ulties could be avoided by the assignment of new EAP Type
    codes."
Although I concur with the assessments of Glen Zorn=2C Dan Harkins=2C<=
br>David Mitton and Dorothy Stanley in many respects=2C I would suggest tha=
t
those concerns are outweighed by the IETF's mission to make informatio=
n
on deployed protocols available to the community.  As a result=2C I believe that the documents should be published=2C provided that the
fo=
llowing concerns can be addressed:

a. Name confusion.  The use of th=
e term "EAP-FAST-GTC" instead of
EAP-GTC helps clarify that the two prot=
ocols are significantly
different.  Similarly=2C the use of the term "EA=
P-FAST-MS-CHAPv2"
would help clarify differences between the implementat=
ions of
EAP MS-CHAPv2=2C which I believe go beyond just the use of thechallenge field (e.g. internationalization support). 

b. EAP archi=
tecture changes.  Suggesting that EAP methods behave
differently when ru=
n within a TLS tunnel negotiating a particular
ciphersuite represents a =
major change to the EAP architecture
as well as to tunneling methods oth=
er than EAP-FAST.  This 
suggestion=2C if made at all=2C needs to be res=
tricted solely to
use within EAP-FAST. 

c. EAP negotiation issues=
.  Neither the IESG note nor the
text explicitly states what is wrong wi=
th using an EAP Type 
Code for incompatible versions of an EAP method th=
at does not
support version negotiation.  Indeed=2C it would appear that=
 some
members of the IESG think that method overloading is required
b=
y EAP tunneling methods desiring to incorporate support for
cryptographi=
c binding.  Saying that this "might be difficult
in some software enviro=
nments" isn't a good characterization. 
Would the IESG use the same word=
s to describe the reuse of
IP protocol numbers within an IP tunnel?  I d=
oubt it.

Glen Zorn said:
I am strongly opposed to the=
 publication of these documents as RFCs in their
current form.  Not only=
 is the "fast provisioning" for EAP-FAST what can
only be characterized =
as a security disaster=2C but EAP-FAST-GTC has nothing
whatsoever to do =
with the EAP-GTC type.  EAP-GTC was "defined for use with
various Token =
Card implementations which require user input" but
EAP-FAST-GTC is used =
solely to transfer a username/password combination=2C the
password in pl=
aintext.  It's hard to see what this has to do with actual
token cards &=
amp=3B appears to be a lazy misuse of an existing type.  Furthermore=2C
=
it's even harder to see how rewarding this kind of nonsense with publicatio=
n
will serve as a warning of any kind=3B I would expect that the action =
of
publication (with or without IESG note) would be more likely taken as=
 notice
that one can do whatever one please without fear

Da= vid Mitton said:

I'm sorry=2C =3B I haven't responded earlier ei= ther=2C but I would like to pile on with some of my comments.
When I read the Cisco EAP-FAST GTC description and was similarly shocked by the nature of the changes=2C and how poorly they technically met their own rationale.
Encoding the "REQ=3D" and "RESP=3D" =3Binto Request and Response text= =2C is absolutely useless=2C since the data flow is unidirectional =3Band know= n to the requester/responder peers.
And then claiming that is more efficent because the username and OTP are combined in one response=2C really ignores the issue that GTC doesn't define what the appropriate response is. =3B And they did nothing to cl= ue the client as to what is being =3Brequested=2C or the format of the res= ponse.
Given that=2C a Client can only strip the useless cybercrud=2C and continue with the normal GTC state machine which is let the user type something in and send it.
A more robust OTP implementation may have several different inputs that it wants from the user besides for username and OTP. =3B (BTW=3B username could be derived from the EAP Identity) =3B =3B There are = possible next token challenges=2C =3B new PIN assignment (user or system generat= ed) =3B and followup re-authentications. =3B =3B Their protocol did nothing= to codify a standard for interoperation where a sequence of =3Brequests were enumerated or named=2C and response items were described. =3B
I'm all for documenting practice=2C but this design/implementation doesn't really seem to solve anything and just creates more confusion.
Dave Mitton

Dan Harkins said:

  I strongly recommend aga=
inst publication of these two documents.
They represent essentially prop=
rietary hacks on established protocols.
The benefit in documenting use o=
f EAP in the Internet today is far
outweighed by the damage done to exis=
ting protocol specification and
implementations. They will serve only to=
 create spagetti code and
unnecessary complexity.

  In addition t=
o the issues noted by others I will also point out that
information is b=
eing extracted from TLS for use in (the exchange
erroneously described a=
s) "EAP-MSCHAPv2" in a way that is different than
the way being proposed=
 by the TLS WG and does not include a binding to
the application.
  I don't believe a stable reference of these proprietary hacks is
nece=
ssary because the lack of an RFC to reference them has not stopped
them =
from being implemented. Whatever process has been used in the
past to co=
nvey their specification can be used going forward.

  draft-cam-wing=
et-eap-fast-provisioning claims a reference to RFC 5226
but nowhere in t=
hat RFC can I find description of the following label
for an initial ass=
ignment of repository values:

  "allocated for management by Cisco"<=
br>
yet the draft instructs IANA to set aside values 11-63 for just that=

purpose. I think that's very inappropriate. Not only is it telling IANA=

to cede some of its authority to a large multinational corporation but<=
br>it is decidedly *NOT* documenting existing use! If this whole exerciseis to document existing use then where are the specifications for thesePAC attribute types?

  The recommended note does nothing to stop t=
his kind of abuse in the
future because the pain you mention is not felt=
 by the one doing
the abuse.

  To condone one transgression is to=
 invite one thousand more.

  regards=2C



  Dan.



=

--_1dfb457c-f640-4ff5-8939-fdd755662bc8_--

From glenzorn@comcast.net  Wed Feb  4 17:33:47 2009
Return-Path: 
X-Original-To: emu@core3.amsl.com
Delivered-To: emu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9AD228C1B7 for ; Wed,  4 Feb 2009 17:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.303
X-Spam-Level: 
X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.295,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suCFDleF5u1b for ; Wed,  4 Feb 2009 17:33:46 -0800 (PST)
Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id E6C4C28C0FD for ; Wed,  4 Feb 2009 17:33:45 -0800 (PST)
Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id C1Nt1b00717UAYkA91ZTg8; Thu, 05 Feb 2009 01:33:27 +0000
Received: from gwzPC ([124.120.227.232]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id C1Yx1b00551UzLU8Z1Z2ub; Thu, 05 Feb 2009 01:33:24 +0000
From: "Glen Zorn" 
To: "'Bernard Aboba'" 
References: 
In-Reply-To: 
Date: Thu, 5 Feb 2009 08:32:38 +0700
Message-ID: <00f201c98731$b1948e20$14bdaa60$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F3_01C9876C.5DF36620"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmG/lo0u/wwsDeKRbuC1l+QeodYZgAMeUZA
Content-Language: en-us
Cc: Dan Harkins , emu@ietf.org, 'Glen Zorn' , iesg@ietf.org
Subject: Re: [Emu] Potential Notes in EAP-FAST Documents
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Feb 2009 01:33:47 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00F3_01C9876C.5DF36620
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes:

 

    IESG Note: EAP-FAST has been implemented by many vendors and it is


    used in the Internet.  Publication of this is intended to promote


    interoperability, even though the use of the EAP-MSCHAPv2 and


    EAP-FAST-GTC EAP methods might be difficult in some software


    environments.  If EAP-FAST were to be designed today, these


    difficulties could be avoided by the assignment of new EAP Type


    codes."





Although I concur with the assessments of Glen Zorn, Dan Harkins,


David Mitton and Dorothy Stanley in many respects, I would suggest that


those concerns are outweighed by the IETF's mission to make information


on deployed protocols available to the community.  As a result, I 


believe that the documents should be published, provided that the


following concerns can be addressed:





a. Name confusion.  The use of the term "EAP-FAST-GTC" instead of


EAP-GTC helps clarify that the two protocols are significantly


different.  Similarly, the use of the term "EAP-FAST-MS-CHAPv2"


would help clarify differences between the implementations of


EAP MS-CHAPv2, which I believe go beyond just the use of the


challenge field (e.g. internationalization support). 
 
I agree that a name change would be beneficial, but I'm much more concerned
about the pirating of EAP Type numbers: if we allow the same EAP Type codes
to be used for what are essentially different protocols, any pretense that
the IETF might have of promoting interoperability simply vanishes.






b. EAP architecture changes.  Suggesting that EAP methods behave


differently when run within a TLS tunnel negotiating a particular


ciphersuite represents a major change to the EAP architecture


as well as to tunneling methods other than EAP-FAST.  This 


suggestion, if made at all, needs to be restricted solely to


use within EAP-FAST. 





c. EAP negotiation issues.  Neither the IESG note nor the


text explicitly states what is wrong with using an EAP Type 


Code for incompatible versions of an EAP method that does not


support version negotiation.  Indeed, it would appear that some


members of the IESG think that method overloading is required


by EAP tunneling methods desiring to incorporate support for


cryptographic binding.  Saying that this "might be difficult


in some software environments" isn't a good characterization. 


Would the IESG use the same words to describe the reuse of


IP protocol numbers within an IP tunnel?  I doubt it. 
 
Well put, and two more good reasons to require the use of new & unique EAP
Types.


Glen Zorn said:

I am strongly opposed to the publication of these documents as RFCs in their


current form.  Not only is the "fast provisioning" for EAP-FAST what can


only be characterized as a security disaster, but EAP-FAST-GTC has nothing


whatsoever to do with the EAP-GTC type.  EAP-GTC was "defined for use with


various Token Card implementations which require user input" but


EAP-FAST-GTC is used solely to transfer a username/password combination, the


password in plaintext.  It's hard to see what this has to do with actual


token cards & appears to be a lazy misuse of an existing type.  Furthermore,


it's even harder to see how rewarding this kind of nonsense with publication


will serve as a warning of any kind; I would expect that the action of


publication (with or without IESG note) would be more likely taken as notice


that one can do whatever one please without fear


David Mitton said:

I'm sorry,  I haven't responded earlier either, but I would like to pile on
with some of my comments.
When I read the Cisco EAP-FAST GTC description and was similarly shocked by
the nature of the changes, and how poorly they technically met their own
rationale.
Encoding the "REQ=" and "RESP=" into Request and Response text, is
absolutely useless, since the data flow is unidirectional and known to the
requester/responder peers.
And then claiming that is more efficent because the username and OTP are
combined in one response, really ignores the issue that GTC doesn't define
what the appropriate response is.  And they did nothing to clue the client
as to what is being requested, or the format of the response.
Given that, a Client can only strip the useless cybercrud, and continue with
the normal GTC state machine which is let the user type something in and
send it.
A more robust OTP implementation may have several different inputs that it
wants from the user besides for username and OTP.  (BTW; username could be
derived from the EAP Identity)   There are possible next token challenges,
new PIN assignment (user or system generated)  and followup
re-authentications.   Their protocol did nothing to codify a standard for
interoperation where a sequence of requests were enumerated or named, and
response items were described.  
I'm all for documenting practice, but this design/implementation doesn't
really seem to solve anything and just creates more confusion.
Dave Mitton

Dan Harkins said:

  I strongly recommend against publication of these two documents.


They represent essentially proprietary hacks on established protocols.


The benefit in documenting use of EAP in the Internet today is far


outweighed by the damage done to existing protocol specification and


implementations. They will serve only to create spagetti code and


unnecessary complexity.





  In addition to the issues noted by others I will also point out that


information is being extracted from TLS for use in (the exchange


erroneously described as) "EAP-MSCHAPv2" in a way that is different than


the way being proposed by the TLS WG and does not include a binding to


the application.





  I don't believe a stable reference of these proprietary hacks is


necessary because the lack of an RFC to reference them has not stopped


them from being implemented. Whatever process has been used in the


past to convey their specification can be used going forward.





  draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226


but nowhere in that RFC can I find description of the following label


for an initial assignment of repository values:





  "allocated for management by Cisco"





yet the draft instructs IANA to set aside values 11-63 for just that


purpose. I think that's very inappropriate. Not only is it telling IANA


to cede some of its authority to a large multinational corporation but


it is decidedly *NOT* documenting existing use! If this whole exercise


is to document existing use then where are the specifications for these


PAC attribute types?





  The recommended note does nothing to stop this kind of abuse in the


future because the pain you mention is not felt by the one doing


the abuse.





  To condone one transgression is to invite one thousand more.





  regards,











  Dan.

 

	

 


------=_NextPart_000_00F3_01C9876C.5DF36620
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Bernard Aboba [mailto:bernard_aboba@=
hotmail.com]
writes:



 



    IESG Note: EAP-FAST has been =
implemented by many vendors and it is

    used in the Internet.  Publication of this is =
intended to promote

    interoperability, even though the use of the =
EAP-MSCHAPv2 and

    EAP-FAST-GTC EAP methods might be difficult in some =
software

    environments.  If EAP-FAST were to be designed =
today, these

    difficulties could be avoided by the assignment of =
new EAP Type

    codes."



Although I concur with the assessments of Glen Zorn, Dan Harkins,

David Mitton and Dorothy Stanley in many respects, I would suggest =
that

those concerns are outweighed by the IETF's mission to make =
information

on deployed protocols available to the community.  As a result, I =


believe that the documents should be published, provided that the

following concerns can be addressed:



a. Name confusion.  The use of the term "EAP-FAST-GTC" =
instead of

EAP-GTC helps clarify that the two protocols are significantly

different.  Similarly, the use of the term =
"EAP-FAST-MS-CHAPv2"

would help clarify differences between the implementations of

EAP MS-CHAPv2, which I believe go beyond just the use of the

challenge field (e.g. internationalization support). 
 
I agree that a name change would be =
beneficial, but I'm much more concerned about the pirating of EAP Type =
numbers: if we allow the same EAP Type codes to be used for what are =
essentially different protocols, any pretense that the IETF might have =
of promoting interoperability simply =
vanishes.




b. EAP architecture changes.  Suggesting that EAP methods =
behave

differently when run within a TLS tunnel negotiating a particular

ciphersuite represents a major change to the EAP architecture

as well as to tunneling methods other than EAP-FAST.  This 

suggestion, if made at all, needs to be restricted solely to

use within EAP-FAST. 



c. EAP negotiation issues.  Neither the IESG note nor the

text explicitly states what is wrong with using an EAP Type 

Code for incompatible versions of an EAP method that does not

support version negotiation.  Indeed, it would appear that some

members of the IESG think that method overloading is required

by EAP tunneling methods desiring to incorporate support for

cryptographic binding.  Saying that this "might be =
difficult

in some software environments" isn't a good characterization. 

Would the IESG use the same words to describe the reuse of

IP protocol numbers within an IP tunnel?  I doubt it. =

 
Well put, and two more good reasons =
to require the use of new & unique EAP =
Types.





Glen Zorn said:



I am strongly opposed to the publication of these documents as RFCs =
in their

current form.  Not only is the "fast provisioning" for =
EAP-FAST what can

only be characterized as a security disaster, but EAP-FAST-GTC has =
nothing

whatsoever to do with the EAP-GTC type.  EAP-GTC was "defined =
for use with

various Token Card implementations which require user input" =
but

EAP-FAST-GTC is used solely to transfer a username/password combination, =
the

password in plaintext.  It's hard to see what this has to do with =
actual

token cards & appears to be a lazy misuse of an existing type.  =
Furthermore,

it's even harder to see how rewarding this kind of nonsense with =
publication

will serve as a warning of any kind; I would expect that the action =
of

publication (with or without IESG note) would be more likely taken as =
notice

that one can do whatever one please without fear





David Mitton said:



I'm sorry,  I haven't responded earlier either, but I would like to =
pile
on with some of my comments.

When I read the Cisco EAP-FAST GTC description and was similarly shocked =
by the
nature of the changes, and how poorly they technically met their own =
rationale.

Encoding the "REQ=3D" and "RESP=3D" into =
Request and
Response text, is absolutely useless, since the data flow is
unidirectional and known to the requester/responder peers.

And then claiming that is more efficent because the username and OTP are
combined in one response, really ignores the issue that GTC doesn't =
define what
the appropriate response is.  And they did nothing to clue the =
client as
to what is being requested, or the format of the response.

Given that, a Client can only strip the useless cybercrud, and continue =
with
the normal GTC state machine which is let the user type something in and =
send
it.

A more robust OTP implementation may have several different inputs that =
it
wants from the user besides for username and OTP.  (BTW; username =
could be
derived from the EAP Identity)   There are possible next token
challenges,  new PIN assignment (user or system generated)  =
and
followup re-authentications.   Their protocol did nothing to =
codify a
standard for interoperation where a sequence of requests were =
enumerated
or named, and response items were described.  

I'm all for documenting practice, but this design/implementation doesn't =
really
seem to solve anything and just creates more confusion.

Dave Mitton



Dan Harkins said:



  I strongly recommend against publication of these two =
documents.

They represent essentially proprietary hacks on established =
protocols.

The benefit in documenting use of EAP in the Internet today is far

outweighed by the damage done to existing protocol specification and

implementations. They will serve only to create spagetti code and

unnecessary complexity.



  In addition to the issues noted by others I will also point out =
that

information is being extracted from TLS for use in (the exchange

erroneously described as) "EAP-MSCHAPv2" in a way that is =
different than

the way being proposed by the TLS WG and does not include a binding =
to

the application.



  I don't believe a stable reference of these proprietary hacks =
is

necessary because the lack of an RFC to reference them has not =
stopped

them from being implemented. Whatever process has been used in the

past to convey their specification can be used going forward.



  draft-cam-winget-eap-fast-provisioning claims a reference to RFC =
5226

but nowhere in that RFC can I find description of the following =
label

for an initial assignment of repository values:



  "allocated for management by Cisco"



yet the draft instructs IANA to set aside values 11-63 for just that

purpose. I think that's very inappropriate. Not only is it telling =
IANA

to cede some of its authority to a large multinational corporation =
but

it is decidedly *NOT* documenting existing use! If this whole =
exercise

is to document existing use then where are the specifications for =
these

PAC attribute types?



  The recommended note does nothing to stop this kind of abuse in =
the

future because the pain you mention is not felt by the one doing

the abuse.



  To condone one transgression is to invite one thousand more.



  regards,







  Dan.



 =





 

  
 





 












------=_NextPart_000_00F3_01C9876C.5DF36620--


From bernard_aboba@hotmail.com  Wed Feb  4 18:01:05 2009
Return-Path: 
X-Original-To: emu@core3.amsl.com
Delivered-To: emu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED073A680D for ; Wed,  4 Feb 2009 18:01:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level: 
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_53=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EX1EZ1tIMXU1 for ; Wed,  4 Feb 2009 18:01:05 -0800 (PST)
Received: from blu0-omc3-s3.blu0.hotmail.com (blu0-omc3-s3.blu0.hotmail.com [65.55.116.78]) by core3.amsl.com (Postfix) with ESMTP id D75223A67F2 for ; Wed,  4 Feb 2009 18:01:04 -0800 (PST)
Received: from BLU137-W54 ([65.55.116.72]) by blu0-omc3-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 4 Feb 2009 18:00:45 -0800
Message-ID: 
Content-Type: multipart/alternative; boundary="_c56c2121-beee-42a8-a1c9-d3d6a88afaeb_"
X-Originating-IP: [131.107.0.80]
From: Bernard Aboba 
To: 
Date: Wed, 4 Feb 2009 18:00:45 -0800
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Feb 2009 02:00:45.0171 (UTC) FILETIME=[8E91DC30:01C98735]
Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Feb 2009 02:01:05 -0000

--_c56c2121-beee-42a8-a1c9-d3d6a88afaeb_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Dan Harkins said: > draft-cam-winget-eap-fast-provisioning claims a referen=
ce to RFC 5226> but nowhere in that RFC can I find description of the follo=
wing label> for an initial assignment of repository values:>> "allocated fo=
r management by Cisco">> yet the draft instructs IANA to set aside values 1=
1-63 for just that> purpose. I think that's very inappropriate. Not only is=
 it telling IANA> to cede some of its authority to a large multinational co=
rporation but> it is decidedly *NOT* documenting existing use! If this whol=
e exercise> is to document existing use then where are the specifications f=
or these> PAC attribute types?Are you saying that the registry of "EAP-FAST=
 PAC Attribute Types" also=20
relates to RFC 4507=2C which is a standards track document?
=20
If so=2C then I may see your point.  RFC 5226 does permit vendor-specific=20
registries.  However=2C if the registry relates to a Standards Track protoc=
ol under
IETF change control=2C then restricting vendor-specific extensions to only =
one
vendor would be highly unusual.  =

--_c56c2121-beee-42a8-a1c9-d3d6a88afaeb_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable







Dan =
Harkins said:
 =3B
>=3B draft-cam-winget-eap-fast-provisioning =
claims a reference to RFC 5226
>=3B but nowhere in that RFC can I find=
 description of the following label
>=3B for an initial assignment of =
repository values:
>=3B
>=3B "allocated for management by Cisco"<=
BR>>=3B
>=3B yet the draft instructs IANA to set aside values 11-63 =
for just that
>=3B purpose. I think that's very inappropriate. Not onl=
y is it telling IANA
>=3B to cede some of its authority to a large mul=
tinational corporation but
>=3B it is decidedly *NOT* documenting exis=
ting use! If this whole exercise
>=3B is to document existing use then=
 where are the specifications for these
>=3B PAC attribute types?
<=
BR>Are you saying that the =3Bregis=
try of "EAP-FAST PAC Attribute Types" also 


relates to RFC 4507=2C which is a standards track document?


 =3B


If so=2C then I may see your point. =3B =
RFC 5226 does permit vendor-specific 


registries=
. =3B However=2C if the registry relates to a Standards Track protocol =
under


IETF chang=
e control=2C then restricting vendor-specific extensions to only one=



vendor wou=
ld be highly unusual. =3B 

=

--_c56c2121-beee-42a8-a1c9-d3d6a88afaeb_--

From jsalowey@cisco.com  Wed Feb  4 18:48:15 2009
Return-Path: 
X-Original-To: emu@core3.amsl.com
Delivered-To: emu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915B33A6804 for ; Wed,  4 Feb 2009 18:48:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.597
X-Spam-Level: 
X-Spam-Status: No, score=-6.597 tagged_above=-999 required=5 tests=[AWL=0.002,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WoG5bhMNwlw for ; Wed,  4 Feb 2009 18:48:14 -0800 (PST)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A6D7D3A6A79 for ; Wed,  4 Feb 2009 18:48:14 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.37,382,1231113600"; d="scan'208";a="133120253"
Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 05 Feb 2009 02:47:55 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n152ltKo010792;  Wed, 4 Feb 2009 18:47:55 -0800
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n152lttw005043; Thu, 5 Feb 2009 02:47:55 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);  Wed, 4 Feb 2009 18:47:55 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 4 Feb 2009 18:47:16 -0800
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Emu] IANA allocation issue in EAP-FAST Documents
Thread-Index: AcmHNZNDvKRfJN62SPODw6MA5k2DvAABlTWQ
References: 
From: "Joseph Salowey (jsalowey)" 
To: "Bernard Aboba" , 
X-OriginalArrivalTime: 05 Feb 2009 02:47:55.0248 (UTC) FILETIME=[256D5700:01C9873C]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=596; t=1233802075; x=1234666075; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20IANA=20allocation=20issue=20in= 20EAP-FAST=20Documents |Sender:=20; bh=0/GhhpmTCirKWfGL4MwkPyk3cowliUW8ssGr+stkahs=; b=X7cOmHqF3KwXw+FJQ13m8B5W9XDUXvYCnfgWK0S9zIeZdu5T8GvqfdkmsJ ME32jCpuZUnXBa5MQGnPjZsBgwyQufI8Nk0Fdpy68VixhFIzIwEpmW2J2vhJ IIkbCSqSANUoXFKjW2VO848crCy4DLt1VwHQLQkFiqKh5/VE30+DE=;
Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); 
Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Feb 2009 02:48:15 -0000

=20

>=20
> Are you saying that the registry of "EAP-FAST PAC Attribute=20
> Types" also=20
>=20
> relates to RFC 4507, which is a standards track document?
>=20
[Joe] This is not directly related to 4507.  RFC 4507 treats tickets as
opaque. =20


>=20
> If so, then I may see your point.  RFC 5226 does permit=20
> vendor-specific=20
>=20
> registries.  However, if the registry relates to a Standards=20
> Track protocol under
>=20
> IETF change control, then restricting vendor-specific=20
> extensions to only one
>=20
> vendor would be highly unusual. =20
>=20
>=20

From glenzorn@comcast.net  Wed Feb  4 20:43:36 2009
Return-Path: 
X-Original-To: emu@core3.amsl.com
Delivered-To: emu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A952A3A6873 for ; Wed,  4 Feb 2009 20:43:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.327
X-Spam-Level: 
X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.271,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBqtSt7k2bOz for ; Wed,  4 Feb 2009 20:43:36 -0800 (PST)
Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 43E8D3A6359 for ; Wed,  4 Feb 2009 20:43:36 -0800 (PST)
Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA07.westchester.pa.mail.comcast.net with comcast id BrUg1b00F0SCNGk574iHZn; Thu, 05 Feb 2009 04:42:17 +0000
Received: from gwzPC ([124.120.227.205]) by OMTA09.westchester.pa.mail.comcast.net with comcast id C4hb1b0024SXqDG3V4hktc; Thu, 05 Feb 2009 04:42:12 +0000
From: "Glen Zorn" 
To: "'Bernard Aboba'" 
References: 
In-Reply-To: 
Date: Thu, 5 Feb 2009 11:41:14 +0700
Message-ID: <001b01c9874c$1006b8b0$30142a10$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C98786.BC6590B0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmHNZBBnWUPW7ErQ0OV9RgmTEnRlgADBk9A
Content-Language: en-us
Cc: Dan Harkins , emu@ietf.org, iesg@ietf.org
Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Feb 2009 04:43:36 -0000

This is a multipart message in MIME format.

------=_NextPart_000_001C_01C98786.BC6590B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes:

 

Dan Harkins said:
 
> draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226
> but nowhere in that RFC can I find description of the following label
> for an initial assignment of repository values:
>
> "allocated for management by Cisco"
>
> yet the draft instructs IANA to set aside values 11-63 for just that
> purpose. I think that's very inappropriate. Not only is it telling IANA
> to cede some of its authority to a large multinational corporation but
> it is decidedly *NOT* documenting existing use! If this whole exercise
> is to document existing use then where are the specifications for these
> PAC attribute types?

Are you saying that the registry of "EAP-FAST PAC Attribute Types" also 

relates to RFC 4507, which is a standards track document?

 

AFAICT, the two seem unrelated.

 

If so, then I may see your point.  RFC 5226 does permit vendor-specific 

registries.  

I can't find this in 5226.  Are you perhaps referring to Private Use
registries?  If so, RFC 5226 has this to say about them:

      Private Use - For private or local use only, with the type and

            purpose defined by the local site.  No attempt is made to

            prevent multiple sites from using the same value in

            different (and incompatible) ways.  There is no need for

            IANA to review such assignments (since IANA does not record

            them) and assignments are not generally useful for broad

            interoperability.  It is the responsibility of the sites

            making use of the Private Use range to ensure that no

            conflicts occur (within the intended scope of use).

Essentially, Private Use numbers are neither allocated nor recorded by IANA
& there is certainly no guarantee that any two sites (or vendors) won't use
the same number for different purposes or vice-versa.  Although it's not
completely clear from the document, draft-cam-winget-eap-fast-provisioning
appears to be setting up registries managed by IANA with a policy of
Specification Required for everybody but Cisco; Cisco would simply allocate
numbers out of their reserved range internally and use IANA to promulgate
their decisions to the outer world.  I can't find anything in RFC 5226 that
even remotely suggests that this is permissible behavior.

However, if the registry relates to a Standards Track protocol under

IETF change control, then restricting vendor-specific extensions to only one

vendor would be highly unusual.  


------=_NextPart_000_001C_01C98786.BC6590B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Bernard Aboba [mailto:bernard_aboba@=
hotmail.com]
writes:



 






Dan Harkins said:

 

> draft-cam-winget-eap-fast-provisioning claims a reference to RFC =
5226

> but nowhere in that RFC can I find description of the following =
label

> for an initial assignment of repository values:

>

> "allocated for management by Cisco"

>

> yet the draft instructs IANA to set aside values 11-63 for just =
that

> purpose. I think that's very inappropriate. Not only is it telling =
IANA

> to cede some of its authority to a large multinational corporation =
but

> it is decidedly *NOT* documenting existing use! If this whole =
exercise

> is to document existing use then where are the specifications for =
these

> PAC attribute types?



Are you saying that the registry of "EAP-FAST PAC Attribute
Types" also 



relates to RFC 4507, which is a standards track =
document?=




 



AFAICT, the two seem unrelated.



 



If so, then I may see your point.  RFC
5226 does permit vendor-specific 



registries.  



I can't find this in 5226.  Are you perhaps =
referring to
Private Use registries?  If so, RFC 5226 has this to say about =
them:



      Private Use - =
For
private or local use only, with the type and



           
purpose defined by the local site.  No attempt is made =
to



           
prevent multiple sites from using the same value =
in



           
different (and incompatible) ways.  There is no need =
for



           
IANA to review such assignments (since IANA does not =
record



           
them) and assignments are not generally useful for =
broad



       =
     interoperability. 
It is the responsibility of the sites



           
making use of the Private Use range to ensure that =
no



           
conflicts occur (within the intended scope of =
use).



Essentially, Private Use numbers are neither allocated =
nor
recorded by IANA & there is certainly no guarantee that any two =
sites (or
vendors) won't use the same number for different purposes or =
vice-versa.  Although
it's not completely clear from the document, =
draft-cam-winget-eap-fast-provisioning
appears to be setting up registries managed by IANA with a policy of
Specification Required for everybody but Cisco; Cisco would =
simply
allocate numbers out of their reserved range internally and use IANA to
promulgate their decisions to the outer world.  I can't find =
anything in
RFC 5226 that even remotely suggests that this is permissible =
behavior.



However, if the registry relates to a Standards Track =
protocol
under



IETF change control, then restricting vendor-specific =
extensions
to only one



vendor would be highly unusual.  =













------=_NextPart_000_001C_01C98786.BC6590B0--


From Pasi.Eronen@nokia.com  Wed Feb  4 23:34:20 2009
Return-Path: 
X-Original-To: emu@core3.amsl.com
Delivered-To: emu@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 518E43A686A for ; Wed,  4 Feb 2009 23:34:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.547
X-Spam-Level: 
X-Spam-Status: No, score=-6.547 tagged_above=-999 required=5 tests=[AWL=0.051,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20G4Eec5Ax5L for ; Wed,  4 Feb 2009 23:34:18 -0800 (PST)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C6CEF3A684C for ; Wed,  4 Feb 2009 23:34:17 -0800 (PST)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n157XeDo008296 for ; Thu, 5 Feb 2009 09:33:56 +0200
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 5 Feb 2009 09:33:51 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 5 Feb 2009 09:33:46 +0200
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Thu, 5 Feb 2009 08:33:45 +0100
From: 
To: 
Date: Thu, 5 Feb 2009 08:33:46 +0100
Thread-Topic: [Emu] Potential Notes in EAP-FAST Documents
Thread-Index: AcmG/lqa1KgpUF8USwKhyQk7NRQaiAAZKlqQ
Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_808FD6E27AD4884E94820BC333B2DB7727E78F274CNOKEUMSG01mgd_"
MIME-Version: 1.0
X-OriginalArrivalTime: 05 Feb 2009 07:33:46.0845 (UTC) FILETIME=[149358D0:01C98764]
X-Nokia-AV: Clean
Subject: Re: [Emu] Potential Notes in EAP-FAST Documents
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Feb 2009 07:34:20 -0000

--_000_808FD6E27AD4884E94820BC333B2DB7727E78F274CNOKEUMSG01mgd_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I would like to remind everyone that these documents did go through
IETF Last Call, and have already been approved by IESG.

If folks are opposed to publishing descriptions of deployed EAP method
when they're less than perfect (or even ugly hacks with bad architecture),
and may not offer perfect security in all circumstances (but accurately
document their limitations), they should have said so much earlier.

(In hindsight, publishing these via the RFC Editor independent submission
route, and including the vendor's name in the document title, might
have been better idea. Since the intent was to describe what existing
implementations do, the IETF does not realistically have much change
control...)

Best regards,
Pasi

________________________________
From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of ext B=
ernard Aboba
Sent: 04 February, 2009 21:25
To: emu@ietf.org
Subject: Re: [Emu] Potential Notes in EAP-FAST Documents

"

    IESG Note: EAP-FAST has been implemented by many vendors and it is
    used in the Internet.  Publication of this is intended to promote
    interoperability, even though the use of the EAP-MSCHAPv2 and
    EAP-FAST-GTC EAP methods might be difficult in some software
    environments.  If EAP-FAST were to be designed today, these
    difficulties could be avoided by the assignment of new EAP Type
    codes."

Although I concur with the assessments of Glen Zorn, Dan Harkins,
David Mitton and Dorothy Stanley in many respects, I would suggest that
those concerns are outweighed by the IETF's mission to make information
on deployed protocols available to the community.  As a result, I
believe that the documents should be published, provided that the
following concerns can be addressed:

a. Name confusion.  The use of the term "EAP-FAST-GTC" instead of
EAP-GTC helps clarify that the two protocols are significantly
different.  Similarly, the use of the term "EAP-FAST-MS-CHAPv2"
would help clarify differences between the implementations of
EAP MS-CHAPv2, which I believe go beyond just the use of the
challenge field (e.g. internationalization support).

b. EAP architecture changes.  Suggesting that EAP methods behave
differently when run within a TLS tunnel negotiating a particular
ciphersuite represents a major change to the EAP architecture
as well as to tunneling methods other than EAP-FAST.  This
suggestion, if made at all, needs to be restricted solely to
use within EAP-FAST.

c. EAP negotiation issues.  Neither the IESG note nor the
text explicitly states what is wrong with using an EAP Type
Code for incompatible versions of an EAP method that does not
support version negotiation.  Indeed, it would appear that some
members of the IESG think that method overloading is required
by EAP tunneling methods desiring to incorporate support for
cryptographic binding.  Saying that this "might be difficult
in some software environments" isn't a good characterization.
Would the IESG use the same words to describe the reuse of
IP protocol numbers within an IP tunnel?  I doubt it.

Glen Zorn said:

I am strongly opposed to the publication of these documents as RFCs in thei=
r
current form.  Not only is the "fast provisioning" for EAP-FAST what can
only be characterized as a security disaster, but EAP-FAST-GTC has nothing
whatsoever to do with the EAP-GTC type.  EAP-GTC was "defined for use with
various Token Card implementations which require user input" but
EAP-FAST-GTC is used solely to transfer a username/password combination, th=
e
password in plaintext.  It's hard to see what this has to do with actual
token cards & appears to be a lazy misuse of an existing type.  Furthermore=
,
it's even harder to see how rewarding this kind of nonsense with publicatio=
n
will serve as a warning of any kind; I would expect that the action of
publication (with or without IESG note) would be more likely taken as notic=
e
that one can do whatever one please without fear

David Mitton said:

I'm sorry,  I haven't responded earlier either, but I would like to pile on=
 with some of my comments.
When I read the Cisco EAP-FAST GTC description and was similarly shocked by=
 the nature of the changes, and how poorly they technically met their own r=
ationale.
Encoding the "REQ=3D" and "RESP=3D" into Request and Response text, is abso=
lutely useless, since the data flow is unidirectional and known to the requ=
ester/responder peers.
And then claiming that is more efficent because the username and OTP are co=
mbined in one response, really ignores the issue that GTC doesn't define wh=
at the appropriate response is.  And they did nothing to clue the client as=
 to what is being requested, or the format of the response.
Given that, a Client can only strip the useless cybercrud, and continue wit=
h the normal GTC state machine which is let the user type something in and =
send it.
A more robust OTP implementation may have several different inputs that it =
wants from the user besides for username and OTP.  (BTW; username could be =
derived from the EAP Identity)   There are possible next token challenges, =
 new PIN assignment (user or system generated)  and followup re-authenticat=
ions.   Their protocol did nothing to codify a standard for interoperation =
where a sequence of requests were enumerated or named, and response items w=
ere described.
I'm all for documenting practice, but this design/implementation doesn't re=
ally seem to solve anything and just creates more confusion.
Dave Mitton

Dan Harkins said:


  I strongly recommend against publication of these two documents.
They represent essentially proprietary hacks on established protocols.
The benefit in documenting use of EAP in the Internet today is far
outweighed by the damage done to existing protocol specification and
implementations. They will serve only to create spagetti code and
unnecessary complexity.

  In addition to the issues noted by others I will also point out that
information is being extracted from TLS for use in (the exchange
erroneously described as) "EAP-MSCHAPv2" in a way that is different than
the way being proposed by the TLS WG and does not include a binding to
the application.

  I don't believe a stable reference of these proprietary hacks is
necessary because the lack of an RFC to reference them has not stopped
them from being implemented. Whatever process has been used in the
past to convey their specification can be used going forward.

  draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226
but nowhere in that RFC can I find description of the following label
for an initial assignment of repository values:

  "allocated for management by Cisco"

yet the draft instructs IANA to set aside values 11-63 for just that
purpose. I think that's very inappropriate. Not only is it telling IANA
to cede some of its authority to a large multinational corporation but
it is decidedly *NOT* documenting existing use! If this whole exercise
is to document existing use then where are the specifications for these
PAC attribute types?

  The recommended note does nothing to stop this kind of abuse in the
future because the pain you mention is not felt by the one doing
the abuse.

  To condone one transgression is to invite one thousand more.

  regards,



  Dan.




--_000_808FD6E27AD4884E94820BC333B2DB7727E78F274CNOKEUMSG01mgd_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable









I would like=
 to remind=20
everyone that these documents did go through
IETF Last Call, and have al=
ready=20
been approved by IESG.


 


If fol=
ks are=20
opposed to publishing descriptions of deployed EAP method
when they're l=
ess=20
than perfect (or even ugly hacks with bad=
=20
architecture), 


and ma=
y not=20
offer perfect security in all=20
circumstances (but accurately=20



document their limitations), they should have said=20
so much earlier.


 =
;


(In hindsight, publishing these via the RFC Edit=
or=20
independent submission


route, and including the vendor's name in t=
he=20
document title, might


have been better idea. Since the intent was to d=
escribe=20
what existing


implementations do, the IETF does not realistica=
lly=20
have much change


control...)


 =
;


Best regards,
Pasi



  

  

  From: emu-bounces@ietf.org=20
  [mailto:emu-bounces@ietf.org] On Behalf Of ext Bernard=20
  Aboba
Sent: 04 February, 2009 21:25
To:=20
  emu@ietf.org
Subject: Re: [Emu] Potential Notes in EAP-FAST=20
  Documents


  
"
    IESG Note: EAP-FAST has been implemented by many=
 vendors and it is
    used in the Internet.  Publication of this is int=
ended to promote
    interoperability, even though the use of the EAP-MS=
CHAPv2 and
    EAP-FAST-GTC EAP methods might be difficult in some softw=
are
    environments.  If EAP-FAST were to be designed today, these
 =
   difficulties could be avoided by the assignment of new EAP Type
    c=
odes."

Although I concur with the assessments of Glen Zorn, Dan Hark=
ins,
David Mitton and Dorothy Stanley in many respects, I would suggest =
that
those concerns are outweighed by the IETF's mission to make informa=
tion
on deployed protocols available to the community.  As a result, I <=
BR>believe that the documents should be published, provided that the
fol=
lowing concerns can be addressed:

a. Name confusion.  The use of the=
 term "EAP-FAST-GTC" instead of
EAP-GTC helps clarify that the two proto=
cols are significantly
different.  Similarly, the use of the term "EAP-F=
AST-MS-CHAPv2"
would help clarify differences between the implementation=
s of
EAP MS-CHAPv2, which I believe go beyond just the use of the
cha=
llenge field (e.g. internationalization support). 

b. EAP architectu=
re changes.  Suggesting that EAP methods behave
differently when run wit=
hin a TLS tunnel negotiating a particular
ciphersuite represents a major=
 change to the EAP architecture
as well as to tunneling methods other th=
an EAP-FAST.  This 
suggestion, if made at all, needs to be restricted s=
olely to
use within EAP-FAST. 

c. EAP negotiation issues.  Neithe=
r the IESG note nor the
text explicitly states what is wrong with using =
an EAP Type 
Code for incompatible versions of an EAP method that does n=
ot
support version negotiation.  Indeed, it would appear that some
me=
mbers of the IESG think that method overloading is required
by EAP tunne=
ling methods desiring to incorporate support for
cryptographic binding. =
 Saying that this "might be difficult
in some software environments" isn=
't a good characterization. 
Would the IESG use the same words to descri=
be the reuse of
IP protocol numbers within an IP tunnel?  I doubt it. 

Glen=20
  Zorn said:
I am strongly opposed to the publication of these docu=
ments as RFCs in their
current form.  Not only is the "fast provisioning=
" for EAP-FAST what can
only be characterized as a security disaster, bu=
t EAP-FAST-GTC has nothing
whatsoever to do with the EAP-GTC type.  EAP-=
GTC was "defined for use with
various Token Card implementations which r=
equire user input" but
EAP-FAST-GTC is used solely to transfer a usernam=
e/password combination, the
password in plaintext.  It's hard to see wha=
t this has to do with actual
token cards & appears to be a lazy misu=
se of an existing type.  Furthermore,
it's even harder to see how reward=
ing this kind of nonsense with publication
will serve as a warning of an=
y kind; I would expect that the action of
publication (with or without I=
ESG note) would be more likely taken as notice
that one can do whatever =
one please without fear

David=20
  Mitton said:

I'm sorry,  I haven't responded earlier either, =
but I=20
  would like to pile on with some of my comments.
When I read the Cisco=
=20
  EAP-FAST GTC description and was similarly shocked by the nature of the=20
  changes, and how poorly they technically met their own rationale.
Enco=
ding=20
  the "REQ=3D" and "RESP=3D" into Request and Response text, is absolu=
tely=20
  useless, since the data flow is unidirectional and known to the=20
  requester/responder peers.
And then claiming that is more efficent bec=
ause=20
  the username and OTP are combined in one response, really ignores the iss=
ue=20
  that GTC doesn't define what the appropriate response is.  And they =
did=20
  nothing to clue the client as to what is being requested, or the for=
mat=20
  of the response.
Given that, a Client can only strip the useless cyber=
crud,=20
  and continue with the normal GTC state machine which is let the user type=
=20
  something in and send it.
A more robust OTP implementation may have se=
veral=20
  different inputs that it wants from the user besides for username and=20
  OTP.  (BTW; username could be derived from the EAP Identity) &n=
bsp;=20
  There are possible next token challenges,  new PIN assignment (user =
or=20
  system generated)  and followup re-authentications.   Thei=
r=20
  protocol did nothing to codify a standard for interoperation where a sequ=
ence=20
  of requests were enumerated or named, and response items were=20
  described.  
I'm all for documenting practice, but this=20
  design/implementation doesn't really seem to solve anything and just crea=
tes=20
  more confusion.
Dave Mitton

Dan Harkins said:

  I s=
trongly recommend against publication of these two documents.
They repre=
sent essentially proprietary hacks on established protocols.
The benefit=
 in documenting use of EAP in the Internet today is far
outweighed by th=
e damage done to existing protocol specification and
implementations. Th=
ey will serve only to create spagetti code and
unnecessary complexity.
  In addition to the issues noted by others I will also point out tha=
t
information is being extracted from TLS for use in (the exchange
er=
roneously described as) "EAP-MSCHAPv2" in a way that is different than
t=
he way being proposed by the TLS WG and does not include a binding to
th=
e application.

  I don't believe a stable reference of these proprie=
tary hacks is
necessary because the lack of an RFC to reference them has=
 not stopped
them from being implemented. Whatever process has been used=
 in the
past to convey their specification can be used going forward.
  draft-cam-winget-eap-fast-provisioning claims a reference to RFC 522=
6
but nowhere in that RFC can I find description of the following label<=
BR>for an initial assignment of repository values:

  "allocated for =
management by Cisco"

yet the draft instructs IANA to set aside value=
s 11-63 for just that
purpose. I think that's very inappropriate. Not on=
ly is it telling IANA
to cede some of its authority to a large multinati=
onal corporation but
it is decidedly *NOT* documenting existing use! If =
this whole exercise
is to document existing use then where are the speci=
fications for these
PAC attribute types?

  The recommended note d=
oes nothing to stop this kind of abuse in the
future because the pain yo=
u mention is not felt by the one doing
the abuse.

  To condone on=
e transgression is to invite one thousand more.

  regards,


  Dan.
--_000_808FD6E27AD4884E94820BC333B2DB7727E78F274CNOKEUMSG01mgd_-- From jari.arkko@piuha.net Thu Feb 5 01:03:01 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 779DF3A6A81 for ; Thu, 5 Feb 2009 01:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VEg4cNzmAthn for ; Thu, 5 Feb 2009 01:03:00 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 872413A689B for ; Thu, 5 Feb 2009 01:03:00 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 409C0198770; Thu, 5 Feb 2009 11:02:40 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id E95C219865B; Thu, 5 Feb 2009 11:02:39 +0200 (EET) Message-ID: <498AAAE7.3010800@piuha.net> Date: Thu, 05 Feb 2009 11:01:27 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:03:01 -0000 Bernard, > c. EAP negotiation issues. Neither the IESG note nor the > text explicitly states what is wrong with using an EAP Type > Code for incompatible versions of an EAP method that does not > support version negotiation. They should state this. > Indeed, it would appear that some > members of the IESG think that method overloading is required > by EAP tunneling methods desiring to incorporate support for > cryptographic binding. Not sure who you are referring to, but for the record I at least do not believe that. Cryptographic binding can clearly be achieved without overloading or re-definition of behaviour of existing components. > Saying that this "might be difficult > in some software environments" isn't a good characterization. > Would the IESG use the same words to describe the reuse of > IP protocol numbers within an IP tunnel? I doubt it. I guess this referred to the difficulty of implementing the remedy where EAP within a tunnel is different from EAP outside the tunnel. In some cases this would be possible, in some other cases not... depending on what the software architecture, APIs, etc are. But in all cases it is painful, which is why this is a bad approach and should not be done by future methods. Jari From dharkins@lounge.org Thu Feb 5 01:03:17 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12A1428C147 for ; Thu, 5 Feb 2009 01:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiQIthX3CODB for ; Thu, 5 Feb 2009 01:03:15 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id D30F328C18F for ; Thu, 5 Feb 2009 01:03:15 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 530301FE0220; Thu, 5 Feb 2009 01:02:56 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 5 Feb 2009 01:02:56 -0800 (PST) Message-ID: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia. com> References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 5 Feb 2009 01:02:56 -0800 (PST) From: "Dan Harkins" To: Pasi.Eronen@nokia.com 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] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:03:17 -0000 If the IESG doesn't want to hear opinions then maybe it shouldn't ask. Since it did (this thread started with a post from "the IESG") then it should listen to the opinions it solicited. With all due respect, don't shut off this discussion with a "reminder" that these documents went through IETF Last Call. The track of proposed publication really has nothing to do with my comments (I can't comment on other people's comments). It is the content of the documents, the haphazard manner in which they were constructed, the disregard for standard ways of doing things they attempt to do, and the blatant arrogance of the IANA considerations that really chaps my hide. Can I instruct IANA to assign management of numbers in a newly created registry to "The Daniel Harkins Trust"? No, probably not. I would expect that would generate lots of protests. And justifiably so. So let me ask you (as a member of the IESG), why do you think it's OK to cede parts of IANA's authority to Cisco Systems, Incorporated? Dan. On Wed, February 4, 2009 11:33 pm, Pasi.Eronen@nokia.com wrote: > I would like to remind everyone that these documents did go through > IETF Last Call, and have already been approved by IESG. > > If folks are opposed to publishing descriptions of deployed EAP method > when they're less than perfect (or even ugly hacks with bad architecture), > and may not offer perfect security in all circumstances (but accurately > document their limitations), they should have said so much earlier. > > (In hindsight, publishing these via the RFC Editor independent submission > route, and including the vendor's name in the document title, might > have been better idea. Since the intent was to describe what existing > implementations do, the IETF does not realistically have much change > control...) > > Best regards, > Pasi > > ________________________________ > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of ext > Bernard Aboba > Sent: 04 February, 2009 21:25 > To: emu@ietf.org > Subject: Re: [Emu] Potential Notes in EAP-FAST Documents > > " > > IESG Note: EAP-FAST has been implemented by many vendors and it is > used in the Internet. Publication of this is intended to promote > interoperability, even though the use of the EAP-MSCHAPv2 and > EAP-FAST-GTC EAP methods might be difficult in some software > environments. If EAP-FAST were to be designed today, these > difficulties could be avoided by the assignment of new EAP Type > codes." > > Although I concur with the assessments of Glen Zorn, Dan Harkins, > David Mitton and Dorothy Stanley in many respects, I would suggest that > those concerns are outweighed by the IETF's mission to make information > on deployed protocols available to the community. As a result, I > believe that the documents should be published, provided that the > following concerns can be addressed: > > a. Name confusion. The use of the term "EAP-FAST-GTC" instead of > EAP-GTC helps clarify that the two protocols are significantly > different. Similarly, the use of the term "EAP-FAST-MS-CHAPv2" > would help clarify differences between the implementations of > EAP MS-CHAPv2, which I believe go beyond just the use of the > challenge field (e.g. internationalization support). > > b. EAP architecture changes. Suggesting that EAP methods behave > differently when run within a TLS tunnel negotiating a particular > ciphersuite represents a major change to the EAP architecture > as well as to tunneling methods other than EAP-FAST. This > suggestion, if made at all, needs to be restricted solely to > use within EAP-FAST. > > c. EAP negotiation issues. Neither the IESG note nor the > text explicitly states what is wrong with using an EAP Type > Code for incompatible versions of an EAP method that does not > support version negotiation. Indeed, it would appear that some > members of the IESG think that method overloading is required > by EAP tunneling methods desiring to incorporate support for > cryptographic binding. Saying that this "might be difficult > in some software environments" isn't a good characterization. > Would the IESG use the same words to describe the reuse of > IP protocol numbers within an IP tunnel? I doubt it. > > Glen Zorn said: > > I am strongly opposed to the publication of these documents as RFCs in > their > current form. Not only is the "fast provisioning" for EAP-FAST what can > only be characterized as a security disaster, but EAP-FAST-GTC has nothing > whatsoever to do with the EAP-GTC type. EAP-GTC was "defined for use with > various Token Card implementations which require user input" but > EAP-FAST-GTC is used solely to transfer a username/password combination, > the > password in plaintext. It's hard to see what this has to do with actual > token cards & appears to be a lazy misuse of an existing type. > Furthermore, > it's even harder to see how rewarding this kind of nonsense with > publication > will serve as a warning of any kind; I would expect that the action of > publication (with or without IESG note) would be more likely taken as > notice > that one can do whatever one please without fear > > David Mitton said: > > I'm sorry, I haven't responded earlier either, but I would like to pile > on with some of my comments. > When I read the Cisco EAP-FAST GTC description and was similarly shocked > by the nature of the changes, and how poorly they technically met their > own rationale. > Encoding the "REQ=" and "RESP=" into Request and Response text, is > absolutely useless, since the data flow is unidirectional and known to the > requester/responder peers. > And then claiming that is more efficent because the username and OTP are > combined in one response, really ignores the issue that GTC doesn't define > what the appropriate response is. And they did nothing to clue the client > as to what is being requested, or the format of the response. > Given that, a Client can only strip the useless cybercrud, and continue > with the normal GTC state machine which is let the user type something in > and send it. > A more robust OTP implementation may have several different inputs that it > wants from the user besides for username and OTP. (BTW; username could be > derived from the EAP Identity) There are possible next token challenges, > new PIN assignment (user or system generated) and followup > re-authentications. Their protocol did nothing to codify a standard for > interoperation where a sequence of requests were enumerated or named, and > response items were described. > I'm all for documenting practice, but this design/implementation doesn't > really seem to solve anything and just creates more confusion. > Dave Mitton > > Dan Harkins said: > > > I strongly recommend against publication of these two documents. > They represent essentially proprietary hacks on established protocols. > The benefit in documenting use of EAP in the Internet today is far > outweighed by the damage done to existing protocol specification and > implementations. They will serve only to create spagetti code and > unnecessary complexity. > > In addition to the issues noted by others I will also point out that > information is being extracted from TLS for use in (the exchange > erroneously described as) "EAP-MSCHAPv2" in a way that is different than > the way being proposed by the TLS WG and does not include a binding to > the application. > > I don't believe a stable reference of these proprietary hacks is > necessary because the lack of an RFC to reference them has not stopped > them from being implemented. Whatever process has been used in the > past to convey their specification can be used going forward. > > draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226 > but nowhere in that RFC can I find description of the following label > for an initial assignment of repository values: > > "allocated for management by Cisco" > > yet the draft instructs IANA to set aside values 11-63 for just that > purpose. I think that's very inappropriate. Not only is it telling IANA > to cede some of its authority to a large multinational corporation but > it is decidedly *NOT* documenting existing use! If this whole exercise > is to document existing use then where are the specifications for these > PAC attribute types? > > The recommended note does nothing to stop this kind of abuse in the > future because the pain you mention is not felt by the one doing > the abuse. > > To condone one transgression is to invite one thousand more. > > regards, > > > > Dan. > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From Pasi.Eronen@nokia.com Thu Feb 5 01:35:33 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93C628C0E4 for ; Thu, 5 Feb 2009 01:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vnh7GlJanKl for ; Thu, 5 Feb 2009 01:35:32 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B62DA3A6BC3 for ; Thu, 5 Feb 2009 01:35:32 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n159WDJ6027525; Thu, 5 Feb 2009 03:35:11 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 11:35:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 11:35:03 +0200 Received: from NOK-AM1MHUB-05.mgdnok.nokia.com (65.54.30.9) by NOK-AM1MHUB-04.mgdnok.nokia.com (65.54.30.8) with Microsoft SMTP Server (TLS) id 8.1.291.1; Thu, 5 Feb 2009 10:35:01 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by NOK-AM1MHUB-05.mgdnok.nokia.com ([65.54.30.9]) with mapi; Thu, 5 Feb 2009 10:35:01 +0100 From: To: Date: Thu, 5 Feb 2009 10:34:57 +0100 Thread-Topic: [Emu] Potential Notes in EAP-FAST Documents Thread-Index: AcmHcJDte9r3AIz9S+CSqH75b22lzAAAj+4g Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E78F28F8@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Feb 2009 09:35:03.0966 (UTC) FILETIME=[0613E3E0:01C98775] X-Nokia-AV: Clean Cc: emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:35:33 -0000 Dan Harkins wrote: > If the IESG doesn't want to hear opinions then maybe it shouldn't > ask. Since it did (this thread started with a post from "the IESG") > then it should listen to the opinions it solicited. With all due > respect, don't shut off this discussion with a "reminder" that these > documents went through IETF Last Call. The IESG asked for comments about a very specific issue (proposed notes to be added to these documents), not whether e.g. anonymous provisioning is a good idea, or whether EAP methods with less than ideal architecture should be published at all. > The track of proposed publication really has nothing to do with my > comments (I can't comment on other people's comments). It is the > content of the documents, the haphazard manner in which they were > constructed, the disregard for standard ways of doing things they > attempt to do, and the blatant arrogance of the IANA considerations > that really chaps my hide. > > Can I instruct IANA to assign management of numbers in a newly > created registry to "The Daniel Harkins Trust"? No, probably not. I > would expect that would generate lots of protests. And justifiably > so. So let me ask you (as a member of the IESG), why do you think > it's OK to cede parts of IANA's authority to Cisco Systems, > Incorporated? When a document creates a new number space, it can specify who administers the numbers. IANA's authority comes from a document giving it the authority, not automatically. IANA has no monopoly in this area, and for a vendor-proprietary protocol,"The Daniel Harkins Trust" would indeed be acceptable. Probably most vendor-specific RFCs don't give IANA any part of the space (i.e., the vendor manages all the numbers) -- this is a bit different since the range is partitioned, and it's possible to get a number without the vendor approving. We also have a number of IETF protocols where the numbers are not administered by IANA. Many documents use registries maintained by ISO or ITU-T. Various documents from the SMIME and PKIX WGs use numbers from a registry maintained by Russ Housley (as an individual contributor, not as IESG member) instead of IANA. RPC program numbers (used in e.g. NFS) are maintained by Sun Microsystems (although there's ongoing work to move them to IANA). Probably other examples exist. Best regards, Pasi From jari.arkko@piuha.net Thu Feb 5 01:40:39 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC8B33A6BC3 for ; Thu, 5 Feb 2009 01:40:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL7PJ+vxuLcl for ; Thu, 5 Feb 2009 01:40:39 -0800 (PST) Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id EDF7328C194 for ; Thu, 5 Feb 2009 01:40:38 -0800 (PST) Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 750C8198788; Thu, 5 Feb 2009 11:40:18 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id AB413198787; Thu, 5 Feb 2009 11:40:17 +0200 (EET) Message-ID: <498AB3B8.8040703@piuha.net> Date: Thu, 05 Feb 2009 11:39:04 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:40:40 -0000 Pasi, > If folks are opposed to publishing descriptions of deployed EAP method > when they're less than perfect (or even ugly hacks with bad > architecture), > and may not offer perfect security in all circumstances (but accurately > document their limitations), they should have said so much earlier. Indeed. > (In hindsight, publishing these via the RFC Editor independent submission > route, and including the vendor's name in the document title, might > have been better idea. Since the intent was to describe what existing > implementations do, the IETF does not realistically have much change > control...) Maybe we should focus on what to do next as opposed to figuring out what we should have done years ago. However, I think this would not have changed the substance of the matter, and per RFC 3932 the IESG would probably have noted that a non-IETF submission should not have an effect in an EAP type code defined by an IETF RFC (RFC 3748). So I think the document took the right path (and I still think it should be published), but we can of course wish that some of this discussion had happened in Last Call. That is, after all, what Last Calls are for :-) Jari From dharkins@lounge.org Thu Feb 5 01:50:20 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B600F3A6940 for ; Thu, 5 Feb 2009 01:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVNNigfj-jxG for ; Thu, 5 Feb 2009 01:50:20 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 1149F3A67AF for ; Thu, 5 Feb 2009 01:50:20 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E707B1FE0220; Thu, 5 Feb 2009 01:49:59 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 5 Feb 2009 01:50:00 -0800 (PST) Message-ID: <0d255dc1d5c12fde2efc7998c98219fb.squirrel@www.trepanning.net> In-Reply-To: <498AB3B8.8040703@piuha.net> References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> <498AB3B8.8040703@piuha.net> Date: Thu, 5 Feb 2009 01:50:00 -0800 (PST) From: "Dan Harkins" To: "Jari Arkko" 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] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 09:50:20 -0000 Hi Jari, On Thu, February 5, 2009 1:39 am, Jari Arkko wrote: [snip] > Maybe we should focus on what to do next as opposed to figuring out what > we should have done years ago. Exactly! So let's, right now, decide to not publish these documents. Dan. From glenzorn@comcast.net Thu Feb 5 03:04:22 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C0F28C192 for ; Thu, 5 Feb 2009 03:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.337 X-Spam-Level: X-Spam-Status: No, score=-2.337 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8d9snoGe2p0 for ; Thu, 5 Feb 2009 03:04:12 -0800 (PST) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 78E353A657C for ; Thu, 5 Feb 2009 03:04:12 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA07.westchester.pa.mail.comcast.net with comcast id CAqu1b0080Fqzac57B3tSC; Thu, 05 Feb 2009 11:03:53 +0000 Received: from gwzPC ([124.120.227.205]) by OMTA08.westchester.pa.mail.comcast.net with comcast id CB2s1b0034SXqDG3UB30Yo; Thu, 05 Feb 2009 11:03:24 +0000 From: "Glen Zorn" To: References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 5 Feb 2009 18:02:53 +0700 Message-ID: <006c01c98781$5d6b8bf0$1842a3d0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C987BC.09CA63F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmG/lqa1KgpUF8USwKhyQk7NRQaiAAZKlqQAAcC4gA= Content-Language: en-us Cc: emu@ietf.org, iesg@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 11:04:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_006D_01C987BC.09CA63F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Pasi Eronen (pasi.eronen@nokia.com) writes: I would like to remind everyone that these documents did go through IETF Last Call, and have already been approved by IESG. Given the quality of the documents in question, perhaps that's not something that you should be bragging about. If folks are opposed to publishing descriptions of deployed EAP method when they're less than perfect (or even ugly hacks with bad architecture), and may not offer perfect security in all circumstances (but accurately document their limitations), they should have said so much earlier. No offense, but I'm getting the real feeling that you're just not paying much attention. The major problems I've heard WRT publication as-is have to do with the misuse of IANA registries, not ugly hacks or "imperfect security". (In hindsight, publishing these via the RFC Editor independent submission route, and including the vendor's name in the document title, might have been better idea. Since the intent was to describe what existing implementations do, the IETF does not realistically have much change control...) Publishing them as individual submissions would have been a better idea I don't see how that would solve the IANA problem. Best regards, Pasi _____ From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of ext Bernard Aboba Sent: 04 February, 2009 21:25 To: emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents " IESG Note: EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this is intended to promote interoperability, even though the use of the EAP-MSCHAPv2 and EAP-FAST-GTC EAP methods might be difficult in some software environments. If EAP-FAST were to be designed today, these difficulties could be avoided by the assignment of new EAP Type codes." Although I concur with the assessments of Glen Zorn, Dan Harkins, David Mitton and Dorothy Stanley in many respects, I would suggest that those concerns are outweighed by the IETF's mission to make information on deployed protocols available to the community. As a result, I believe that the documents should be published, provided that the following concerns can be addressed: a. Name confusion. The use of the term "EAP-FAST-GTC" instead of EAP-GTC helps clarify that the two protocols are significantly different. Similarly, the use of the term "EAP-FAST-MS-CHAPv2" would help clarify differences between the implementations of EAP MS-CHAPv2, which I believe go beyond just the use of the challenge field (e.g. internationalization support). b. EAP architecture changes. Suggesting that EAP methods behave differently when run within a TLS tunnel negotiating a particular ciphersuite represents a major change to the EAP architecture as well as to tunneling methods other than EAP-FAST. This suggestion, if made at all, needs to be restricted solely to use within EAP-FAST. c. EAP negotiation issues. Neither the IESG note nor the text explicitly states what is wrong with using an EAP Type Code for incompatible versions of an EAP method that does not support version negotiation. Indeed, it would appear that some members of the IESG think that method overloading is required by EAP tunneling methods desiring to incorporate support for cryptographic binding. Saying that this "might be difficult in some software environments" isn't a good characterization. Would the IESG use the same words to describe the reuse of IP protocol numbers within an IP tunnel? I doubt it. Glen Zorn said: I am strongly opposed to the publication of these documents as RFCs in their current form. Not only is the "fast provisioning" for EAP-FAST what can only be characterized as a security disaster, but EAP-FAST-GTC has nothing whatsoever to do with the EAP-GTC type. EAP-GTC was "defined for use with various Token Card implementations which require user input" but EAP-FAST-GTC is used solely to transfer a username/password combination, the password in plaintext. It's hard to see what this has to do with actual token cards & appears to be a lazy misuse of an existing type. Furthermore, it's even harder to see how rewarding this kind of nonsense with publication will serve as a warning of any kind; I would expect that the action of publication (with or without IESG note) would be more likely taken as notice that one can do whatever one please without fear David Mitton said: I'm sorry, I haven't responded earlier either, but I would like to pile on with some of my comments. When I read the Cisco EAP-FAST GTC description and was similarly shocked by the nature of the changes, and how poorly they technically met their own rationale. Encoding the "REQ=" and "RESP=" into Request and Response text, is absolutely useless, since the data flow is unidirectional and known to the requester/responder peers. And then claiming that is more efficent because the username and OTP are combined in one response, really ignores the issue that GTC doesn't define what the appropriate response is. And they did nothing to clue the client as to what is being requested, or the format of the response. Given that, a Client can only strip the useless cybercrud, and continue with the normal GTC state machine which is let the user type something in and send it. A more robust OTP implementation may have several different inputs that it wants from the user besides for username and OTP. (BTW; username could be derived from the EAP Identity) There are possible next token challenges, new PIN assignment (user or system generated) and followup re-authentications. Their protocol did nothing to codify a standard for interoperation where a sequence of requests were enumerated or named, and response items were described. I'm all for documenting practice, but this design/implementation doesn't really seem to solve anything and just creates more confusion. Dave Mitton Dan Harkins said: I strongly recommend against publication of these two documents. They represent essentially proprietary hacks on established protocols. The benefit in documenting use of EAP in the Internet today is far outweighed by the damage done to existing protocol specification and implementations. They will serve only to create spagetti code and unnecessary complexity. In addition to the issues noted by others I will also point out that information is being extracted from TLS for use in (the exchange erroneously described as) "EAP-MSCHAPv2" in a way that is different than the way being proposed by the TLS WG and does not include a binding to the application. I don't believe a stable reference of these proprietary hacks is necessary because the lack of an RFC to reference them has not stopped them from being implemented. Whatever process has been used in the past to convey their specification can be used going forward. draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226 but nowhere in that RFC can I find description of the following label for an initial assignment of repository values: "allocated for management by Cisco" yet the draft instructs IANA to set aside values 11-63 for just that purpose. I think that's very inappropriate. Not only is it telling IANA to cede some of its authority to a large multinational corporation but it is decidedly *NOT* documenting existing use! If this whole exercise is to document existing use then where are the specifications for these PAC attribute types? The recommended note does nothing to stop this kind of abuse in the future because the pain you mention is not felt by the one doing the abuse. To condone one transgression is to invite one thousand more. regards, Dan. ------=_NextPart_000_006D_01C987BC.09CA63F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pasi Eronen (pasi.eronen@nokia.com) writes:

 

I would like to remind everyone that these documents did go = through
IETF Last Call, and have already been approved by IESG.

Given the quality of the documents in question, perhaps = that's not something that you should be bragging = about…

If folks are opposed to publishing descriptions of deployed = EAP method
when they're less than perfect (or even ugly hacks with bad = architecture), =

and may not offer perfect security in all circumstances (but accurately =

document their limitations), they should have said = so much earlier.=

No offense, but I'm getting the real feeling that you're = just not paying much attention.  The major problems I've heard WRT = publication as-is have to do with the misuse of IANA registries, not ugly hacks or "imperfect security". 

(In hindsight, publishing these via the RFC Editor = independent submission=

route, and including the vendor's name in the document = title, might=

have been better idea. Since the intent was to describe what existing=

implementations do, the IETF does not realistically have = much change=

control...)

Publishing them as individual submissions would have been = a better idea I don't see how that would solve the IANA = problem.    =

Best regards,
Pasi=

 =

From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of ext Bernard Aboba
Sent: 04 February, 2009 21:25
To: emu@ietf.org
Subject: Re: [Emu] Potential Notes in EAP-FAST = Documents=

"= 

    IESG Note: EAP-FAST has been implemented by many =
vendors and it is

    used in the Internet.  Publication of this is =
intended to promote

    interoperability, even though the use of the =
EAP-MSCHAPv2 and

    EAP-FAST-GTC EAP methods might be difficult in some =
software

    environments.  If EAP-FAST were to be designed =
today, these

    difficulties could be avoided by the assignment of =
new EAP Type

    codes."



Although I concur with the assessments of Glen Zorn, Dan Harkins,

David Mitton and Dorothy Stanley in many respects, I would suggest =
that

those concerns are outweighed by the IETF's mission to make =
information

on deployed protocols available to the community.  As a result, I =


believe that the documents should be published, provided that the

following concerns can be addressed:



a. Name confusion.  The use of the term "EAP-FAST-GTC" =
instead of

EAP-GTC helps clarify that the two protocols are significantly

different.  Similarly, the use of the term =
"EAP-FAST-MS-CHAPv2"

would help clarify differences between the implementations of

EAP MS-CHAPv2, which I believe go beyond just the use of the

challenge field (e.g. internationalization support). 



b. EAP architecture changes.  Suggesting that EAP methods =
behave

differently when run within a TLS tunnel negotiating a particular

ciphersuite represents a major change to the EAP architecture

as well as to tunneling methods other than EAP-FAST.  This 

suggestion, if made at all, needs to be restricted solely to

use within EAP-FAST. 



c. EAP negotiation issues.  Neither the IESG note nor the

text explicitly states what is wrong with using an EAP Type 

Code for incompatible versions of an EAP method that does not

support version negotiation.  Indeed, it would appear that some

members of the IESG think that method overloading is required

by EAP tunneling methods desiring to incorporate support for

cryptographic binding.  Saying that this "might be =
difficult

in some software environments" isn't a good characterization. 

Would the IESG use the same words to describe the reuse of

IP protocol numbers within an IP tunnel?  I doubt it. =


Glen Zorn said:

I am strongly opposed to the publication of these documents as RFCs =
in their

current form.  Not only is the "fast provisioning" for =
EAP-FAST what can

only be characterized as a security disaster, but EAP-FAST-GTC has =
nothing

whatsoever to do with the EAP-GTC type.  EAP-GTC was "defined =
for use with

various Token Card implementations which require user input" =
but

EAP-FAST-GTC is used solely to transfer a username/password combination, =
the

password in plaintext.  It's hard to see what this has to do with =
actual

token cards & appears to be a lazy misuse of an existing type.  =
Furthermore,

it's even harder to see how rewarding this kind of nonsense with =
publication

will serve as a warning of any kind; I would expect that the action =
of

publication (with or without IESG note) would be more likely taken as =
notice

that one can do whatever one please without fear


David Mitton said:

I'm sorry,  I haven't responded earlier either, but I would like to = pile on with some of my comments.
When I read the Cisco EAP-FAST GTC description and was similarly shocked = by the nature of the changes, and how poorly they technically met their own = rationale.
Encoding the "REQ=3D" and "RESP=3D" into = Request and Response text, is absolutely useless, since the data flow is unidirectional and known to the requester/responder peers.
And then claiming that is more efficent because the username and OTP are combined in one response, really ignores the issue that GTC doesn't = define what the appropriate response is.  And they did nothing to clue the = client as to what is being requested, or the format of the response.
Given that, a Client can only strip the useless cybercrud, and continue = with the normal GTC state machine which is let the user type something in and = send it.
A more robust OTP implementation may have several different inputs that = it wants from the user besides for username and OTP.  (BTW; username = could be derived from the EAP Identity)   There are possible next token challenges,  new PIN assignment (user or system generated)  = and followup re-authentications.   Their protocol did nothing to = codify a standard for interoperation where a sequence of requests were = enumerated or named, and response items were described. 
I'm all for documenting practice, but this design/implementation doesn't = really seem to solve anything and just creates more confusion.
Dave Mitton

Dan Harkins said:

  I strongly recommend against publication of these two =
documents.

They represent essentially proprietary hacks on established =
protocols.

The benefit in documenting use of EAP in the Internet today is far

outweighed by the damage done to existing protocol specification and

implementations. They will serve only to create spagetti code and

unnecessary complexity.



  In addition to the issues noted by others I will also point out =
that

information is being extracted from TLS for use in (the exchange

erroneously described as) "EAP-MSCHAPv2" in a way that is =
different than

the way being proposed by the TLS WG and does not include a binding =
to

the application.



  I don't believe a stable reference of these proprietary hacks =
is

necessary because the lack of an RFC to reference them has not =
stopped

them from being implemented. Whatever process has been used in the

past to convey their specification can be used going forward.



  draft-cam-winget-eap-fast-provisioning claims a reference to RFC =
5226

but nowhere in that RFC can I find description of the following =
label

for an initial assignment of repository values:



  "allocated for management by Cisco"



yet the draft instructs IANA to set aside values 11-63 for just that

purpose. I think that's very inappropriate. Not only is it telling =
IANA

to cede some of its authority to a large multinational corporation =
but

it is decidedly *NOT* documenting existing use! If this whole =
exercise

is to document existing use then where are the specifications for =
these

PAC attribute types?



  The recommended note does nothing to stop this kind of abuse in =
the

future because the pain you mention is not felt by the one doing

the abuse.



  To condone one transgression is to invite one thousand more.



  regards,







  Dan.

 =

 

------=_NextPart_000_006D_01C987BC.09CA63F0-- From glenzorn@comcast.net Thu Feb 5 04:18:51 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 087723A690E for ; Thu, 5 Feb 2009 04:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akag-p8zCNr8 for ; Thu, 5 Feb 2009 04:18:50 -0800 (PST) Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id 257533A6862 for ; Thu, 5 Feb 2009 04:18:50 -0800 (PST) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id CCEJ1b0031GXsucAACJXMH; Thu, 05 Feb 2009 12:18:31 +0000 Received: from gwzPC ([124.120.227.205]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id CCJD1b00A4SXqDG8TCJJlt; Thu, 05 Feb 2009 12:18:29 +0000 From: "Glen Zorn" To: , References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727E78F28F8@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E78F28F8@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 5 Feb 2009 19:17:50 +0700 Message-ID: <007c01c9878b$ccf741d0$66e5c570$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmHcJDte9r3AIz9S+CSqH75b22lzAAAj+4gAATLLvA= Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 12:18:51 -0000 Pasi Eronen (pasi.eronen@nokia.com) writes: ... > > Can I instruct IANA to assign management of numbers in a newly > > created registry to "The Daniel Harkins Trust"? No, probably not. I > > would expect that would generate lots of protests. And justifiably > > so. So let me ask you (as a member of the IESG), why do you think > > it's OK to cede parts of IANA's authority to Cisco Systems, > > Incorporated? > > When a document creates a new number space, it can specify who > administers the numbers. IANA's authority comes from a document > giving it the authority, not automatically. > > IANA has no monopoly in this area, and for a vendor-proprietary > protocol,"The Daniel Harkins Trust" would indeed be acceptable. > Probably most vendor-specific RFCs don't give IANA any part of the > space (i.e., the vendor manages all the numbers) -- this is a bit > different since the range is partitioned, and it's possible to > get a number without the vendor approving. > > We also have a number of IETF protocols where the numbers are not > administered by IANA. Many documents use registries maintained by ISO > or ITU-T. Various documents from the SMIME and PKIX WGs use numbers > from a registry maintained by Russ Housley (as an individual > contributor, not as IESG member) instead of IANA. RPC program numbers > (used in e.g. NFS) are maintained by Sun Microsystems (although > there's ongoing work to move them to IANA). Probably other examples > exist. Ok, so now I'm totally confused. None of the examples you cite are IANA registries & I would have no problem w/Cisco handing out numbers for their proprietary protocol, but that's not what they're doing. What they're doing is establishing an _IANA registry_ but retaining a significant portion of that registry under proprietary control, presumably expecting IANA to publish numbers at their behest. Are you saying that's OK? From Pasi.Eronen@nokia.com Thu Feb 5 04:52:34 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF7C23A6BFC; Thu, 5 Feb 2009 04:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKuMg-QaxCAG; Thu, 5 Feb 2009 04:52:33 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B4C983A6AAA; Thu, 5 Feb 2009 04:52:33 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n15Cpt4t026301; Thu, 5 Feb 2009 06:52:10 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 14:51:57 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 14:51:53 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 5 Feb 2009 13:51:52 +0100 From: To: Date: Thu, 5 Feb 2009 13:51:52 +0100 Thread-Topic: [Emu] Potential Notes in EAP-FAST Documents Thread-Index: AcmG/lqa1KgpUF8USwKhyQk7NRQaiAAZKlqQAAcC4gAAAri40A== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E78F2B67@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> <006c01c98781$5d6b8bf0$1842a3d0$@net> In-Reply-To: <006c01c98781$5d6b8bf0$1842a3d0$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Feb 2009 12:51:53.0169 (UTC) FILETIME=[84E94410:01C98790] X-Nokia-AV: Clean Cc: emu@ietf.org, iesg@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 12:52:34 -0000 Glen Zorn wrote: > > I would like to remind everyone that these documents did go > > through IETF Last Call, and have already been approved by IESG. > > Given the quality of the documents in question, perhaps that's not > something that you should be bragging about... > > > If folks are opposed to publishing descriptions of deployed EAP > > method when they're less than perfect (or even ugly hacks with bad > > architecture), and may not offer perfect security in all > > circumstances (but accurately document their limitations), they > > should have said so much earlier. > > No offense, but I'm getting the real feeling that you're just not > paying much attention. The major problems I've heard WRT > publication as-is have to do with the misuse of IANA registries, not > ugly hacks or "imperfect security". I am paying attention, thank you. Of the emails on emu@ietf.org about EAP-FAST in the past month or so, less than half of the text seems to be about re-using EAP-GTC/MSCHAPv2 type codes. Your first email (Jan 27) mentions only anonymous provisioning (nothing about EAP type codes), and your second message (Feb 3) first talks about the insecurity of anonymous provisioning, and then about the EAP-GTC type code. The EAP-GTC type code re-use is not a new concern; it was specifically discussed before the IESG approved the document, and the discussion resulted in changes in the document. As far as I can tell, this thread has contained no new information about the topic. It seems you would have preferred that IESG had reached a different decision back then. That's a perfectly valid opinion, but the IETF Last Call would have been the right time to express it. For EAP-MSCHAPv2, I think there has been some new information that wasn't really well considered before IESG approved the document. IESG is proposing solving it basically the same way as for EAP-GTC -- noting that this is bad design, and future design should not do it this way. > > (In hindsight, publishing these via the RFC Editor independent > > submission route, and including the vendor's name in the document > > title, might have been better idea. Since the intent was to > > describe what existing implementations do, the IETF does not > > realistically have much change control...) > > Publishing them as individual submissions would have been a better > idea I don't see how that would solve the IANA problem. BTW, you can look at this either as changing an existing code point, or defining a field (an EAP-FAST TLV "Value" part) that contains either protocol X (normal EAP header with IANA-allocated EAP Type code) or protocol Y (some other stuff). Basically, the change that was made to draft-zhou-emu-fast-gtc says "if this byte contains anything else than 0x06, interprete it as normal EAP Header with IANA-allocated EAP Type number. If it contains 0x06, interprete it as described below." (not using those words, but that's the idea) When some field can contain either X or Y, normally we'd multiplex them by having a separate "type" field outside the field itself. That's the approach used in e.g. RFC5281, which changes MS-CHAPv2 challenge processing in very similar way as draft-cam-winget-eap- fast-provisioning. Another approach is to multiplex by "peeking inside the content"; while this is usually less preferable, it's a choice the protocol designer gets to make when defining a new field (and is used in some IETF specs too; e.g. draft-ietf-avt-dtls-srtp). Choosing this approach to multiplexing the contents of this field certainly was not a good design decision, and the proposed IESG text basically says so (and warns that it probably doesn't exactly simplify implementation either). But I don't think it should alone prevent publishing a description of somewhat widely implemented protocol. *IF* this caused interoperability problems for folks who don't implement this specification (or between folks who do implement this spec and those that don't), I'd be very worried indeed. But that does not seem to be the case. Best regards, Pasi From Pasi.Eronen@nokia.com Thu Feb 5 05:02:44 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF7723A6B19 for ; Thu, 5 Feb 2009 05:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.573 X-Spam-Level: X-Spam-Status: No, score=-6.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVQGdbs5mgol for ; Thu, 5 Feb 2009 05:02:44 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 9A63A3A6C8A for ; Thu, 5 Feb 2009 05:02:43 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n15D297d025589; Thu, 5 Feb 2009 15:02:19 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 15:02:03 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Feb 2009 15:01:55 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 5 Feb 2009 14:01:55 +0100 From: To: , Date: Thu, 5 Feb 2009 14:01:56 +0100 Thread-Topic: [Emu] Potential Notes in EAP-FAST Documents Thread-Index: AcmHcJDte9r3AIz9S+CSqH75b22lzAAAj+4gAATLLvAAAqLk0A== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E78F2B82@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727E78F28F8@NOK-EUMSG-01.mgdnok.nokia.com> <007c01c9878b$ccf741d0$66e5c570$@net> In-Reply-To: <007c01c9878b$ccf741d0$66e5c570$@net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Feb 2009 13:01:55.0570 (UTC) FILETIME=[EBF85D20:01C98791] X-Nokia-AV: Clean Cc: emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 13:02:44 -0000 Glen Zorn wrote: > Ok, so now I'm totally confused. None of the examples you cite are > IANA registries & I would have no problem w/Cisco handing out > numbers for their proprietary protocol, but that's not what they're > doing. What they're doing is establishing an _IANA registry_ but > retaining a significant portion of that registry under proprietary > control, presumably expecting IANA to publish numbers at their > behest. Are you saying that's OK? Ah -- my understand was that Cisco is not expecting IANA to publish anything at their behest; IANA will just mark 11-63 as "Allocated for Cisco", and if Cisco wants to use any of those numbers, they don't need to tell IANA. Or in other words, I thought IANA would operate the registry just like any other IANA registry with "Specification Required" policy, except the free values are 64-255. (I think this approach, while perhaps a bit unusual, is better than the normal "can't extend the protocol unless vendor agrees" approach.) Best regards, Pasi From glenzorn@comcast.net Thu Feb 5 05:23:12 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40213A6B97 for ; Thu, 5 Feb 2009 05:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8u-v326QD83 for ; Thu, 5 Feb 2009 05:23:11 -0800 (PST) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by core3.amsl.com (Postfix) with ESMTP id B58253A6AF2 for ; Thu, 5 Feb 2009 05:23:11 -0800 (PST) Received: from OMTA12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA10.westchester.pa.mail.comcast.net with comcast id CBX11b0090xGWP85ADNs0r; Thu, 05 Feb 2009 13:22:52 +0000 Received: from gwzPC ([124.120.227.205]) by OMTA12.westchester.pa.mail.comcast.net with comcast id CDNA1b0074SXqDG3YDNLPM; Thu, 05 Feb 2009 13:22:47 +0000 From: "Glen Zorn" To: References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727E78F28F8@NOK-EUMSG-01.mgdnok.nokia.com> <007c01c9878b$ccf741d0$66e5c570$@net> <808FD6E27AD4884E94820BC333B2DB7727E78F2B82@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E78F2B82@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 5 Feb 2009 20:21:47 +0700 Message-ID: <009801c98794$c8a1db50$59e591f0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmHcJDte9r3AIz9S+CSqH75b22lzAAAj+4gAATLLvAAAqLk0AAAeYNQ Content-Language: en-us Cc: iesg@ietf.org, emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 13:23:12 -0000 Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] writes: > Glen Zorn wrote: > > > Ok, so now I'm totally confused. None of the examples you cite are > > IANA registries & I would have no problem w/Cisco handing out > > numbers for their proprietary protocol, but that's not what they're > > doing. What they're doing is establishing an _IANA registry_ but > > retaining a significant portion of that registry under proprietary > > control, presumably expecting IANA to publish numbers at their > > behest. Are you saying that's OK? > > Ah -- my understand was that Cisco is not expecting IANA to publish > anything at their behest; IANA will just mark 11-63 as "Allocated for > Cisco", and if Cisco wants to use any of those numbers, they don't > need to tell IANA. > > Or in other words, I thought IANA would operate the registry just like > any other IANA registry with "Specification Required" policy, except > the free values are 64-255. Hmm. OK, that's not an unreasonable interpretation but in that case I don't understand why 1) the first 10, 3, whatever numbers are doing in the registry at all, since their status as proprietary allocations are just the same as the next set & 2) why the document doesn't just say that the range is reserved. "Managed by Cisco" implies to me that Cisco plans to allocate the number themselves (presumably as a convenience & to avoid the pain (embarrassment?) of publishing an RFC every five minutes), then advertise them using IANA. Since I've been wrong before, though ;-), I'd be interested in hearing from the authors on this subject. ... From dharkins@lounge.org Thu Feb 5 11:17:09 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2663A659C for ; Thu, 5 Feb 2009 11:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0roNOE9rz5S for ; Thu, 5 Feb 2009 11:17:08 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id B3E6C3A6783 for ; Thu, 5 Feb 2009 11:17:08 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2D582A8880D4; Thu, 5 Feb 2009 11:17:10 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 5 Feb 2009 11:17:10 -0800 (PST) Message-ID: <611c3d187c4c5f25d86aa5de53dd1399.squirrel@www.trepanning.net> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E78F2B82@NOK-EUMSG-01.mgdnok.nokia. com> References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727E78F28F8@NOK-EUMSG-01.mgdnok.nokia.com> <007c01c9878b$ccf741d0$66e5c570$@net> <808FD6E27AD4884E94820BC333B2DB7727E78F2B82@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 5 Feb 2009 11:17:10 -0800 (PST) From: "Dan Harkins" To: Pasi.Eronen@nokia.com 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] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 19:17:09 -0000 Hi Pasi, On Thu, February 5, 2009 5:01 am, Pasi.Eronen@nokia.com wrote: > Glen Zorn wrote: > >> Ok, so now I'm totally confused. None of the examples you cite are >> IANA registries & I would have no problem w/Cisco handing out >> numbers for their proprietary protocol, but that's not what they're >> doing. What they're doing is establishing an _IANA registry_ but >> retaining a significant portion of that registry under proprietary >> control, presumably expecting IANA to publish numbers at their >> behest. Are you saying that's OK? > > Ah -- my understand was that Cisco is not expecting IANA to publish > anything at their behest; IANA will just mark 11-63 as "Allocated for > Cisco", and if Cisco wants to use any of those numbers, they don't > need to tell IANA. So if I want to make a proprietary hack to this protocol I must have a public specification reviewed by a Designated Expert while Cisco can make proprietary hacks to their heart's content. And this arrangement is enforced by the Internet Assigned Numbers Authority. Where in RFC 5226 does it mention this sort of arrangement? This whole snafu is because Cisco is abusing numbers assigned by IANA. They make proprietary hacks to established protocols, claim universal support for their hacks, and use that claim to get something published that should never be published. And we're going to publish a note lamenting the fact that this happened ("If EAP-FAST were designed today, these difficulties could be avoided....") while we basically ensure it will happen again! It's like telling an alcoholic not to drink while you give him a gift certificate from a liquor store. Dan. From ncamwing@cisco.com Thu Feb 5 14:28:39 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69E213A6AF2 for ; Thu, 5 Feb 2009 14:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OvEsiOhkTLv for ; Thu, 5 Feb 2009 14:28:38 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AA8023A6942 for ; Thu, 5 Feb 2009 14:27:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,387,1231113600"; d="scan'208";a="243841262" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 05 Feb 2009 22:27:39 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n15MRdat005522; Thu, 5 Feb 2009 14:27:39 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n15MRcNA006853; Thu, 5 Feb 2009 22:27:39 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Feb 2009 14:27:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 5 Feb 2009 14:27:39 -0800 Message-ID: <08A9A3213527A6428774900A80DBD8D8086463ED@xmb-sjc-222.amer.cisco.com> In-Reply-To: <498AAAE7.3010800@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Potential Notes in EAP-FAST Documents Thread-Index: AcmHcIKQxlZi9qBVQmy9UN/FkNbZzgAcBHDQ References: <498AAAE7.3010800@piuha.net> From: "Nancy Cam-Winget (ncamwing)" To: "Jari Arkko" , "Bernard Aboba" X-OriginalArrivalTime: 05 Feb 2009 22:27:38.0984 (UTC) FILETIME=[F3D24E80:01C987E0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3202; t=1233872859; x=1234736859; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ncamwing@cisco.com; z=From:=20=22Nancy=20Cam-Winget=20(ncamwing)=22=20 |Subject:=20RE=3A=20[Emu]=20Potential=20Notes=20in=20EAP-FA ST=20Documents |Sender:=20; bh=TPaXzsPsrCC2ds1RVfk4pAwotysaCKSsum0e/OyYJIw=; b=TVqM5WWV5DriQIP3xgBkuyeayBJztDfIOtYfMrWW6xLPpB5MAGXoTiVl7O qrFDqrDPk0E048/dlG/ZuvAXDYyWrdaFvmjMepcoFNSlcpzZNXJhCJVoK6SS qsosq3O8ux; Authentication-Results: sj-dkim-3; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2009 22:28:39 -0000 Hi, Per the potential notes and given feedback thus far, we (the authors) can address the relevant concerns with updates to the draft(s) as follows: 1. Update the EAP-FAST provisioning draft to change EAP-MSCHAPv2 to EAP-FAST-MSCHAPv2 throughout the document where the reference is to its working inside the EAP-FAST tunnel during anonymous provisioning mode. Also clarify the use of EAP-FAST-MSCHAPv2 during anonymous provisioning in section 3.2.3 2. The following text could be added either in the introduction or IANA considerations (or anywhere the IESG prefers): "EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this is intended to promote interoperability. The reuse of EAP-MSCHAPv2/EAP-GTC EAP method IDs with different meaning and behavior inside the tunnel method might cause problems in some environments. If EAP-FAST were to be designed today, these difficulties could be avoided by the assignment of new EAP Type codes, which was more difficult before RFC 3748 defined expanded EAP Types. The reuse may cause problems in implementations where the use of unaltered methods is required. It also can make implementations that use methods both within and outside of the tunnel method more difficult, since this support requires special case execution of these methods within a tunnel. Given these issues, assigned method types must not be re-used with different meaning inside tunneled methods in the future." =20 Thanks, Nancy. =20 -----Original Message----- From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Jari Arkko Sent: Thursday, February 05, 2009 1:01 AM To: Bernard Aboba Cc: emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents Bernard, > c. EAP negotiation issues. Neither the IESG note nor the text=20 > explicitly states what is wrong with using an EAP Type Code for=20 > incompatible versions of an EAP method that does not support version=20 > negotiation. They should state this. > Indeed, it would appear that some > members of the IESG think that method overloading is required by EAP=20 > tunneling methods desiring to incorporate support for cryptographic=20 > binding. Not sure who you are referring to, but for the record I at least do not believe that. Cryptographic binding can clearly be achieved without overloading or re-definition of behaviour of existing components. > Saying that this "might be difficult > in some software environments" isn't a good characterization.=20 > Would the IESG use the same words to describe the reuse of IP protocol > numbers within an IP tunnel? I doubt it. I guess this referred to the difficulty of implementing the remedy where EAP within a tunnel is different from EAP outside the tunnel. In some cases this would be possible, in some other cases not... depending on what the software architecture, APIs, etc are. But in all cases it is painful, which is why this is a bad approach and should not be done by future methods. Jari _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu From glenzorn@comcast.net Thu Feb 5 19:49:59 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2E413A6987 for ; Thu, 5 Feb 2009 19:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.387 X-Spam-Level: X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fg+DdA5+14nx for ; Thu, 5 Feb 2009 19:49:58 -0800 (PST) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 6C9343A6953 for ; Thu, 5 Feb 2009 19:49:58 -0800 (PST) Received: from OMTA08.westchester.pa.mail.comcast.net ([76.96.62.12]) by QMTA03.westchester.pa.mail.comcast.net with comcast id CE471b07n0Fqzac53Tpz9N; Fri, 06 Feb 2009 03:49:59 +0000 Received: from gwzPC ([124.120.226.104]) by OMTA08.westchester.pa.mail.comcast.net with comcast id CTow1b00H2Fmdu43UTp6JA; Fri, 06 Feb 2009 03:49:30 +0000 From: "Glen Zorn" To: References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> <006c01c98781$5d6b8bf0$1842a3d0$@net> <808FD6E27AD4884E94820BC333B2DB7727E78F2B67@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E78F2B67@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 6 Feb 2009 10:48:52 +0700 Message-ID: <003201c9880d$e8160780$b8421680$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmG/lqa1KgpUF8USwKhyQk7NRQaiAAZKlqQAAcC4gAAAri40AAfzvPg Content-Language: en-us Cc: emu@ietf.org, iesg@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 03:49:59 -0000 Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] writes: > Glen Zorn wrote: > > > > I would like to remind everyone that these documents did go > > > through IETF Last Call, and have already been approved by IESG. > > > > Given the quality of the documents in question, perhaps that's not > > something that you should be bragging about... > > > > > If folks are opposed to publishing descriptions of deployed EAP > > > method when they're less than perfect (or even ugly hacks with bad > > > architecture), and may not offer perfect security in all > > > circumstances (but accurately document their limitations), they > > > should have said so much earlier. > > > > No offense, but I'm getting the real feeling that you're just not > > paying much attention. The major problems I've heard WRT > > publication as-is have to do with the misuse of IANA registries, not > > ugly hacks or "imperfect security". > > I am paying attention, thank you. Of the emails on emu@ietf.org about > EAP-FAST in the past month or so, less than half of the text seems to > be about re-using EAP-GTC/MSCHAPv2 type codes. Your first email (Jan > 27) mentions only anonymous provisioning (nothing about EAP type > codes), and your second message (Feb 3) first talks about the > insecurity of anonymous provisioning, and then about the EAP-GTC type > code. Indeed, my initial comments were admittedly more appropriate to the topic of an IESG note; the misuse of EAP type codes can't be fixed with a note, though. > > The EAP-GTC type code re-use is not a new concern; it was specifically > discussed before the IESG approved the document, and the discussion > resulted in changes in the document. As far as I can tell, this thread > has contained no new information about the topic. It seems you would > have preferred that IESG had reached a different decision back > then. That's a perfectly valid opinion, but the IETF Last Call > would have been the right time to express it. I just have to ask: if the purpose of IESG review is not to catch problems missed in IETF Last Call, what is it? > > For EAP-MSCHAPv2, I think there has been some new information that > wasn't really well considered before IESG approved the document. > IESG is proposing solving it basically the same way as for EAP-GTC -- > noting that this is bad design, and future design should not do it > this way. > > > > (In hindsight, publishing these via the RFC Editor independent > > > submission route, and including the vendor's name in the document > > > title, might have been better idea. Since the intent was to > > > describe what existing implementations do, the IETF does not > > > realistically have much change control...) > > > > Publishing them as individual submissions would have been a better > > idea I don't see how that would solve the IANA problem. > > BTW, you can look at this either as changing an existing code point, > or defining a field (an EAP-FAST TLV "Value" part) that contains > either protocol X (normal EAP header with IANA-allocated EAP Type > code) or protocol Y (some other stuff). > > Basically, the change that was made to draft-zhou-emu-fast-gtc says > "if this byte contains anything else than 0x06, interprete it as > normal EAP Header with IANA-allocated EAP Type number. If it contains > 0x06, interprete it as described below." (not using those words, but > that's the idea) > > When some field can contain either X or Y, normally we'd multiplex > them by having a separate "type" field outside the field itself. > That's the approach used in e.g. RFC5281, which changes MS-CHAPv2 > challenge processing in very similar way as draft-cam-winget-eap- > fast-provisioning. > > Another approach is to multiplex by "peeking inside the content"; > while this is usually less preferable, it's a choice the protocol > designer gets to make when defining a new field (and is used in > some IETF specs too; e.g. draft-ietf-avt-dtls-srtp). > > Choosing this approach to multiplexing the contents of this field > certainly was not a good design decision, and the proposed IESG text > basically says so (and warns that it probably doesn't exactly > simplify implementation either). Possibly one of the most important things I learned in college was what people _say_ most often has little to do with what they actually believe: to find out what people really believe you much look at their actions (OK, a simple but somewhat stronger variant of "actions speak louder than words" ;-). In this case, what the authors have done is ignore not just IETF process but the simplest rules of protocol design & what the IESG is proposing to _do_ is confirm that that's just fine. Your proposed note is essentially irrelevant. It might not be if it addressed the correct issues with the draft instead of rationalizing the misuse of type codes. > But I don't think it should alone > prevent publishing a description of somewhat widely implemented > protocol. OK, then change the numbers; doing so doesn't modify the the protocol at all. > > *IF* this caused interoperability problems for folks who don't > implement this specification (or between folks who do implement > this spec and those that don't), I'd be very worried indeed. > But that does not seem to be the case. > > Best regards, > Pasi From glenzorn@comcast.net Fri Feb 6 01:30:32 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CAEE3A6A05 for ; Fri, 6 Feb 2009 01:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du9UMXzT60No for ; Fri, 6 Feb 2009 01:30:28 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 7F29D3A6B18 for ; Fri, 6 Feb 2009 01:30:28 -0800 (PST) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA09.westchester.pa.mail.comcast.net with comcast id CZWX1b00316LCl059ZWXxe; Fri, 06 Feb 2009 09:30:31 +0000 Received: from gwzPC ([124.120.226.104]) by OMTA06.westchester.pa.mail.comcast.net with comcast id CZVi1b0082Fmdu43SZVrJ3; Fri, 06 Feb 2009 09:30:13 +0000 From: "Glen Zorn" To: "'Alan DeKok'" References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> In-Reply-To: <497D92A7.8080009@deployingradius.com> Date: Fri, 6 Feb 2009 16:29:24 +0700 Message-ID: <003d01c9883d$793fb290$6bbf17b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acl/oj4YtVrl0te/SvSaw0A9ZHGljwImj3VQ Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 09:30:32 -0000 Alan DeKok [mailto:aland@deployingradius.com] writes: > Dan Harkins wrote: > > A tunnel method is definitely in our charter and we have had much > > discussion on what that would look like. If you re-read the notes > from > > IETF 71 there was a long discussion about choosing an existing one to > > update and not necessarily rolling a new one from scratch. The > candidates > > sure seem to be TTLS and FAST, given the presentations on them we've > had. > > Discussing the applicability, cost, benefit, etc. of EAP-FAST is a > good idea. Re-visiting its architectural choices isn't something we > have time for. In other words, no technical review. OK, great, how about we just let the Cisco & Juniper marketing departments slug it out & let us know who wins? > > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From glenzorn@comcast.net Fri Feb 6 02:12:02 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7B813A6BB7 for ; Fri, 6 Feb 2009 02:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_22=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAj3uiI7pMYs for ; Fri, 6 Feb 2009 02:12:01 -0800 (PST) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id D9B2328C16D for ; Fri, 6 Feb 2009 02:11:58 -0800 (PST) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id Ca1i1b0030FhH24A6aC1bK; Fri, 06 Feb 2009 10:12:01 +0000 Received: from gwzPC ([124.120.226.104]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id CaBh1b0052Fmdu48UaBnjA; Fri, 06 Feb 2009 10:11:59 +0000 From: "Glen Zorn" To: "'Nancy Cam-Winget \(ncamwing\)'" , "'Jari Arkko'" , "'Bernard Aboba'" References: <498AAAE7.3010800@piuha.net> <08A9A3213527A6428774900A80DBD8D8086463ED@xmb-sjc-222.amer.cisco.com> In-Reply-To: <08A9A3213527A6428774900A80DBD8D8086463ED@xmb-sjc-222.amer.cisco.com> Date: Fri, 6 Feb 2009 17:11:09 +0700 Message-ID: <004101c98843$47592260$d60b6720$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmHcIKQxlZi9qBVQmy9UN/FkNbZzgAcBHDQABfV7vA= Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 10:12:02 -0000 > 2. The following text could be added either in the introduction or IANA > considerations (or anywhere the IESG prefers): > "EAP-FAST has been implemented by many vendors and it is used in the > Internet. Publication of this is intended to promote interoperability. > The reuse of EAP-MSCHAPv2/EAP-GTC EAP method IDs with different meaning > and behavior inside the tunnel method might cause problems in some > environments. If EAP-FAST were to be designed today, these > difficulties > could be avoided by the assignment of new EAP Type codes, which was > more > difficult before RFC 3748 defined expanded EAP Types. Uh-huh. The extremely onerous & time-consuming FC,FS allocation policy... > The reuse may > cause problems in implementations where the use of unaltered methods is > required. It also can make implementations that use methods both > within > and outside of the tunnel method more difficult, since this support > requires special case execution of these methods within a tunnel. > Given > these issues, assigned method types must not be re-used with different > meaning inside tunneled methods in the future." This is getting tiresome. Given your obvious & continuing disdain for both the recipients of your messages (do you think that nobody on this list ever requested an EAP Type code pre-3748?) & the IETF in general, combined with the poor quality of the documents themselves, I will have to agree with Dan's assertion & ask that these documents not be published & that the existing IANA registries be removed. I'm sure that Cisco's marketing department can continue its fine job of publicizing EAP-FAST & you can just run your very own registry of EAP-FAST numbers. > > Thanks, > Nancy. > > > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Jari Arkko > Sent: Thursday, February 05, 2009 1:01 AM > To: Bernard Aboba > Cc: emu@ietf.org > Subject: Re: [Emu] Potential Notes in EAP-FAST Documents > > Bernard, > > > c. EAP negotiation issues. Neither the IESG note nor the text > > explicitly states what is wrong with using an EAP Type Code for > > incompatible versions of an EAP method that does not support version > > negotiation. > > They should state this. > > > Indeed, it would appear that some > > members of the IESG think that method overloading is required by EAP > > tunneling methods desiring to incorporate support for cryptographic > > binding. > Not sure who you are referring to, but for the record I at least do not > believe that. Cryptographic binding can clearly be achieved without > overloading or re-definition of behaviour of existing components. > > > Saying that this "might be difficult > > in some software environments" isn't a good characterization. > > Would the IESG use the same words to describe the reuse of IP > protocol > > > numbers within an IP tunnel? I doubt it. > > I guess this referred to the difficulty of implementing the remedy > where > EAP within a tunnel is different from EAP outside the tunnel. In some > cases this would be possible, in some other cases not... depending on > what the software architecture, APIs, etc are. But in all cases it is > painful, which is why this is a bad approach and should not be done by > future methods. > > Jari > > _______________________________________________ > 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 aland@deployingradius.com Fri Feb 6 05:08:57 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F99828C210 for ; Fri, 6 Feb 2009 05:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dG8e6DUygQpU for ; Fri, 6 Feb 2009 05:08:56 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 5B43228C1E2 for ; Fri, 6 Feb 2009 05:08:56 -0800 (PST) Received: from Thor.local (alexander.quiconnect.net [213.30.156.62]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 30AA9123443D; Fri, 6 Feb 2009 14:08:57 +0100 (CET) Message-ID: <498C3668.1040604@deployingradius.com> Date: Fri, 06 Feb 2009 14:08:56 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Glen Zorn References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> In-Reply-To: <003d01c9883d$793fb290$6bbf17b0$@net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 13:08:57 -0000 Glen Zorn wrote: > Alan DeKok [mailto:aland@deployingradius.com] writes: >> Discussing the applicability, cost, benefit, etc. of EAP-FAST is a >> good idea. Re-visiting its architectural choices isn't something we >> have time for. > > In other words, no technical review. OK, great, how about we just let the > Cisco & Juniper marketing departments slug it out & let us know who wins? A technical review of EAP-FAST as it applies to the charter work items is relevant. This WG is also a reasonable place to discuss the status of the current EAP-FAST document. However, re-designing EAP-FAST is not on the charter of this WG. Alan DeKok. From yohba@tari.toshiba.com Fri Feb 6 12:25:37 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42EDD3A6C11 for ; Fri, 6 Feb 2009 12:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZOV7zGTgjJU for ; Fri, 6 Feb 2009 12:25:35 -0800 (PST) Received: from toshi17.tari.toshiba.com (unknown [IPv6:2001:418:1403:0:212:17ff:fe52:7811]) by core3.amsl.com (Postfix) with ESMTP id B2D543A6C09 for ; Fri, 6 Feb 2009 12:25:35 -0800 (PST) Received: from steelhead.localdomain (tarij-62.tari.toshiba.com [172.30.24.110]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id n16KLfLs007593; Fri, 6 Feb 2009 15:21:41 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.69) (envelope-from ) id 1LVXGC-0002cx-3w; Fri, 06 Feb 2009 15:25:12 -0500 Date: Fri, 6 Feb 2009 15:25:12 -0500 From: Yoshihiro Ohba To: "Nancy Cam-Winget (ncamwing)" Message-ID: <20090206202512.GJ5856@steelhead.localdomain> References: <498AAAE7.3010800@piuha.net> <08A9A3213527A6428774900A80DBD8D8086463ED@xmb-sjc-222.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <08A9A3213527A6428774900A80DBD8D8086463ED@xmb-sjc-222.amer.cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Bernard Aboba , emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Feb 2009 20:25:37 -0000 I think assigning a new EAP Type for an existing EAP method with different usages intended for a particular tunneling method is a bad idea. Can we avoid it? Since the Intended status of this draft is Informational, I think adding an IESG Note describing the issue recognized by the IESG may be ok. Thanks, Yoshihiro Ohba On Thu, Feb 05, 2009 at 02:27:39PM -0800, Nancy Cam-Winget (ncamwing) wrote: > Hi, > > Per the potential notes and given feedback thus far, we (the authors) > can address the relevant concerns with updates to the draft(s) as > follows: > > 1. Update the EAP-FAST provisioning draft to change EAP-MSCHAPv2 to > EAP-FAST-MSCHAPv2 throughout the document where the reference is to its > working inside the EAP-FAST tunnel during anonymous provisioning mode. > Also clarify the use of EAP-FAST-MSCHAPv2 during anonymous provisioning > in section 3.2.3 > > 2. The following text could be added either in the introduction or IANA > considerations (or anywhere the IESG prefers): > "EAP-FAST has been implemented by many vendors and it is used in the > Internet. Publication of this is intended to promote interoperability. > The reuse of EAP-MSCHAPv2/EAP-GTC EAP method IDs with different meaning > and behavior inside the tunnel method might cause problems in some > environments. If EAP-FAST were to be designed today, these difficulties > could be avoided by the assignment of new EAP Type codes, which was more > difficult before RFC 3748 defined expanded EAP Types. The reuse may > cause problems in implementations where the use of unaltered methods is > required. It also can make implementations that use methods both within > and outside of the tunnel method more difficult, since this support > requires special case execution of these methods within a tunnel. Given > these issues, assigned method types must not be re-used with different > meaning inside tunneled methods in the future." > > Thanks, > Nancy. > > > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Jari Arkko > Sent: Thursday, February 05, 2009 1:01 AM > To: Bernard Aboba > Cc: emu@ietf.org > Subject: Re: [Emu] Potential Notes in EAP-FAST Documents > > Bernard, > > > c. EAP negotiation issues. Neither the IESG note nor the text > > explicitly states what is wrong with using an EAP Type Code for > > incompatible versions of an EAP method that does not support version > > negotiation. > > They should state this. > > > Indeed, it would appear that some > > members of the IESG think that method overloading is required by EAP > > tunneling methods desiring to incorporate support for cryptographic > > binding. > Not sure who you are referring to, but for the record I at least do not > believe that. Cryptographic binding can clearly be achieved without > overloading or re-definition of behaviour of existing components. > > > Saying that this "might be difficult > > in some software environments" isn't a good characterization. > > Would the IESG use the same words to describe the reuse of IP protocol > > > numbers within an IP tunnel? I doubt it. > > I guess this referred to the difficulty of implementing the remedy where > EAP within a tunnel is different from EAP outside the tunnel. In some > cases this would be possible, in some other cases not... depending on > what the software architecture, APIs, etc are. But in all cases it is > painful, which is why this is a bad approach and should not be done by > future methods. > > Jari > > _______________________________________________ > 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 glenzorn@comcast.net Sat Feb 7 17:33:37 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52503A6CB0 for ; Sat, 7 Feb 2009 17:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaHonFHJPYt7 for ; Sat, 7 Feb 2009 17:33:36 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 462673A68D7 for ; Sat, 7 Feb 2009 17:33:35 -0800 (PST) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA09.westchester.pa.mail.comcast.net with comcast id D0zL1b00H0EZKEL59DZgeH; Sun, 08 Feb 2009 01:33:40 +0000 Received: from gwzPC ([124.120.225.79]) by OMTA01.westchester.pa.mail.comcast.net with comcast id DDZ41b00H1jQXF83MDZCEA; Sun, 08 Feb 2009 01:33:35 +0000 From: "Glen Zorn" To: "'Alan DeKok'" References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> <498C3668.1040604@deployingradius.com> In-Reply-To: <498C3668.1040604@deployingradius.com> Date: Sun, 8 Feb 2009 08:32:18 +0700 Message-ID: <000b01c9898d$27c4e920$774ebb60$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmIXBLEA9rF7UJhRPi+vtBlf/X7nwBMJ9wg Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 01:33:37 -0000 Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > Alan DeKok [mailto:aland@deployingradius.com] writes: > >> Discussing the applicability, cost, benefit, etc. of EAP-FAST is a > >> good idea. Re-visiting its architectural choices isn't something we > >> have time for. > > > > In other words, no technical review. OK, great, how about we just > let the > > Cisco & Juniper marketing departments slug it out & let us know who > wins? > > A technical review of EAP-FAST as it applies to the charter work > items > is relevant. This WG is also a reasonable place to discuss the status > of the current EAP-FAST document. However, re-designing EAP-FAST is > not > on the charter of this WG. > > Alan DeKok. From glenzorn@comcast.net Sat Feb 7 18:26:54 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1713A680D for ; Sat, 7 Feb 2009 18:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SluaDTTFbN9O for ; Sat, 7 Feb 2009 18:26:53 -0800 (PST) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by core3.amsl.com (Postfix) with ESMTP id 3CB613A67F9 for ; Sat, 7 Feb 2009 18:26:53 -0800 (PST) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id DDyf1b0091GXsucA3ESxmu; Sun, 08 Feb 2009 02:26:57 +0000 Received: from gwzPC ([124.120.225.79]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id DESf1b0061jQXF88TESk7T; Sun, 08 Feb 2009 02:26:55 +0000 From: "Glen Zorn" To: "'Alan DeKok'" References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> <498C3668.1040604@deployingradius.com> In-Reply-To: <498C3668.1040604@deployingradius.com> Date: Sun, 8 Feb 2009 09:25:53 +0700 Message-ID: <000c01c98994$9b1b6a00$d1523e00$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmIXBLEA9rF7UJhRPi+vtBlf/X7nwBMQdBg Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 02:26:54 -0000 Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > Alan DeKok [mailto:aland@deployingradius.com] writes: > >> Discussing the applicability, cost, benefit, etc. of EAP-FAST is a > >> good idea. Re-visiting its architectural choices isn't something we > >> have time for. > > > > In other words, no technical review. OK, great, how about we just > let the > > Cisco & Juniper marketing departments slug it out & let us know who > wins? > > A technical review of EAP-FAST as it applies to the charter work > items > is relevant. Thanks for the clarification. However, it's hard for me to understand how the architectural choices of EAP-FAST could be irrelevant to the charter work items. > This WG is also a reasonable place to discuss the status > of the current EAP-FAST document. However, re-designing EAP-FAST is > not > on the charter of this WG. OK, great. Just out of curiosity, though, would you mind explaining the criteria upon which these policies are based since EAP-FAST is not specifically mentioned anywhere in the charter? > > Alan DeKok. From aland@deployingradius.com Sat Feb 7 22:44:31 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0901B3A6D04 for ; Sat, 7 Feb 2009 22:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[AWL=0.859, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7alSf9Xt3YA for ; Sat, 7 Feb 2009 22:44:30 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 19B383A68E1 for ; Sat, 7 Feb 2009 22:44:30 -0800 (PST) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 6F4E6123444C; Sun, 8 Feb 2009 07:44:32 +0100 (CET) Message-ID: <498E7F4F.1030102@deployingradius.com> Date: Sun, 08 Feb 2009 07:44:31 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Glen Zorn References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> <498C3668.1040604@deployingradius.com> <000c01c98994$9b1b6a00$d1523e00$@net> In-Reply-To: <000c01c98994$9b1b6a00$d1523e00$@net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 06:44:31 -0000 Glen Zorn wrote: >> A technical review of EAP-FAST as it applies to the charter work >> items >> is relevant. > > Thanks for the clarification. However, it's hard for me to understand how > the architectural choices of EAP-FAST could be irrelevant to the charter > work items. They are not irrelevant. See below. >> This WG is also a reasonable place to discuss the status >> of the current EAP-FAST document. However, re-designing EAP-FAST is >> not >> on the charter of this WG. > > OK, great. Just out of curiosity, though, would you mind explaining the > criteria upon which these policies are based since EAP-FAST is not > specifically mentioned anywhere in the charter? The charter requires us to extend an existing TLS-based tunneled method. Hence the tunneled requirements draft. Both EAP-TTLS and EAP-FAST have been proposed as choices for the tunneled method. One or the other may have particular architectural choices that prevents it from satisfying the tunneled requirements. In that case, those architectural choices would be relevant. Architectural choices that are "unusual", but which also do not impact the methods ability to satisfy the tunnel requirements are out of scope of the charter. They can be discussed here with respect to the EAP-FAST documents && the current IESG review, but they should have no impact on the choice of tunneled method. Alan DeKok. From dharkins@lounge.org Sat Feb 7 23:00:33 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46E23A6A6B for ; Sat, 7 Feb 2009 23:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.257 X-Spam-Level: X-Spam-Status: No, score=-2.257 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyzrRRb3NWxK for ; Sat, 7 Feb 2009 23:00:32 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id E2D1D3A695E for ; Sat, 7 Feb 2009 23:00:32 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 04B41A888108; Sat, 7 Feb 2009 23:00:34 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 7 Feb 2009 23:00:35 -0800 (PST) Message-ID: In-Reply-To: <498E7F4F.1030102@deployingradius.com> References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> <498C3668.1040604@deployingradius.com> <000c01c98994$9b1b6a00$d1523e00$@net> <498E7F4F.1030102@deployingradius.com> Date: Sat, 7 Feb 2009 23:00:35 -0800 (PST) From: "Dan Harkins" To: "Alan DeKok" 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] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 07:00:33 -0000 Hi Alan, On Sat, February 7, 2009 10:44 pm, Alan DeKok wrote: > Glen Zorn wrote: >>> A technical review of EAP-FAST as it applies to the charter work >>> items >>> is relevant. >> >> Thanks for the clarification. However, it's hard for me to understand >> how >> the architectural choices of EAP-FAST could be irrelevant to the charter >> work items. > > They are not irrelevant. See below. > >>> This WG is also a reasonable place to discuss the status >>> of the current EAP-FAST document. However, re-designing EAP-FAST is >>> not >>> on the charter of this WG. >> >> OK, great. Just out of curiosity, though, would you mind explaining the >> criteria upon which these policies are based since EAP-FAST is not >> specifically mentioned anywhere in the charter? > > The charter requires us to extend an existing TLS-based tunneled > method. Hence the tunneled requirements draft. > > Both EAP-TTLS and EAP-FAST have been proposed as choices for the > tunneled method. One or the other may have particular architectural > choices that prevents it from satisfying the tunneled requirements. In > that case, those architectural choices would be relevant. > > Architectural choices that are "unusual", but which also do not impact > the methods ability to satisfy the tunnel requirements are out of scope > of the charter. They can be discussed here with respect to the EAP-FAST > documents && the current IESG review, but they should have no impact on > the choice of tunneled method. What if some architectural decision(s) make(s) one worse than the other as a tunneled method of choice, even though _technically_ they both satisfy the requirements? Are we forbidden from discussing that? If it comes down to a beauty contest, we're only allowed to discuss whether both contestants for Miss EMU are technically female but not whether one is a gimp hunchback with worts? Dan. From glenzorn@comcast.net Sat Feb 7 23:27:37 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5CF43A6A6B for ; Sat, 7 Feb 2009 23:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMDUERMr4WIt for ; Sat, 7 Feb 2009 23:27:36 -0800 (PST) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id C71203A63D2 for ; Sat, 7 Feb 2009 23:27:36 -0800 (PST) Received: from OMTA08.emeryville.ca.mail.comcast.net ([76.96.30.12]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id DKPL1b0080FhH24A1KThxD; Sun, 08 Feb 2009 07:27:41 +0000 Received: from gwzPC ([124.120.225.79]) by OMTA08.emeryville.ca.mail.comcast.net with comcast id DKTM1b00A1jQXF88UKTVj5; Sun, 08 Feb 2009 07:27:39 +0000 From: "Glen Zorn" To: "'Alan DeKok'" References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> <498C3668.1040604@deployingradius.com> <000c01c98994$9b1b6a00$d1523e00$@net> <498E7F4F.1030102@deployingradius.com> In-Reply-To: <498E7F4F.1030102@deployingradius.com> Date: Sun, 8 Feb 2009 14:26:34 +0700 Message-ID: <001901c989be$9d163680$d742a380$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmJuLPINN+wPA+4TgyjYvN6UwmHMgABJnLw Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 07:27:37 -0000 Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > >> A technical review of EAP-FAST as it applies to the charter work > >> items > >> is relevant. > > > > Thanks for the clarification. However, it's hard for me to > understand how > > the architectural choices of EAP-FAST could be irrelevant to the > charter > > work items. > > They are not irrelevant. See below. > > >> This WG is also a reasonable place to discuss the status > >> of the current EAP-FAST document. However, re-designing EAP-FAST is > >> not > >> on the charter of this WG. > > > > OK, great. Just out of curiosity, though, would you mind explaining > the > > criteria upon which these policies are based since EAP-FAST is not > > specifically mentioned anywhere in the charter? > > The charter requires us to extend an existing TLS-based tunneled > method. I can't see that in the charter. This is what it says (in part): - Enable TLS-based EAP methods to support channel bindings. This item will not generate a new method; rather, it will focus on adding support for EAP channel bindings to the tunneled method (described below), and if possible, other TLS-based EAP methods. Potential mechanisms for adding channel binding support will be investigated, including tunneling of channel binding parameters, or a TLS extension, or other standard TLS mechanism - A mechanism to support extensible communication within a TLS protected tunnel. This mechanism will support meeting the requirements of an enhanced TLS mechanism, a password based authentication mechanism, and additional inner authentication mechanisms. It will also support channel bindings (as described above) in order to meet RFC 4962 requirements. Note that while it does say that the enabling of support for channel bindings will not generate a new method it says nothing of the sort about the tunneled method itself, > Hence the tunneled requirements draft. > > Both EAP-TTLS and EAP-FAST have been proposed as choices for the > tunneled method. Although their promoters have (apparently quite effectively ;-) positioned the question as a choice between EAP-TTLS & EAP-FAST, I can find nothing in the charter that actually requires us to take that path. > One or the other may have particular architectural > choices that prevents it from satisfying the tunneled requirements. In > that case, those architectural choices would be relevant. > > Architectural choices that are "unusual", but which also do not > impact > the methods ability to satisfy the tunnel requirements are out of scope > of the charter. They can be discussed here with respect to the EAP- > FAST > documents && the current IESG review, but they should have no impact on > the choice of tunneled method. > > Alan DeKok. From aland@deployingradius.com Sat Feb 7 23:43:47 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48F03A67EA for ; Sat, 7 Feb 2009 23:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=0.835, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlGdoqtzgHyi for ; Sat, 7 Feb 2009 23:43:47 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 270DD3A67D8 for ; Sat, 7 Feb 2009 23:43:47 -0800 (PST) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 81994123444C; Sun, 8 Feb 2009 08:43:50 +0100 (CET) Message-ID: <498E8D36.7070709@deployingradius.com> Date: Sun, 08 Feb 2009 08:43:50 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Dan Harkins References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> <498C3668.1040604@deployingradius.com> <000c01c98994$9b1b6a00$d1523e00$@net> <498E7F4F.1030102@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 07:43:48 -0000 Dan Harkins wrote: > What if some architectural decision(s) make(s) one worse than the other > as a tunneled method of choice, even though _technically_ they both > satisfy the requirements? Are we forbidden from discussing that? No. > If it comes down to a beauty contest, we're only allowed to discuss > whether both contestants for Miss EMU are technically female but not > whether one is a gimp hunchback with worts? Ease of implementation and deployment is one useful criteria out of many. Alan DeKok. From aland@deployingradius.com Sat Feb 7 23:47:08 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F813A67EE for ; Sat, 7 Feb 2009 23:47:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.786 X-Spam-Level: X-Spam-Status: No, score=-1.786 tagged_above=-999 required=5 tests=[AWL=0.813, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChFBLX3K6gSZ for ; Sat, 7 Feb 2009 23:47:08 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 271A53A63D2 for ; Sat, 7 Feb 2009 23:47:08 -0800 (PST) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 861ED123444C; Sun, 8 Feb 2009 08:47:11 +0100 (CET) Message-ID: <498E8DFE.3040806@deployingradius.com> Date: Sun, 08 Feb 2009 08:47:10 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Glen Zorn References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> <498C3668.1040604@deployingradius.com> <000c01c98994$9b1b6a00$d1523e00$@net> <498E7F4F.1030102@deployingradius.com> <001901c989be$9d163680$d742a380$@net> In-Reply-To: <001901c989be$9d163680$d742a380$@net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 07:47:09 -0000 Glen Zorn wrote: > Note that while it does say that the enabling of support for channel > bindings will not generate a new method it says nothing of the sort about > the tunneled method itself, Yes. >> Both EAP-TTLS and EAP-FAST have been proposed as choices for the >> tunneled method. > > Although their promoters have (apparently quite effectively ;-) positioned > the question as a choice between EAP-TTLS & EAP-FAST, I can find nothing in > the charter that actually requires us to take that path. We discuss what has been proposed. If there is another TLS-based EAP method that should be included in the above list, feel free to propose it. Until another method is proposed, and/or a more in-depth review happens, the TLS-based EAP methods that *may* satisfy the tunnel requirements are currently TTLS and FAST. I encourage people to review the EAP methods against the tunnel requirements document. Alan DeKok. From glenzorn@comcast.net Sun Feb 8 00:03:18 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0657D3A6CC6 for ; Sun, 8 Feb 2009 00:03:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReAwhrdj6-Tr for ; Sun, 8 Feb 2009 00:03:17 -0800 (PST) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 398A73A66B4 for ; Sun, 8 Feb 2009 00:03:17 -0800 (PST) Received: from OMTA12.emeryville.ca.mail.comcast.net ([76.96.30.44]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id DKyQ1b0080x6nqcA9L3MHy; Sun, 08 Feb 2009 08:03:21 +0000 Received: from gwzPC ([124.120.225.79]) by OMTA12.emeryville.ca.mail.comcast.net with comcast id DL321b00G1jQXF88YL38MR; Sun, 08 Feb 2009 08:03:19 +0000 From: "Glen Zorn" To: "'Alan DeKok'" References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> <498C3668.1040604@deployingradius.com> <000c01c98994$9b1b6a00$d1523e00$@net> <498E7F4F.1030102@deployingradius.com> <001901c989be$9d163680$d742a380$@net> <498E8DFE.3040806@deployingradius.com> In-Reply-To: <498E8DFE.3040806@deployingradius.com> Date: Sun, 8 Feb 2009 15:02:14 +0700 Message-ID: <001a01c989c3$98bbead0$ca33c070$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmJwXRSsN5N6uY8Q9C7iUd18cseWAAAahbw Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 08:03:18 -0000 Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > > Note that while it does say that the enabling of support for channel > > bindings will not generate a new method it says nothing of the sort > about > > the tunneled method itself, > > Yes. > > >> Both EAP-TTLS and EAP-FAST have been proposed as choices for the > >> tunneled method. > > > > Although their promoters have (apparently quite effectively ;-) > positioned > > the question as a choice between EAP-TTLS & EAP-FAST, I can find > nothing in > > the charter that actually requires us to take that path. > > We discuss what has been proposed. If there is another TLS-based EAP > method that should be included in the above list, feel free to propose > it. This thread is not about what is being discussed or proposed, it's about what the charter says. ... From aland@deployingradius.com Sun Feb 8 00:42:11 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BD9F3A6D29 for ; Sun, 8 Feb 2009 00:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.808 X-Spam-Level: X-Spam-Status: No, score=-1.808 tagged_above=-999 required=5 tests=[AWL=0.791, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60eX++xjwMnR for ; Sun, 8 Feb 2009 00:42:10 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id B61093A6CCE for ; Sun, 8 Feb 2009 00:42:10 -0800 (PST) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id BBF76123444C; Sun, 8 Feb 2009 09:42:13 +0100 (CET) Message-ID: <498E9AE5.4020005@deployingradius.com> Date: Sun, 08 Feb 2009 09:42:13 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Glen Zorn References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> <498C3668.1040604@deployingradius.com> <000c01c98994$9b1b6a00$d1523e00$@net> <498E7F4F.1030102@deployingradius.com> <001901c989be$9d163680$d742a380$@net> <498E8DFE.3040806@deployingradius.com> <001a01c989c3$98bbead0$ca33c070$@net> In-Reply-To: <001a01c989c3$98bbead0$ca33c070$@net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Feb 2009 08:42:11 -0000 Glen Zorn wrote: >> We discuss what has been proposed. If there is another TLS-based EAP >> method that should be included in the above list, feel free to propose >> it. > > This thread is not about what is being discussed or proposed, it's about > what the charter says. The charter does not require us to choose a particular method. Alan DeKok. From glenzorn@comcast.net Sun Feb 8 20:20:56 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D56E3A6898 for ; Sun, 8 Feb 2009 20:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.398 X-Spam-Level: X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6Owpe-FEnJa for ; Sun, 8 Feb 2009 20:20:55 -0800 (PST) Received: from QMTA02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [76.96.30.24]) by core3.amsl.com (Postfix) with ESMTP id 12B7D3A67A3 for ; Sun, 8 Feb 2009 20:20:54 -0800 (PST) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id Deyz1b03E0S2fkCA2gM0aD; Mon, 09 Feb 2009 04:21:00 +0000 Received: from gwzPC ([124.120.222.28]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id DgLg1b00N0dNKQk8VgLmWD; Mon, 09 Feb 2009 04:20:58 +0000 From: "Glen Zorn" To: "'Alan DeKok'" References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> <498C3668.1040604@deployingradius.com> <000c01c98994$9b1b6a00$d1523e00$@net> <498E7F4F.1030102@deployingradius.com> <001901c989be$9d163680$d742a380$@net> <498E8DFE.3040806@deployingradius.com> <001a01c989c3$98bbead0$ca33c070$@net> <498E9AE5.4020005@deployingradius.com> In-Reply-To: <498E9AE5.4020005@deployingradius.com> Date: Mon, 9 Feb 2009 11:19:45 +0700 Message-ID: <001001c98a6d$aed14b30$0c73e190$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmJySZBCq2qYbbqSyqViE/VBxyZswAPESmg Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 04:20:56 -0000 Alan DeKok [mailto:aland@deployingradius.com] writes: > Glen Zorn wrote: > >> We discuss what has been proposed. If there is another TLS-based > EAP > >> method that should be included in the above list, feel free to > propose > >> it. > > > > This thread is not about what is being discussed or proposed, it's > about > > what the charter says. > > The charter does not require us to choose a particular method. The point is that you stated that the charter "requires us to extend an existing TLS-based tunneled method" when in fact it does nothing of the sort. Either this was just an error that for some reason you refuse to admit or you and Joe are interpreting the charter to mean that. Such interpretation is w/i your purview as WG Chairs but since it is at least unobvious, a non-null rationale would be appreciated. > > Alan DeKok. From aland@deployingradius.com Sun Feb 8 23:30:14 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A73E3A6827 for ; Sun, 8 Feb 2009 23:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36C8x7Y5e-vN for ; Sun, 8 Feb 2009 23:30:14 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id D2DE23A6A8B for ; Sun, 8 Feb 2009 23:30:13 -0800 (PST) Received: from Thor.local (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 505E8123444C; Mon, 9 Feb 2009 08:30:17 +0100 (CET) Message-ID: <498FDB89.5060300@deployingradius.com> Date: Mon, 09 Feb 2009 08:30:17 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Glen Zorn References: <497A4B3F.3020600@open1x.org> <497C24CF.6080206@deployingradius.com> <497D92A7.8080009@deployingradius.com> <003d01c9883d$793fb290$6bbf17b0$@net> <498C3668.1040604@deployingradius.com> <000c01c98994$9b1b6a00$d1523e00$@net> <498E7F4F.1030102@deployingradius.com> <001901c989be$9d163680$d742a380$@net> <498E8DFE.3040806@deployingradius.com> <001a01c989c3$98bbead0$ca33c070$@net> <498E9AE5.4020005@deployingradius.com> <001001c98a6d$aed14b30$0c73e190$@net> In-Reply-To: <001001c98a6d$aed14b30$0c73e190$@net> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] Potential Issues with EAP-FAST X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2009 07:30:14 -0000 Glen Zorn wrote: > The point is that you stated that the charter "requires us to extend an > existing TLS-based tunneled method" when in fact it does nothing of the > sort. Either this was just an error that for some reason you refuse to > admit or you and Joe are interpreting the charter to mean that. Such > interpretation is w/i your purview as WG Chairs but since it is at least > unobvious, a non-null rationale would be appreciated. You are free to propose *any* TLS-based EAP method that satisfies the tunneled requirements document. This includes new methods of your own invention. So far, only TTLS and FAST have been discussed. In the absence of additional proposals, we will likely be extending an existing method. Alan DeKok. From yaronf@checkpoint.com Tue Feb 10 13:30:04 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F07F28C20D for ; Tue, 10 Feb 2009 13:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiLqAJa7-VsY for ; Tue, 10 Feb 2009 13:30:03 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id BC1DC28C1FF for ; Tue, 10 Feb 2009 13:30:02 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9682A29C006; Tue, 10 Feb 2009 22:36:47 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 99AB929C002 for ; Tue, 10 Feb 2009 22:36:46 +0200 (IST) X-CheckPoint: {4991E507-10000-88241DC2-7B6} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n1AKajv3016484 for ; Tue, 10 Feb 2009 22:36:46 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 10 Feb 2009 22:36:45 +0200 From: Yaron Sheffer To: "emu@ietf.org" Date: Tue, 10 Feb 2009 22:36:42 +0200 Thread-Topic: I-D Action:draft-sheffer-emu-eap-eke-01.txt Thread-Index: AcmLlp6I9ML7vVgTR7SDkNI56veFlgAJ98qg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D98157DDC0@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Emu] FW: I-D Action:draft-sheffer-emu-eap-eke-01.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Feb 2009 21:30:04 -0000 Hi everyone, We have just published a new version of the EAP-EKE draft, closing a vulner= ability that was discovered on CFRG. I hope everyone has had enough EAP-FAS= T bashing for a while (:-) and can give our protocol some bashing, too. Thanks, Yaron -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, February 10, 2009 12:45 To: i-d-announce@ietf.org Subject: I-D Action:draft-sheffer-emu-eap-eke-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : An EAP Authentication Method Based on the EKE Pro= tocol Author(s) : Y. Sheffer, et al. Filename : draft-sheffer-emu-eap-eke-01.txt Pages : 24 Date : 2009-02-10 The Extensible Authentication Protocol (EAP) describes a framework that allows the use of multiple authentication mechanisms. This document defines an authentication mechanism for EAP called EAP-EKE, based on the Encrypted Key Exchange (EKE) protocol. This method provides mutual authentication through the use of a short, easy to remember password. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sheffer-emu-eap-eke-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Email secured by Check Point From tim.polk@nist.gov Wed Feb 11 06:25:28 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5E6828C0EB; Wed, 11 Feb 2009 06:25:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6myclH-rfmhb; Wed, 11 Feb 2009 06:25:28 -0800 (PST) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id CBBB028C0CE; Wed, 11 Feb 2009 06:25:27 -0800 (PST) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id n1BEPXos004866; Wed, 11 Feb 2009 09:25:35 -0500 In-Reply-To: <003201c9880d$e8160780$b8421680$@net> References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> <006c01c98781$5d6b8bf0$1842a3d0$@net> <808FD6E27AD4884E94820BC333B2DB7727E78F2B67@NOK-EUMSG-01.mgdnok.nokia.com> <003201c9880d$e8160780$b8421680$@net> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tim Polk Date: Wed, 11 Feb 2009 09:26:14 -0500 To: emu@ietf.org X-Mailer: Apple Mail (2.753.1) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov Cc: "iesg@ietf.org IESG" Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 14:25:29 -0000 Folks, As the AD that sponsored publication of the EAP-FAST documents under discussion, I have been trying to find the best way forward. I believe that the best course of action involves some clarifications to draft-cam-winget-eap-fast- provisioning to distinguish the modified and unmodified use of EAP-MSCHAPv2, and IESG notes to ensure these publications do not establish precedent for future reuse of EAP type codes with different semantics. First, I support revising draft-cam-winget-eap-fast-provisioning so that the modified form of EAP-MSCHAPv2 is consistently referred to as EAP-FAST- MSCHAPv2. The authors offered to make this change earlier in the thread, and I have seen some support and no opposition to this suggestion. Second, I will be offering the following text for IESG notes on both documents. The notes clearly state the drawbacks for EAP type code reuse and define an acceptable path for future protocol developers. ------ draft-cam-winget-eap-fast-provisioning ----- EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this specification is intended to promote interoperability by documenting current use of existing EAP methods within EAP-FAST. The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code assigned to EAP-MSCHAPv2 (26) for authentication within an anonymous TLS tunnel. In order to minimize the risk associated with an anonymous tunnel, changes to the method were made that are not interoperable with EAP- MSCHAPv2. Since EAP-MSCHAPv2 does not support method-specific version negotiation, the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous EAP-FAST tunnel. This behavior may cause problems in implementations where the use of unaltered EAP-MSCHAPv2 is needed inside an anonymous EAP-FAST tunnel. Since such support requires special case execution of a method within a tunnel, it also complicates implementations that use the same method code both within and outside of the tunnel method. If EAP-FAST were to be designed today, these difficulties could be avoided by utilization of unique EAP Type codes. Given these issues, assigned method types must not be re-used with different meaning inside tunneled methods in the future. ---- draft-zhou-emu-fast-gtc ------ EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this specification is intended to promote interoperability by documenting current use of existing EAP methods within EAP-FAST. The EAP method EAP-FAST-GTC reuses the EAP type code assigned to EAP-GTC (6). The reuse of previously assigned EAP Type Codes is incompatible with EAP method negotiation as defined in RFC 3748. Since EAP-GTC does not support method-specific version negotiation, the use of EAP-FAST-GTC is implied when used inside the EAP-FAST tunnel during authentication. This behavior may cause problems in implementations where the use of another vendor's EAP-GTC is required. Since such support requires special case execution of a method within a tunnel, it also complicates implementations that use the same method code both within and outside of the tunnel method. If EAP-FAST were to be designed today, these difficulties could be avoided by utilization of unique EAP Type codes. Given these issues, assigned method types must not be re-used with different meaning inside tunneled methods in the future. I am not under the illusion that this text will be entirely satisfactory to anyone, but I believe that it is an *appropriate* resolution to the problem. Thanks, Tim Polk From g_e_montenegro@yahoo.com Wed Feb 11 10:21:34 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4454D3A6A24 for ; Wed, 11 Feb 2009 10:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV8HDJldgEFm for ; Wed, 11 Feb 2009 10:21:34 -0800 (PST) Received: from web82606.mail.mud.yahoo.com (web82606.mail.mud.yahoo.com [68.142.201.123]) by core3.amsl.com (Postfix) with SMTP id 059463A680E for ; Wed, 11 Feb 2009 10:21:30 -0800 (PST) Received: (qmail 36479 invoked by uid 60001); 11 Feb 2009 18:14:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=bgPKUDq6wU5vd3AvRR8P0NUkAofRY4zeNUUlVM+yKtUINuD75fxS0s18XsppRUNI7sRdKZLQ9j69Q8TAR3TebK+47XGggG2sUJ9uxIo7QGox7+WfIfnAaM5d0L/gZvFTm5xIJdyLeyRPCVxQeLh0vtWSEvkkrqzZzNKfiB/Mo8I=; X-YMail-OSG: gugvQ5MVM1lUYH46yRNS8QbljnVYB.epXAq7rJ4o.5JM43oG369m05OhziTxlg.WZOlN9.RZ_RTloArAqmGYAf2.sOPiq8epkRefyTF4N7QYko0JS19_nNkmDFYB3HhuUbRGb3fFUZZBPMq3DSYsKmcSH4pprk2mnd_U_Hj1ivvh8TKqrl5i9goXsG9ZRZsPFD1V3YIGq0Ya Received: from [24.16.92.42] by web82606.mail.mud.yahoo.com via HTTP; Wed, 11 Feb 2009 10:14:55 PST X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> <006c01c98781$5d6b8bf0$1842a3d0$@net> <808FD6E27AD4884E94820BC333B2DB7727E78F2B67@NOK-EUMSG-01.mgdnok.nokia.com> <003201c9880d$e8160780$b8421680$@net> Date: Wed, 11 Feb 2009 10:14:55 -0800 (PST) From: gabriel montenegro To: Tim Polk , emu@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <899331.35411.qm@web82606.mail.mud.yahoo.com> Cc: "iesg@ietf.orgIESG" Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 18:21:34 -0000 This looks like a good resolution. Thanks Tim. Gabriel ----- Original Message ---- > From: Tim Polk > To: emu@ietf.org > Cc: "iesg@ietf.org IESG" > Sent: Wednesday, February 11, 2009 6:26:14 AM > Subject: Re: [Emu] Potential Notes in EAP-FAST Documents > > Folks, > > As the AD that sponsored publication of the EAP-FAST documents under discussion, > I have been trying to find the best way forward. I believe that the best course > of action > involves some clarifications to draft-cam-winget-eap-fast-provisioning to > distinguish > the modified and unmodified use of EAP-MSCHAPv2, and IESG notes to ensure these > publications do not establish precedent for future reuse of EAP type codes with > different semantics. > > First, I support revising draft-cam-winget-eap-fast-provisioning so that the > modified > form of EAP-MSCHAPv2 is consistently referred to as EAP-FAST-MSCHAPv2. The > authors offered to make this change earlier in the thread, and I have seen some > support and no opposition to this suggestion. > > Second, I will be offering the following text for IESG notes on both documents. > The > notes clearly state the drawbacks for EAP type code reuse and define an > acceptable > path for future protocol developers. > > ------ draft-cam-winget-eap-fast-provisioning ----- > > EAP-FAST has been implemented by many vendors and it is used in the > Internet. Publication of this specification is intended to promote > interoperability by documenting current use of existing EAP methods > within EAP-FAST. > > The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code assigned to > EAP-MSCHAPv2 (26) for authentication within an anonymous TLS tunnel. In > order to minimize the risk associated with an anonymous tunnel, changes > to the method were made that are not interoperable with EAP-MSCHAPv2. > Since EAP-MSCHAPv2 does not support method-specific version negotiation, > the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous > EAP-FAST tunnel. This behavior may cause problems in implementations > where the use of unaltered EAP-MSCHAPv2 is needed inside an anonymous > EAP-FAST tunnel. Since such support requires special case execution of > a method within a tunnel, it also complicates implementations that use > the same method code both within and outside of the tunnel method. If > EAP-FAST were to be designed today, these difficulties could be avoided > by utilization of unique EAP Type codes. Given these issues, assigned > method types must not be re-used with different meaning inside tunneled > methods in the future. > > ---- draft-zhou-emu-fast-gtc ------ > > EAP-FAST has been implemented by many vendors and it is used in the > Internet. Publication of this specification is intended to promote > interoperability by documenting current use of existing EAP methods > within EAP-FAST. > > The EAP method EAP-FAST-GTC reuses the EAP type code assigned to > EAP-GTC (6). The reuse of previously assigned EAP Type Codes is > incompatible with EAP method negotiation as defined in RFC 3748. Since > EAP-GTC does not support method-specific version negotiation, the use of > EAP-FAST-GTC is implied when used inside the EAP-FAST tunnel during > authentication. This behavior may cause problems in implementations where > the use of another vendor's EAP-GTC is required. Since such support > requires > special case execution of a method within a tunnel, it also complicates > implementations that use the same method code both within and outside of > the tunnel method. If EAP-FAST were to be designed today, these > difficulties could be avoided by utilization of unique EAP Type codes. > Given these issues, assigned method types must not be re-used with > different meaning inside tunneled methods in the future. > > I am not under the illusion that this text will be entirely satisfactory to > anyone, > but I believe that it is an *appropriate* resolution to the problem. > > Thanks, > > Tim Polk > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From bernard_aboba@hotmail.com Wed Feb 11 10:25:26 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E9373A6D1F for ; Wed, 11 Feb 2009 10:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzTXN5g0yMcp for ; Wed, 11 Feb 2009 10:25:16 -0800 (PST) Received: from blu0-omc3-s38.blu0.hotmail.com (blu0-omc3-s38.blu0.hotmail.com [65.55.116.113]) by core3.amsl.com (Postfix) with ESMTP id C8D953A6D29 for ; Wed, 11 Feb 2009 10:25:15 -0800 (PST) Received: from BLU137-W38 ([65.55.116.73]) by blu0-omc3-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 10:25:20 -0800 Message-ID: X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: Date: Wed, 11 Feb 2009 10:25:20 -0800 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Feb 2009 18:25:20.0730 (UTC) FILETIME=[18D34BA0:01C98C76] Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 18:25:27 -0000 Tim -- This works for me.=20 Thanks (to you and other members of the IESG) for putting in the time to ge= t this right.=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Folks=2C As the AD that sponsored publication of the EAP-FAST documents under =20 discussion=2C I have been trying to find the best way forward. I believe that the =20 best course of action involves some clarifications to draft-cam-winget-eap-fast-=20 provisioning to distinguish the modified and unmodified use of EAP-MSCHAPv2=2C and IESG notes to =20 ensure these publications do not establish precedent for future reuse of EAP type =20 codes with different semantics. First=2C I support revising draft-cam-winget-eap-fast-provisioning so =20 that the modified form of EAP-MSCHAPv2 is consistently referred to as EAP-FAST-=20 MSCHAPv2. The authors offered to make this change earlier in the thread=2C and I have =20 seen some support and no opposition to this suggestion. Second=2C I will be offering the following text for IESG notes on both =20 documents. The notes clearly state the drawbacks for EAP type code reuse and define =20 an acceptable path for future protocol developers. ------ draft-cam-winget-eap-fast-provisioning ----- EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this specification is intended to promote interoperability by documenting current use of existing EAP methods within EAP-FAST. The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code =20 assigned to EAP-MSCHAPv2 (26) for authentication within an anonymous TLS =20 tunnel. In order to minimize the risk associated with an anonymous tunnel=2C =20 changes to the method were made that are not interoperable with EAP-=20 MSCHAPv2. Since EAP-MSCHAPv2 does not support method-specific version =20 negotiation=2C the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous EAP-FAST tunnel. This behavior may cause problems in =20 implementations where the use of unaltered EAP-MSCHAPv2 is needed inside an =20 anonymous EAP-FAST tunnel. Since such support requires special case =20 execution of a method within a tunnel=2C it also complicates implementations =20 that use the same method code both within and outside of the tunnel =20 method. If EAP-FAST were to be designed today=2C these difficulties could be =20 avoided by utilization of unique EAP Type codes. Given these issues=2C =20 assigned method types must not be re-used with different meaning inside =20 tunneled methods in the future. ---- draft-zhou-emu-fast-gtc ------ EAP-FAST has been implemented by many vendors and it is used in the Internet. Publication of this specification is intended to promote interoperability by documenting current use of existing EAP methods within EAP-FAST. The EAP method EAP-FAST-GTC reuses the EAP type code assigned to EAP-GTC (6). The reuse of previously assigned EAP Type Codes is incompatible with EAP method negotiation as defined in RFC =20 3748. Since EAP-GTC does not support method-specific version negotiation=2C =20 the use of EAP-FAST-GTC is implied when used inside the EAP-FAST tunnel during authentication. This behavior may cause problems in =20 implementations where the use of another vendor's EAP-GTC is required. Since such =20 support requires special case execution of a method within a tunnel=2C it also =20 complicates implementations that use the same method code both within and =20 outside of the tunnel method. If EAP-FAST were to be designed today=2C these difficulties could be avoided by utilization of unique EAP Type =20 codes. Given these issues=2C assigned method types must not be re-used with different meaning inside tunneled methods in the future. I am not under the illusion that this text will be entirely =20 satisfactory to anyone=2C but I believe that it is an *appropriate* resolution to the problem. Thanks=2C Tim Polk From j@w1.fi Wed Feb 11 12:13:27 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94133A6C08; Wed, 11 Feb 2009 12:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6McVF7TzfjRi; Wed, 11 Feb 2009 12:13:27 -0800 (PST) Received: from jmalinen.user.openhosting.com (128-177-27-249.ip.openhosting.com [128.177.27.249]) by core3.amsl.com (Postfix) with ESMTP id F1AE13A6B0B; Wed, 11 Feb 2009 12:13:26 -0800 (PST) Received: from jm (a91-155-82-88.elisa-laajakaista.fi [91.155.82.88]) (authenticated bits=0) by jmalinen.user.openhosting.com (8.13.8/8.13.8) with ESMTP id n1BKDJKO031777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 15:13:20 -0500 Received: by jm (sSMTP sendmail emulation); Wed, 11 Feb 2009 22:13:20 +0200 Date: Wed, 11 Feb 2009 22:13:20 +0200 From: Jouni Malinen To: Tim Polk Message-ID: <20090211201320.GA22148@jm.kir.nu> References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> <006c01c98781$5d6b8bf0$1842a3d0$@net> <808FD6E27AD4884E94820BC333B2DB7727E78F2B67@NOK-EUMSG-01.mgdnok.nokia.com> <003201c9880d$e8160780$b8421680$@net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: emu@ietf.org, "iesg@ietf.org IESG" Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 20:13:28 -0000 On Wed, Feb 11, 2009 at 09:26:14AM -0500, Tim Polk wrote: > Second, I will be offering the following text for IESG notes on both > documents. The > notes clearly state the drawbacks for EAP type code reuse and define an > acceptable > path for future protocol developers. This looks like an appropriate text to add. However, I would request a small clarification on the exact scope of the different EAP-MSCHAPv2 and EAP-GTC behavior. As far as EAP-FAST-MSCHAPv2 vs. EAP-MSCHAPv2 is concerned, I would expect that EAP-FAST-MSCHAPv2 is actually used both for unauthenticated (anonymous) and server-authenticated provisioning while the proposed note seemed to indicate that the different behavior is implied by the use of an anonymous tunnel. See below for suggested changes to resolve this. I'm assuming that the implicit challenges derived from the TLS handshake are not used in the EAP-FAST authentication, i.e., normal authentication would be using something that is closer to EAP-MSCHAPv2, not EAP-FAST-MSCHAPv2. However, I think that even that use of EAP-MSCHAPv2 differs a bit from the way it is used in other protocols, e.g., as far as key derivation is concerned, but this would have been more of a comment for RFC 4851 than these two drafts that are now discussed. Anyway, since the key derivation from inner method is used also during provisioning, it would be useful to specify the exact process used to derive ISK from EAP-FAST-MSCHAPv2 (especially the order of send/recv MS-MPPE keys which seems to differ from the way this is used in PEAPv0 with cryptobinding). > ------ draft-cam-winget-eap-fast-provisioning ----- > The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code assigned to > EAP-MSCHAPv2 (26) for authentication within an anonymous TLS tunnel. s/an anonymous TLS tunnel/the EAP-FAST tunnel during provisioning/ > In > order to minimize the risk associated with an anonymous tunnel, > changes > to the method were made that are not interoperable with EAP- > MSCHAPv2. This use of "anonymous tunnel" sounds fine. > Since EAP-MSCHAPv2 does not support method-specific version > negotiation, > the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous > EAP-FAST tunnel. s/of an anonymous EAP-FAST tunnel/inside the EAP-FAST tunnel during provisioning/ > This behavior may cause problems in > implementations > where the use of unaltered EAP-MSCHAPv2 is needed inside an > anonymous > EAP-FAST tunnel. Since such support requires special case execution > of > a method within a tunnel, it also complicates implementations that > use > the same method code both within and outside of the tunnel > method. That "anonymous" should likely be replaced, too, but I don't have a good proposal for this one. Maybe s/an anonymous/the/ The implementation complexity comes both from different tunneling methods using different versions of EAP-MSCHAPv2 and from the different use within EAP-FAST depending on state (provisioning vs. authentication). > ---- draft-zhou-emu-fast-gtc ------ > Since > EAP-GTC does not support method-specific version negotiation, the > use of > EAP-FAST-GTC is implied when used inside the EAP-FAST tunnel during > authentication. s/ during authentication// I'm not sure whether this "during authentication" was referring to the case where EAP-FAST provisioning is not used (i.e., normal authentication after PAC has been previously provisioned). Anyway, it is probably clearer to just specify that EAP-FAST-GTC is used in all cases inside EAP-FAST tunnel since the draft seems to indicate that this is indeed the case (just note that EAP-FAST-GTC is not allowed in unauthenticated/anonymous provisioning, but it is allowed in server-authenticated provisioning). -- Jouni Malinen PGP id EFC895FA From bernard_aboba@hotmail.com Wed Feb 11 13:29:30 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF2443A680B for ; Wed, 11 Feb 2009 13:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqr-5+Ej4SVg for ; Wed, 11 Feb 2009 13:29:30 -0800 (PST) Received: from blu0-omc3-s16.blu0.hotmail.com (blu0-omc3-s16.blu0.hotmail.com [65.55.116.91]) by core3.amsl.com (Postfix) with ESMTP id D00C33A659C for ; Wed, 11 Feb 2009 13:29:29 -0800 (PST) Received: from BLU137-W13 ([65.55.116.73]) by blu0-omc3-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 13:29:34 -0800 Message-ID: X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: Date: Wed, 11 Feb 2009 13:29:34 -0800 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Feb 2009 21:29:34.0494 (UTC) FILETIME=[D561D3E0:01C98C8F] Subject: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 21:29:30 -0000 Jouni Malinen said: "This looks like an appropriate text to add. However=2C I would request a small clarification on the exact scope of the different EAP-MSCHAPv2 and EAP-GTC behavior. As far as EAP-FAST-MSCHAPv2 vs. EAP-MSCHAPv2 is concerned=2C I would expect that EAP-FAST-MSCHAPv2 is actually used both for unauthenticated (anonymous) and server-authenticated provisioning while the proposed note seemed to indicate that the different behavior is implied by the use of an anonymous tunnel. See below for suggested changes to resolve this. I'm assuming that the implicit challenges derived from the TLS handshake are not used in the EAP-FAST authentication=2C i.e.=2C normal authenticatio= n would be using something that is closer to EAP-MSCHAPv2=2C not EAP-FAST-MSCHAPv2. However=2C I think that even that use of EAP-MSCHAPv2 differs a bit from the way it is used in other protocols=2C e.g.=2C as far as key derivation is concerned=2C but this would have been more of a comment for RFC 4851 than these two drafts that are now discussed. Anyway=2C since the key derivation from inner method is used also during provisioning=2C it would be useful to specify the exact process used to derive ISK from EAP-FAST-MSCHAPv2 (especially the order of send/recv MS-MPPE keys which seems to differ from the way this is used in PEAPv0 with cryptobinding). " Are you suggesting that the version of EAP-MSCHAPv2 described in the docume= nt differs in terms of the MSK/EMSK derivation? Or are you suggesting that further details are= needed on how padding is accomplished with respect to ISK derivation? =20 In general=2C ISK derivation doesn't relate to an EAP method so much as the= tunneling method that utilizes the keys exported by the inner method. So if the issue is purely = in the ISKs=2C then this doesn't really relate to EAP-FAST-MSCHAPv2 or EAP-MSCHAPv2 so much as to EA= P-FAST provisioning mechanism.=20 From j@w1.fi Wed Feb 11 14:12:38 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3FB928C367 for ; Wed, 11 Feb 2009 14:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EoZbb+skCUQc for ; Wed, 11 Feb 2009 14:12:37 -0800 (PST) Received: from jmalinen.user.openhosting.com (128-177-27-249.ip.openhosting.com [128.177.27.249]) by core3.amsl.com (Postfix) with ESMTP id 0FB1228C36C for ; Wed, 11 Feb 2009 14:12:36 -0800 (PST) Received: from jm (a91-155-82-88.elisa-laajakaista.fi [91.155.82.88]) (authenticated bits=0) by jmalinen.user.openhosting.com (8.13.8/8.13.8) with ESMTP id n1BMCb21002095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Feb 2009 17:12:38 -0500 Received: by jm (sSMTP sendmail emulation); Thu, 12 Feb 2009 00:12:36 +0200 Date: Thu, 12 Feb 2009 00:12:36 +0200 From: Jouni Malinen To: Bernard Aboba Message-ID: <20090211221236.GA27123@jm.kir.nu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: emu@ietf.org Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:12:38 -0000 On Wed, Feb 11, 2009 at 01:29:34PM -0800, Bernard Aboba wrote: > Are you suggesting that the version of EAP-MSCHAPv2 described in the document differs in terms > of the MSK/EMSK derivation? Or are you suggesting that further details are needed on how padding > is accomplished with respect to ISK derivation? Former (for MSK part) as far as using EAP-MSCHAPv2 inside EAP-FAST is concerned (the document itself does not describe EAP-MSCHAPv2 MSK derivation). > In general, ISK derivation doesn't relate to an EAP method so much as the tunneling method that > utilizes the keys exported by the inner method. So if the issue is purely in the ISKs, then this > doesn't really relate to EAP-FAST-MSCHAPv2 or EAP-MSCHAPv2 so much as to EAP-FAST > provisioning mechanism. What I noticed when implementing EAP-FAST and cryptobinding support for EAP-PEAPv0 is that I have to swap the order of MS-MPPE send/recv keys (i.e., swap octets 0..15 with 16..31) of the MSK from EAP-MSCHAPv2 between PEAPv0 and EAP-FAST uses in order to interoperate with other implementations. In other words, EAP-FAST and EAP-PEAPv0(with cryptobinding) seem to use different derivation of ISK when using EAP-MSCHAPv2 as the inner method. I do not see need for similar swapping of the ISK octets with EAP-TLS as the inner method, so I would assume the difference is indeed in how the EAP-MSCHAPv2 MSK derivation is defined. After reviewing the description of the MS-CHAPv2 key derivation, I think I ended up agreeing with the way this is done in PEAPv0+cryptobinding and the order used in deployed EAP-FAST implementations would thus not match with the EAP-MSCHAPv2 definition for MSK derivation. -- Jouni Malinen PGP id EFC895FA From david@mitton.com Wed Feb 11 14:58:10 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55B643A6B91 for ; Wed, 11 Feb 2009 14:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.141 X-Spam-Level: X-Spam-Status: No, score=-1.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 256S-gsOhkIW for ; Wed, 11 Feb 2009 14:58:09 -0800 (PST) Received: from smtprelay.hostedemail.com (smtprelay0250.hostedemail.com [216.40.44.250]) by core3.amsl.com (Postfix) with ESMTP id 82A8B3A6A1A for ; Wed, 11 Feb 2009 14:58:09 -0800 (PST) Received: from filter.hostedemail.com (ff-bigip1 [10.5.19.254]) by smtprelay03.hostedemail.com (Postfix) with SMTP id 3FCEA2152AC2; Wed, 11 Feb 2009 22:58:12 +0000 (UTC) X-SpamScore: 1 X-Spam-Summary: 10, 1, 0, 03fd9e6fea513f7c, 80fcc780ad92201b, david@mitton.com, j@w1.fi:bernard_aboba@hotmail.com:emu@ietf.org, RULES_HIT:152:355:375:379:599:945:962:967:972:973:980:982:983:988:989:1189:1208:1224:1260:1311:1313:1314:1345:1373:1394:1395:1436:1437:1513:1515:1516:1517:1521:1534:1542:1588:1589:1593:1594:1676:1711:1730:1747:1766:1792:2198:2199:2393:2525:2553:2559:2563:2682:2685:2731:2857:2859:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3027:3280:3354:3865:3866:3867:3868:3870:3871:3873:3874:3876:3877:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4860:5007:6114:6119:6261:7679:7903:8501:9010:9025:9391, 0, RBL:none, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:, MSBL:none, DNSBL:none Received: from webmail06 (imap-ext [216.40.42.5]) (Authenticated sender: david@mitton.com) by omf04.hostedemail.com (Postfix) with ESMTP; Wed, 11 Feb 2009 22:58:11 +0000 (UTC) Date: Wed, 11 Feb 2009 22:58:11 +0000 (GMT) From: David Mitton To: j@w1.fi Message-ID: <1079005519.16371.1234393091734.JavaMail.mail@webmail06> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-session-marker: 6461766964406D6974746F6E2E636F6D Cc: bernard_aboba@hotmail.com, emu@ietf.org Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: david@mitton.com List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 22:58:10 -0000

Earlier, I felt like asking if there were any independently developed im= plementations of EAP-FAST, now I see one.

And we see what gets discovered when you attempt interoperabilty testing= with real running code.
Dave.


Feb 11, 2009 05:13:19 PM, j@w1= .fi wrote:

On Wed, Feb 1= 1, 2009 at 01:29:34PM -0800, Bernard Aboba wrote:

> Are you sugge= sting that the version of EAP-MSCHAPv2 described in the document differs in= terms
> of the MSK/EMSK derivation?  Or are you suggesting that= further details are needed on how padding
> is accomplished with res= pect to ISK derivation?  

Former (for MSK part) as far as using= EAP-MSCHAPv2 inside EAP-FAST is
concerned (the document itself does not= describe EAP-MSCHAPv2 MSK
derivation).

> In general, ISK deri= vation doesn't relate to an EAP method so much as the tunneling method that=
> utilizes the keys exported by the inner method.  So if the is= sue is purely in the ISKs, then this
> doesn't really relate to EAP-F= AST-MSCHAPv2 or EAP-MSCHAPv2 so much as to EAP-FAST
> provisioning me= chanism.

What I noticed when implementing EAP-FAST and cryptobindin= g support for
EAP-PEAPv0 is that I have to swap the order of MS-MPPE sen= d/recv keys
(i.e., swap octets 0..15 with 16..31) of the MSK from EAP-MS= CHAPv2
between PEAPv0 and EAP-FAST uses in order to interoperate with ot= her
implementations.

In other words, EAP-FAST and EAP-PEAPv0(with= cryptobinding) seem to use
different derivation of ISK when using EAP-M= SCHAPv2 as the inner method.
I do not see need for similar swapping of t= he ISK octets with EAP-TLS as
the inner method, so I would assume the di= fference is indeed in how the
EAP-MSCHAPv2 MSK derivation is defined. Af= ter reviewing the description
of the MS-CHAPv2 key derivation, I think I= ended up agreeing with the
way this is done in PEAPv0+cryptobinding and= the order used in deployed
EAP-FAST implementations would thus not matc= h with the EAP-MSCHAPv2
definition for MSK derivation.

--
Jou= ni Malinen                   &= nbsp;                    =    PGP id EFC895FA
__________________________________________= _____
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/l= istinfo/emu
From bernard_aboba@hotmail.com Wed Feb 11 15:56:04 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4393D3A69F2 for ; Wed, 11 Feb 2009 15:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eHttuXQhKIs for ; Wed, 11 Feb 2009 15:56:03 -0800 (PST) Received: from blu0-omc2-s15.blu0.hotmail.com (blu0-omc2-s15.blu0.hotmail.com [65.55.111.90]) by core3.amsl.com (Postfix) with ESMTP id 5156D3A6886 for ; Wed, 11 Feb 2009 15:56:03 -0800 (PST) Received: from BLU137-W24 ([65.55.111.73]) by blu0-omc2-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Feb 2009 15:56:08 -0800 Message-ID: X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: , Date: Wed, 11 Feb 2009 15:56:08 -0800 Importance: Normal In-Reply-To: <1079005519.16371.1234393091734.JavaMail.mail@webmail06> References: <1079005519.16371.1234393091734.JavaMail.mail@webmail06> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Feb 2009 23:56:08.0331 (UTC) FILETIME=[4EEADDB0:01C98CA4] Cc: emu@ietf.org Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2009 23:56:04 -0000 Just to make sure I understand this: You are saying that in addition to the interoperability issues described in Tim's note with respect to the EAP-FAST-MSCHAPv2=2C that this document also does not conform to the key derivation specified in EAP MS-CHAPv2=2C=20 and that as a result it can't interoperate with existing implementations of EAP MS-CHAPv2=2C for regular non-provisioning uses? =20 ________________________________ > Date: Wed=2C 11 Feb 2009 22:58:11 +0000 > From: david@mitton.com > To: j@w1.fi > CC: bernard_aboba@hotmail.com=3B emu@ietf.org > Subject: Re: Re: [Emu] Key derivation differences > > Earlier=2C I felt like asking if there were any independently developed i= mplementations of EAP-FAST=2C now I see one. > > > And we see what gets discovered when you attempt interoperabilty testing = with real running code. > > Dave. > > > Feb 11=2C 2009 05:13:19 PM=2C j@w1.fi wrote: > > On Wed=2C Feb 11=2C 2009 at 01:29:34PM -0800=2C Bernard Aboba wrote: > >> Are you suggesting that the version of EAP-MSCHAPv2 described in the doc= ument differs in terms >> of the MSK/EMSK derivation? Or are you suggesting that further details a= re needed on how padding >> is accomplished with respect to ISK derivation? > > Former (for MSK part) as far as using EAP-MSCHAPv2 inside EAP-FAST is > concerned (the document itself does not describe EAP-MSCHAPv2 MSK > derivation). > >> In general=2C ISK derivation doesn't relate to an EAP method so much as = the tunneling method that >> utilizes the keys exported by the inner method. So if the issue is purel= y in the ISKs=2C then this >> doesn't really relate to EAP-FAST-MSCHAPv2 or EAP-MSCHAPv2 so much as to= EAP-FAST >> provisioning mechanism. > > What I noticed when implementing EAP-FAST and cryptobinding support for > EAP-PEAPv0 is that I have to swap the order of MS-MPPE send/recv keys > (i.e.=2C swap octets 0..15 with 16..31) of the MSK from EAP-MSCHAPv2 > between PEAPv0 and EAP-FAST uses in order to interoperate with other > implementations. > > In other words=2C EAP-FAST and EAP-PEAPv0(with cryptobinding) seem to use > different derivation of ISK when using EAP-MSCHAPv2 as the inner method. > I do not see need for similar swapping of the ISK octets with EAP-TLS as > the inner method=2C so I would assume the difference is indeed in how the > EAP-MSCHAPv2 MSK derivation is defined. After reviewing the description > of the MS-CHAPv2 key derivation=2C I think I ended up agreeing with the > way this is done in PEAPv0+cryptobinding and the order used in deployed > EAP-FAST implementations would thus not match with the EAP-MSCHAPv2 > definition for MSK derivation. > > -- > Jouni Malinen PGP id EFC895FA > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From glenzorn@comcast.net Wed Feb 11 17:26:46 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C32AB3A6A42 for ; Wed, 11 Feb 2009 17:26:46 -0800 (PST) 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=[BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBdAOlyUle61 for ; Wed, 11 Feb 2009 17:26:45 -0800 (PST) Received: from QMTA06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [76.96.30.56]) by core3.amsl.com (Postfix) with ESMTP id AF0C13A69EE for ; Wed, 11 Feb 2009 17:26:45 -0800 (PST) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA06.emeryville.ca.mail.comcast.net with comcast id EcUl1b0090lTkoCA6pSrmq; Thu, 12 Feb 2009 01:26:51 +0000 Received: from gwzPC ([124.120.218.181]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id EpSE1b0053vQyGU8QpSPoE; Thu, 12 Feb 2009 01:26:46 +0000 From: "Glen Zorn" To: "'Tim Polk'" References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com> <006c01c98781$5d6b8bf0$1842a3d0$@net> <808FD6E27AD4884E94820BC333B2DB7727E78F2B67@NOK-EUMSG-01.mgdnok.nokia.com> <003201c9880d$e8160780$b8421680$@net> In-Reply-To: Date: Thu, 12 Feb 2009 08:25:52 +0700 Message-ID: <000601c98cb0$ec00add0$c4020970$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmMVJwMzzog0lbHRfqquijymYv/lQAWnzkg Content-Language: en-us Cc: iesg@ietf.org, emu@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 01:26:46 -0000 Tim Polk [mailto:tim.polk@nist.gov] writes: > Folks, > > As the AD that sponsored publication of the EAP-FAST documents under > discussion, > I have been trying to find the best way forward. I believe that the > best course of action > involves some clarifications to draft-cam-winget-eap-fast- > provisioning to distinguish > the modified and unmodified use of EAP-MSCHAPv2, and IESG notes to > ensure these > publications do not establish precedent for future reuse of EAP type > codes with > different semantics. I'm sure that the IESG views its essentially invertebrate response to this outrageous behavior as stern but fair. If this pirating of IANA allocated parameters is actually allowed (as it appears that it will be), I suggest that you keep this stern warning around (perhaps as a form-letter template so you can easily fill in the blanks); even better, publish it (suitably modified for generality) as an RFC so the next few hundred "designers" who can't be bothered with IANA can just reference it. > > First, I support revising draft-cam-winget-eap-fast-provisioning so > that the modified > form of EAP-MSCHAPv2 is consistently referred to as EAP-FAST- > MSCHAPv2. The > authors offered to make this change earlier in the thread, and I have > seen some > support and no opposition to this suggestion. > > Second, I will be offering the following text for IESG notes on both > documents. The > notes clearly state the drawbacks for EAP type code reuse and define > an acceptable > path for future protocol developers. > > ------ draft-cam-winget-eap-fast-provisioning ----- > > EAP-FAST has been implemented by many vendors and it is used in > the > Internet. Publication of this specification is intended to > promote > interoperability by documenting current use of existing EAP > methods > within EAP-FAST. > > The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code > assigned to > EAP-MSCHAPv2 (26) for authentication within an anonymous TLS > tunnel. In > order to minimize the risk associated with an anonymous tunnel, > changes > to the method were made that are not interoperable with EAP- > MSCHAPv2. > Since EAP-MSCHAPv2 does not support method-specific version > negotiation, > the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous > EAP-FAST tunnel. This behavior may cause problems in > implementations > where the use of unaltered EAP-MSCHAPv2 is needed inside an > anonymous > EAP-FAST tunnel. Since such support requires special case > execution of > a method within a tunnel, it also complicates implementations > that use > the same method code both within and outside of the tunnel > method. If > EAP-FAST were to be designed today, these difficulties could be > avoided > by utilization of unique EAP Type codes. Given these issues, > assigned > method types must not be re-used with different meaning inside > tunneled > methods in the future. > > ---- draft-zhou-emu-fast-gtc ------ > > EAP-FAST has been implemented by many vendors and it is used in > the > Internet. Publication of this specification is intended to > promote > interoperability by documenting current use of existing EAP > methods > within EAP-FAST. > > The EAP method EAP-FAST-GTC reuses the EAP type code assigned to > EAP-GTC (6). The reuse of previously assigned EAP Type Codes is > incompatible with EAP method negotiation as defined in RFC > 3748. Since > EAP-GTC does not support method-specific version negotiation, > the use of > EAP-FAST-GTC is implied when used inside the EAP-FAST tunnel > during > authentication. This behavior may cause problems in > implementations where > the use of another vendor's EAP-GTC is required. Since such > support requires > special case execution of a method within a tunnel, it also > complicates > implementations that use the same method code both within and > outside of > the tunnel method. If EAP-FAST were to be designed today, these > difficulties could be avoided by utilization of unique EAP Type > codes. > Given these issues, assigned method types must not be re-used with > different meaning inside tunneled methods in the future. > > I am not under the illusion that this text will be entirely > satisfactory to anyone, > but I believe that it is an *appropriate* resolution to the problem. > > Thanks, > > Tim Polk > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hzhou@cisco.com Wed Feb 11 19:05:56 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 220DE3A69F2; Wed, 11 Feb 2009 19:05:56 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uahYgjdf8dLY; Wed, 11 Feb 2009 19:05:54 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 718423A69E4; Wed, 11 Feb 2009 19:05:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,194,1233532800"; d="scan'208";a="36771656" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 12 Feb 2009 03:05:58 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1C35wUW016395; Wed, 11 Feb 2009 22:05:58 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n1C35wbr000205; Thu, 12 Feb 2009 03:05:58 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Feb 2009 22:05:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Feb 2009 22:05:57 -0500 Message-ID: <9958B444368E884DBB215F3FEF36F5B708F4DD04@xmb-rtp-212.amer.cisco.com> In-Reply-To: <20090211201320.GA22148@jm.kir.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Potential Notes in EAP-FAST Documents Thread-Index: AcmMhToZYb4ZoFogRIuG/S9/eQj6agANd42Q References: <808FD6E27AD4884E94820BC333B2DB7727E78F274C@NOK-EUMSG-01.mgdnok.nokia.com><006c01c98781$5d6b8bf0$1842a3d0$@net><808FD6E27AD4884E94820BC333B2DB7727E78F2B67@NOK-EUMSG-01.mgdnok.nokia.com><003201c9880d$e8160780$b8421680$@net> <20090211201320.GA22148@jm.kir.nu> From: "Hao Zhou (hzhou)" To: "Jouni Malinen" , "Tim Polk" X-OriginalArrivalTime: 12 Feb 2009 03:05:58.0742 (UTC) FILETIME=[D421A760:01C98CBE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6401; t=1234407959; x=1235271959; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20(hzhou)=22=20 |Subject:=20RE=3A=20[Emu]=20Potential=20Notes=20in=20EAP-FA ST=20Documents |Sender:=20 |To:=20=22Jouni=20Malinen=22=20,=20=22Tim=20Polk=2 2=20; bh=mScsY8kf4iuRLPABg7mNFyXwENWEnQHoyulss6Bahdw=; b=UpQANhgQBVEXJBM0jcQ9GChbdRomSVq6+P30UhLKBRG36zh7Ho4mZ8xeFu lyr59OeXqsVGIkvz/N1tmG2/9JaPJb4q2fxvrmg3I21pvdwW7Mb0/Rf5yr2W bkc3G3yKZB; Authentication-Results: rtp-dkim-1; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: emu@ietf.org, iesg@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 03:05:56 -0000 Jouni: Thanks for the feedback. To clarify, EAP-FAST-MSCHAPv2 is only being used during anonymous provisioning mode, in other cases, the normal EAP-MSCHAPv2 is being used. This is mentioned in draft-cam-winget-eap-fast-provisioning Section 3.2.3 and reflects current implementations. The design is to specifically minimize the risk associated with an anonymous tunnel, which does not apply to an authenticated tunnel. =20 As for the ISK derivation from EAP-MSCHAPv2, a further clarification is probably helpful. As discussed, EAP-MSCHAPv2 documentation doesn't really describe how MSK is generated, only referencing RFC3079. RFC3079 only describes how two 128-bit keys are generated, but leaves out how these two keys are combined to form the MSK. This leaves it to be defined in a tunnel method specific way. It seems that EAP-FAST may have defined a combining algorithm different with the other method.=20 Here is what we propose to add to draft-cam-winget-eap-fast-provisioning Section 3.2.3 to clarify the issue.=20 "The inner session key (ISK) generation for EAP-FAST-MSCHAPv2 and EAP-MSCHAPv2 used inside EAP-FAST MUST follow the steps below. Two 128 bit master keys MasterSendKey and MasterReceiveKey are generated according to the RFC3079. They are combined to form the ISK, with MasterSendKey taking the first 16 octets and MasterReceiveKey taking the last 16 octets. " As for the GTC comment, you are right that EAP-FAST-GTC is being used in all cases inside EAP-FAST. So your suggestion of removing "during authentication" or changing it to "always" is fine. =20 > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Jouni Malinen > Sent: Wednesday, February 11, 2009 3:13 PM > To: Tim Polk > Cc: emu@ietf.org; iesg@ietf.org IESG > Subject: Re: [Emu] Potential Notes in EAP-FAST Documents >=20 > On Wed, Feb 11, 2009 at 09:26:14AM -0500, Tim Polk wrote: >=20 > > Second, I will be offering the following text for IESG=20 > notes on both=20 > > documents. The notes clearly state the drawbacks for EAP type code=20 > > reuse and define an acceptable path for future protocol developers. >=20 > This looks like an appropriate text to add. However, I would=20 > request a small clarification on the exact scope of the=20 > different EAP-MSCHAPv2 and EAP-GTC behavior. As far as=20 > EAP-FAST-MSCHAPv2 vs. EAP-MSCHAPv2 is concerned, I would=20 > expect that EAP-FAST-MSCHAPv2 is actually used both for=20 > unauthenticated (anonymous) and server-authenticated=20 > provisioning while the proposed note seemed to indicate that=20 > the different behavior is implied by the use of an anonymous=20 > tunnel. See below for suggested changes to resolve this. >=20 > I'm assuming that the implicit challenges derived from the=20 > TLS handshake are not used in the EAP-FAST authentication,=20 > i.e., normal authentication would be using something that is=20 > closer to EAP-MSCHAPv2, not EAP-FAST-MSCHAPv2. However, I=20 > think that even that use of EAP-MSCHAPv2 differs a bit from=20 > the way it is used in other protocols, e.g., as far as key=20 > derivation is concerned, but this would have been more of a=20 > comment for RFC 4851 than these two drafts that are now discussed. > Anyway, since the key derivation from inner method is used=20 > also during provisioning, it would be useful to specify the=20 > exact process used to derive ISK from EAP-FAST-MSCHAPv2=20 > (especially the order of send/recv MS-MPPE keys which seems=20 > to differ from the way this is used in PEAPv0 with cryptobinding). >=20 > > ------ draft-cam-winget-eap-fast-provisioning ----- > > The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type=20 > code assigned to > > EAP-MSCHAPv2 (26) for authentication within an=20 > anonymous TLS tunnel. =20 >=20 > s/an anonymous TLS tunnel/the EAP-FAST tunnel during provisioning/ >=20 > > In > > order to minimize the risk associated with an anonymous tunnel,=20 > > changes > > to the method were made that are not interoperable with EAP-=20 > > MSCHAPv2. >=20 > This use of "anonymous tunnel" sounds fine. >=20 > > Since EAP-MSCHAPv2 does not support method-specific version=20 > > negotiation, > > the use of EAP-FAST-MSCHAPv2 is implied by the use of=20 > an anonymous > > EAP-FAST tunnel. >=20 > s/of an anonymous EAP-FAST tunnel/inside the EAP-FAST tunnel=20 > during provisioning/ >=20 > > This behavior may cause problems in implementations > > where the use of unaltered EAP-MSCHAPv2 is needed inside an=20 > > anonymous > > EAP-FAST tunnel. Since such support requires special case=20 > > execution of > > a method within a tunnel, it also complicates implementations=20 > > that use > > the same method code both within and outside of the tunnel > > method. >=20 > That "anonymous" should likely be replaced, too, but I don't=20 > have a good proposal for this one. Maybe s/an anonymous/the/ >=20 > The implementation complexity comes both from different=20 > tunneling methods using different versions of EAP-MSCHAPv2=20 > and from the different use within EAP-FAST depending on state=20 > (provisioning vs. > authentication). >=20 >=20 > > ---- draft-zhou-emu-fast-gtc ------ >=20 > > Since > > EAP-GTC does not support method-specific version=20 > negotiation, the=20 > > use of > > EAP-FAST-GTC is implied when used inside the EAP-FAST=20 > tunnel during > > authentication. >=20 > s/ during authentication// >=20 > I'm not sure whether this "during authentication" was=20 > referring to the case where EAP-FAST provisioning is not used=20 > (i.e., normal authentication after PAC has been previously=20 > provisioned). Anyway, it is probably clearer to just specify=20 > that EAP-FAST-GTC is used in all cases inside EAP-FAST tunnel=20 > since the draft seems to indicate that this is indeed the=20 > case (just note that EAP-FAST-GTC is not allowed in=20 > unauthenticated/anonymous provisioning, but it is allowed in=20 > server-authenticated provisioning). >=20 > --=20 > Jouni Malinen PGP=20 > id EFC895FA > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20 From bernarda@windows.microsoft.com Wed Feb 4 13:19:50 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C329D3A6832 for ; Wed, 4 Feb 2009 13:19:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.373 X-Spam-Level: X-Spam-Status: No, score=-109.373 tagged_above=-999 required=5 tests=[AWL=1.225, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oEn0CEKtK3BW for ; Wed, 4 Feb 2009 13:19:46 -0800 (PST) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id E1A093A698C for ; Wed, 4 Feb 2009 13:19:46 -0800 (PST) Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.99.4; Wed, 4 Feb 2009 13:19:20 -0800 Received: from tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com (157.54.18.32) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.18.53) with Microsoft SMTP Server id 8.2.99.4; Wed, 4 Feb 2009 13:19:20 -0800 Received: from NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com ([fe80::75be:c82f:ae04:55bf]) by tk5-exmlt-w601.wingroup.windeploy.ntdev.microsoft.com ([157.54.18.32]) with mapi; Wed, 4 Feb 2009 13:20:49 -0800 From: Bernard Aboba To: "emu@ietf.org" Date: Wed, 4 Feb 2009 13:19:04 -0800 Thread-Topic: IANA allocation issue in EAP-FAST Documents Thread-Index: AcmHDPGhDtdqMsPaT++CTA72hptm2AAAKZ+w Message-ID: <2828BDE8DC61004E8104C78E82A0B39713F1D62D97@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2828BDE8DC61004E8104C78E82A0B39713F1D62D97NAEXMSGW601wi_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 11 Feb 2009 21:23:33 -0800 Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2009 21:19:50 -0000 --_000_2828BDE8DC61004E8104C78E82A0B39713F1D62D97NAEXMSGW601wi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dan Harkins said: > draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226 > but nowhere in that RFC can I find description of the following label > for an initial assignment of repository values: > > "allocated for management by Cisco" > > yet the draft instructs IANA to set aside values 11-63 for just that > purpose. I think that's very inappropriate. Not only is it telling IANA > to cede some of its authority to a large multinational corporation but > it is decidedly *NOT* documenting existing use! If this whole exercise > is to document existing use then where are the specifications for these > PAC attribute types? It would appear that the registry of "EAP-FAST PAC Attribute Types" relates to a Standard Track document, RFC 4507, although the document itself doesn't indicate that it updates RFC 4507. RFC 5226 does permit vendor-specific registries, although it is somewhat od= d to enable vendor extensions for only one vendor, particularly if this does rel= ate to an IETF standards track document (which would imply IETF change control, no= ?) --_000_2828BDE8DC61004E8104C78E82A0B39713F1D62D97NAEXMSGW601wi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dan Harkins said:
 
> draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226<= br> > but nowhere in that RFC can I find description of the following label<= br> > for an initial assignment of repository values:
>
> "allocated for management by Cisco"
>
> yet the draft instructs IANA to set aside values 11-63 for just that > purpose. I think that's very inappropriate. Not only is it telling IAN= A
> to cede some of its authority to a large multinational corporation but=
> it is decidedly *NOT* documenting existing use! If this whole exercise=
> is to document existing use then where are the specifications for thes= e
> PAC attribute types?

It would appear that the registry of "EAP-= FAST PAC Attribute Types" relates
to a Standard Track document, RFC 4507, although the document itself

doesn’t indicate that it updates RFC 4507.

 

RFC 5226 does permit vendor-specific registries, although it i= s somewhat odd to

enable vendor extensions for only one vendor, particularly if = this does relate to

an IETF standards track document (which would imply IETF chang= e control, no?)
 
 

--_000_2828BDE8DC61004E8104C78E82A0B39713F1D62D97NAEXMSGW601wi_-- From glenzorn@comcast.net Wed Feb 11 21:30:54 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2F5B3A696E for ; Wed, 11 Feb 2009 21:30:54 -0800 (PST) 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.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0MolR7zy6Ah for ; Wed, 11 Feb 2009 21:30:47 -0800 (PST) Received: from QMTA09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by core3.amsl.com (Postfix) with ESMTP id 280573A6A18 for ; Wed, 11 Feb 2009 21:30:47 -0800 (PST) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA09.westchester.pa.mail.comcast.net with comcast id EtFC1b00216LCl059tWtr5; Thu, 12 Feb 2009 05:30:53 +0000 Received: from gwzPC ([124.120.218.181]) by OMTA06.westchester.pa.mail.comcast.net with comcast id EtWS1b0093vQyGU3StWa8E; Thu, 12 Feb 2009 05:30:52 +0000 From: "Glen Zorn" To: "'Bernard Aboba'" References: <2828BDE8DC61004E8104C78E82A0B39713F1D62D97@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <2828BDE8DC61004E8104C78E82A0B39713F1D62D97@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 12 Feb 2009 12:29:58 +0700 Message-ID: <002701c98cd3$01f98e50$05ecaaf0$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C98D0D.AE586650" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmHDPGhDtdqMsPaT++CTA72hptm2AAAKZ+wAXE5BSA= Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 05:30:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0028_01C98D0D.AE586650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Bernard. I can't find anything in 5226 that says anything about vendor-specific registries. Can you send a quote? From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Thursday, February 05, 2009 4:19 AM To: emu@ietf.org Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents Dan Harkins said: > draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226 > but nowhere in that RFC can I find description of the following label > for an initial assignment of repository values: > > "allocated for management by Cisco" > > yet the draft instructs IANA to set aside values 11-63 for just that > purpose. I think that's very inappropriate. Not only is it telling IANA > to cede some of its authority to a large multinational corporation but > it is decidedly *NOT* documenting existing use! If this whole exercise > is to document existing use then where are the specifications for these > PAC attribute types? It would appear that the registry of "EAP-FAST PAC Attribute Types" relates to a Standard Track document, RFC 4507, although the document itself doesn't indicate that it updates RFC 4507. RFC 5226 does permit vendor-specific registries, although it is somewhat odd to enable vendor extensions for only one vendor, particularly if this does relate to an IETF standards track document (which would imply IETF change control, no?) ------=_NextPart_000_0028_01C98D0D.AE586650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, Bernard.  I can't find anything in 5226 that = says anything about vendor-specific registries.  Can you send a = quote?

 

From:= emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of = Bernard Aboba
Sent: Thursday, February 05, 2009 4:19 AM
To: emu@ietf.org
Subject: Re: [Emu] IANA allocation issue in EAP-FAST = Documents

 

Dan Harkins said:
 
> draft-cam-winget-eap-fast-provisioning claims a reference to RFC = 5226
> but nowhere in that RFC can I find description of the following = label
> for an initial assignment of repository values:
>
> "allocated for management by Cisco"
>
> yet the draft instructs IANA to set aside values 11-63 for just = that
> purpose. I think that's very inappropriate. Not only is it telling = IANA
> to cede some of its authority to a large multinational corporation = but
> it is decidedly *NOT* documenting existing use! If this whole = exercise
> is to document existing use then where are the specifications for = these
> PAC attribute types?

It would appear that the registry of = "EAP-FAST PAC Attribute Types" relates
to a Standard Track document, RFC 4507, although the document = itself

doesn’t indicate that it updates RFC 4507. =

 

RFC 5226 does permit vendor-specific registries, although = it is somewhat odd to

enable vendor extensions for only one vendor, particularly = if this does relate to

an IETF standards track document (which would imply IETF = change control, no?)
 
 

------=_NextPart_000_0028_01C98D0D.AE586650-- From dharkins@lounge.org Wed Feb 11 23:14:03 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305733A699A; Wed, 11 Feb 2009 23:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTchY8zolbIQ; Wed, 11 Feb 2009 23:14:02 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 6E0FA3A6843; Wed, 11 Feb 2009 23:14:02 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9463EA8880D4; Wed, 11 Feb 2009 23:14:07 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 11 Feb 2009 23:14:07 -0800 (PST) Message-ID: <122ee5321a655251454c0260c3dac4ee.squirrel@www.trepanning.net> In-Reply-To: <2828BDE8DC61004E8104C78E82A0B39713F1D62D97@NA-EXMSG-W601.wingroup.win deploy.ntdev.microsoft.com> References: <2828BDE8DC61004E8104C78E82A0B39713F1D62D97@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> Date: Wed, 11 Feb 2009 23:14:07 -0800 (PST) From: "Dan Harkins" To: "Bernard Aboba" 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" , iesg@ietf.org Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 07:14:03 -0000 Hi Bernard, "odd" isn't the word I'd use to describe it. Audacious and hubristic are a bit more like it. These aren't "private use" or vendor-specific attributes. Let's be very specific about that. I don't understand your mention of modifying RFC 4507. Is this yet another problem with these drafts? Dan. On Wed, February 4, 2009 1:19 pm, Bernard Aboba wrote: > Dan Harkins said: > >> draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226 >> but nowhere in that RFC can I find description of the following label >> for an initial assignment of repository values: >> >> "allocated for management by Cisco" >> >> yet the draft instructs IANA to set aside values 11-63 for just that >> purpose. I think that's very inappropriate. Not only is it telling IANA >> to cede some of its authority to a large multinational corporation but >> it is decidedly *NOT* documenting existing use! If this whole exercise >> is to document existing use then where are the specifications for these >> PAC attribute types? > > It would appear that the registry of "EAP-FAST PAC Attribute Types" > relates > to a Standard Track document, RFC 4507, although the document itself > doesn't indicate that it updates RFC 4507. > > RFC 5226 does permit vendor-specific registries, although it is somewhat > odd to > enable vendor extensions for only one vendor, particularly if this does > relate to > an IETF standards track document (which would imply IETF change control, > no?) > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From dharkins@lounge.org Wed Feb 11 23:21:50 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D460F3A6A98 for ; Wed, 11 Feb 2009 23:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vgUjP3FGynN for ; Wed, 11 Feb 2009 23:21:50 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 13F513A699A for ; Wed, 11 Feb 2009 23:21:50 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2C76BA8881B6; Wed, 11 Feb 2009 23:21:54 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 11 Feb 2009 23:21:55 -0800 (PST) Message-ID: <0dcd37b497f78a52a42c97aee247240a.squirrel@www.trepanning.net> In-Reply-To: <002701c98cd3$01f98e50$05ecaaf0$@net> References: <2828BDE8DC61004E8104C78E82A0B39713F1D62D97@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com> <002701c98cd3$01f98e50$05ecaaf0$@net> Date: Wed, 11 Feb 2009 23:21:55 -0800 (PST) From: "Dan Harkins" To: "Glen Zorn" 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: 'Bernard Aboba' , emu@ietf.org Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 07:21:50 -0000 Maybe we should just update RFC 5226 to add "allocated for management by Cisco" to the list of labels for initial assignment. Then other RFCs could give a block of numberspace to Cisco and we wouldn't have the kind of problem being caused by these drafts. Cisco wouldn't need to steal an already-assigned value for whatever weird proprietary hack they want to do, they can just take one from their own numberspace. Dan. On Wed, February 11, 2009 9:29 pm, Glen Zorn wrote: > Hi, Bernard. I can't find anything in 5226 that says anything about > vendor-specific registries. Can you send a quote? > > > > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of > Bernard Aboba > Sent: Thursday, February 05, 2009 4:19 AM > To: emu@ietf.org > Subject: Re: [Emu] IANA allocation issue in EAP-FAST Documents > > > > Dan Harkins said: > >> draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226 >> but nowhere in that RFC can I find description of the following label >> for an initial assignment of repository values: >> >> "allocated for management by Cisco" >> >> yet the draft instructs IANA to set aside values 11-63 for just that >> purpose. I think that's very inappropriate. Not only is it telling IANA >> to cede some of its authority to a large multinational corporation but >> it is decidedly *NOT* documenting existing use! If this whole exercise >> is to document existing use then where are the specifications for these >> PAC attribute types? > > It would appear that the registry of "EAP-FAST PAC Attribute Types" > relates > to a Standard Track document, RFC 4507, although the document itself > > doesn't indicate that it updates RFC 4507. > > > > RFC 5226 does permit vendor-specific registries, although it is somewhat > odd > to > > enable vendor extensions for only one vendor, particularly if this does > relate to > > an IETF standards track document (which would imply IETF change control, > no?) > > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From j@w1.fi Thu Feb 12 00:30:27 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867973A6A24; Thu, 12 Feb 2009 00:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJSByT-6c-fZ; Thu, 12 Feb 2009 00:30:26 -0800 (PST) Received: from jmalinen.user.openhosting.com (128-177-27-249.ip.openhosting.com [128.177.27.249]) by core3.amsl.com (Postfix) with ESMTP id 8F78A3A6978; Thu, 12 Feb 2009 00:30:26 -0800 (PST) Received: from jm (a91-155-82-88.elisa-laajakaista.fi [91.155.82.88]) (authenticated bits=0) by jmalinen.user.openhosting.com (8.13.8/8.13.8) with ESMTP id n1C8UGNH002153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 03:30:18 -0500 Received: by jm (sSMTP sendmail emulation); Thu, 12 Feb 2009 10:30:16 +0200 Date: Thu, 12 Feb 2009 10:30:16 +0200 From: Jouni Malinen To: "Hao Zhou (hzhou)" Message-ID: <20090212083016.GA31253@jm.kir.nu> References: <20090211201320.GA22148@jm.kir.nu> <9958B444368E884DBB215F3FEF36F5B708F4DD04@xmb-rtp-212.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9958B444368E884DBB215F3FEF36F5B708F4DD04@xmb-rtp-212.amer.cisco.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Tim Polk , emu@ietf.org, iesg@ietf.org Subject: Re: [Emu] Potential Notes in EAP-FAST Documents X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 08:30:27 -0000 On Wed, Feb 11, 2009 at 10:05:57PM -0500, Hao Zhou (hzhou) wrote: > To clarify, EAP-FAST-MSCHAPv2 is only being used during anonymous > provisioning mode, in other cases, the normal EAP-MSCHAPv2 is being > used. This is mentioned in draft-cam-winget-eap-fast-provisioning > Section 3.2.3 and reflects current implementations. The design is to > specifically minimize the risk associated with an anonymous tunnel, > which does not apply to an authenticated tunnel. Thanks. Apparently, I looked at my implementation bit too quickly and assumed it was using the implicit challenges for both provision cases, but you are correct, the draft does indeed state this only for anonymous provisioning and I now confirmed that that was also what my implementation was doing. In other words, the changes I asked for the note for draft-cam-winget-eap-fast-provisioning for the topic of when to use EAP-MSCHAPv2 vs. EAP-FAST-MSCHAPv2 should not be made and only the change request for draft-zhou-emu-fast-gtc would be suitable. > As for the ISK derivation from EAP-MSCHAPv2, a further clarification is > probably helpful. As discussed, EAP-MSCHAPv2 documentation doesn't > really describe how MSK is generated, only referencing RFC3079. RFC3079 > only describes how two 128-bit keys are generated, but leaves out how > these two keys are combined to form the MSK. This leaves it to be > defined in a tunnel method specific way. It seems that EAP-FAST may have > defined a combining algorithm different with the other method. I agree for the part that MSK derivation for EAP-MSCHAPv2 is not very well defined and it did require going through multiple documents to figure out the order. As far as MSK derivation for an inner method being tunnel method specific is concerned, I do not agree with that. It should be up to the inner method specification to define how MSK is derived and tunnel method ISK should just use that MSK. I do not remember anymore where exactly I found this, but probably based on the MSCHAPv2 documents and the way MS-MPPE keys are used in other methods, I ended up with EAP-MSCHAPv2 MSK = server MS-MPPE-Recv-Key | server MS-MPPE-Send-Key This is the order used in EAP-PEAPv0 cryptobinding derivation. In EAP-FAST, the opposite order is used: MSK = server MS-MPPE-Send-Key | server MS-MPPE-Recv-Key > Here is what we propose to add to draft-cam-winget-eap-fast-provisioning > Section 3.2.3 to clarify the issue. > > "The inner session key (ISK) generation for EAP-FAST-MSCHAPv2 and > EAP-MSCHAPv2 used inside EAP-FAST MUST follow the steps below. Two 128 > bit master keys MasterSendKey and MasterReceiveKey are generated > according to the RFC3079. They are combined to form the ISK, with > MasterSendKey taking the first 16 octets and MasterReceiveKey taking the > last 16 octets. " Taken into account that MasterSendKey in RFC 3079 is defined as the server MS-MPPE-Send-Key, this matches with the order I described above and including this note in the draft would indeed be a helpful clarification. -- Jouni Malinen PGP id EFC895FA From j@w1.fi Thu Feb 12 00:49:04 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C843928C0E7 for ; Thu, 12 Feb 2009 00:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zKx-yER3eEe for ; Thu, 12 Feb 2009 00:49:04 -0800 (PST) Received: from jmalinen.user.openhosting.com (128-177-27-249.ip.openhosting.com [128.177.27.249]) by core3.amsl.com (Postfix) with ESMTP id DE3563A68CC for ; Thu, 12 Feb 2009 00:49:03 -0800 (PST) Received: from jm (a91-155-82-88.elisa-laajakaista.fi [91.155.82.88]) (authenticated bits=0) by jmalinen.user.openhosting.com (8.13.8/8.13.8) with ESMTP id n1C8n4iY015091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Feb 2009 03:49:06 -0500 Received: by jm (sSMTP sendmail emulation); Thu, 12 Feb 2009 10:49:04 +0200 Date: Thu, 12 Feb 2009 10:49:04 +0200 From: Jouni Malinen To: Bernard Aboba Message-ID: <20090212084904.GB31253@jm.kir.nu> References: <1079005519.16371.1234393091734.JavaMail.mail@webmail06> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: emu@ietf.org Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 08:49:04 -0000 On Wed, Feb 11, 2009 at 03:56:08PM -0800, Bernard Aboba wrote: > You are saying that in addition to the interoperability issues described in > Tim's note with respect to the EAP-FAST-MSCHAPv2, that this document > also does not conform to the key derivation specified in EAP MS-CHAPv2, > and that as a result it can't interoperate with existing implementations of > EAP MS-CHAPv2, for regular non-provisioning uses? I'm not sure I would go as far as saying it does not conform to a specification taken into account the unclear situation on how MSK derivation for EAP-MSCHAPv2 is defined. More exact statement would be that EAP-FAST ISK and PEAPv0/cryptobinding ISK derivations use different order of MS-MPPE-Send-Key and MS-MPPE-Recv-Key in the EAP-MSCHAPv2 MSK. In other words, implementations that try to use the same EAP-MSCHAPv2 implementation (including the rules for MSK derivation) would not interoperate with both deployed EAP-FAST and EAP-PEAPv0/cryptobinding implementations. Depending on the Send/Recv key order in the MSK, one of the tunnel methods using the MSK from EAP-MSCHAPv2 would need to swap the keys. In my particular case, I ended up implementing EAP-FAST first and found the issue when trying to interoperate with EAP-PEAPv0 cryptobinding after that. As far as which use is correct is concerned, it is not exactly trivial thing to figure out, but my current interpretation of various specifications related to MS-MPPE keys is that the order used in PEAPv0 cryptobinding would match with the order used in other methods. Anyway, having a single document describing EAP-MSCHAPv2, including MSK derivation, would be a useful thing to have for anyone who wants to implement these things. The use of MS-MPPE Send/Recv keys that are different for server and peer side instead of defining the same derivation of full MSK for both server and peer make it very easy to get this wrong. I ended up having to figure this out by testing against deployed implementations and getting surprised that the same code does not work with both uses. Anyway, like I mentioned before, this EAP-MSCHAPv2 MSK difference is not strictly speaking an issue that would be specific to draft-cam-winget-eap-fast-provisioning; it would have been useful to describe it in RFC 4851. Anyway, it looks like the authors are willing to include the additional description in draft-cam-winget-eap-fast-provisioning and for the goal of describing a deployed protocol and allowing vendors to implement it in interoperable way, it is useful to get this described somewhere and this draft looks like the best place to do so at this point. -- Jouni Malinen PGP id EFC895FA From Pasi.Eronen@nokia.com Thu Feb 12 05:18:37 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B39C28C1F3 for ; Thu, 12 Feb 2009 05:18:37 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0dmXAFlGO7N for ; Thu, 12 Feb 2009 05:18:33 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 17D0628C21B for ; Thu, 12 Feb 2009 05:18:32 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1CDIBUg018452; Thu, 12 Feb 2009 15:18:34 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 15:17:56 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 15:17:56 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 12 Feb 2009 14:17:55 +0100 From: To: , Date: Thu, 12 Feb 2009 14:17:53 +0100 Thread-Topic: [Emu] Key derivation differences Thread-Index: AcmMj99pRXpdteTXSTSMuchTmVBIsgAghxVw Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E79E917C@NOK-EUMSG-01.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2009 13:17:56.0252 (UTC) FILETIME=[51790DC0:01C98D14] X-Nokia-AV: Clean Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 13:18:37 -0000 Bernard Aboba wrote: > Are you suggesting that the version of EAP-MSCHAPv2 described in the > document differs in terms of the MSK/EMSK derivation? Or are you > suggesting that further details are needed on how padding is > accomplished with respect to ISK derivation? Hmm.. it seems the EAP-MSCHAPv2 specification (on msdn.microsoft.com) itself does not really specify how the MSK is derived. The spec says: 3.1.5.1 Master Session Key (MSK) Derivation Upon successful authentication, Extensible Authentication Protocol Method for Microsoft CHAP derives the Master Session Key ([RFC3748]), as specified in [RFC3079], section 3.3. But Section 3.3 of RFC 3079 is not about EAP. It does specify how to calculate a 128-bit MasterKey, a 128-bit MasterSendKey, a 128-bit MasterReceiveKey, a 128-bit SendSessionKey, and a 128-bit ReceiveSessionKey. But how to get an EAP MSK from those is not specified. The PEAP specification (also on msdn.microsoft.com) specifies how to derive an "ISK" from MS-MPPE-Send-Key and MS-MPPE-Recv-Key produced by the inner method (but not from inner method MSK!). 3.1.5.6.2.2 Intermediate PEAP MAC Key (IPMK) and Compound MAC Key (CMK) [..] Peer ISK =3D MS-MPPE-Send-Key | MS-MPPE-Recv-Key Server ISK =3D MS-MPPE-Recv-Key | MS-MPPE-Send-Key So even PEAP seems to use both orders of send/recv keys... (But I agree that it wouldn't hurt to say which order is used where.) Best regards, Pasi From bernard_aboba@hotmail.com Thu Feb 12 07:51:39 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1AAA3A6827 for ; Thu, 12 Feb 2009 07:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhCHUfJtNssZ for ; Thu, 12 Feb 2009 07:51:39 -0800 (PST) Received: from blu0-omc3-s29.blu0.hotmail.com (blu0-omc3-s29.blu0.hotmail.com [65.55.116.104]) by core3.amsl.com (Postfix) with ESMTP id D67C63A6848 for ; Thu, 12 Feb 2009 07:51:38 -0800 (PST) Received: from BLU137-W20 ([65.55.116.72]) by blu0-omc3-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 07:51:44 -0800 Message-ID: X-Originating-IP: [24.16.117.112] From: Bernard Aboba To: , Date: Thu, 12 Feb 2009 07:51:44 -0800 Importance: Normal In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E79E917C@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727E79E917C@NOK-EUMSG-01.mgdnok.nokia.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2009 15:51:44.0529 (UTC) FILETIME=[CDF46010:01C98D29] Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 15:51:39 -0000 > But Section 3.3 of RFC 3079 is not about EAP. It does specify how to > calculate a 128-bit MasterKey=2C a 128-bit MasterSendKey=2C a 128-bit > MasterReceiveKey=2C a 128-bit SendSessionKey=2C and a 128-bit > ReceiveSessionKey. But how to get an EAP MSK from those is not > specified. RFC 5216 describes the relationship between the MSK and the receive and send keys (which was how the MSK was originally defined in RFC 2716): Enc-RECV-Key =3D MSK(0=2C31) =3D Peer to Authenticator Encryption Key (MS-MPPE-Recv-Key in [RFC2548]). Also known as the PMK in [IEEE-802.11]. Enc-SEND-Key =3D MSK(32=2C63) =3D Authenticator to Peer Encryption Key (MS-MPPE-Send-Key in [RFC2548] From jsalowey@cisco.com Thu Feb 12 08:14:55 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE2F28C218 for ; Thu, 12 Feb 2009 08:14:55 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ou5mxT86+2R for ; Thu, 12 Feb 2009 08:14:54 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0B3ED28C0E9 for ; Thu, 12 Feb 2009 08:14:51 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,197,1233532800"; d="scan'208";a="63234587" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 12 Feb 2009 16:14:51 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1CGEpKM013591; Thu, 12 Feb 2009 08:14:51 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n1CGEpL5003097; Thu, 12 Feb 2009 16:14:51 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Feb 2009 08:14:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Feb 2009 08:14:50 -0800 Message-ID: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E79E917C@NOK-EUMSG-01.mgdnok.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Key derivation differences Thread-Index: AcmMj99pRXpdteTXSTSMuchTmVBIsgAghxVwAAU0iDA= References: <808FD6E27AD4884E94820BC333B2DB7727E79E917C@NOK-EUMSG-01.mgdnok.nokia.com> From: "Joseph Salowey (jsalowey)" To: , , X-OriginalArrivalTime: 12 Feb 2009 16:14:51.0404 (UTC) FILETIME=[0898B4C0:01C98D2D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2201; t=1234455291; x=1235319291; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20Key=20derivation=20differences |Sender:=20; bh=xeaV1r+nYtEuYjCFsuRvgDZ4uv03+9/tz3wI126hL7A=; b=gO5asj4NLlfsq/5wDtz/9jlhLnqchlgOdyR/aupUI4AHgyysNuDQbPpc/g ohXgEzkkIN3LrWpErhOqBhWujZbi+lUgEeWcLcJmOI/CeUp0TZd4gN1LT7Xn ZXqZZ4rhAu; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 16:14:55 -0000 Interesting, so it looks like EAP-MSCHAPv2 isn't fully defined except within a tunnel method, so its behavior is specific to the tunnel method... =20 > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Pasi.Eronen@nokia.com > Sent: Thursday, February 12, 2009 5:18 AM > To: bernard_aboba@hotmail.com; emu@ietf.org > Subject: Re: [Emu] Key derivation differences >=20 > Bernard Aboba wrote: > > Are you suggesting that the version of EAP-MSCHAPv2=20 > described in the=20 > > document differs in terms of the MSK/EMSK derivation? Or are you=20 > > suggesting that further details are needed on how padding is=20 > > accomplished with respect to ISK derivation? >=20 > Hmm.. it seems the EAP-MSCHAPv2 specification (on=20 > msdn.microsoft.com) itself does not really specify how the=20 > MSK is derived. The spec says: >=20 > 3.1.5.1 Master Session Key (MSK) Derivation >=20 > Upon successful authentication, Extensible Authentication Protocol > Method for Microsoft CHAP derives the Master Session Key > ([RFC3748]), as specified in [RFC3079], section 3.3. >=20 > But Section 3.3 of RFC 3079 is not about EAP. It does specify=20 > how to calculate a 128-bit MasterKey, a 128-bit=20 > MasterSendKey, a 128-bit MasterReceiveKey, a 128-bit=20 > SendSessionKey, and a 128-bit ReceiveSessionKey. But how to=20 > get an EAP MSK from those is not specified. >=20 > The PEAP specification (also on msdn.microsoft.com) specifies=20 > how to derive an "ISK" from MS-MPPE-Send-Key and=20 > MS-MPPE-Recv-Key produced by the inner method (but not from=20 > inner method MSK!). >=20 > 3.1.5.6.2.2 Intermediate PEAP MAC Key (IPMK) and Compound=20 > MAC Key (CMK) > [..] > Peer ISK =3D MS-MPPE-Send-Key | MS-MPPE-Recv-Key > Server ISK =3D MS-MPPE-Recv-Key | MS-MPPE-Send-Key >=20 > So even PEAP seems to use both orders of send/recv keys... >=20 > (But I agree that it wouldn't hurt to say which order is used > where.) >=20 > Best regards, > Pasi > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20 From hzhou@cisco.com Thu Feb 12 08:25:48 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FDED3A6929 for ; Thu, 12 Feb 2009 08:25:48 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUGdY+jxV64t for ; Thu, 12 Feb 2009 08:25:47 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 6F1283A6915 for ; Thu, 12 Feb 2009 08:25:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,197,1233532800"; d="scan'208";a="36872457" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 12 Feb 2009 16:25:52 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1CGPqRx015450; Thu, 12 Feb 2009 11:25:52 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1CGPqJs029813; Thu, 12 Feb 2009 16:25:52 GMT Received: from xmb-rtp-212.amer.cisco.com ([64.102.31.111]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Feb 2009 11:25:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Feb 2009 11:25:47 -0500 Message-ID: <9958B444368E884DBB215F3FEF36F5B708FCB9F2@xmb-rtp-212.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Key derivation differences Thread-Index: AcmNKdIlvLOhSByPRgWAzArTJ/CGEAAAmQWA References: <808FD6E27AD4884E94820BC333B2DB7727E79E917C@NOK-EUMSG-01.mgdnok.nokia.com> From: "Hao Zhou (hzhou)" To: "Bernard Aboba" , , X-OriginalArrivalTime: 12 Feb 2009 16:25:52.0293 (UTC) FILETIME=[92845D50:01C98D2E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1935; t=1234455952; x=1235319952; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hzhou@cisco.com; z=From:=20=22Hao=20Zhou=20(hzhou)=22=20 |Subject:=20RE=3A=20[Emu]=20Key=20derivation=20differences |Sender:=20 |To:=20=22Bernard=20Aboba=22=20, =20,=0A=20=20=20=20=20=20=20=20; bh=OnESdpHCTOHXCFR3E1qwR0WhFU5Qi2h0PWj90gurHDc=; b=TaRcl5M9nhEXK/g1YXYK/ZK/jECHiqWbPNHcEGOYmwBQbOCZwMN5g6zMta 5qhnuSo/aYdjL+91Ley/rZO1cP7KN8l9sZyeAPVgOEC6KkkELEKebpolG7M3 fg5Rav+Tgf; Authentication-Results: rtp-dkim-2; header.From=hzhou@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 16:25:48 -0000 First, RFC5216 is about EAP-TLS, not sure it can be applied to EAP-MSCHAPv2 or other EAP method.=20 Second, in the EAP-MSCHAPv2 case, there are only two 16 octets MPPE keys generated, not the two 32 octets MSK (0.31) and MSK (32, 63) as described in RFC5216. So it's not really clear to me how to put these two 16 octet keys together to form the 64 octet MSK (as defined by RFC3748). It's conceivable that different interpretations could happen. Third, I probably agree with Jouni that it's best to define how MSK is derived in each EAP method documentation itself, as each recent EAP method RFC adheres to. That would leave no room for different interpretations that is specific to the tunnel method.=20 > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Bernard Aboba > Sent: Thursday, February 12, 2009 10:52 AM > To: pasi.eronen@nokia.com; emu@ietf.org > Subject: Re: [Emu] Key derivation differences >=20 >=20 > > But Section 3.3 of RFC 3079 is not about EAP. It does=20 > specify how to=20 > > calculate a 128-bit MasterKey, a 128-bit MasterSendKey, a 128-bit=20 > > MasterReceiveKey, a 128-bit SendSessionKey, and a 128-bit=20 > > ReceiveSessionKey. But how to get an EAP MSK from those is not=20 > > specified. >=20 > RFC 5216 describes the relationship between the MSK and the=20 > receive and send keys (which was how the MSK was originally=20 > defined in RFC 2716): >=20 > Enc-RECV-Key =3D MSK(0,31) =3D Peer to Authenticator Encryption Key > (MS-MPPE-Recv-Key in [RFC2548]). Also known as the > PMK in [IEEE-802.11]. > Enc-SEND-Key =3D MSK(32,63) =3D Authenticator to Peer Encryption = Key > (MS-MPPE-Send-Key in [RFC2548]=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20 From Pasi.Eronen@nokia.com Thu Feb 12 08:27:14 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA5653A6A28 for ; Thu, 12 Feb 2009 08:27:14 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXBPEj-QU1GA for ; Thu, 12 Feb 2009 08:27:14 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0136B3A6929 for ; Thu, 12 Feb 2009 08:27:13 -0800 (PST) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n1CGQhNh010471; Thu, 12 Feb 2009 10:27:17 -0600 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 18:26:41 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 18:26:36 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 18:26:31 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.106]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 12 Feb 2009 17:26:31 +0100 From: To: , Date: Thu, 12 Feb 2009 17:26:30 +0100 Thread-Topic: [Emu] Key derivation differences Thread-Index: AcmNKdSuJHZrigYoQ4aeIyEgJ1xVUwABCrAQ Message-ID: <808FD6E27AD4884E94820BC333B2DB7727E79E9378@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727E79E917C@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2009 16:26:31.0718 (UTC) FILETIME=[AA042460:01C98D2E] X-Nokia-AV: Clean Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Feb 2009 16:27:14 -0000 Bernard Aboba wrote: > > But Section 3.3 of RFC 3079 is not about EAP. It does specify how to > > calculate a 128-bit MasterKey, a 128-bit MasterSendKey, a 128-bit > > MasterReceiveKey, a 128-bit SendSessionKey, and a 128-bit > > ReceiveSessionKey. But how to get an EAP MSK from those is not > > specified. > > RFC 5216 describes the relationship between the MSK and the receive > and send keys (which was how the MSK was originally defined > in RFC 2716): > > Enc-RECV-Key =3D MSK(0,31) =3D Peer to Authenticator Encryption Key > (MS-MPPE-Recv-Key in [RFC2548]). Also known as the > PMK in [IEEE-802.11]. > Enc-SEND-Key =3D MSK(32,63) =3D Authenticator to Peer Encryption Key > (MS-MPPE-Send-Key in [RFC2548] Right, but this formula assumes that MS-MPPE-Recv-Key and -Send-Key are 32 bytes (256 bits). The keys produced by RFC 3079 Section 3.3 are only 128 bits, so concatenating any two of them (in any order) doesn't produce an EAP MSK (which is at least 64 octets). Best regards, Pasi From bernard_aboba@hotmail.com Thu Feb 12 18:50:52 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0FA3A6D6A for ; Thu, 12 Feb 2009 18:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DftakfSuhiT for ; Thu, 12 Feb 2009 18:50:51 -0800 (PST) Received: from blu0-omc3-s22.blu0.hotmail.com (blu0-omc3-s22.blu0.hotmail.com [65.55.116.97]) by core3.amsl.com (Postfix) with ESMTP id EE2373A6D64 for ; Thu, 12 Feb 2009 18:50:50 -0800 (PST) Received: from BLU137-W41 ([65.55.116.74]) by blu0-omc3-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Feb 2009 18:50:57 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_86416860-5737-4550-990a-339800ffd37c_" X-Originating-IP: [131.107.0.80] From: Bernard Aboba To: Date: Thu, 12 Feb 2009 18:50:56 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 13 Feb 2009 02:50:57.0159 (UTC) FILETIME=[E528C170:01C98D85] Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Feb 2009 02:50:52 -0000 --_86416860-5737-4550-990a-339800ffd37c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jouni Malinen said: =20 "As far as MSK derivation for an inner method being tunnel methodspecific i= s concerned=2C I do not agree with that. It should be up to theinner method= specification to define how MSK is derived and tunnelmethod ISK should jus= t use that MSK.I do not remember anymore where exactly I found this=2C but = probablybased on the MSCHAPv2 documents and the way MS-MPPE keys are used i= nother methods=2C I ended up with EAP-MSCHAPv2 MSK =3D server MS-MPPE-Re= cv-Key | server MS-MPPE-Send-KeyThis is the order used in EAP-PEAPv0 crypto= binding derivation.In EAP-FAST=2C the opposite order is used: MSK =3D se= rver MS-MPPE-Send-Key | server MS-MPPE-Recv-Key"I agree with this. Allowin= g tunnel methods to re-define the MSK derivation of inner EAP methods does = not make sense.=20 =20 With respect to the composition of the MSK from the server MS-MPPE-Recv-Key= and MS-MPPE-Send-Key=2C the formula you cite above is correct=2C which is confirmed in RFC 5216=2C Section 2.3:=20 =20 Enc-RECV-Key =3D MSK(0=2C31) =3D Peer to Authenticator Encryption Key = (MS-MPPE-Recv-Key in [RFC2548]). Also known as the = PMK in [IEEE-802.11]. Enc-SEND-Key =3D MSK(32=2C63) =3D Authenti= cator to Peer Encryption Key (MS-MPPE-Send-Key in [RFC2548= ]) =20 So yes=2C the EAP-FAST formula is reversed.=20 =20 With respect to padding=2C Pasi points out correctly that neither RFC 2759 = nor 3079 describe how the 128-bit keys produced by MS-CHAPv2 are to be inte= rpretted in this formula. By IETF 74=2C I'm hoping to have one or more MS= -CHAPv2 errata to clarify this and other issues that have come up (such as = internationalization).=20 =20 =20 = --_86416860-5737-4550-990a-339800ffd37c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Jouni Malinen said:
 =3B
"As far as MSK derivation for an inner method being tunnel method
specif= ic is concerned=2C I do not agree with that. It should be up to the
inne= r method specification to define how MSK is derived and tunnel
method IS= K should just use that MSK.

I do not remember anymore where exactly = I found this=2C but probably
based on the MSCHAPv2 documents and the way= MS-MPPE keys are used in
other methods=2C I ended up with EAP-MSCHAPv2<= BR> =3B =3B =3B MSK =3D server MS-MPPE-Recv-Key | server MS-MPP= E-Send-Key

This is the order used in EAP-PEAPv0 cryptobinding deriva= tion.

In EAP-FAST=2C the opposite order is used:
 =3B =3B=  =3B MSK =3D server MS-MPPE-Send-Key | server MS-MPPE-Recv-Key
"
=
I agree with this. =3B Allowing tunnel methods to re-define the MSK= derivation =3Bof inner EAP methods does not make sense.
 =3B
With respect to the composition of the MSK from the =3Bserver MS-MPPE-R= ecv-Key and MS-MPPE-Send-Key=2C =3Bthe formula you
cite above is correct=2C which is confirmed in RFC 5216=2C Section 2.3:  =3B
 =3B =3B Enc-RECV-Key =3D MSK(0=2C31) =3D Peer to Authenticator Enc= ryption Key
 =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B =3B =3B = =3B (MS-MPPE-Recv-Key in [RFC2548]). =3B Also known as the
 =3B&= nbsp=3B =3B =3B =3B =3B =3B =3B =3B =3B&nbs= p=3B =3B =3B =3B =3B =3B =3B PMK in [IEEE-802.11].<= BR> =3B =3B Enc-SEND-Key =3D MSK(32=2C63) =3D Authenticator to Peer= Encryption Key
 =3B =3B =3B =3B =3B =3B =3B=  =3B =3B =3B =3B =3B =3B =3B =3B =3B&nb= sp=3B (MS-MPPE-Send-Key in [RFC2548])
 =3B
So yes=2C the EAP-FAST formula is reversed.
 =3B
With respect to padding=2C Pasi points out correctly that neither RFC 2759 = nor 3079 describe how the 128-bit keys produced by MS-CHAPv2 are to be inte= rpretted in this formula. =3B =3B By IETF 74=2C I'm hoping to have = one or more MS-CHAPv2 errata to clarify this and other issues that have com= e up (such as internationalization).
 =3B
 =3B
 =3B
= --_86416860-5737-4550-990a-339800ffd37c_-- From glenzorn@comcast.net Tue Feb 17 02:20:57 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0893828C156 for ; Tue, 17 Feb 2009 02:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFl+D3im1nSm for ; Tue, 17 Feb 2009 02:20:56 -0800 (PST) Received: from QMTA04.emeryville.ca.mail.comcast.net (qmta04.emeryville.ca.mail.comcast.net [76.96.30.40]) by core3.amsl.com (Postfix) with ESMTP id 0B08D28C152 for ; Tue, 17 Feb 2009 02:20:55 -0800 (PST) Received: from OMTA04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by QMTA04.emeryville.ca.mail.comcast.net with comcast id GyDP1b00F0lTkoCA4yM77D; Tue, 17 Feb 2009 10:21:07 +0000 Received: from gwzPC ([124.121.211.18]) by OMTA04.emeryville.ca.mail.comcast.net with comcast id GyLd1b0020QNFrQ8QyLj3o; Tue, 17 Feb 2009 10:21:05 +0000 From: "Glen Zorn" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , "'Hannes Tschofenig'" References: <000d01c9899e$0ef1b750$2cd525f0$@net><005d01c98ceb$91f44dc0$b5dce940$@net><072201c98cee$d3b79a20$0201a8c0@nsnintra.net><006d01c98cef$ea02bc50$be0834f0$@net><004301c98f9d$18744400$0201a8c0@nsnintra.net> <029f01c990b7$d6bf83a0$843e8ae0$@net> <3D3C75174CB95F42AD6BCC56E5555B45010DB86A@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45010DB86A@FIESEXC015.nsn-intra.net> Date: Tue, 17 Feb 2009 17:20:32 +0700 Message-ID: <034401c990e9$6f05f190$4d11d4b0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmJne22RSz8ctHLRr21sWgCN0HuDQDSTJfgAAHKDdAAAExZ4ACoykjgAElBYYAAB6qBkAAECsHA Content-Language: en-us Cc: geopriv@ietf.org, emu@ietf.org, Bernard_Aboba@hotmail.com, 'Mark Jones' , 'Avi Lior' , iesg@ietf.org Subject: Re: [Emu] [Geopriv] Comments on draft-ietf-geopriv-radius-lo-20.txt PART 2 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 10:20:57 -0000 Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofenig@nsn.com] writes: Copying the emu WG & IESG because this seems relevant to an on-going debate in that WG... > >Great, so change it. :-) > > This stuff is already implemented and it is also referenced by > specifications outside the IETF. The following text is included on the first page of every Internet-Draft, including this one: Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." EAP-FAST is a _proprietary_ protocol, but the "Internet-Draft" describing its bizarre pirating of IANA-allocated EAP numbers can't be changed because EAP-FAST has been "implemented"; yet for some even more bizarre reason, the IESG seems to believe that the same people who ignore the transient nature of Internet-Drafts will for some reason honor their weak-kneed "IESG Note"! Now, yet another Internet-Draft can't be changed because it's been implemented. If the people who implemented these attributes can read, then they certainly would have designed their code in such a way that it's easily modifiable; if not, too bad. Furthermore, the claim is that these attributes are opaque to any RADIUS server, so the only code needing change would be special purpose anyway. OTOH, maybe we should replace the boilerplate above with something like Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time unless somebody somewhere has written some code implementing the protocol described therein. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress" except if you really feel like it. All problems solved! > I am a bit reluctant to changing the spec just for the fun of it. The reason to change the spec is to bring it more in line with the RADIUS design guidelines, no for the fun of it. There is no need to use a complex attribute in this case, so don't do it. ... From aland@deployingradius.com Tue Feb 24 07:33:43 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453443A6A2D for ; Tue, 24 Feb 2009 07:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tngepu-A4NXW for ; Tue, 24 Feb 2009 07:33:42 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 8FB9D3A6956 for ; Tue, 24 Feb 2009 07:33:42 -0800 (PST) Received: from Thor.local (unknown [194.219.237.151]) by liberty.deployingradius.com (Postfix) with ESMTPSA id F05581234471 for ; Tue, 24 Feb 2009 16:34:00 +0100 (CET) Message-ID: <49A41367.2060508@deployingradius.com> Date: Tue, 24 Feb 2009 16:33:59 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: emu@ietf.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Emu] Call for agenda items for IETF 74 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 15:33:43 -0000 This is a call for agenda items for IETF 74. Interested parties should email the chairs, and ask for a time slot. Alan DeKok. From bernard_aboba@hotmail.com Tue Feb 24 09:58:43 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD63C28C171 for ; Tue, 24 Feb 2009 09:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRFU7srHzxs0 for ; Tue, 24 Feb 2009 09:58:43 -0800 (PST) Received: from blu0-omc3-s30.blu0.hotmail.com (blu0-omc3-s30.blu0.hotmail.com [65.55.116.105]) by core3.amsl.com (Postfix) with ESMTP id 077113A6977 for ; Tue, 24 Feb 2009 09:58:42 -0800 (PST) Received: from BLU137-W33 ([65.55.116.72]) by blu0-omc3-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Feb 2009 09:59:02 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_6be9ce50-7d94-491b-a56c-ad559938f00d_" X-Originating-IP: [131.107.0.75] From: Bernard Aboba To: , Date: Tue, 24 Feb 2009 09:59:02 -0800 Importance: Normal In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727E79E9378@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727E79E917C@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727E79E9378@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 X-OriginalArrivalTime: 24 Feb 2009 17:59:02.0672 (UTC) FILETIME=[93998100:01C996A9] Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 17:58:43 -0000 --_6be9ce50-7d94-491b-a56c-ad559938f00d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > RFC 5216 describes the relationship between the MSK and the receive > > and send keys (which was how the MSK was originally defined > > in RFC 2716): > > > > Enc-RECV-Key =3D MSK(0=2C31) =3D Peer to Authenticator Encryption Key > > (MS-MPPE-Recv-Key in [RFC2548]). Also known as the > > PMK in [IEEE-802.11]. > > Enc-SEND-Key =3D MSK(32=2C63) =3D Authenticator to Peer Encryption Key > > (MS-MPPE-Send-Key in [RFC2548] >=20 > Right=2C but this formula assumes that MS-MPPE-Recv-Key and -Send-Key > are 32 bytes (256 bits). The keys produced by RFC 3079 Section 3.3 > are only 128 bits=2C so concatenating any two of them (in any order) > doesn't produce an EAP MSK (which is at least 64 octets). Does the following more accurately describe what you are seeing? =20 At the end of successful authentication=2C EAP-MSCHAPv2 derives two 16-byte MPPE keys as specified in [RFC3079] Section 3.3. The Master Session Key ([= RFC3748]) is derived from the two MPPE keys as follows: =20 MSK =3D 16-byte MPPE-Send-Key + 16 bytes zeroes (padding) + 16-byte MPPE-Re= ceive-Key + 16 bytes zeroes (padding) --_6be9ce50-7d94-491b-a56c-ad559938f00d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B >=3B RFC 5216 describes the relationship between the MSK and the r= eceive
>=3B >=3B and send keys (which was how the MSK was originally= defined
>=3B >=3B in RFC 2716):
>=3B >=3B
>=3B >=3B E= nc-RECV-Key =3D MSK(0=2C31) =3D Peer to Authenticator Encryption Key
>= =3B >=3B (MS-MPPE-Recv-Key in [RFC2548]). Also known as the
>=3B >= =3B PMK in [IEEE-802.11].
>=3B >=3B Enc-SEND-Key =3D MSK(32=2C63) = =3D Authenticator to Peer Encryption Key
>=3B >=3B (MS-MPPE-Send-Key= in [RFC2548]
>=3B
>=3B Right=2C but this formula assumes that M= S-MPPE-Recv-Key and -Send-Key
>=3B are 32 bytes (256 bits). The keys p= roduced by RFC 3079 Section 3.3
>=3B are only 128 bits=2C so concatena= ting any two of them (in any order)
>=3B doesn't produce an EAP MSK (w= hich is at least 64 octets).

Does the following more accurately describe what you are seeing?
 =3B
At the end of successful authentication=2C EAP-MSCHAPv2 derives two 16-byte=
MPPE keys as specified in [RFC3079] Section 3.3. =3B The Master Session= Key ([RFC3748])
is derived from the two MPPE keys as follows:
 =3B
MSK =3D 16-byte MPPE-Send-Key + 16 bytes zeroes (padding) + 16-byte MPPE-Re= ceive-Key + 16 bytes zeroes (padding)
= --_6be9ce50-7d94-491b-a56c-ad559938f00d_-- From j@w1.fi Tue Feb 24 10:33:28 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1527028C24F for ; Tue, 24 Feb 2009 10:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC-mt5lILyxU for ; Tue, 24 Feb 2009 10:33:27 -0800 (PST) Received: from jmalinen.user.openhosting.com (128-177-27-249.ip.openhosting.com [128.177.27.249]) by core3.amsl.com (Postfix) with ESMTP id 2393F28C24E for ; Tue, 24 Feb 2009 10:33:26 -0800 (PST) Received: from jm (a91-155-82-88.elisa-laajakaista.fi [91.155.82.88]) (authenticated bits=0) by jmalinen.user.openhosting.com (8.13.8/8.13.8) with ESMTP id n1OIXgP5010454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Feb 2009 13:33:43 -0500 Received: by jm (sSMTP sendmail emulation); Tue, 24 Feb 2009 20:33:42 +0200 Date: Tue, 24 Feb 2009 20:33:41 +0200 From: Jouni Malinen To: Bernard Aboba Message-ID: <20090224183341.GA11396@jm.kir.nu> References: <808FD6E27AD4884E94820BC333B2DB7727E79E917C@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB7727E79E9378@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: emu@ietf.org Subject: Re: [Emu] Key derivation differences X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Feb 2009 18:33:28 -0000 On Tue, Feb 24, 2009 at 09:59:02AM -0800, Bernard Aboba wrote: > Does the following more accurately describe what you are seeing? > At the end of successful authentication, EAP-MSCHAPv2 derives two 16-byte > > MPPE keys as specified in [RFC3079] Section 3.3. The Master Session Key ([RFC3748]) > > is derived from the two MPPE keys as follows: > > MSK = 16-byte MPPE-Send-Key + 16 bytes zeroes (padding) + 16-byte MPPE-Receive-Key + 16 bytes zeroes (padding) This does not match with the way ISK is generated in either EAP-FAST or EAP-PEAPv0 with cryptobinding. The main problem is in there being no clear description on how to derive a 64-octet MSK from EAP-MSCHAPv2. Anyway, ISK is only going to use up to 32 octets of MSK (the first octets; anything beyond that will be ignored). Consequently, the zero padding in the MSK must not occur in that part to match the current uses. In addition, the Send vs. Recv key concept is problematic since the EAP peer and server (or well, more likely authenticator and supplicant) have different directions for sending and receiving. If we want to define EAP-MSCHAPv2 MSK derivation in a way that matches with the normal ISK generation rules (take first 32 octets) in EAP-PEAPv0 with cryptobinding, we would get something like this: MSK = 16-byte server/authenticator MS-MPPE-Send-Key | 16-byte server/authenticator MS-MPPE-Recv-Key | 32 bytes of something (e.g., zeroes; ISK does not care, some other uses might, so likely better to use something else than zeroes..) On the peer, the first keys would be peer MS-MPPE-Recv-Key | peer MS-MPPE-Send-Key (i.e., reverse Recv/Send). If we want to define EAP-MSCHAPv2 MSK derivation in a way that matches with the normal ISK generation rules in EAP-FAST, we would have to swap Send and Recv in the above description for EAP-PEAPv0 due to the other order of Send/Recv MPPE keys used there. In other words, we cannot come up with a EAP-MSCHAPv2 MSK derivation rules that would cleanly fit into all deployed uses and there will unfortunately be need for tunnel method specific exception in either EAP-PEAP with cryptobinding or EAP-FAST. Either way, it would be useful to get this documented clearly so that all future uses of EAP-MSCHAPv2 would be able to refer to an existing specification instead of having to come up with their own MSK/ISK derivation rules as was done with EAP-PEAP cryptobinding and EAP-FAST. -- Jouni Malinen PGP id EFC895FA From rfc-editor@rfc-editor.org Wed Feb 25 15:30:04 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A038728C280; Wed, 25 Feb 2009 15:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.709 X-Spam-Level: X-Spam-Status: No, score=-16.709 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, FUZZY_CPILL=0.001, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WjJc+HBIbW9; Wed, 25 Feb 2009 15:30:03 -0800 (PST) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id CF89628C288; Wed, 25 Feb 2009 15:30:03 -0800 (PST) Received: by bosco.isi.edu (Postfix, from userid 70) id 896DF233E9A; Wed, 25 Feb 2009 15:29:29 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090225232929.896DF233E9A@bosco.isi.edu> Date: Wed, 25 Feb 2009 15:29:29 -0800 (PST) Cc: emu@ietf.org, rfc-editor@rfc-editor.org Subject: [Emu] RFC 5433 on Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Feb 2009 23:30:04 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5433 Title: Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method Author: T. Clancy, H. Tschofenig Status: Standards Track Date: February 2009 Mailbox: clancy@ltsnet.net, Hannes.Tschofenig@gmx.net Pages: 38 Characters: 80452 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-emu-eap-gpsk-17.txt URL: http://www.rfc-editor.org/rfc/rfc5433.txt This memo defines an Extensible Authentication Protocol (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight shared-key authentication protocol supporting mutual authentication and key derivation. [STANDARDS TRACK] This document is a product of the EAP Method Update Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From root@core3.amsl.com Thu Feb 26 17:15:01 2009 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9F3263A6A43; Thu, 26 Feb 2009 17:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090227011501.9F3263A6A43@core3.amsl.com> Date: Thu, 26 Feb 2009 17:15:01 -0800 (PST) Cc: emu@ietf.org Subject: [Emu] I-D Action:draft-ietf-emu-eaptunnel-req-02.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Feb 2009 01:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : Requirements for a Tunnel Based EAP Method Author(s) : K. Hoeper, et al. Filename : draft-ietf-emu-eaptunnel-req-02.txt Pages : 24 Date : 2009-02-26 This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-eaptunnel-req-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-emu-eaptunnel-req-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-26170941.I-D@ietf.org> --NextPart--