From pascal.urien@gmail.com Tue Aug 2 10:09:08 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AF721F86DF for ; Tue, 2 Aug 2011 10:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.173 X-Spam-Level: X-Spam-Status: No, score=-3.173 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVn4RQxDiruk for ; Tue, 2 Aug 2011 10:09:07 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 27C0F21F86DC for ; Tue, 2 Aug 2011 10:09:07 -0700 (PDT) Received: by qyk29 with SMTP id 29so4365748qyk.10 for ; Tue, 02 Aug 2011 10:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ga3+8Ks6dnLtyp6ozFQvmiTul2FDUyzhwITY7ViYGIg=; b=JYQ5jk8lrQU2DG739DiKAEtPQ0tdPCyDu79hvgMc8mUdUSDfrd9y8h/KRwa4YaPfQ5 WoaTHRUu5ItmspH69H/2Dkrp6v02bIlootGjuIqtlalVn4KnY13t+DU9A/oP1VeoXQz0 F7Jt5DLRRc4P7TBQ2Fqh7/RTRCYtRcj0qiLBQ= MIME-Version: 1.0 Received: by 10.229.233.74 with SMTP id jx10mr673240qcb.262.1312304954775; Tue, 02 Aug 2011 10:09:14 -0700 (PDT) Received: by 10.229.50.66 with HTTP; Tue, 2 Aug 2011 10:09:14 -0700 (PDT) In-Reply-To: <1595-1307461282-359547@sneakemail.com> References: <1595-1307461282-359547@sneakemail.com> Date: Tue, 2 Aug 2011 19:09:14 +0200 Message-ID: From: Pascal Urien To: Michael Thomsen Content-Type: multipart/alternative; boundary=00163630fb8daa999604a988ce02 Cc: emu@ietf.org Subject: Re: [Emu] draft-urien-eap-smartcard-20.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:09:08 -0000 --00163630fb8daa999604a988ce02 Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, That you very much for this review. The new draft, http://tools.ietf.org/html/draft-urien-eap-smartcard-21 has been updated with the corrected value 1: Corrected In test #2 (Wrong SQN) you're calculating MAC-S with a non-zero AMF giving 7CD924E739F12369. According to 3GPP TS 33.102 AMF is set to zeros when calculating AUTS. When doing that I get 0010C1DA38A75A31 instead. 2: Corrected >>In test #6 (Reauth, Good Counter) the counter value is 0000, whereas RFC4187 specifies that the minimum counter value of the first packet should be 0001. Also, you use the 64-byte MSK value generated in test #1 instead of MK, whereas RFC4187 specifies XKEY'=SHA1(Identity|counter|NONCE_S|MK). This obviously gives a quite different result than what you get. 3:To be Corrected In the "Get MSK" commands in test #1 and test #6 the first 32 bytes of MSK are switched with the last 32 bytes of MSK. I don't see anything in your document stating that this should be the behaviour. The order is switched on supllicant side. To be documented 4: Corrected In test #6 and test #7 the MAC is not calculated over (EAP-packet | Nounce-S), as specified in RFC4187. Best Regards Pascal 2011/6/7 Michael Thomsen > Hi Pascal, > > sorry, I don't quite understand what you mean by "former EAP-AKA version", > but I've stumpled upon a few things I don't quite understand: > > 1: > -- > In test #2 (Wrong SQN) you're calculating MAC-S with a non-zero AMF giving > 7CD924E739F12369. According to 3GPP TS 33.102 AMF is set to zeros when > calculating AUTS. When doing that I get 0010C1DA38A75A31 instead. > > According to RFC4187 AT_AUTS should include "the AKA AUTS parameter, 112 > bits" I don't see anything about the AMF field not being zeroed, as it is > per usual. > > 2: > -- > In test #6 (Reauth, Good Counter) the counter value is 0000, whereas > RFC4187 specifies that the minimum counter value of the first packet should > be 0001. Also, you use the 64-byte MSK value generated in test #1 instead of > MK, whereas RFC4187 specifies XKEY'=SHA1(Identity|counter|NONCE_S|MK). This > obviously gives a quite different result than what you get. > > 3: > -- > In the "Get MSK" commands in test #1 and test #6 the first 32 bytes of MSK > are switched with the last 32 bytes of MSK. I don't see anything in your > document stating that this should be the behaviour. > > 4: > -- > In test #6 and test #7 the MAC is not calculated over (EAP-packet | > Nounce-S), as specified in RFC4187. > > Kind regards, > Michael Thomsen > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > --00163630fb8daa999604a988ce02 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Michael,
=A0
That you very much for this review.
=A0
=A0T= he new draft, http://tools.ietf.org/html/draft-urien-eap-smartcard-21=A0 has b= een updated with the corrected value
=A0
1: Corrected

In test #2 (Wrong SQN) you're calculating MAC-S with a non-zero AMF = giving 7CD924E739F12369. According to 3GPP TS 33.102 AMF is set to zeros wh= en calculating AUTS. When doing that I get 0010C1DA38A75A31 instead.

2: Corrected

>>In test #6 (Reauth, Good Counter) the counter value is 0000, whe= reas RFC4187 specifies that the minimum counter value of the first packet s= hould be 0001. Also, you use the 64-byte MSK value generated in test #1 ins= tead of MK, whereas RFC4187 specifies XKEY'=3DSHA1(Identity|counter|NON= CE_S|MK). This obviously gives a quite different result than what you get.<= /p>

3:To be Corrected

In the "Get MSK" commands in test #1 and test #6 the first 32 = bytes of MSK are switched with the last 32 bytes of MSK. I don't see an= ything in your document stating that this should be the behaviour.

The order is switched on supllicant side. To be documented

4: Corrected

In test #6 and test #7 the MAC is not calculated over (EAP-packet | Noun= ce-S), as specified in RFC4187.

=A0
Best Regards
=A0
Pascal

2011/6/7 Michael Thomsen <<= a href=3D"mailto:ietf-denmike@snkmail.com">ietf-denmike@snkmail.com>=
Hi Pascal,

sorry, I don&#= 39;t quite understand what you mean by "former EAP-AKA version", = but I've stumpled upon a few things I don't quite understand:

1:
--
In test #2 (Wrong SQN) you're calculating MAC-S with a = non-zero AMF giving 7CD924E739F12369. According to 3GPP TS 33.102 AMF is se= t to zeros when calculating AUTS. When doing that I get 0010C1DA38A75A31 in= stead.

According to RFC4187 AT_AUTS should include "the AKA AUTS paramete= r, 112 bits" I don't see anything about the AMF field not being ze= roed, as it is per usual.

2:
--
In test #6 (Reauth, Good Count= er) the counter value is 0000, whereas RFC4187 specifies that the minimum c= ounter value of the first packet should be 0001. Also, you use the 64-byte = MSK value generated in test #1 instead of MK, whereas RFC4187 specifies XKE= Y'=3DSHA1(Identity|counter|NONCE_S|MK). This obviously gives a quite di= fferent result than what you get.

3:
--
In the "Get MSK" commands in test #1 and test #6 = the first 32 bytes of MSK are switched with the last 32 bytes of MSK. I don= 't see anything in your document stating that this should be the behavi= our.

4:
--
In test #6 and test #7 the MAC is not calculated over (EAP-= packet | Nounce-S), as specified in RFC4187.

Kind regards,
=A0Michael Thomsen
___________________________________= ____________
Emu mailing list
Emu@ietf.org
https:= //www.ietf.org/mailman/listinfo/emu

--00163630fb8daa999604a988ce02-- From pascal.urien@gmail.com Tue Aug 2 10:43:49 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E3E11E80AC for ; Tue, 2 Aug 2011 10:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.279 X-Spam-Level: X-Spam-Status: No, score=-3.279 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu09D4o7OdUI for ; Tue, 2 Aug 2011 10:43:48 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF3611E80B1 for ; Tue, 2 Aug 2011 10:43:46 -0700 (PDT) Received: by qyk9 with SMTP id 9so1884242qyk.10 for ; Tue, 02 Aug 2011 10:43:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=kdl1ktgFcsZZOfzhRM7c1OkavbatCHbnlmOSyOd5tdU=; b=rlgTqAwCoAPhjwMgByiOCA3GsUXYgC+wytUO1td9RhJ7gSYE3ooeGC5OW5wkcYrrRh +VcZ5Tl1Wf3oQr8H9mu+lI01S0gjWnOPsb4FD/cKbtQcNHozjVRqR4aQ2+EKGA0KnPFP TlilZ+nNU1RTgHqsdGUqHBLCuT59y82gInkEM= MIME-Version: 1.0 Received: by 10.229.233.74 with SMTP id jx10mr701827qcb.262.1312307035862; Tue, 02 Aug 2011 10:43:55 -0700 (PDT) Received: by 10.229.50.66 with HTTP; Tue, 2 Aug 2011 10:43:55 -0700 (PDT) Date: Tue, 2 Aug 2011 19:43:55 +0200 Message-ID: From: Pascal Urien To: emu@ietf.org Content-Type: multipart/alternative; boundary=00163630fb8db5767e04a9894a1f Subject: [Emu] EAP-TLS smart cards for payments X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2011 17:43:49 -0000 --00163630fb8db5767e04a9894a1f Content-Type: text/plain; charset=ISO-8859-1 Hi all, A payment platform was recently tested, which is based on EAP-TLS smart cards, detailled in http://tools.ietf.org/html/draft-urien-eap-smartcard-21 A paper is available at IEEE EXPLORE "A breakthrough for prepaid payment: End to end token exchange and management using secure SSL channels created by EAP-TLS smart cards" Urien, Pascal; Pasquet, Marc; Kiennert, Christophe; International Conference on Collaboration Technologies and Systems (CTS), 2011 "In this paper we present an innovative architecture for prepaid services. Digital tokens are securely exchanged between EAP-TLS smart cards used both by merchant and customer. We describe the global framework that comprises a back-office server delivering tokens, a front-office server collecting tokens from merchant terminal, merchants and customers equipped with smart cards. We detail data exchange choreography and discuss performances issues for the experimental platform built with commercial devices." Pascal --00163630fb8db5767e04a9894a1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
=A0
A payment platform was recently tested,=A0 which is based on EAP-TLS s= mart cards, detailled in http://tools.ietf.org/html/draft-urien-eap-smartcard-21
=A0
A paper is=A0available at IEEE EXPLORE
"A breakthrough for prepaid payment: End to end token exchange an= d management using secure SSL channels created by EAP-TLS smart cards"=
Urien, Pascal; Pasquet, Marc; Kiennert, Christophe;
International = Conference on Collaboration Technologies and Systems (CTS), 2011
"In this paper we present an innovative architecture for prepaid = services. Digital tokens are securely exchanged between EAP-TLS smart cards= used both by merchant and customer. We describe the global framework that = comprises a back-office server delivering tokens, a front-office server col= lecting tokens from merchant terminal, merchants and customers equipped wit= h smart cards. We detail data exchange choreography and discuss performance= s issues for the experimental platform built with commercial devices."=
=A0
Pascal
--00163630fb8db5767e04a9894a1f-- From jsalowey@cisco.com Tue Aug 9 22:31:22 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD09C21F8829 for ; Tue, 9 Aug 2011 22:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGrtVxiaFTwY for ; Tue, 9 Aug 2011 22:31:22 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 16B7E21F880C for ; Tue, 9 Aug 2011 22:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1963; q=dns/txt; s=iport; t=1312954313; x=1314163913; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=5MDhgMvRArVSfktgmL1Hxbg42iSPnzadtkwj/LEQSq0=; b=hSjfV5Do2ivPGC6zNk5h6kc6Pc6SubFaaPWOUIyODfQH+SFuFdJB/8rg +4CatmjO253PAeY2kDUcx6rZyt1GGUvrRf/LMoN5c035nMpZh/uruq4nl 3oTPPurCGhluM+qljXLF4fsSgHLpDhy9nqH6JBWZh747JYDWBqyNICM/V c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcGAH0XQk6rRDoJ/2dsb2JhbABBmCqPG3eBWQEngjKHT54VgSMBnj+FZ18Eh12LLIUKjAM X-IronPort-AV: E=Sophos;i="4.67,349,1309737600"; d="scan'208";a="11617169" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by rcdn-iport-7.cisco.com with ESMTP; 10 Aug 2011 05:31:47 +0000 Received: from [10.33.249.202] ([10.33.249.202]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p7A5VjAJ013724 for ; Wed, 10 Aug 2011 05:31:46 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2011 22:31:34 -0700 Message-Id: To: emu@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [Emu] Channel Binding attributes X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 05:31:22 -0000 At the meeting in Quebec we discussed removing attributes specific to = particular media types or lower layers and including recommendations for = a small number of generally useful attributes in the draft. =20 The attribute that seems to be most useful would be one that indicates = what protocol is carrying the EAP conversation between the EAP peer and = authenticator. Its not clear to me if there is an existing attribute = that meets this need. It seems that there are the following contenders: NAS-Port-Type (RFC-2865) - this attribute contains the physical type = port that is carrying the EAP conversation. It has values for things = like ethernet, 802.11,802.16, various flavors of PPPoE, etc. Since it = represents a physical port It does not have values for higher layer = protocols such as IKEv2 or PANA. Tunnel-Type (RFC-2868) - this attribute is used for setting up = compulsory tunnels and contains a value for IPSEC ESP tunnel. It's not = clear to me if this would be suitable to indicate IKEv2. EAP-Lower-Layer (http://tools.ietf.org/html/draft-aboba-radext-wlan-13) = - this is an draft attribute designed to indicate the EAP lower layer. = It contains several values to cover many of the EAP lower layers. IT = does cover IKEv2 and PANA. Its likely that list values need to be = augmented and cleaned up. =20 NAS-Port-Type and Tunnel-Type seem to have limitations. My initial = suggestion is the following: - Define the EAP-Lower-Layer attribute in the document - If the lower layer protocol does not define a specific attribute = indicate the lower layer type then EAP-Lower-Layer attributes MUST be = included. Would it also be useful to include NAS-Port-Type? - If the lower layer protocol does define a specific attribute then that = attribute MUST be included and EAP-Lower-Layer MAY be included. Would = it be easier just to always use EAP-Lower-Layer? =20 Thoughts? Joe= From gwz@net-zen.net Wed Aug 10 01:41:10 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DF021F8797 for ; Wed, 10 Aug 2011 01:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPOMgXHFNgly for ; Wed, 10 Aug 2011 01:41:10 -0700 (PDT) Received: from smtpauth02.prod.mesa1.secureserver.net (smtpauth02.prod.mesa1.secureserver.net [64.202.165.182]) by ietfa.amsl.com (Postfix) with SMTP id 10E7E21F8788 for ; Wed, 10 Aug 2011 01:41:09 -0700 (PDT) Received: (qmail 27138 invoked from network); 10 Aug 2011 08:41:40 -0000 Received: from unknown (124.120.242.122) by smtpauth02.prod.mesa1.secureserver.net (64.202.165.182) with ESMTP; 10 Aug 2011 08:41:39 -0000 Message-ID: <4E42443D.5070805@net-zen.net> Date: Wed, 10 Aug 2011 15:41:33 +0700 From: Glen Zorn Organization: Network Zen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Joe Salowey References: In-Reply-To: X-Enigmail-Version: 1.2 Content-Type: multipart/mixed; boundary="------------090007070103090005060907" Cc: emu@ietf.org Subject: Re: [Emu] Channel Binding attributes X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 08:41:10 -0000 This is a multi-part message in MIME format. --------------090007070103090005060907 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/10/2011 12:31 PM, Joe Salowey wrote: > At the meeting in Quebec we discussed removing attributes specific to particular media types or lower layers and including recommendations for a small number of generally useful attributes in the draft. > > The attribute that seems to be most useful would be one that indicates what protocol is carrying the EAP conversation between the EAP peer and authenticator. Its not clear to me if there is an existing attribute that meets this need. It seems that there are the following contenders: > > NAS-Port-Type (RFC-2865) - this attribute contains the physical type port that is carrying the EAP conversation. It has values for things like ethernet, 802.11,802.16, various flavors of PPPoE, etc. Since it represents a physical port It does not have values for higher layer protocols such as IKEv2 or PANA. > > Tunnel-Type (RFC-2868) - this attribute is used for setting up compulsory tunnels and contains a value for IPSEC ESP tunnel. It's not clear to me if this would be suitable to indicate IKEv2. > > EAP-Lower-Layer (http://tools.ietf.org/html/draft-aboba-radext-wlan-13) - this is an draft attribute designed to indicate the EAP lower layer. It contains several values to cover many of the EAP lower layers. IT does cover IKEv2 and PANA. Its likely that list values need to be augmented and cleaned up. > > NAS-Port-Type and Tunnel-Type seem to have limitations. My initial suggestion is the following: > > - Define the EAP-Lower-Layer attribute in the document Since the draft you cite seems to be fairly evolved (at least it's been around a long time ;-), is there any reason not to simply publish it? ... --------------090007070103090005060907 Content-Type: text/x-vcard; charset=utf-8; name="gwz.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="gwz.vcf" begin:vcard fn:Glen Zorn n:Zorn;Glen org:Network Zen adr:;;;Seattle;WA;;USA email;internet:gwz@net-zen.net tel;cell:+66 87 040 4617 note:PGP Key Fingerprint: DAD3 F5D3 ACE6 4195 9C5C 2EE1 6E17 B5F6 5953 B45F version:2.1 end:vcard --------------090007070103090005060907-- From hartmans@mit.edu Wed Aug 10 07:55:47 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4937F21F8A66 for ; Wed, 10 Aug 2011 07:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.93 X-Spam-Level: X-Spam-Status: No, score=-103.93 tagged_above=-999 required=5 tests=[AWL=-1.665, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRzVHh4fb4ig for ; Wed, 10 Aug 2011 07:55:46 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D2AB821F884C for ; Wed, 10 Aug 2011 07:55:46 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5F93B203B1; Wed, 10 Aug 2011 10:58:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7C0A442B6; Wed, 10 Aug 2011 10:56:02 -0400 (EDT) From: Sam Hartman To: Joe Salowey References: Date: Wed, 10 Aug 2011 10:56:02 -0400 In-Reply-To: (Joe Salowey's message of "Tue, 9 Aug 2011 22:31:34 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emu@ietf.org Subject: Re: [Emu] Channel Binding attributes X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 14:55:47 -0000 >>>>> "Joe" == Joe Salowey writes: Joe> (http://tools.ietf.org/html/draft-aboba-radext-wlan-13) - this Joe> is an draft attribute designed to indicate the EAP lower layer. Joe> It contains several values to cover many of the EAP lower Joe> layers. IT does cover IKEv2 and PANA. Its likely that list Joe> values need to be augmented and cleaned up. Joe> NAS-Port-Type and Tunnel-Type seem to have limitations. My Joe> initial suggestion is the following: Joe> - Define the EAP-Lower-Layer attribute in the document Since there are are already approved normative references waiting on eap-chbind, I'd prefer to define the attribute here. However if Bernard's draft is ready to last call I'd be fine with that. Joe> - If the lower layer protocol does not define a specific Joe> attribute indicate the lower layer type then EAP-Lower-Layer Joe> attributes MUST be included. Would it also be useful to Joe> include NAS-Port-Type? I think nas-port-type should be a SHOULD here. For things like abfab it makes no sense at all. for things like PANA it may or may not make sense. Joe> - If the lower layer protocol does define a specific attribute Joe> then that attribute MUST be included and EAP-Lower-Layer MAY be Joe> included. Would it be easier just to always use Joe> EAP-Lower-Layer? I'd have a hard time justifying such a MUST for something like abfab on the grounds RFC 2119 gives for when a MUST is appropriate. I think SHOULD rather than MAY include eap-lower-layer better captures what's going on. Joe> Thoughts? I'd be happy to implement this within the next couple of weeks. Obviously if Bernard's draft is ready and we can just send it on and use eap-lower-layer that would be less work for me. From jsalowey@cisco.com Wed Aug 10 21:24:53 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714E121F87D9 for ; Wed, 10 Aug 2011 21:24:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.849 X-Spam-Level: X-Spam-Status: No, score=-103.849 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CA+FFXUMhIPI for ; Wed, 10 Aug 2011 21:24:52 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id ACB3221F87D6 for ; Wed, 10 Aug 2011 21:24:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1985; q=dns/txt; s=iport; t=1313036726; x=1314246326; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HXUDD7ho8ap6JhXrBkr5S5SDIZMWSwEWLcDbLFgmIgM=; b=lA/BnzPaVrVlIdrZhszHJfJXPorqt1BUeD6qHrTo3dzL9wFfXwG1fy1Q vKoPZ0G8iyz6mTGU7jRKVAGdp6hALONVBEJjC60vaR2+NvbNm32eD4jOu l7/GvT8oat+UJv+rXTd7SXyjxD8GCBIvpRbnzh49DNFPT+zcTVRNhxQqm U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIdYQ06rRDoH/2dsb2JhbABBp0R3gUABAQEBAgESASc/BQsLDgouVwY1h0wEnhUBnmSFZ18Eh1+LL4ULjAQ X-IronPort-AV: E=Sophos;i="4.67,354,1309737600"; d="scan'208";a="12021430" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by rcdn-iport-9.cisco.com with ESMTP; 11 Aug 2011 04:25:24 +0000 Received: from [10.33.249.202] ([10.33.249.202]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p7B4PMfB030063; Thu, 11 Aug 2011 04:25:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Joe Salowey In-Reply-To: <4E42443D.5070805@net-zen.net> Date: Wed, 10 Aug 2011 21:25:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5564E5CB-B890-4617-A187-73587B19AF88@cisco.com> References: <4E42443D.5070805@net-zen.net> To: Glen Zorn X-Mailer: Apple Mail (2.1084) Cc: emu@ietf.org Subject: Re: [Emu] Channel Binding attributes X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Aug 2011 04:24:53 -0000 On Aug 10, 2011, at 1:41 AM, Glen Zorn wrote: > On 8/10/2011 12:31 PM, Joe Salowey wrote: >=20 >> At the meeting in Quebec we discussed removing attributes specific to = particular media types or lower layers and including recommendations for = a small number of generally useful attributes in the draft. =20 >>=20 >> The attribute that seems to be most useful would be one that = indicates what protocol is carrying the EAP conversation between the EAP = peer and authenticator. Its not clear to me if there is an existing = attribute that meets this need. It seems that there are the following = contenders: >>=20 >> NAS-Port-Type (RFC-2865) - this attribute contains the physical = type port that is carrying the EAP conversation. It has values for = things like ethernet, 802.11,802.16, various flavors of PPPoE, etc. = Since it represents a physical port It does not have values for higher = layer protocols such as IKEv2 or PANA. >>=20 >> Tunnel-Type (RFC-2868) - this attribute is used for setting up = compulsory tunnels and contains a value for IPSEC ESP tunnel. It's not = clear to me if this would be suitable to indicate IKEv2. >>=20 >> EAP-Lower-Layer = (http://tools.ietf.org/html/draft-aboba-radext-wlan-13) - this is an = draft attribute designed to indicate the EAP lower layer. It contains = several values to cover many of the EAP lower layers. IT does cover = IKEv2 and PANA. Its likely that list values need to be augmented and = cleaned up. =20 >>=20 >> NAS-Port-Type and Tunnel-Type seem to have limitations. My initial = suggestion is the following: >>=20 >> - Define the EAP-Lower-Layer attribute in the document >=20 > Since the draft you cite seems to be fairly evolved (at least it's = been > around a long time ;-), is there any reason not to simply publish it? >=20 [Joe] I don't think its ready for publication yet. I think its only = partially current with 802.1X-2010.=20 > ... > From dharkins@lounge.org Tue Aug 23 11:00:34 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1299221F8A71 for ; Tue, 23 Aug 2011 11:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.335 X-Spam-Level: X-Spam-Status: No, score=-5.335 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0OWcfPLVi4C for ; Tue, 23 Aug 2011 11:00:32 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A803321F8A70 for ; Tue, 23 Aug 2011 11:00:32 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 929651022404C for ; Tue, 23 Aug 2011 11:01:40 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 23 Aug 2011 11:01:40 -0700 (PDT) Message-ID: Date: Tue, 23 Aug 2011 11:01:40 -0700 (PDT) From: "Dan Harkins" To: emu@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 Subject: [Emu] simple PKI X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 18:00:34 -0000 Hello, The tunneled method draft has TLVs to pass a "Server Trusted Root" certificate chain from the server to the peer and also to pass a certs-only PKCS#7 package from the server to the peer. The latter is the 2nd half of the "simple PKI" request/response as described in RFC 5272. So it kind of begs the question, where's the 1st half? Where is the PKCS#10 package that the peer sends the server? So I propose fixing this omission by adding a new TLV for PKCS#10 certificate signing request. Something along the lines of: 4.2.X Certificate Signing Request TLV The Certificate Signing Request TLV is used by the peer to initiate the "simple PKI" Request/Response from [RFC 5272]. The format of the request is as specified in Section 6.4 of [RFC4945]. The Certificate Signing Request TLV is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ PKCS#10 ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 0 (Optional) R Reserved, set to zero (0) TLV Type TBD for Certificate Signing Request TLV Length variable PKCS#10 the Certificate Signing Request regards, Dan. From dharkins@lounge.org Tue Aug 23 12:03:40 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6465A21F8ABE for ; Tue, 23 Aug 2011 12:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az4Ecrn6s8Oo for ; Tue, 23 Aug 2011 12:03:39 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id DDF6421F8564 for ; Tue, 23 Aug 2011 12:03:39 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7CFF21022404C for ; Tue, 23 Aug 2011 12:04:48 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 23 Aug 2011 12:04:48 -0700 (PDT) Message-ID: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> Date: Tue, 23 Aug 2011 12:04:48 -0700 (PDT) From: "Dan Harkins" To: emu@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 Subject: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 19:03:40 -0000 Hello, The tunnel method draft indicates that an anonymous TLS ciphersuite should only be used in accordance with the server unauthenticated provisioning mode described in RFC 5422. This is unfortunate because the technique described in RFC 5422 requires changes to an existing EAP method, which is unnecessarily confusing, and it is also susceptible to attack. I propose we fix this problem by defining a server unauthenticated provisioning mode in the draft itself, something similar to the technique used by TEAM. To do this there are a couple places that need to get touched. - Section 3.2 says, "Other ciphersuites MAY be supported. It is RECOMMENDED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used in the context of the provisioning described in [RFC5422]." I suggest it say, "Other ciphersuites MAY be supported. It is REQUIRED that anonymous ciphersuites such as TLS_DH_anon_WITH_AES_128_CBC_SHA only be used in the context of the provisioning described in ." - Adding a new section to describe the technique. I suggest making this a new 3.4 and bumping 3.4-7 to 3.5-8. New section should read: "3.4 Server Unauthenticated Provisioning Mode "In Server Unauthenticated Provisioning Mode, an unauthenticated tunnel is established in phase 1 and the peer and server negotiate an EAP method in phase 2 that supports mutual authentication and key derivation that is resistant to dictionary attack. This provisioning mode enables the bootstrapping of peers when the peer lacks a strong credential usable for mutual authentication with the server during phase 1. "Upon successful completion of the EAP method in phase 2, the peer and server exchange a Crypto-Binding TLV to bind the inner method with the outer method and ensure that a man-in-the-middle attack has not been attempted. "Support for the Server Unauthenticated Provisioning Mode is optional but to ensure interoperability, an implementation that does support Server Unauthenticated Provisioning Mode MUST support TLS_DH_anon_WITH_AES_128_CBC_SHA as a TLS ciphersuite and MUST support EAP-pwd [RFC 5931] as a phase 2 method. "Other anonymous ciphersuites MAY be supported. Phase 2 EAP methods used in Server Unauthenticated Provisioning Mode MUST provide mutual authentication, key generation, and be resistant to dictionary attack." regards, Dan. From dharkins@lounge.org Tue Aug 23 13:02:45 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DDC21F8B7B for ; Tue, 23 Aug 2011 13:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.188 X-Spam-Level: X-Spam-Status: No, score=-6.188 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd0LfrnBzbJm for ; Tue, 23 Aug 2011 13:02:45 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1279821F8B42 for ; Tue, 23 Aug 2011 13:02:45 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C35E11022404C for ; Tue, 23 Aug 2011 13:03:53 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 23 Aug 2011 13:03:53 -0700 (PDT) Message-ID: <63fefc3113bff759d29e7339aa2ecf6a.squirrel@www.trepanning.net> Date: Tue, 23 Aug 2011 13:03:53 -0700 (PDT) From: "Dan Harkins" To: emu@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 Subject: [Emu] TLV type layout X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:02:45 -0000 Hello, I noticed that the initial registry for TLV types starts out with three reserved numbers which is pretty odd. It says in the IANA Considerations (similar verbage is in the General TLV Format of section 4.2.1): A summary of the EAP-FAST TLV types is given below: 0 Reserved 1 Reserved 2 Reserved 3 Result TLV 4 NAK TLV 5 Error TLV et cetera Since this is the initial layout of a new registry it doesn't serve a purpose to have 1 and 2 "reserved". Zero I can understand, but not 1 and 2. I propose this get changed to move everything from 3 on up by 2 so "Result TLV" becomes 1, "NAK TLV" becomes 2, et cetera. regards, Dan. From dharkins@lounge.org Tue Aug 23 13:11:06 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAA621F8B87 for ; Tue, 23 Aug 2011 13:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRxrkl-xRjbj for ; Tue, 23 Aug 2011 13:11:05 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D9B2F21F8B76 for ; Tue, 23 Aug 2011 13:11:05 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6B3CA1022404C for ; Tue, 23 Aug 2011 13:12:13 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 23 Aug 2011 13:12:13 -0700 (PDT) Message-ID: Date: Tue, 23 Aug 2011 13:12:13 -0700 (PDT) From: "Dan Harkins" To: emu@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 Subject: [Emu] comment vous appelez-vous? X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:11:06 -0000 Hello, In Quebec there was a discussion on what we're gonna call the tunnel method. The candidates discussed were: - ITEM -- Internet Tunnel EAP Method - ETA -- Extensible Tunneled Authentication - TEAP -- Tunnel EAP - EAP-TUNNEL - TEAM -- Tunneled Extensible Authentication Method I have seen no further discussion on the list about this though. So let me start one. My personal preference is ETA because it opens up the obvious self- deprecating comment: "what's the ETA? Well in EMU it's about 4 years." Ha ha ha...yea, not that funny. regards, Dan. From klaas@wierenga.net Wed Aug 24 02:21:51 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2D621F8B00 for ; Wed, 24 Aug 2011 02:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2P4QUZkZWfD for ; Wed, 24 Aug 2011 02:21:50 -0700 (PDT) Received: from out23-ams.mf.surf.net (out23-ams.mf.surf.net [145.0.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 7E83621F8AFE for ; Wed, 24 Aug 2011 02:21:50 -0700 (PDT) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7O9Mxlg023978 for ; Wed, 24 Aug 2011 11:22:59 +0200 Received: from rtp-isp-nat1.cisco.com ([64.102.254.33] helo=macmini.wierenga.net) by teletubbie.het.net.je with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1Qw9ei-000Ebj-9w for emu@ietf.org; Wed, 24 Aug 2011 11:21:53 +0200 Message-ID: <4E54C2EF.1080708@wierenga.net> Date: Wed, 24 Aug 2011 11:22:55 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: emu@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: no malware found X-Bayes-Prob: 0.5 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uFo9mX5x - faf24b8ac94d - 20110824 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.23 Subject: Re: [Emu] comment vous appelez-vous? X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 09:21:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 8/23/11 10:12 PM, Dan Harkins wrote: > > Hello, > > In Quebec there was a discussion on what we're gonna call the > tunnel method. The candidates discussed were: > > - ITEM -- Internet Tunnel EAP Method - ETA -- Extensible Tunneled > Authentication - TEAP -- Tunnel EAP - EAP-TUNNEL - TEAM -- Tunneled > Extensible Authentication Method > > I have seen no further discussion on the list about this though. > So let me start one. > > My personal preference is ETA because it opens up the obvious > self- deprecating comment: "what's the ETA? Well in EMU it's about > 4 years." Ha ha ha...yea, not that funny. in the latter category: CHEAP: CHannel Binding EAP method.... what a wonderful world in which EAP methods are FAST and CHEAP.... Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5UwuoACgkQH2Wy/p4XeFLWigCcD/IUx8o9EteV+RWBxK7OFZaV BdYAnjSBHR5hEulNXpT2N4y3ur7PQxfC =fvyi -----END PGP SIGNATURE----- From glenzorn@gmail.com Wed Aug 24 05:33:45 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A0321F8B17 for ; Wed, 24 Aug 2011 05:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbDExMSk7Zja for ; Wed, 24 Aug 2011 05:33:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6C3621F8785 for ; Wed, 24 Aug 2011 05:33:44 -0700 (PDT) Received: by vxi29 with SMTP id 29so1191858vxi.31 for ; Wed, 24 Aug 2011 05:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=e5hUrF+PBPT/2i9N1hlx35eNvl2XuopYni19t/Qxmzc=; b=etIuDLseB0hiKXvz0kndmCV4wAXiL4Pyxq3tvXOFk1jpBawyw96MmMJpaQK+sTS4Z3 GXW5h3uaNGlLWXg3F81gv11jx1WWWqNDq35JxpWRFRxdjJe1ahwewZrYO7aBE0mYy7rE zPcwtfUAi8SYXrCJva70oN3JrbhewYghQueGw= Received: by 10.220.39.195 with SMTP id h3mr1460115vce.202.1314189294829; Wed, 24 Aug 2011 05:34:54 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-122-122-148.revip2.asianet.co.th [124.122.122.148]) by mx.google.com with ESMTPS id bs1sm414371vcb.42.2011.08.24.05.34.51 (version=SSLv3 cipher=OTHER); Wed, 24 Aug 2011 05:34:54 -0700 (PDT) Message-ID: <4E54EFE8.2060406@gmail.com> Date: Wed, 24 Aug 2011 19:34:48 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Dan Harkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] comment vous appelez-vous? X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 12:33:45 -0000 On 8/24/2011 3:12 AM, Dan Harkins wrote: > > Hello, > > In Quebec there was a discussion on what we're gonna call the tunnel > method. The candidates discussed were: > > - ITEM -- Internet Tunnel EAP Method > - ETA -- Extensible Tunneled Authentication > - TEAP -- Tunnel EAP > - EAP-TUNNEL > - TEAM -- Tunneled Extensible Authentication Method > > I have seen no further discussion on the list about this though. So > let me start one. > > My personal preference is ETA because it opens up the obvious self- > deprecating comment: "what's the ETA? Well in EMU it's about 4 years." > Ha ha ha...yea, not that funny. I like TEAM. > > regards, > > Dan. > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Wed Aug 24 12:14:23 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D219621F8C40 for ; Wed, 24 Aug 2011 12:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.701 X-Spam-Level: X-Spam-Status: No, score=-103.701 tagged_above=-999 required=5 tests=[AWL=-1.436, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w52gkmKnSczr for ; Wed, 24 Aug 2011 12:14:23 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5A321F8C19 for ; Wed, 24 Aug 2011 12:14:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D587420148; Wed, 24 Aug 2011 15:17:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0F5AE423D; Wed, 24 Aug 2011 15:15:28 -0400 (EDT) From: Sam Hartman To: "Dan Harkins" References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> Date: Wed, 24 Aug 2011 15:15:28 -0400 In-Reply-To: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> (Dan Harkins's message of "Tue, 23 Aug 2011 12:04:48 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 19:14:24 -0000 >>>>> "Dan" == Dan Harkins writes: Dan> and MUST support EAP-pwd [RFC 5931] as a phase 2 method. I support all of dan's changes regarding unauthenticated server mode with the exception of the quoted text above. I do not generally support a down-reference to an informational document in a case like this. (It would need to be a normative reference in that context). I don't think RFc 5931 is an appropriate mandatory-to-implement. I'm not sure we have any MTI choices for this other than GPSK. I'd be happy either with GPSK or leaving the MTI eap method unspecified. From dharkins@lounge.org Wed Aug 24 13:21:18 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8165D21F8C30 for ; Wed, 24 Aug 2011 13:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4+qNlQYlliC for ; Wed, 24 Aug 2011 13:21:17 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8AC21F8C72 for ; Wed, 24 Aug 2011 13:21:13 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 8088F1022404C; Wed, 24 Aug 2011 13:22:24 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 24 Aug 2011 13:22:24 -0700 (PDT) Message-ID: In-Reply-To: References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> Date: Wed, 24 Aug 2011 13:22:24 -0700 (PDT) From: "Dan Harkins" To: "Sam Hartman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:21:18 -0000 On Wed, August 24, 2011 12:15 pm, Sam Hartman wrote: >>>>>> "Dan" == Dan Harkins writes: > > Dan> and MUST support EAP-pwd [RFC 5931] as a phase 2 method. > > > I support all of dan's changes regarding unauthenticated server mode > with the exception of the quoted text above. I do not generally support > a down-reference to an informational document in a case like this. (It > would need to be a normative reference in that context). I don't think > RFc 5931 is an appropriate mandatory-to-implement. I'm not sure we have > any MTI choices for this other than GPSK. > > I'd be happy either with GPSK or leaving the MTI eap method unspecified. > EAP-GPSK is not resistant to dictionary attack and therefore would be unqualifed to be used according to the changes I propose that you already support (i.e. that the EAP method be resistant to dictionary attack). Regarding what it means to be resistant to a dictionary attack, let me quote some experts in the field [1], "One sees whether or not one has security against dictionary attacks by looking to see if maximal adversarial advantage grows primarily with the ratio of interaction to the size of the password space." You will note that with GPSK it does not. Given a password space of X (all numbers less than 2^128, or the words from Webster's, whatever) there can be one single interaction followed by computational work to exhaustively go through the password space seeing if a guess is correct. The adversarial advantage grows through computation and not interaction. Increasing the size of the password space (which is what EAP-GPSK recommends) may make a successful dictionary attack harder but it does not magically make a protocol resistant to dictionary attack. On the other hand, EAP-pwd is resistant to dictionary attack. Normative reference to Informational RFCs is done all the time. What would we do without RFC 2104! regards, Dan. [1] Mihir Bellare, David Pointcheval, and Phillip Rogaway in "Authenticated Key Exchange Secure Against Dictionary Attack". From hartmans@mit.edu Wed Aug 24 13:32:38 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8672721F8CFD for ; Wed, 24 Aug 2011 13:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.651 X-Spam-Level: X-Spam-Status: No, score=-103.651 tagged_above=-999 required=5 tests=[AWL=-1.386, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiPBdEu+-nry for ; Wed, 24 Aug 2011 13:32:38 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1925621F8CFB for ; Wed, 24 Aug 2011 13:32:38 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C9DE3203CB; Wed, 24 Aug 2011 16:36:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 08837423D; Wed, 24 Aug 2011 16:33:43 -0400 (EDT) From: Sam Hartman To: "Dan Harkins" References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> Date: Wed, 24 Aug 2011 16:33:43 -0400 In-Reply-To: (Dan Harkins's message of "Wed, 24 Aug 2011 13:22:24 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 20:32:38 -0000 >>>>> "Dan" == Dan Harkins writes: Dan> On Wed, August 24, 2011 12:15 pm, Sam Hartman wrote: >>>>>>> "Dan" == Dan Harkins writes: >> Dan> and MUST support EAP-pwd [RFC 5931] as a phase 2 method. >> >> >> I support all of dan's changes regarding unauthenticated server >> mode with the exception of the quoted text above. I do not >> generally support a down-reference to an informational document >> in a case like this. (It would need to be a normative reference >> in that context). I don't think RFc 5931 is an appropriate >> mandatory-to-implement. I'm not sure we have any MTI choices for >> this other than GPSK. >> >> I'd be happy either with GPSK or leaving the MTI eap method >> unspecified. >> EAP-GPSK is not resistant to dictionary attack and therefore would Dan> be unqualifed to be used according to the changes I propose Dan> that you already support (i.e. that the EAP method be resistant Dan> to dictionary attack). OK. Then I think we need to broaden up your text somewhat. I think GPSK is fine in a deployment where you expect random keys. I think something that has offline dictionary attack resistance would be fine in an area where passwords might be used. I'd like to relax your text to permit both. Dan> Regarding what it means to be resistant to a dictionary Dan> attack, let me quote some experts in the field [1], "One sees Dan> whether or not one has security against dictionary attacks by Dan> looking to see if maximal adversarial advantage grows primarily Dan> with the ratio of interaction to the size of the password Dan> space." I think that definition is OK. I don't want us to require ZKPP to get the dictionary attack resistance security claim. I agree GPSK should not have the dictionary attack resistance security claim. I do want GPSK to be permitted in environments where it is appropriate. I absolutely do not support EAP-PWD as a MTI for this document unless EAP-PWD is moved to the standards track. From dharkins@lounge.org Wed Aug 24 15:48:33 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4D1121F8D02 for ; Wed, 24 Aug 2011 15:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yp-MoAmW-aeE for ; Wed, 24 Aug 2011 15:48:33 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 350C321F8CEB for ; Wed, 24 Aug 2011 15:48:33 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E4F271022404C; Wed, 24 Aug 2011 15:49:44 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 24 Aug 2011 15:49:45 -0700 (PDT) Message-ID: <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> In-Reply-To: References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> Date: Wed, 24 Aug 2011 15:49:45 -0700 (PDT) From: "Dan Harkins" To: "Sam Hartman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 22:48:33 -0000 The distinction between "passwords" and "random keys" is really open to interpretation using them in email is therefore somewhat problematic. A "random key" could be 8 uniformly random bits while a "password" could be drawn from a pool (each having equal likelihood of being chosen) of 2^16 entries. So let me interpret your email to mean that "passwords" are easy to guess and "random keys" are not. On Wed, August 24, 2011 1:33 pm, Sam Hartman wrote: >>>>>> "Dan" == Dan Harkins writes: > > Dan> On Wed, August 24, 2011 12:15 pm, Sam Hartman wrote: > >>>>>>> "Dan" == Dan Harkins writes: > >> > Dan> and MUST support EAP-pwd [RFC 5931] as a phase 2 method. > >> > >> > >> I support all of dan's changes regarding unauthenticated server > >> mode with the exception of the quoted text above. I do not > >> generally support a down-reference to an informational document > >> in a case like this. (It would need to be a normative reference > >> in that context). I don't think RFc 5931 is an appropriate > >> mandatory-to-implement. I'm not sure we have any MTI choices for > >> this other than GPSK. > >> > >> I'd be happy either with GPSK or leaving the MTI eap method > >> unspecified. > >> > > EAP-GPSK is not resistant to dictionary attack and therefore would > Dan> be unqualifed to be used according to the changes I propose > Dan> that you already support (i.e. that the EAP method be resistant > Dan> to dictionary attack). > OK. Then I think we need to broaden up your text somewhat. I think > GPSK is fine in a deployment where you expect random keys. I think > something that has offline dictionary attack resistance would be fine in > an area where passwords might be used. But areas where passwords "might be used" are more expansive, and I might add include, the areas where one might have random keys. So something that has resistance to dictionary attack is "fine" everywhere that any secret blob credential (i.e. "password" or "random key") is used. In fact, if you have the ability to to provision 128-bit (or greater) blobs in disparate places then you have the ability to provision a certificate or something that makes EAP-GPSK pointless. If, on the other hand, you really really want to provision 128-bit blobs in lieu of certificates then you really have no need to do the tunneled method with an anonymous DH ciphersuite in phase 1. Just do EAP-GPSK and be done with it. > I'd like to relax your text to permit both. > > > Dan> Regarding what it means to be resistant to a dictionary > Dan> attack, let me quote some experts in the field [1], "One sees > Dan> whether or not one has security against dictionary attacks by > Dan> looking to see if maximal adversarial advantage grows primarily > Dan> with the ratio of interaction to the size of the password > Dan> space." > > I think that definition is OK. I don't want us to require ZKPP to get > the dictionary attack resistance security claim. I agree GPSK should not > have the dictionary attack resistance security claim. > > I do want GPSK to be permitted in environments where it is appropriate. No one is banning EAP-GPSK. You're free to use it. It just doesn't seem to make sense relaxing security requirements to provide solutions to problems that don't really exist. > I absolutely do not support EAP-PWD as a MTI for this document unless > EAP-PWD is moved to the standards track. So you're drawing a line in the sand over the capricious nature of a past IESG decision and not on security? Really? Why are you not running around insisting that RFC 2104 be moved to standards track? Dan. From dharkins@lounge.org Wed Aug 24 15:51:05 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE48421F8B80 for ; Wed, 24 Aug 2011 15:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otJdaIPtOGGF for ; Wed, 24 Aug 2011 15:51:04 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1020621F8B27 for ; Wed, 24 Aug 2011 15:51:04 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id EB3271022404C for ; Wed, 24 Aug 2011 15:52:14 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 24 Aug 2011 15:52:14 -0700 (PDT) Message-ID: <23120dc91395de12d8f88dddd42a9997.squirrel@www.trepanning.net> Date: Wed, 24 Aug 2011 15:52:14 -0700 (PDT) From: "Dan Harkins" To: emu@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 Subject: [Emu] need a normative reference to an Informational RFC X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2011 22:51:05 -0000 Hello, Section 5.3 of the tunnel method I-D refers to HMAC yet there is no normative reference to the Informational RFC that defines it. This needs to be fixed. A normative reference to RFC 2104 needs to be added to section 9.1. regards, Dan. From hartmans@mit.edu Wed Aug 24 17:18:41 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DCE21F8B55 for ; Wed, 24 Aug 2011 17:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.634 X-Spam-Level: X-Spam-Status: No, score=-103.634 tagged_above=-999 required=5 tests=[AWL=-1.369, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7ep+s28KlJk for ; Wed, 24 Aug 2011 17:18:41 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 62C0F21F8B53 for ; Wed, 24 Aug 2011 17:18:41 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id EEAC820148; Wed, 24 Aug 2011 20:22:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7A204423D; Wed, 24 Aug 2011 20:19:44 -0400 (EDT) From: Sam Hartman To: "Dan Harkins" References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> Date: Wed, 24 Aug 2011 20:19:44 -0400 In-Reply-To: <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> (Dan Harkins's message of "Wed, 24 Aug 2011 15:49:45 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 00:18:41 -0000 >>>>> "Dan" == Dan Harkins writes: Dan> In fact, if you have the ability to to provision 128-bit (or Dan> greater) blobs in disparate places then you have the ability to Dan> provision a certificate or something that makes EAP-GPSK Dan> pointless. If, on the other hand, you really really want to Dan> provision 128-bit blobs in lieu of certificates then you really Dan> have no need to do the tunneled method with an anonymous DH Dan> ciphersuite in phase 1. Just do EAP-GPSK and be done with it. I can think of a lot of reasons I might want a tunnel with EAP-GPSK. Examples including wanting channel bindings that don't fit in the 200 bytes or whatever GPSK gives me, wanting to do NEA, etc. So, I think it is reasonable to configure a policy that uses EAP-GPSK with an anonymous ciphersuite in exactly the cases where GPSK is appropriate to use at all. If you'd like text suggestions I'd be happy to provide. >> I absolutely do not support EAP-PWD as a MTI for this document >> unless EAP-PWD is moved to the standards track. Dan> So you're drawing a line in the sand over the capricious Dan> nature of a past IESG decision and not on security? Really? Why Dan> are you not running around insisting that RFC 2104 be moved to Dan> standards track? I don't consider the decision capricious. EAP-PWD has not met process hurtles that are important for IETF standards. In particular there are a number of approaches for doing that sort of password method; we haven't decided that's the one we want to use. If EAP-PWD had the sort of deployment MSCHAPv2 had, I'd support an RFC 3967 down-ref to it: the market has spoken and MSCHAPv2 has significant deployment. However, a normative down-ref to EAP-PWD would be an end-run around the question of whether EAP-PWD is the method that does approximately what it does that we want to recommend. That decision should be faced directly not as part of some other spec. Dan> Dan. From dharkins@lounge.org Wed Aug 24 19:27:04 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70FD21F8AED for ; Wed, 24 Aug 2011 19:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuW7tslbpDSJ for ; Wed, 24 Aug 2011 19:27:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D3BDB21F8AD9 for ; Wed, 24 Aug 2011 19:27:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id ECB231022404C; Wed, 24 Aug 2011 19:28:15 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 24 Aug 2011 19:28:16 -0700 (PDT) Message-ID: <4b9c28e27e7a32813d553f4ab78091cb.squirrel@www.trepanning.net> In-Reply-To: References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> Date: Wed, 24 Aug 2011 19:28:16 -0700 (PDT) From: "Dan Harkins" To: "Sam Hartman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 02:27:04 -0000 On Wed, August 24, 2011 5:19 pm, Sam Hartman wrote: > > EAP-PWD has not met process hurtles that are important for IETF > standards. Thanks, in part, to you. > In particular there are a number of approaches for doing that > sort of password method; we haven't decided that's the one we want to > use. That's right "we" haven't decided on One Way To Do It(tm). Nor are "we" planning to. So you're appealing to wait for the conclusion of a process that does not exist and has no plans of being started? That's absurd. There are security properties that you said you agreed are important. I am suggesting to use a method that satisfies those properties for the purposes of interoperability. Just because you don't like my choice (and apparently "we" haven't used a non-existent process to choose) doesn't mean the security properties should be downgraded. > If EAP-PWD had the sort of deployment MSCHAPv2 had, I'd support an RFC > 3967 down-ref to it: the market has spoken and MSCHAPv2 has significant > deployment. I refer you to section 4 of RFC 3967, "On the other hand...." > However, a normative down-ref to EAP-PWD would be an > end-run around the question of whether EAP-PWD is the method that does > approximately what it does that we want to recommend. That decision > should be faced directly not as part of some other spec. I can assure you that EAP-pwd is "the method that does approximately what it does". That is tautologically true. First you were opposed because it amounted to a normative reference to an Informational RFC, but that's not a consistent position to take (see RFC 2104). So now it's that "we" haven't decided on what password method to use. But "we" have not decided to use MSCHAPv2 or EAP-GPSK to handle password authentication either. Using either of those is likewise an "end-run around the question [of] what we want to recommend." But for some reason you bring these flawed protocols up as alternatives to EAP-pwd. So why are you really opposed to protocols being resistant to dictionary attack? Dan. From glenzorn@gmail.com Wed Aug 24 23:01:07 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2660721F8A69 for ; Wed, 24 Aug 2011 23:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uy-EoXGV+SV for ; Wed, 24 Aug 2011 23:01:06 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE3E21F8A6F for ; Wed, 24 Aug 2011 23:01:06 -0700 (PDT) Received: by gwb20 with SMTP id 20so1738808gwb.31 for ; Wed, 24 Aug 2011 23:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XMRwmbVybCs84kzx25LidNcYkpZTLYZ17wv8s3RQFIA=; b=o2NdbggKOgdyp6jnfllzpNp5VjsemYXWHOAKQ9Z4g2b8mNjBEoS7a1vP6JF+Kd8iBH hkWZkUCwMl1Jo6UpDwSJsraCyS7cM70BoEam1MJmgnZriypkCjQEdpKaMCtPZ0/Vkupf OK01/GKs7KAout+3ioIsZZ1LzQQVurFESEFas= Received: by 10.100.114.9 with SMTP id m9mr1445418anc.48.1314252137957; Wed, 24 Aug 2011 23:02:17 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-120-20-200.revip2.asianet.co.th [124.120.20.200]) by mx.google.com with ESMTPS id l13sm262743anj.42.2011.08.24.23.02.14 (version=SSLv3 cipher=OTHER); Wed, 24 Aug 2011 23:02:16 -0700 (PDT) Message-ID: <4E55E563.6040601@gmail.com> Date: Thu, 25 Aug 2011 13:02:11 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Dan Harkins References: <63fefc3113bff759d29e7339aa2ecf6a.squirrel@www.trepanning.net> In-Reply-To: <63fefc3113bff759d29e7339aa2ecf6a.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: emu@ietf.org Subject: Re: [Emu] TLV type layout X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 06:01:07 -0000 On 8/24/2011 3:03 AM, Dan Harkins wrote: > > Hello, > > I noticed that the initial registry for TLV types starts out with > three reserved numbers which is pretty odd. It says in the IANA > Considerations (similar verbage is in the General TLV Format of > section 4.2.1): > > A summary of the EAP-FAST TLV types is given below: > > 0 Reserved > 1 Reserved > 2 Reserved > 3 Result TLV > 4 NAK TLV > 5 Error TLV > et cetera > > Since this is the initial layout of a new registry it doesn't serve > a purpose to have 1 and 2 "reserved". Zero I can understand, Can you explain it to me, because I don't ;-). All numbers except those specifically assigned are by definition reserved, right? > but not > 1 and 2. > > I propose this get changed to move everything from 3 on up by 2 so > "Result TLV" becomes 1, "NAK TLV" becomes 2, et cetera. I would prefer to start at 0. > > regards, > > Dan. > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From yaronf.ietf@gmail.com Thu Aug 25 02:46:00 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B69321F84F2 for ; Thu, 25 Aug 2011 02:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ow1FnldSjZYq for ; Thu, 25 Aug 2011 02:46:00 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADCF421F84E9 for ; Thu, 25 Aug 2011 02:45:59 -0700 (PDT) Received: by wyg8 with SMTP id 8so1737699wyg.31 for ; Thu, 25 Aug 2011 02:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=1d/jReqOFG/xzdg7Sp+ECP9sej/6jx+mxtvlO3sXdjU=; b=QfewJjLyrrZbKNSbZEIOtiI8Kw3LBN3lTk8JLAy3RnsS1292ZENplpzJKrhAfuOPTV stXRCoT9G1JiMqY3q4vR6+qjhG5BDGMjqs7EJxpQWJLEV5mznfHBabaSlDtrmbotVL4e Il084tq3/BepqyweTxJfdyTIqH/OGiJD7GM6A= Received: by 10.227.42.131 with SMTP id s3mr1307026wbe.104.1314265631919; Thu, 25 Aug 2011 02:47:11 -0700 (PDT) Received: from [10.0.0.6] (93-172-150-185.bb.netvision.net.il [93.172.150.185]) by mx.google.com with ESMTPS id 11sm304299wbw.43.2011.08.25.02.47.10 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 02:47:11 -0700 (PDT) Message-ID: <4E561A1D.6000007@gmail.com> Date: Thu, 25 Aug 2011 12:47:09 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110627 Thunderbird/5.0 MIME-Version: 1.0 To: emu@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Emu] MTI password-based method X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 09:46:00 -0000 I'd like to point out that EAP-EKE (RFC 6124) is another potential candidate for this role. Yes, it is also Informational. Thanks, Yaron On 08/25/2011 09:01 AM, emu-request@ietf.org wrote: > Message: 1 > Date: Wed, 24 Aug 2011 15:15:28 -0400 > From: Sam Hartman > To: "Dan Harkins" > Cc: emu@ietf.org > Subject: Re: [Emu] server unauthenticated provisioning mode > Message-ID: > Content-Type: text/plain; charset=us-ascii > >>>>>> "Dan" == Dan Harkins writes: > Dan> and MUST support EAP-pwd [RFC 5931] as a phase 2 method. > > > I support all of dan's changes regarding unauthenticated server mode > with the exception of the quoted text above. I do not generally support > a down-reference to an informational document in a case like this. (It > would need to be a normative reference in that context). I don't think > RFc 5931 is an appropriate mandatory-to-implement. I'm not sure we have > any MTI choices for this other than GPSK. > > I'd be happy either with GPSK or leaving the MTI eap method unspecified. > > > ------------------------------ > From hartmans@mit.edu Thu Aug 25 08:34:22 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B320321F87D6 for ; Thu, 25 Aug 2011 08:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=-1.317, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aILzzatlWtA for ; Thu, 25 Aug 2011 08:34:22 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 48C9721F8715 for ; Thu, 25 Aug 2011 08:34:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2FF4F20464; Thu, 25 Aug 2011 11:37:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6FE25423D; Thu, 25 Aug 2011 11:35:25 -0400 (EDT) From: Sam Hartman To: "Dan Harkins" References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> <4b9c28e27e7a32813d553f4ab78091cb.squirrel@www.trepanning.net> Date: Thu, 25 Aug 2011 11:35:25 -0400 In-Reply-To: <4b9c28e27e7a32813d553f4ab78091cb.squirrel@www.trepanning.net> (Dan Harkins's message of "Wed, 24 Aug 2011 19:28:16 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 15:34:22 -0000 Dan: 1) My desire to use GPSK with anonymous server authentication is more or less unrelated to any other part of this discussion. I want to be able to do it because I think I might deploy it and I don't want the spec to forbid a deployment I consider reasonable. There is no security justification for forbidding GPSK with strong keys combined with anonymous authentication. Again I'd be happy to provide text. 2) You've convinced me that GPSK is not a good MTI choice because of the dictionary attack resistance issue. I didn't carefully consider before suggesting GPSK as an MTI mechanism. I do think GPSK should be permitted to use (point 1) but I agree that's a kind of obscure deployment. 3) I think MSCHAPv2 is an entirely inappropriate MTI for this mechanism. I brought that up as an example about how under certain conditions the fact that something is the kind of thing the IETF standardizes but is never the less informational should not block a downward reference. I was attempting to explain my thinking on the process issue to you, not to suggest MSCHAPv2 for this document. Apparently I failed to explain my thinking on the process issue. 4) I don't think we have any generally appropriate MTI mechanisms here, so we should not choose one. I think it would be fine to say implementations MAY implement [EAP-PWD] [EAP-EKE] or other methods of their choice. From dharkins@lounge.org Thu Aug 25 14:20:50 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3CE21F8BBD for ; Thu, 25 Aug 2011 14:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.213 X-Spam-Level: X-Spam-Status: No, score=-6.213 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVcUy31eK7aL for ; Thu, 25 Aug 2011 14:20:49 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 127C321F8BB9 for ; Thu, 25 Aug 2011 14:20:49 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 690EE1022404C; Thu, 25 Aug 2011 14:22:03 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 25 Aug 2011 14:22:03 -0700 (PDT) Message-ID: <04f60572044e1534aaa136093e77f0f4.squirrel@www.trepanning.net> In-Reply-To: References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> <4b9c28e27e7a32813d553f4ab78091cb.squirrel@www.trepanning.net> Date: Thu, 25 Aug 2011 14:22:03 -0700 (PDT) From: "Dan Harkins" To: "Sam Hartman" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 21:20:50 -0000 Sam, On Thu, August 25, 2011 8:35 am, Sam Hartman wrote: > Dan: > > 1) My desire to use GPSK with anonymous server authentication is more or > less unrelated to any other part of this discussion. I want to be able > to do it because I think I might deploy it and I don't want the spec to > forbid a deployment I consider reasonable. There is no security > justification for forbidding GPSK with strong keys combined with > anonymous authentication. Again I'd be happy to provide text. If you have a scalable way to securely deploy large uniformly random blobs of bits in multiple disparate locations you have the ability to deploy a PKCS#12 containing everything you need to use the tunnel method with nice strong certificate-based authentication. > 2) You've convinced me that GPSK is not a good MTI choice because of the > dictionary attack resistance issue. I didn't carefully consider before > suggesting GPSK as an MTI mechanism. I do think GPSK should be > permitted to use (point 1) but I agree that's a kind of obscure > deployment. The rare, and obscure, deployment in which it is appropriate to use EAP-GPSK would also be quite appropriate to use EAP-pwd. But the converse does not hold. The more common, and unobscure, deployment that is inappropriate for EAP-GPSK would still be quite appropriate for EAP-pwd. So there's no use case that EAP-GPSK is uniquely appropriate for, but there are plenty that EAP-pwd is uniquely appropriate for. > 3) I think MSCHAPv2 is an entirely inappropriate MTI for this > mechanism. I brought that up as an example about how under certain > conditions the fact that something is the kind of thing the IETF > standardizes but is never the less informational should not block a > downward reference. I was attempting to explain my thinking on the > process issue to you, not to suggest MSCHAPv2 for this document. > Apparently I failed to explain my thinking on the process issue. I completely missed that. Sorry. But if the IETF standardized a wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate a shared key) then I really don't understand your opposition to EAP-pwd. MSCHAPv2 became widespread solely due to Windows. A fait acomplii is much more of an "end run" than a down-ref to EAP-pwd. > 4) I don't think we have any generally appropriate MTI mechanisms here, > so we should not choose one. I think it would be fine to say > implementations MAY implement [EAP-PWD] [EAP-EKE] or other methods of > their choice. Like EAP-GPSK? Why stop there? How about EAP-MD5! It's their choice after all. The thing is, EAP-GPSK allows for using short, low entropy, ASCII strings as the shared secret. You may say that your particular use is gonna have large uniformly random hexadecimal blobs of bits as the shared secret but the RFC says the UI must support ASCII and sets no lower limit on the size of the shared secret. So, effectively, you're insisting that the tunnel method be susceptible to dictionary attack! Maybe my frustration is getting the better of me but RFC 3967 (which clarifies when standards track documents may refer normatively to documents at a lower level) says in its security considerations that: "inappropriate or excessive use of the process might be considered a downgrade attack on the quality of IETF standards or, worse, on the rigorous review of security aspects of standards." and I'd like to know: - why it is not inappropriate to insist on the completion of a non-existent process before we require the use of any ZKPP; and, - why making it possible to launch a dictionary attack against the tunnel method is not a downgrade attack on the quality of this IETF standard. Dan. From dharkins@lounge.org Thu Aug 25 14:23:51 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADAE21F8C6C for ; Thu, 25 Aug 2011 14:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ4LYATnh607 for ; Thu, 25 Aug 2011 14:23:50 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4C821F8C7B for ; Thu, 25 Aug 2011 14:23:50 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AB7821022404C; Thu, 25 Aug 2011 14:25:04 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 25 Aug 2011 14:25:04 -0700 (PDT) Message-ID: <7eb72501f8c9784dcbd6cbef3573ab55.squirrel@www.trepanning.net> In-Reply-To: <4E55E563.6040601@gmail.com> References: <63fefc3113bff759d29e7339aa2ecf6a.squirrel@www.trepanning.net> <4E55E563.6040601@gmail.com> Date: Thu, 25 Aug 2011 14:25:04 -0700 (PDT) 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: emu@ietf.org Subject: Re: [Emu] TLV type layout X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 21:23:51 -0000 On Wed, August 24, 2011 11:02 pm, Glen Zorn wrote: > On 8/24/2011 3:03 AM, Dan Harkins wrote: >> >> Hello, >> >> I noticed that the initial registry for TLV types starts out with >> three reserved numbers which is pretty odd. It says in the IANA >> Considerations (similar verbage is in the General TLV Format of >> section 4.2.1): >> >> A summary of the EAP-FAST TLV types is given below: >> >> 0 Reserved >> 1 Reserved >> 2 Reserved >> 3 Result TLV >> 4 NAK TLV >> 5 Error TLV >> et cetera >> >> Since this is the initial layout of a new registry it doesn't serve >> a purpose to have 1 and 2 "reserved". Zero I can understand, > > Can you explain it to me, because I don't ;-). All numbers except those > specifically assigned are by definition reserved, right? That's a general convention. And zero is generally more special than the other numbers because it's in a class by itself (zero) whereas all there numbers are in the same class (non-zero). >> but not >> 1 and 2. >> >> I propose this get changed to move everything from 3 on up by 2 so >> "Result TLV" becomes 1, "NAK TLV" becomes 2, et cetera. > > I would prefer to start at 0. I would be perfectly happy with starting at 0. I'm just not happy starting at 3. Dan. From glenzorn@gmail.com Thu Aug 25 22:30:58 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047B221F84CB for ; Thu, 25 Aug 2011 22:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXUNsTKmMlpo for ; Thu, 25 Aug 2011 22:30:57 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4F521F84C8 for ; Thu, 25 Aug 2011 22:30:57 -0700 (PDT) Received: by gxk19 with SMTP id 19so2879107gxk.31 for ; Thu, 25 Aug 2011 22:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4d/Eofy3QPf8q8bjmmXhFHzCLJtY8T3L0fTQ0GK3hmQ=; b=otqSgYPmHgk1O3JdXA+vaf4phpy1wDpFfdDc2NUNgQdzJMj+N2igHX6NPLzCuRzKSM InwaOCuTuBVRGIYOx6oYPoADFnFv1ELtAv2Aoaui3yMVR/ql55z6L7ZShz20Q0Ff8o3j vmcMv1jncRBdEXU3aW5zoCToES1vLwsov0SIE= Received: by 10.100.121.4 with SMTP id t4mr613965anc.60.1314336732465; Thu, 25 Aug 2011 22:32:12 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-122-65-112.revip2.asianet.co.th [124.122.65.112]) by mx.google.com with ESMTPS id j30sm1237701ann.22.2011.08.25.22.32.09 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 22:32:12 -0700 (PDT) Message-ID: <4E572FD4.4040704@gmail.com> Date: Fri, 26 Aug 2011 12:32:04 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Dan Harkins References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> <4b9c28e27e7a32813d553f4ab78091cb.squirrel@www.trepanning.net> <04f60572044e1534aaa136093e77f0f4.squirrel@www.trepanning.net> In-Reply-To: <04f60572044e1534aaa136093e77f0f4.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 05:30:58 -0000 On 8/26/2011 4:22 AM, Dan Harkins wrote: >> 3) I think MSCHAPv2 is an entirely inappropriate MTI for this >> mechanism. I brought that up as an example about how under certain >> conditions the fact that something is the kind of thing the IETF >> standardizes but is never the less informational should not block a >> downward reference. I was attempting to explain my thinking on the >> process issue to you, not to suggest MSCHAPv2 for this document. >> Apparently I failed to explain my thinking on the process issue. > > I completely missed that. Sorry. But if the IETF standardized a > wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate a > shared key) Please check your sources & refrain from spouting nonsense; if EAP-pwd is really so wonderful you shouldn't need to disparage other work, it should stand on its own merit. > then I really don't understand your opposition to EAP-pwd. > MSCHAPv2 became widespread solely due to Windows. Hardly. The fact that the IETF was busy a) insisting that there was no, and never would be, any need for dynamic key generation (let alone mutual authentication) in network access protocols (specifically PPP; how could there be, since the only appropriate usage of PPP was to connect two routers which can easily be configured with telnet) and b) waiting with baited breath for the magical genesis of the universal PKI (which would happen because IPsec required it & that hamstrung niche protocol was so wonderful that the world would change to satisfy its requirements) certainly had a lot to do with it. MS-CHAPv2 succeeded because it satisfied a need that the IETF was simultaneously too ignorant and arrogant to see. ... From dharkins@lounge.org Thu Aug 25 23:11:52 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201A321F8AFF for ; Thu, 25 Aug 2011 23:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ9yeSH0lUqp for ; Thu, 25 Aug 2011 23:11:51 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 92CC821F8AFB for ; Thu, 25 Aug 2011 23:11:51 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id BACB11022404C; Thu, 25 Aug 2011 23:13:05 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 25 Aug 2011 23:13:05 -0700 (PDT) Message-ID: <7512996bb3562a81db9cb1d4a7fb5998.squirrel@www.trepanning.net> In-Reply-To: <4E572FD4.4040704@gmail.com> References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> <4b9c28e27e7a32813d553f4ab78091cb.squirrel@www.trepanning.net> <04f60572044e1534aaa136093e77f0f4.squirrel@www.trepanning.net> <4E572FD4.4040704@gmail.com> Date: Thu, 25 Aug 2011 23:13:05 -0700 (PDT) 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: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 06:11:52 -0000 On Thu, August 25, 2011 10:32 pm, Glen Zorn wrote: > On 8/26/2011 4:22 AM, Dan Harkins wrote: > >>> 3) I think MSCHAPv2 is an entirely inappropriate MTI for this >>> mechanism. I brought that up as an example about how under certain >>> conditions the fact that something is the kind of thing the IETF >>> standardizes but is never the less informational should not block a >>> downward reference. I was attempting to explain my thinking on the >>> process issue to you, not to suggest MSCHAPv2 for this document. >>> Apparently I failed to explain my thinking on the process issue. >> >> I completely missed that. Sorry. But if the IETF standardized a >> wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate a >> shared key) > > Please check your sources & refrain from spouting nonsense; if EAP-pwd > is really so wonderful you shouldn't need to disparage other work, it > should stand on its own merit. I stand corrected. That must be why draft-zorn-emu-team proposed using MSCHAPv2. Oh wait, it didn't. It proposed using EAP-pwd. >> then I really don't understand your opposition to EAP-pwd. >> MSCHAPv2 became widespread solely due to Windows. > > Hardly. The fact that the IETF was busy a) insisting that there was no, > and never would be, any need for dynamic key generation (let alone > mutual authentication) in network access protocols (specifically PPP; > how could there be, since the only appropriate usage of PPP was to > connect two routers which can easily be configured with telnet) and b) > waiting with baited breath for the magical genesis of the universal PKI > (which would happen because IPsec required it & that hamstrung niche > protocol was so wonderful that the world would change to satisfy its > requirements) certainly had a lot to do with it. MS-CHAPv2 succeeded > because it satisfied a need that the IETF was simultaneously too > ignorant and arrogant to see. That's great Glen. You accuse me of disparaging other work and then you go and disparage other work. "Do as I say and not as I do". OK, I promise. Dan. From glenzorn@gmail.com Thu Aug 25 23:26:30 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC13921F8593 for ; Thu, 25 Aug 2011 23:26:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDnp1Hihr45H for ; Thu, 25 Aug 2011 23:26:30 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4076421F8B0C for ; Thu, 25 Aug 2011 23:26:30 -0700 (PDT) Received: by gxk19 with SMTP id 19so2923271gxk.31 for ; Thu, 25 Aug 2011 23:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=G6GTnyEFGXvU8quGMvbL2NwBFAD9cBQvX0GQ+XxlR90=; b=NDodYGQz0H2Iw811e3qJFOkVDH+FET90pofiLMk/R6r2m9OPhdUtOb43Xf/ZOSh1k9 OHPn3jQN5zyCrwF4WPvf1/WkAkQLsfj4ndKOM48t6Zx8oAlpZBfxFERRXcTHhPZC2zj2 YjorClKXkwA6scDL6B/UE1Sm6b/+hNy6jtUN4= Received: by 10.236.136.196 with SMTP id w44mr4075429yhi.56.1314340065468; Thu, 25 Aug 2011 23:27:45 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-122-65-112.revip2.asianet.co.th [124.122.65.112]) by mx.google.com with ESMTPS id z29sm1800578yhn.2.2011.08.25.23.27.42 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 23:27:45 -0700 (PDT) Message-ID: <4E573CDB.1080006@gmail.com> Date: Fri, 26 Aug 2011 13:27:39 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Dan Harkins References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> <4b9c28e27e7a32813d553f4ab78091cb.squirrel@www.trepanning.net> <04f60572044e1534aaa136093e77f0f4.squirrel@www.trepanning.net> <4E572FD4.4040704@gmail.com> <7512996bb3562a81db9cb1d4a7fb5998.squirrel@www.trepanning.net> In-Reply-To: <7512996bb3562a81db9cb1d4a7fb5998.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 06:26:31 -0000 On 8/26/2011 1:13 PM, Dan Harkins wrote: > > > On Thu, August 25, 2011 10:32 pm, Glen Zorn wrote: >> On 8/26/2011 4:22 AM, Dan Harkins wrote: >> >>>> 3) I think MSCHAPv2 is an entirely inappropriate MTI for this >>>> mechanism. I brought that up as an example about how under certain >>>> conditions the fact that something is the kind of thing the IETF >>>> standardizes but is never the less informational should not block a >>>> downward reference. I was attempting to explain my thinking on the >>>> process issue to you, not to suggest MSCHAPv2 for this document. >>>> Apparently I failed to explain my thinking on the process issue. >>> >>> I completely missed that. Sorry. But if the IETF standardized a >>> wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate a >>> shared key) >> >> Please check your sources & refrain from spouting nonsense; if EAP-pwd >> is really so wonderful you shouldn't need to disparage other work, it >> should stand on its own merit. > > I stand corrected. That must be why draft-zorn-emu-team proposed using > MSCHAPv2. Oh wait, it didn't. It proposed using EAP-pwd. & this has a relation to your misrepresentation how? > >>> then I really don't understand your opposition to EAP-pwd. >>> MSCHAPv2 became widespread solely due to Windows. >> >> Hardly. The fact that the IETF was busy a) insisting that there was no, >> and never would be, any need for dynamic key generation (let alone >> mutual authentication) in network access protocols (specifically PPP; >> how could there be, since the only appropriate usage of PPP was to >> connect two routers which can easily be configured with telnet) and b) >> waiting with baited breath for the magical genesis of the universal PKI >> (which would happen because IPsec required it & that hamstrung niche >> protocol was so wonderful that the world would change to satisfy its >> requirements) certainly had a lot to do with it. MS-CHAPv2 succeeded >> because it satisfied a need that the IETF was simultaneously too >> ignorant and arrogant to see. > > That's great Glen. You accuse me of disparaging other work and then > you go and disparage other work. "Do as I say and not as I do". OK, > I promise. Actually, Dan, I disparaged the _lack_ of work (in PPP) and the unrealistic expectations of the "leaders" (in IPsec). IPsec need not have been hamstrung by an unrealistic dependency upon PKI and needn't have been turned into a niche protocol either. From glenzorn@gmail.com Thu Aug 25 23:58:26 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF8221F8B1A for ; Thu, 25 Aug 2011 23:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKoBErvDelgo for ; Thu, 25 Aug 2011 23:58:25 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A198121F8772 for ; Thu, 25 Aug 2011 23:58:25 -0700 (PDT) Received: by ywe9 with SMTP id 9so2934105ywe.31 for ; Thu, 25 Aug 2011 23:59:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=wJyKwd3L16spCgp8FlJmSWAlDPoZ0i7d6UFvNDdd1NQ=; b=jDMVzhWUs+aXLGJfestLSD5cmBCbhMjDMOM8ar262eFAGurjpaHVDDI4OfGf+CuNbh 0umPJ786fZUZb2IafUdrkv7mL3Pat0whC9RGGWX1NC0cUbnrjoD8f6UqawXr/mSwx24s 4tlSOciMrOqJ3spS07qLnvUlPHC8kHoLorIhw= Received: by 10.236.177.72 with SMTP id c48mr4127607yhm.79.1314341980962; Thu, 25 Aug 2011 23:59:40 -0700 (PDT) Received: from [192.168.1.98] (ppp-124-122-65-112.revip2.asianet.co.th [124.122.65.112]) by mx.google.com with ESMTPS id a29sm566163yhj.17.2011.08.25.23.59.38 (version=SSLv3 cipher=OTHER); Thu, 25 Aug 2011 23:59:40 -0700 (PDT) Message-ID: <4E574456.9000007@gmail.com> Date: Fri, 26 Aug 2011 13:59:34 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Dan Harkins References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> <4b9c28e27e7a32813d553f4ab78091cb.squirrel@www.trepanning.net> <04f60572044e1534aaa136093e77f0f4.squirrel@www.trepanning.net> <4E572FD4.4040704@gmail.com> <7512996bb3562a81db9cb1d4a7fb5998.squirrel@www.trepanning.net> <4E573CDB.1080006@gmail.com> In-Reply-To: <4E573CDB.1080006@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 06:58:26 -0000 On 8/26/2011 1:27 PM, Glen Zorn wrote: ... >>> Hardly. The fact that the IETF was busy a) insisting that there was no, >>> and never would be, any need for dynamic key generation (let alone >>> mutual authentication) in network access protocols (specifically PPP; >>> how could there be, since the only appropriate usage of PPP was to >>> connect two routers which can easily be configured with telnet) and b) >>> waiting with baited breath for the magical genesis of the universal PKI >>> (which would happen because IPsec required it & that hamstrung niche >>> protocol was so wonderful that the world would change to satisfy its >>> requirements) certainly had a lot to do with it. MS-CHAPv2 succeeded >>> because it satisfied a need that the IETF was simultaneously too >>> ignorant and arrogant to see. >> >> That's great Glen. You accuse me of disparaging other work and then >> you go and disparage other work. "Do as I say and not as I do". OK, >> I promise. > > Actually, Dan, I disparaged the _lack_ of work (in PPP) and the > unrealistic expectations of the "leaders" (in IPsec). IPsec need not > have been hamstrung by an unrealistic dependency upon PKI and needn't > have been turned into a niche protocol either. & in any case, you can disparage other work (esp. MS-CHAP) all day long; all I really want is that you do it with some accuracy. From dharkins@lounge.org Fri Aug 26 08:55:43 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9688B21F8509 for ; Fri, 26 Aug 2011 08:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.221 X-Spam-Level: X-Spam-Status: No, score=-6.221 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QlzuxUbhYpn for ; Fri, 26 Aug 2011 08:55:43 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2489521F84FC for ; Fri, 26 Aug 2011 08:55:43 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A649E1022404C; Fri, 26 Aug 2011 08:56:59 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 26 Aug 2011 08:56:59 -0700 (PDT) Message-ID: <9139533370ecd95c12b385c2610bdfb2.squirrel@www.trepanning.net> In-Reply-To: <4E573CDB.1080006@gmail.com> References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> <4b9c28e27e7a32813d553f4ab78091cb.squirrel@www.trepanning.net> <04f60572044e1534aaa136093e77f0f4.squirrel@www.trepanning.net> <4E572FD4.4040704@gmail.com> <7512996bb3562a81db9cb1d4a7fb5998.squirrel@www.trepanning.net> <4E573CDB.1080006@gmail.com> Date: Fri, 26 Aug 2011 08:56:59 -0700 (PDT) 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: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:55:43 -0000 On Thu, August 25, 2011 11:27 pm, Glen Zorn wrote: > On 8/26/2011 1:13 PM, Dan Harkins wrote: >> >> >> On Thu, August 25, 2011 10:32 pm, Glen Zorn wrote: >>> On 8/26/2011 4:22 AM, Dan Harkins wrote: >>> >>>>> 3) I think MSCHAPv2 is an entirely inappropriate MTI for this >>>>> mechanism. I brought that up as an example about how under certain >>>>> conditions the fact that something is the kind of thing the IETF >>>>> standardizes but is never the less informational should not block a >>>>> downward reference. I was attempting to explain my thinking on the >>>>> process issue to you, not to suggest MSCHAPv2 for this document. >>>>> Apparently I failed to explain my thinking on the process issue. >>>> >>>> I completely missed that. Sorry. But if the IETF standardized a >>>> wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate >>>> a >>>> shared key) >>> >>> Please check your sources & refrain from spouting nonsense; if EAP-pwd >>> is really so wonderful you shouldn't need to disparage other work, it >>> should stand on its own merit. >> >> I stand corrected. That must be why draft-zorn-emu-team proposed using >> MSCHAPv2. Oh wait, it didn't. It proposed using EAP-pwd. > > & this has a relation to your misrepresentation how? It doesn't really, it was a reference to your implication that EAP-pwd cannot stand on its own merit, and requires the disparagement of other work to prop it up. Which I think we can both agree is not the case. Anyway, yes I misrepresented MSCHAPv2. It does produce a key. I was wrong. But I still think the statement that MSCHAPv2 is inappropriate for doing server unauthenticated provisioning mode is valid even with a secret key output by MSCHAPv2. I hope we can both agree on that too. Dan. From glenzorn@gmail.com Fri Aug 26 22:20:25 2011 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787B621F8A97 for ; Fri, 26 Aug 2011 22:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtk4yHU6bzhb for ; Fri, 26 Aug 2011 22:20:25 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBCDC21F8A67 for ; Fri, 26 Aug 2011 22:20:24 -0700 (PDT) Received: by yie12 with SMTP id 12so2538539yie.31 for ; Fri, 26 Aug 2011 22:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8FR48bEq3j7Htm9+LlhM9VQZ330tD8oDilvpMHglugw=; b=msFchnT7zEOyQpuM0pkdomND4gUsdA8Kc7xyykAMbc5mzviFptWFo87tzl4Aj9NZjs M2rU12FUdV5JVtbabHgzus9bwSwIolo/NSgUMsXhnZ1N3i88AFXZXJqMKe/sGjFB5XoD 8RbyllmtipNhM5A4yhbFR0cR/BEbdPV581jBc= Received: by 10.101.26.3 with SMTP id d3mr1821619anj.105.1314422501580; Fri, 26 Aug 2011 22:21:41 -0700 (PDT) Received: from [192.168.1.98] (ppp-115-87-77-81.revip4.asianet.co.th [115.87.77.81]) by mx.google.com with ESMTPS id d33sm2289464ano.35.2011.08.26.22.21.36 (version=SSLv3 cipher=OTHER); Fri, 26 Aug 2011 22:21:40 -0700 (PDT) Message-ID: <4E587EDC.6000601@gmail.com> Date: Sat, 27 Aug 2011 12:21:32 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Dan Harkins References: <903fd07b1005de677ae850769bc0d9ba.squirrel@www.trepanning.net> <6b23533ec43dc5c694d925e9302d721d.squirrel@www.trepanning.net> <4b9c28e27e7a32813d553f4ab78091cb.squirrel@www.trepanning.net> <04f60572044e1534aaa136093e77f0f4.squirrel@www.trepanning.net> <4E572FD4.4040704@gmail.com> <7512996bb3562a81db9cb1d4a7fb5998.squirrel@www.trepanning.net> <4E573CDB.1080006@gmail.com> <9139533370ecd95c12b385c2610bdfb2.squirrel@www.trepanning.net> In-Reply-To: <9139533370ecd95c12b385c2610bdfb2.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , emu@ietf.org Subject: Re: [Emu] server unauthenticated provisioning mode X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 05:20:25 -0000 On 8/26/2011 10:56 PM, Dan Harkins wrote: ... >>>>> I completely missed that. Sorry. But if the IETF standardized a >>>>> wholly inappropriate protocol like MSCHAPv2 (it doesn't even generate >>>>> a >>>>> shared key) >>>> >>>> Please check your sources & refrain from spouting nonsense; if EAP-pwd >>>> is really so wonderful you shouldn't need to disparage other work, it >>>> should stand on its own merit. >>> >>> I stand corrected. That must be why draft-zorn-emu-team proposed using >>> MSCHAPv2. Oh wait, it didn't. It proposed using EAP-pwd. >> >> & this has a relation to your misrepresentation how? > > It doesn't really, it was a reference to your implication that EAP-pwd > cannot stand on its own merit, and requires the disparagement of other > work to prop it up. Which I think we can both agree is not the case. Actually, Dan, I implied (or intended to imply) no such thing. My point was that making demonstrably false claims about other protocols doesn't strengthen your case but only weakens it, making it appear that EAP-pwd cannot stand on its own merits. MS-CHAPv2 was not specifically _not_ standardized by the IETF, the protocol was documented in a purely informational document ("This memo provides information for the Internet community. It does not specify an Internet standard of any kind."). While the ubiquity of Windows undoubtedly had an influence on its adoption, the main reason IMHO was that it solved a real problem which was widely disparaged within the IETF as either nonexistent or inappropriate (i.e., "if you would just change everything you do the way we told you to, that problem wouldn't exist"). > > Anyway, yes I misrepresented MSCHAPv2. It does produce a key. I was > wrong. > > But I still think the statement that MSCHAPv2 is inappropriate for > doing server unauthenticated provisioning mode is valid even with a > secret key output by MSCHAPv2. I hope we can both agree on that too. I am inclined to think that resistance to attack is a valuable thing in this case; EAP-pwd is demonstrably less susceptible to a variety of attacks than MS-CHAPv2 (or for that matter, EAP-GPSK). Furthermore, I think that constraining the choice of a MTI type on the basis of a single academic project (instead of security) is basically unconscionable.