From ietf-secretariat-reply@ietf.org Fri Aug 2 05:04:20 2013 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 4824F11E8323 for ; Fri, 2 Aug 2013 05:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 KmJNKmC8So8k; Fri, 2 Aug 2013 05:04:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7E811E82EC; Fri, 2 Aug 2013 05:04:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-crypto-bind@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130802120419.31315.14120.idtracker@ietfa.amsl.com> Date: Fri, 02 Aug 2013 05:04:19 -0700 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: 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, 02 Aug 2013 12:04:20 -0000 State changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ From Josh.Howlett@ja.net Sat Aug 3 03:53:28 2013 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 2BC2121E8103 for ; Sat, 3 Aug 2013 03:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.669 X-Spam-Level: X-Spam-Status: No, score=-101.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, 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 sVmBevLX3jXV for ; Sat, 3 Aug 2013 03:53:20 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4AF8A11E8139 for ; Sat, 3 Aug 2013 03:53:13 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 34BA54A6B76_1FCE116B for ; Sat, 3 Aug 2013 10:53:10 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id D58204A6B1C_1FCE115F for ; Sat, 3 Aug 2013 10:53:09 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Sat, 3 Aug 2013 11:53:09 +0100 From: Josh Howlett To: "emu@ietf.org" Thread-Topic: Some proposed error conditions for TEAP Thread-Index: AQHOkDejY4UXy9LBjEiw2wL8xzrc7A== Date: Sat, 3 Aug 2013 10:53:07 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Emu] Some proposed error conditions for TEAP 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, 03 Aug 2013 10:53:28 -0000 As discussed in Berlin, to get the ball rolling here is an initial proposal for some inner method error conditions. In addition to these, might there also be some value in an "Information-URL" TLV? The value could point to a web resource that provides further information for TEAP connections that are successful but where, for example, user notification or action is desirable (e.g., password change). Josh. --- General errors - Unspecified server problem - Unspecified authentication failure - Unspecified authorisation failure - User account credentials unavailable - User account expired - User account locked: try again later - User account locked: admin intervention required - Authentication server unavailable - Authentication server not trusted - Clock skew too great - Invalid inner realm Password errors - User account unknown - User account password expired - User account password incorrect - User account password change required Challenge-Response errors - Challenge expired - Challenge algorithm mismatch One time password errors - Token out of sync: administrator intervention required - Token out of sync: PIN change required - Token revoked - Tokens exhausted Certificate errors - User certificate not supplied - User certificate rejected - User certificate validation failure - User certificate expired - User certificate revoked - User certificate algorithm mismatch - Temporary problem validating user certificate Channel binding errors - Channel binding data required but not supplied - Channel binding data did not include required information - Channel binding failed Successful outcomes - User account expires soon - User account credential expires soon - User account authorisations change soon - Clock skew detected - Contact administrator for unspecified reason Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From ietf-secretariat-reply@ietf.org Tue Aug 6 16:46:33 2013 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 0738621E80C2 for ; Tue, 6 Aug 2013 16:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.43 X-Spam-Level: X-Spam-Status: No, score=-101.43 tagged_above=-999 required=5 tests=[AWL=-1.049, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, 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 ThjTKjCoqp9J; Tue, 6 Aug 2013 16:46:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B57EB21E80BE; Tue, 6 Aug 2013 16:46:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70p1 Message-ID: <20130806234632.21025.14288.idtracker@ietfa.amsl.com> Date: Tue, 06 Aug 2013 16:46:32 -0700 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: 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, 06 Aug 2013 23:46:33 -0000 State changed to IESG Evaluation from Waiting for AD Go-Ahead ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-m= ethod/ From stefan.winter@restena.lu Thu Aug 8 03:23:13 2013 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 A107421E8091 for ; Thu, 8 Aug 2013 03:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.056 X-Spam-Level: X-Spam-Status: No, score=-2.056 tagged_above=-999 required=5 tests=[AWL=0.544, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYtznCoAz4Jd for ; Thu, 8 Aug 2013 03:23:13 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id AF4F021F9D5D for ; Thu, 8 Aug 2013 03:23:12 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 877081058D for ; Thu, 8 Aug 2013 12:23:11 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 797261058C for ; Thu, 8 Aug 2013 12:23:11 +0200 (CEST) Message-ID: <5203718A.6050702@restena.lu> Date: Thu, 08 Aug 2013 12:23:06 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: emu@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kBhJP9SRstdmUgh6vFqQ5wq6DuCsgLerW" X-Virus-Scanned: ClamAV Subject: Re: [Emu] Some proposed error conditions for TEAP 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, 08 Aug 2013 10:23:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kBhJP9SRstdmUgh6vFqQ5wq6DuCsgLerW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > As discussed in Berlin, to get the ball rolling here is an initial > proposal for some inner method error conditions. The question IMHO is: there are many inner EAP methods specified already, and they don't typically specify or signal most of the error conditions below to the EAP peer. The TEAP document can't impose change on all those inner methods; they are what they are. If they tell neither the EAP peer nor export that information to the TEAP layer, then there is nothing we can write in the TEAP document that will make it happen. This limits the scope of the error conditions to cases where TEAP has "all in its own hands" - which I believe is limited to the "Optional Password Authentication" of chapter 3.3.2. > In addition to these, might there also be some value in an > "Information-URL" TLV? The value could point to a web resource that > provides further information for TEAP connections that are successful b= ut > where, for example, user notification or action is desirable (e.g., > password change). I like that one. > General errors >=20 > - Unspecified server problem > - Unspecified authentication failure > - Unspecified authorisation failure > - User account credentials unavailable > - User account expired > - User account locked: try again later > - User account locked: admin intervention required > - Authentication server unavailable I'm not sure about terminology here... "authentication server" often refers to RADIUS servers, EAP servers, or maybe the authentication backend that the EAP server consults to do its work. Since we are talking about inner method failures, and we came to a stage where RADIUS is obviously working, because it demonstrated that it can transport messages to the EAP server; and where the EAP server is obviously working, because it did the entire phase 1 exchange, the error conditions above must refer to the "authentication backend" or "identity management backend" (since that backend contains not just authentication details for connecting entities, but also authorisation information). I like that term more than a "server" (the backend could be a flat file in simple deployments). This would mean changing the first and last one to: - Unspecified ID Management Backend problem - ID Management Backend unavailable > - Authentication server not trusted In phase 2 with Password Authentication, the server identity is not verified (again). And for Phase 2 being another EAP method, this untrustedness (as in X.509 verify failure?) would be signalled with a TLS fatal alert in the inner method TLS setup phase. > - Clock skew too great Same; clock is irrelevant for password auth. If inner is EAP, the method running either already has a way to signal this to the EAP peer or not; nothing TEAP can do about this. > - Invalid inner realm That's good. Where outer and inner EAP terminate at the same server, it may also be possible to check if there was a mismatch between inner and outer realm; which may be administratively prohibited. This would add: - Realm mismatch between inner and outer identity > Password errors >=20 > - User account unknown >=20 > - User account password expired >=20 > - User account password incorrect >=20 > - User account password change required All fine (as in: works for TEAP's password auth - and some inner EAP methods even signal this, e.g. MSCHAPv2; others may not and there is nothing TEAP can do if not). > Challenge-Response errors >=20 > - Challenge expired > - Challenge algorithm mismatch >=20 >=20 > One time password errors >=20 > - Token out of sync: administrator intervention required > - Token out of sync: PIN change required > - Token revoked > - Tokens exhausted >=20 > Certificate errors >=20 > - User certificate not supplied > - User certificate rejected >=20 > - User certificate validation failure >=20 > - User certificate expired > - User certificate revoked >=20 > - User certificate algorithm mismatch >=20 > - Temporary problem validating user certificate All of these refer to specific, existing EAP types which don't usually provide signalling for these error conditions to their EAP peer. We're sort of lost with these IMHO. Except for the certificate errors; there EAP-TLS can signal some of those error conditions with TLS alerts. But this is again not TEAP's "business". > Channel binding errors >=20 > - Channel binding data required but not supplied > - Channel binding data did not include required information > - Channel binding failed People who know more about channel binding would have to take a look at these. Can the inner method detect that its channel binding with outer failed? Or can that only be done by the outer method? In that case, it's indeed TEAPs business to generate appropriate errors inside phase 2, but outside the EAP conversation that is going on inside Phase 2. Section 3.8.4 should then specify these error conditions. > Successful outcomes >=20 > - User account expires soon > - User account credential expires soon > - User account authorisations change soon > - Clock skew detected >=20 > - Contact administrator for unspecified reason Again something we can do for password auth, but not if inner EAP is used= =2E Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --kBhJP9SRstdmUgh6vFqQ5wq6DuCsgLerW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIDcY8ACgkQ+jm90f8eFWa4/ACcD24ASmKVaahYjklTIbusz5nO wIUAnRzL6qfHmr9Iy4Imq6UHwtEmcfaI =CPrs -----END PGP SIGNATURE----- --kBhJP9SRstdmUgh6vFqQ5wq6DuCsgLerW-- From martin.stiemerling@neclab.eu Thu Aug 8 12:24:12 2013 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 4665221E8053; Thu, 8 Aug 2013 12:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 OtCPooDMrH0Z; Thu, 8 Aug 2013 12:24:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7527411E8211; Thu, 8 Aug 2013 12:24:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Martin Stiemerling" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130808192411.10939.54546.idtracker@ietfa.amsl.com> Date: Thu, 08 Aug 2013 12:24:11 -0700 Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org, emu-chairs@tools.ietf.org Subject: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS) 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, 08 Aug 2013 19:24:12 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-emu-eap-tunnel-method-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Two points about Section 3.7. "Fragmentation" - Both ends have to wait for either each fragment or fragment ack to arrive. However, the timers on how to long to wait before giving up waiting for fragments or acks are missing. = - how does the sending TEAP entity determine what the maximum transmission unit (MTU) of the path is? From jsalowey@cisco.com Fri Aug 9 16:25:40 2013 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 F08A121F9DC9; Fri, 9 Aug 2013 16:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ZygLPMAgsxXw; Fri, 9 Aug 2013 16:25:36 -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 299B111E8129; Fri, 9 Aug 2013 16:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1504; q=dns/txt; s=iport; t=1376090436; x=1377300036; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jp4/45HG2wrbKpj6z0DaouazmVYmVzkqb1DBNPOlIWk=; b=VA+a8tbuRrYy7G/TBBcHzI8lMdV3Pf67po31Aa6NNiu3g2f0cnIQtRCK 0Zpuk8KcUFb+HvfrCvcbBlF+CGt8zAtkdtI3g+I/PgKCDhU6dhfQ8kiGy U0f4bHsrGSBYsv0vhZdOgO8nHGCKzGAcxqz2pyqpPhBOu7gSSJZfiBVl+ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAHR4BVKtJV2Z/2dsb2JhbABbgwY1UL5agRwWdIIkAQEBAwE6PwULAgEIIhQQMiUCBA4FCAGIAQYMuFOObIETAjECBQKDGHUDmQyQJYFhgTqBcTk X-IronPort-AV: E=Sophos;i="4.89,849,1367971200"; d="scan'208";a="242655136" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 09 Aug 2013 23:20:31 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r79NKVxO011309 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 Aug 2013 23:20:31 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 9 Aug 2013 18:20:31 -0500 From: "Joseph Salowey (jsalowey)" To: Martin Stiemerling Thread-Topic: Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS) Thread-Index: AQHOlGzqRv9ursZ3CEK5mQ7jUsqK3JmN2Q0A Date: Fri, 9 Aug 2013 23:20:30 +0000 Message-ID: References: <20130808192411.10939.54546.idtracker@ietfa.amsl.com> In-Reply-To: <20130808192411.10939.54546.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <711F30982F105E4885813B0B02E5890D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , The IESG , "" , "" Subject: Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS) 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, 09 Aug 2013 23:25:41 -0000 On Aug 8, 2013, at 12:24 PM, Martin Stiemerling wrote: > Martin Stiemerling has entered the following ballot position for > draft-ietf-emu-eap-tunnel-method-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Two points about Section 3.7. "Fragmentation" > - Both ends have to wait for either each fragment or fragment ack to > arrive. However, the timers on how to long to wait before giving up > waiting for fragments or acks are missing.=20 >=20 [Joe] Retransmission and timeout behavior for EAP is discussed in the EAP R= FC 3748 Section 4.3.=20 > - how does the sending TEAP entity determine what the maximum > transmission unit (MTU) of the path is? >=20 >=20 [Joe] Typically EAP receives MTU information from the lower layer. This is= described in EAP RFC 3748 section 3.1. =20 >=20 >=20 From spencerdawkins.ietf@gmail.com Fri Aug 9 11:33:48 2013 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 8DF6021F8267; Fri, 9 Aug 2013 11:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SLuayo4v-4P; Fri, 9 Aug 2013 11:33:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC5C21F81FF; Fri, 9 Aug 2013 11:28:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Spencer Dawkins" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130809182802.7830.86269.idtracker@ietfa.amsl.com> Date: Fri, 09 Aug 2013 11:28:02 -0700 X-Mailman-Approved-At: Sat, 10 Aug 2013 11:28:01 -0700 Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org, emu-chairs@tools.ietf.org Subject: [Emu] Spencer Dawkins' No Objection on draft-ietf-emu-eap-tunnel-method-07: (with COMMENT) 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, 09 Aug 2013 18:33:48 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-emu-eap-tunnel-method-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I considered balloting Discuss, but I'm assuming that either I'm missing something really obvious, or this will be an easy fix ... In 3.1. Version Negotiation If the TEAP server does not support the version number proposed by the TEAP peer, it MAY terminate the conversation with EAP-Failure or negotiate for another EAP type. Otherwise the TEAP conversation continues. I'm wondering if "MAY terminate the conversation" is what you mean when the TEAP peer doesn't propose a version number that the TEAP server supports. I'm reading "otherwise the TEAP conversation continues" as saying that the two alternatives given are the only choices when the TEAP server doesn't support a proposed version number. Did I get that right? = If you're expecting the TEAP server to do one of those two things, something like "MUST terminate the conversation unless the TEAP server negotiates for a different version number" might be clearer. If there are more than two alternatives, it would be helpful to rephrase this text so it's clear that theTEAP server isn't limited to those two alternatives. From barryleiba@computer.org Mon Aug 12 09:43:08 2013 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 B54E821E80B0; Mon, 12 Aug 2013 09:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.286 X-Spam-Level: X-Spam-Status: No, score=-102.286 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 f9bIJ4AIRVDW; Mon, 12 Aug 2013 09:43:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB4921E8182; Mon, 12 Aug 2013 09:05:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Barry Leiba" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130812160508.20694.35958.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 09:05:08 -0700 Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org, emu-chairs@tools.ietf.org Subject: [Emu] Barry Leiba's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 16:43:08 -0000 Barry Leiba has entered the following ballot position for draft-ietf-emu-eap-tunnel-method-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm going to raise Spencer's comment to a DISCUSS: I find the version negotiation in Section 3.1 to be somewhat confusingly written. Possibly it will be implemented correctly because people generally know how to code version negotiation -- but I don't think the text here makes it clear. First, you seem to be using "EAP peer" and "TEAP peer" interchangably. = Please make sure you're consistent in your usage, and if there really is a difference then make that clear and explain it. You similarly say "EAP server" and "TEAP server" -- again, are they the same, or different enities? Second, I'm confused by "server" and "peer". Peers talk with peers; when there's a server, there's a client. What does it mean to have a server and a peer (in the document in general, and in this negotiation in particular)? Now, I think you're trying to say this: 1. The server gives the highest version it supports. 2. The client does one of three things: 2a. Sends a response that echos the server's version. 2b. Sends a response that offers a lower version. 2c. Sends a Nak, and we're done here (perhaps we continue with something else). 3. For 2b, the server does one of two things: 3a. Accepts the client's version and continues. 3b. [Does something else; see Spencer's comment.] Now, I like this approach, in that both the client and server can refuse an earlier version (which perhaps has security flaws), so that's nice. = But I think the wording of the negotiation process ought to be fixed to make it clearer, and that what happens in case 3b, especially, needs to be clearer. I also think that numbering the list(s) will help, though you don't have to use my numbering (and if you can make it clear without numbers, that's fine). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I note that the shepherd writeup included key information about reviews from outside the working group. Thanks for that; it's very useful. In Section 3.3.2, it might be useful to (briefly) note *why* one SHOULD NOT use EAP-FAST-GTC. From jari.arkko@piuha.net Mon Aug 12 10:16:59 2013 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 BC8B321F8F29; Mon, 12 Aug 2013 10:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 sL2Q8Jx4-2JD; Mon, 12 Aug 2013 10:16:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1816C21F844D; Mon, 12 Aug 2013 10:03:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Jari Arkko" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130812170350.20195.71345.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 10:03:50 -0700 Cc: draft-ietf-emu-crypto-bind@tools.ietf.org, emu@ietf.org, emu-chairs@tools.ietf.org Subject: [Emu] Jari Arkko's No Objection on draft-ietf-emu-crypto-bind-04: (with COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 17:16:59 -0000 Jari Arkko has entered the following ballot position for draft-ietf-emu-crypto-bind-04: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Is there a response to the Gen-ART review by Francis Dupont? From jsalowey@cisco.com Mon Aug 12 11:10:13 2013 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 D395421F9E5C; Mon, 12 Aug 2013 11:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 fVdYnbl+KxIb; Mon, 12 Aug 2013 11:10:09 -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 56BED21F9B92; Mon, 12 Aug 2013 11:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2451; q=dns/txt; s=iport; t=1376331008; x=1377540608; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=FWE4zyTLKdkqIFAV4i/O45Yr0SJWqI2cefvzLm7A1uA=; b=DLypQGhIGQMNpwuQqw+0pcrI6WheAlVasrNxg9htmbBS+X8rfvA0EcUJ 2/hDdCJQaWkR8XdaFUL8nDYOKfvzaCg9mz1L6rvYzXMd9iUg/bChJ0mJ1 LvDGzGzNm29KZEqZrNZ57W+HyRMnKcpZ/inzo9vOPKEHF0T20S4TXFjBA o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFMkCVKtJV2Y/2dsb2JhbABbgwY1UL5WgRoWdIIkAQEBAwE6PwULAgEIIhQQIRElAgQOBQgBh3UDCQYMrWoNiF6NSoErCoEJAjECBYMbdgOVe4MVin6FJ4FhgTqBaAkXIg X-IronPort-AV: E=Sophos;i="4.89,863,1367971200"; d="scan'208";a="246370663" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 12 Aug 2013 18:10:07 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7CIA7Um003443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 18:10:07 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 13:10:07 -0500 From: "Joseph Salowey (jsalowey)" To: Spencer Dawkins Thread-Topic: Spencer Dawkins' No Objection on draft-ietf-emu-eap-tunnel-method-07: (with COMMENT) Thread-Index: AQHOlS8M6njzubiPtkuDZONvYcxOh5mSN9aA Date: Mon, 12 Aug 2013 18:10:06 +0000 Message-ID: References: <20130809182802.7830.86269.idtracker@ietfa.amsl.com> In-Reply-To: <20130809182802.7830.86269.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <6B5DB9ABE1CA534E8BE66C279E912B13@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , The IESG , "" , "" Subject: Re: [Emu] Spencer Dawkins' No Objection on draft-ietf-emu-eap-tunnel-method-07: (with COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 18:10:14 -0000 Hi Spencer, I think the text is a bit confusing. I should say something like: "It should say "it MUST either terminate the conversation with an EAP-Failu= re or negotiate a new EAP type. If the server does support the version the= n the conversation continues using the version proposed by the peer. " Does this help? Thanks, Joe On Aug 9, 2013, at 11:28 AM, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-emu-eap-tunnel-method-07: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I considered balloting Discuss, but I'm assuming that either I'm missing > something really obvious, or this will be an easy fix ... >=20 > In 3.1. Version Negotiation >=20 > If the TEAP server does not support the version number proposed by > the TEAP peer, it MAY terminate the conversation with EAP-Failure > or negotiate for another EAP type. Otherwise the TEAP > conversation continues. >=20 > I'm wondering if "MAY terminate the conversation" is what you mean when > the TEAP peer doesn't propose a version number that the TEAP server > supports. >=20 > I'm reading "otherwise the TEAP conversation continues" as saying that > the two alternatives given are the only choices when the TEAP server > doesn't support a proposed version number. Did I get that right?=20 >=20 > If you're expecting the TEAP server to do one of those two things, > something like "MUST terminate the conversation unless the TEAP server > negotiates for a different version number" might be clearer. >=20 > If there are more than two alternatives, it would be helpful to rephrase > this text so it's clear that theTEAP server isn't limited to those two > alternatives. >=20 >=20 From jsalowey@cisco.com Mon Aug 12 12:24:52 2013 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 A00C521F9E68; Mon, 12 Aug 2013 12:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.849 X-Spam-Level: X-Spam-Status: No, score=-110.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 uyHDfk2KT5EQ; Mon, 12 Aug 2013 12:24:47 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3B721F9E37; Mon, 12 Aug 2013 12:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5072; q=dns/txt; s=iport; t=1376335486; x=1377545086; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pBrjHJ2p/o5HDs1TYrTFtB59WFPxrPiRthCZtq5Epz0=; b=hk4wRmIWrm+seTou1UAH1X3XNSjoJB/e7A/duYEdFIoNX1XR8stijK4Y NN88cUssZHd4eWHvkLy3Yl3iBKw4pgIafKzbdjqSi5Bhux/e9lyhfyJOr vGYciWMuTxkNjwy9frJO0YZWl8pzVQlRnKDSwTFUk4vk1NdRfoplJgWxH c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACE2CVKtJV2b/2dsb2JhbABbgwY1UL5WgRsWdIIkAQEBAwEBAQE3NAsFCwIBCCIUECcLJQIEDgUIAYgBBgy2W451gRMCMQIFgxt2A5NMhUSQJYFhgTqBcTk X-IronPort-AV: E=Sophos;i="4.89,863,1367971200"; d="scan'208";a="246223677" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 12 Aug 2013 19:24:45 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7CJOj22001803 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Aug 2013 19:24:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.235]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 12 Aug 2013 14:24:45 -0500 From: "Joseph Salowey (jsalowey)" To: Barry Leiba Thread-Topic: [Emu] Barry Leiba's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) Thread-Index: AQHOl3sOa3N1c6zuh0+lOMEMXJqBqJmSSBuA Date: Mon, 12 Aug 2013 19:24:44 +0000 Message-ID: References: <20130812160508.20694.35958.idtracker@ietfa.amsl.com> In-Reply-To: <20130812160508.20694.35958.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.54] Content-Type: text/plain; charset="us-ascii" Content-ID: <3D7EBD65F5E33949BDC4D393BD6D4CFF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , The IESG , "" , "" Subject: Re: [Emu] Barry Leiba's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 19:24:52 -0000 Hi Barry, Comments inline below/=20 On Aug 12, 2013, at 9:05 AM, Barry Leiba wrote: > Barry Leiba has entered the following ballot position for > draft-ietf-emu-eap-tunnel-method-07: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) >=20 >=20 > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > I'm going to raise Spencer's comment to a DISCUSS: I find the version > negotiation in Section 3.1 to be somewhat confusingly written. Possibly > it will be implemented correctly because people generally know how to > code version negotiation -- but I don't think the text here makes it > clear. >=20 > First, you seem to be using "EAP peer" and "TEAP peer" interchangably.=20 > Please make sure you're consistent in your usage, and if there really is > a difference then make that clear and explain it. You similarly say "EAP > server" and "TEAP server" -- again, are they the same, or different > enities? >=20 [Joe] TEAP and EAP are interchangeable in this case. We'll clean up this = section.=20 > Second, I'm confused by "server" and "peer". Peers talk with peers; when > there's a server, there's a client. What does it mean to have a server > and a peer (in the document in general, and in this negotiation in > particular)? >=20 [Joe] EAP Peer refers to the client. This is EAP specific terminology, I d= on't know why EAP uses peer instead of client, but I think its important fo= r us to stay consistent with EAP terminology.=20 > Now, I think you're trying to say this: > 1. The server gives the highest version it supports. > 2. The client does one of three things: > 2a. Sends a response that echos the server's version. > 2b. Sends a response that offers a lower version. > 2c. Sends a Nak, and we're done here (perhaps we continue with something > else). > 3. For 2b, the server does one of two things: > 3a. Accepts the client's version and continues. > 3b. [Does something else; see Spencer's comment.] >=20 > Now, I like this approach, in that both the client and server can refuse > an earlier version (which perhaps has security flaws), so that's nice.=20 > But I think the wording of the negotiation process ought to be fixed to > make it clearer, and that what happens in case 3b, especially, needs to > be clearer. >=20 > I also think that numbering the list(s) will help, though you don't have > to use my numbering (and if you can make it clear without numbers, that's > fine). >=20 [Joe] How about the following text? =20 Version negotiation proceeds as follows: 1. In the first EAP-Request sent with EAP type=3DTEAP, the TEAP server MUST= set the version field to the highest version it supports. 2a. If the TEAP peer supports the proposed version, it responds with an EAP= -Response of EAP type=3DTEAP including the version number proposed by the T= EAP server. 2b. If the TEAP peer does not support the proposed version but supports a l= ower version, it responds with an EAP-Response of EAP type=3DTEAP and sets = the version field its highest supported version. 2c. If the TEAP peer only supports versions higher than the version propose= d by the TEAP server, then use of TEAP will not be possible. In this case,= the TEAP peer sends back an EAP-Nak either to negotiate a different EAP ty= pe or to indicate no other EAP types are a available. 3a. If the TEAP server does not support the version number proposed by the= TEAP peer, it it MUST either terminate the conversation with an EAP-Failur= e or negotiate a new EAP type. =20 3b. If the TEAP server does support the version then the conversation cont= inues using the version proposed by the TEAP peer. >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I note that the shepherd writeup included key information about reviews > from outside the working group. Thanks for that; it's very useful. >=20 > In Section 3.3.2, it might be useful to (briefly) note *why* one SHOULD > NOT use EAP-FAST-GTC. >=20 [Joe] Modified text:=20 The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT RECOMMENDED= with TEAPv1 because EAP-FAST-GTC is not compliant with EAP-GTC defined in = [RFC3748]. >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From barryleiba@gmail.com Mon Aug 12 13:01:21 2013 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 97D4021F9E47; Mon, 12 Aug 2013 13:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.986 X-Spam-Level: X-Spam-Status: No, score=-101.986 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, 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 sarYjygfL1bf; Mon, 12 Aug 2013 13:01:21 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 00DAE21F9E33; Mon, 12 Aug 2013 13:01:20 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id a1so3196817qcx.17 for ; Mon, 12 Aug 2013 13:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=4MtZqU4Di7hH7NdletlURzV1JQp0ftRpBqnOuSglfGE=; b=MF5TsDa2emtoSUGSNdzBVut3UnwRoM3zKim1GtcZOlZzozPt9Z5yUBQQpiv1X/CNa+ ZG5ik0wcVt7CC4r4zFGvNnEZ2/wS8TMkdj36jhLhWToBTwBum9BU4sXAL5gCMt+X4zs+ JY6QUWMddWGjBW89YX7Kx2VnrJEGyb0G+Y6lyjEhMSXGjs8PjUEnbXhZskHOvrFh3Waz 0i6y0371uC+kkNiuAaRxmX/xL2mLUMXmVeZTphg5En0h7A/dA98OmvS3xQ2CAA29z0Zx 79gnjwuSCfV1LvA+np9gLS0jpHk2eeWk1PrhK6Gkufc87XO7ooAACsKqGf6ObxTMIYxN SJLA== MIME-Version: 1.0 X-Received: by 10.224.166.197 with SMTP id n5mr814011qay.98.1376337680422; Mon, 12 Aug 2013 13:01:20 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.224.59.211 with HTTP; Mon, 12 Aug 2013 13:01:20 -0700 (PDT) In-Reply-To: References: <20130812160508.20694.35958.idtracker@ietfa.amsl.com> Date: Mon, 12 Aug 2013 22:01:20 +0200 X-Google-Sender-Auth: tKNUn3vfjtgY5aFNUBMnLdGofe8 Message-ID: From: Barry Leiba To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , The IESG , "" , "" Subject: Re: [Emu] Barry Leiba's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 20:01:21 -0000 > [Joe] TEAP and EAP are interchangeable in this case. We'll clean up this section. Thanks. > [Joe] EAP Peer refers to the client. This is EAP specific terminology, I don't know > why EAP uses peer instead of client, but I think its important for us to stay consistent > with EAP terminology. You're right; 'nuff said on this one, and thanks for the explanation. > [Joe] How about the following text? > > Version negotiation proceeds as follows: > > 1. In the first EAP-Request sent with EAP type=TEAP, the TEAP server > MUST set the version field to the highest version it supports. > > 2a. If the TEAP peer supports the proposed version, it responds with an > EAP-Response of EAP type=TEAP including the version number proposed > by the TEAP server. > > 2b. If the TEAP peer does not support the proposed version but supports a > lower version, it responds with an EAP-Response of EAP type=TEAP and > sets the version field its highest supported version. > > 2c. If the TEAP peer only supports versions higher than the version proposed > by the TEAP server, then use of TEAP will not be possible. In this case, the > TEAP peer sends back an EAP-Nak either to negotiate a different EAP type > or to indicate no other EAP types are a available. > > 3a. If the TEAP server does not support the version number proposed by the > TEAP peer, it it MUST either terminate the conversation with an EAP-Failure > or negotiate a new EAP type. > > 3b. If the TEAP server does support the version then the conversation > continues using the version proposed by the TEAP peer. That looks clear to me; thanks for addressing this! >> In Section 3.3.2, it might be useful to (briefly) note *why* one SHOULD >> NOT use EAP-FAST-GTC. > > [Joe] Modified text: > > The use of EAP-FAST-GTC as defined in RFC 5421 [RFC5421] is NOT > RECOMMENDED with TEAPv1 because EAP-FAST-GTC is not compliant > with EAP-GTC defined in [RFC3748]. Perfect. Again, thanks. Barry From spencerdawkins.ietf@gmail.com Mon Aug 12 11:20:39 2013 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 1FBFA21F9DDB; Mon, 12 Aug 2013 11:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3FRyA+eN6e-9; Mon, 12 Aug 2013 11:20:38 -0700 (PDT) Received: from mail-pd0-x232.google.com (mail-pd0-x232.google.com [IPv6:2607:f8b0:400e:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1242821F9DC6; Mon, 12 Aug 2013 11:20:38 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so3733170pde.23 for ; Mon, 12 Aug 2013 11:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qsJ3txPuFeyrinun0fjH+IXoN11ztBYgYVTXNsA+yYc=; b=v/A0bgP1I8D95nhOObYMeNpjZEs5SKlT31shfZ3tMEnUQaQWdAhktFHZNPQjS9z/C8 Zkb2Tw/RQj2JANyP0NNyMcxvddxzyhvEHTpfqnOccm2Y5BCNmNiTQnVTbAxrUEZywdXJ 8UG6GglLGMgmQgKTQK1QV5PWPvyYt2+SM7SD+065WlfjbjQ2XCYVjzeNRvzBI6LmyxMG BaIJ+HuKV4/8AuHYqkMFzP3Kv+JurHkwiLBNMJdOFk1DEPnq7WXAcmJlpPAZBYFbW/Tv YxwyQaM/W2zluLiT89Y3Z/97EC0oLbkbNn1pQLK5L6pqugiTTcfo9pGvzDLMFf+J1XIu MAvQ== X-Received: by 10.66.188.203 with SMTP id gc11mr354465pac.63.1376331637809; Mon, 12 Aug 2013 11:20:37 -0700 (PDT) Received: from [192.168.0.30] (173-135-27-189.pools.spcsdns.net. [173.135.27.189]) by mx.google.com with ESMTPSA id sx7sm38695730pbc.41.2013.08.12.11.20.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 12 Aug 2013 11:20:36 -0700 (PDT) Message-ID: <5209276A.9010009@gmail.com> Date: Mon, 12 Aug 2013 13:20:26 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <20130809182802.7830.86269.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 12 Aug 2013 13:54:51 -0700 Cc: "" , The IESG , "" , "" Subject: Re: [Emu] Spencer Dawkins' No Objection on draft-ietf-emu-eap-tunnel-method-07: (with COMMENT) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 18:20:39 -0000 On 8/12/2013 1:10 PM, Joseph Salowey (jsalowey) wrote: > Hi Spencer, > > I think the text is a bit confusing. I should say something like: > > "It should say "it MUST either terminate the conversation with an EAP-Failure or negotiate a new EAP type. If the server does support the version then the conversation continues using the version proposed by the peer." > > Does this help? Yes, it helps me quite a bit. I note that Barry picked this question up, but has additional comments in his Discuss as well ... Spencer > Thanks, > > Joe > On Aug 9, 2013, at 11:28 AM, Spencer Dawkins wrote: > >> Spencer Dawkins has entered the following ballot position for >> draft-ietf-emu-eap-tunnel-method-07: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> I considered balloting Discuss, but I'm assuming that either I'm missing >> something really obvious, or this will be an easy fix ... >> >> In 3.1. Version Negotiation >> >> If the TEAP server does not support the version number proposed by >> the TEAP peer, it MAY terminate the conversation with EAP-Failure >> or negotiate for another EAP type. Otherwise the TEAP >> conversation continues. >> >> I'm wondering if "MAY terminate the conversation" is what you mean when >> the TEAP peer doesn't propose a version number that the TEAP server >> supports. >> >> I'm reading "otherwise the TEAP conversation continues" as saying that >> the two alternatives given are the only choices when the TEAP server >> doesn't support a proposed version number. Did I get that right? >> >> If you're expecting the TEAP server to do one of those two things, >> something like "MUST terminate the conversation unless the TEAP server >> negotiates for a different version number" might be clearer. >> >> If there are more than two alternatives, it would be helpful to rephrase >> this text so it's clear that theTEAP server isn't limited to those two >> alternatives. >> >> From stephen.farrell@cs.tcd.ie Wed Aug 14 10:58:33 2013 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 03A4C11E8181; Wed, 14 Aug 2013 10:58:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 cNmL12eUQSQL; Wed, 14 Aug 2013 10:58:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D1411E8159; Wed, 14 Aug 2013 10:58:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 10:58:31 -0700 Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org, emu-chairs@tools.ietf.org Subject: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) 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, 14 Aug 2013 17:58:33 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-emu-eap-tunnel-method-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- These discuss points are more questions I'd really like answered than blocking points (depending on the answers I guess:-) but I expect should be easily resolved. (1) 3.4: when x.500 names or SubjectAltNames are "exported" is it clear how those are formatted? Maybe a pointer to where that's defined would be good in case implementers get it wrong. You might also want to warn here (or somewhere) about names that contain a null byte in case that attack is used e.g. with a TLS server cert subject name like "CN=3Dwww.paypal.com\0.badguy.com" Even though that's really a PKI failure, not detecting it here would be bad too. (2) 5.2, at the end: this adds a dependency on the TLS-PRF. I don't suppose TLS1.3 will be a big enough change for that to be a problem, but what if it was? E.g. if someone convinced the TLS WG to use IKE instead? Do you really need the same PRF or could you pick one for TEAP and remove the dependency? Same question for the MAC in 5.3. (3) 7.3: you have a MAY for this separation but also define what would become a cleartext password set of TLVs on the link between the two boxes here. Could you not at least REQUIRE protection (e.g. using IPsec) of that link if the basic password method will be used? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 3.2: You're allowing TLS compression. Is there the potential for something like a CRIME attack here? I guess not, given that there's no way to programatically get a peer or inner method server to send attacker-chosen data. Is that correct? (Just checking.) - 3.2.2: Since a PAC-lifetime is a wall-clock time then it would provide a way to correlate old and new sessions (i.e. act as a fingerprint) if its ever carried in clear. Can that happen? - 3.3.3, 1st para: what does "clear text" mean here? Do you mean within the TLS tunnel or not? I hope you do mean within the TLS tunnel, but I think you need to be clear(er) in any case. - 3.8: this says mutual auth "results" if the peer trusts the server cert belongs to the server - that sounds wrong, isn't it? - 3.8.1: I think you need an s/MAY/MUST/ here - you say the request "MAY be issued only ..." but I think you mean "MUST be issued only..." - 3.8.2: Just checking, and I may be wrong here. Say if I establish a TLS server-auth tunnel and then renegotiate to get TLS client-auth (with id privacy) as well, and then the Peer wants to get a new cert. This calls for the tls-unique for the initial server-auth TLS session to be used in the pkcs#10. Am I reading it right? Is that ok? I think it is, but just want to check since its pretty confusing;-) - The secdir review [1] raised a couple of questions that I think would be good to answer. Did I miss that answer? [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html From hartmans@mit.edu Wed Aug 14 13:12:12 2013 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 3B96F21E80DA; Wed, 14 Aug 2013 13:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 xkTCsMJKPMve; Wed, 14 Aug 2013 13:12:07 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 907A521E80F7; Wed, 14 Aug 2013 13:11:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9F3F220288; Wed, 14 Aug 2013 16:10:20 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2HGun8N8WRP; Wed, 14 Aug 2013 16:10:20 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 14 Aug 2013 16:10:20 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5F2338051A; Wed, 14 Aug 2013 16:11:29 -0400 (EDT) From: Sam Hartman To: "Stephen Farrell" References: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 16:11:29 -0400 In-Reply-To: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> (Stephen Farrell's message of "Wed, 14 Aug 2013 10:58:31 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, The IESG , emu-chairs@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) 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, 14 Aug 2013 20:12:12 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> (1) 3.4: when x.500 names or SubjectAltNames are "exported" Stephen> is it clear how those are formatted? Maybe a pointer to Stephen> where that's defined would be good in case implementers get Stephen> it wrong. You might also want to warn here (or somewhere) Stephen> about names that contain a null byte in case that attack is Stephen> used e.g. with a TLS server cert subject name like Stephen> "CN=www.paypal.com\0.badguy.com" Even though that's really Stephen> a PKI failure, not detecting it here would be bad too. we're talking about the server and peer ID? I asked the same question and we pondered it during an IETF meeting and all came to the conclusion that the formatting doesn't matter. We want to specify what's included but we don't need to specify how it's formatting. The argument that convinced me to drop the issue was that peer id and server id didn''t seem to be used and probably aren't interoperable. Someone decided somewhere that EAP methods should have these but didn't define them well enough to be useful. Stephen> (3) 7.3: you have a MAY for this separation but also define Stephen> what would become a cleartext password set of TLVs on the Stephen> link between the two boxes here. Could you not at least Stephen> REQUIRE protection (e.g. using IPsec) of that link if the Stephen> basic password method will be used? I would object fairly strongly to IPsec here because I don't think it's reasonably implementable by the EAP implementation. Basically no implementation of EAP is going to be in a good position to manipulate the SPD and figure out whether IPsec is actually used. I think RADIUS over TLS and Diameter over TLS are much better security mechanisms for this. From hartmans@mit.edu Wed Aug 14 13:16:09 2013 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 638D221F93FB; Wed, 14 Aug 2013 13:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 JVnDV8z8aKo8; Wed, 14 Aug 2013 13:16:03 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 90B2511E8118; Wed, 14 Aug 2013 13:16:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 23D002028D; Wed, 14 Aug 2013 16:14:52 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Adk_uwOUsPox; Wed, 14 Aug 2013 16:14:51 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 14 Aug 2013 16:14:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CFC588051A; Wed, 14 Aug 2013 16:16:00 -0400 (EDT) From: Sam Hartman To: "Joseph Salowey \(jsalowey\)" References: <20130808192411.10939.54546.idtracker@ietfa.amsl.com> Date: Wed, 14 Aug 2013 16:16:00 -0400 In-Reply-To: (Joseph Salowey's message of "Fri, 9 Aug 2013 23:20:30 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "" , "" , The IESG , "" , Martin Stiemerling Subject: Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS) 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, 14 Aug 2013 20:16:09 -0000 >>>>> "Joseph" == Joseph Salowey (jsalowey) writes: Joseph> [Joe] Retransmission and timeout behavior for EAP is Joseph> discussed in the EAP RFC 3748 Section 4.3. Echoing Joe's point, we over in abfab (draft-ietf-abfab-gss-eap) would be really unhappy if EAP method specs started discussing timeouts. From hartmans@mit.edu Wed Aug 14 13:22:26 2013 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 C322F21E80DF; Wed, 14 Aug 2013 13:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 h3r0XR6xMGkm; Wed, 14 Aug 2013 13:22:17 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3C921E80D6; Wed, 14 Aug 2013 13:22:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 599B720280; Wed, 14 Aug 2013 16:21:06 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xim3f0Au-Lp4; Wed, 14 Aug 2013 16:21:05 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 14 Aug 2013 16:21:05 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5EBA78051A; Wed, 14 Aug 2013 16:22:14 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <5203718A.6050702@restena.lu> Date: Wed, 14 Aug 2013 16:22:14 -0400 In-Reply-To: <5203718A.6050702@restena.lu> (Stefan Winter's message of "Thu, 08 Aug 2013 12:23:06 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: emu@ietf.org, iesg@ietf.org Subject: Re: [Emu] Some proposed error conditions for draft-ietf-emu-eap-tunnel-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: Wed, 14 Aug 2013 20:22:26 -0000 IESG, we seem to have a case where a document is on tomorrow's agenda but a last-call discussion got left hanging. Josh Howlett brought forward a last call comment about error handling; it was discussed in the Berlin session. There seemed to be general support for adding errors. Josh proposed a set of errors that day. There was one response, but as best I can tell the discussion kind of dangled while still active as everyone recovered from the IETF. I think this issue should be resolved before approval. >>>>> "Stefan" == Stefan Winter writes: Stefan> Hi, >> As discussed in Berlin, to get the ball rolling here is an >> initial proposal for some inner method error conditions. Stefan> The question IMHO is: there are many inner EAP methods Stefan> specified already, and they don't typically specify or Stefan> signal most of the error conditions below to the EAP Stefan> peer. The TEAP document can't impose change on all those Stefan> inner methods; they are what they are. If they tell neither Stefan> the EAP peer nor export that information to the TEAP layer, Stefan> then there is nothing we can write in the TEAP document that Stefan> will make it happen. agreed. Stefan> This limits the scope of the error conditions to cases where Stefan> TEAP has "all in its own hands" - which I believe is limited Stefan> to the "Optional Password Authentication" of chapter 3.3.2. DIsagreed. AAA servers don't signal all of these up, but AAA servers often signal a number of these. For example in Freeradius I could actually figure out a number of these even across an inner tunnel and could easily expand the server to do better than that. However if you have nothing else then you are left with inner method error. From stephen.farrell@cs.tcd.ie Thu Aug 15 03:17:39 2013 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 19E4C21E809D; Thu, 15 Aug 2013 03:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 rj++4CMQyBoO; Thu, 15 Aug 2013 03:17:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C3B11E80E4; Thu, 15 Aug 2013 03:17:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815101738.15648.65106.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 03:17:38 -0700 Cc: draft-ietf-emu-crypto-bind@tools.ietf.org, emu@ietf.org, emu-chairs@tools.ietf.org Subject: [Emu] Stephen Farrell's Yes on draft-ietf-emu-crypto-bind-04: (with COMMENT) 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, 15 Aug 2013 10:17:39 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-emu-crypto-bind-04: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 3.2.3: this confused me "First, the server and peer prove to each other knowledge of the inner MSK. Then, the inner MSK is combined into some outer key material to form the tunnel's keys." Reading that, the implication would be that I form a tunnel, then inside the tunnel do EAP resulting in the inner MSK, and after that I "form the tunnel's keys" which seems impossible as I've used the tunnel already so how can I "form" its keys? Do you mean "confirm" instead? (And a nit: "combined into" seems odd, "combined with" would be clearer for me.) From hartmans@mit.edu Thu Aug 15 06:44:12 2013 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 DCE0821E8139; Thu, 15 Aug 2013 06:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 BmOcVhd-wAxL; Thu, 15 Aug 2013 06:44:07 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1437F21E814C; Thu, 15 Aug 2013 06:44:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 01ABF2028D; Thu, 15 Aug 2013 09:42:54 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdPfdf53uMMP; Thu, 15 Aug 2013 09:42:53 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 15 Aug 2013 09:42:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2F2CD8052F; Thu, 15 Aug 2013 09:44:05 -0400 (EDT) From: Sam Hartman To: "Stephen Farrell" References: <20130815101738.15648.65106.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 09:44:05 -0400 In-Reply-To: <20130815101738.15648.65106.idtracker@ietfa.amsl.com> (Stephen Farrell's message of "Thu, 15 Aug 2013 03:17:38 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-ietf-emu-crypto-bind@tools.ietf.org, The IESG , emu-chairs@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Stephen Farrell's Yes on draft-ietf-emu-crypto-bind-04: (with COMMENT) 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, 15 Aug 2013 13:44:13 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> Stephen Farrell has entered the following ballot position Stephen> COMMENT: ---------------------------------------------------------------------- Stephen> 3.2.3: this confused me "First, the server and peer prove Stephen> to each other knowledge of the inner MSK. Then, the inner Stephen> MSK is combined into some outer key material to form the Stephen> tunnel's keys." Reading that, the implication would be Stephen> that I form a tunnel, then inside the tunnel do EAP Stephen> resulting in the inner MSK, and after that I "form the Stephen> tunnel's keys" which seems impossible as I've used the Stephen> tunnel already so how can I "form" its keys? Do you mean Stephen> "confirm" instead? (And a nit: "combined into" seems odd, Stephen> "combined with" would be clearer for me.) No your first reading is correct. Perhaps tunnel's EAP keys would make it more clear. At the end of tunnel setup after inner EAP methods are run, the MSK and EMSK for the tunnel are generated. Obviously the traffic keys for the tunnel are generated much earlier. I'm happy if you and Shawn agree on an RFC editor note to do something like say tunnel's EAP keys and use combined with From stephen.farrell@cs.tcd.ie Thu Aug 15 06:56:48 2013 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 D1E8921E8143; Thu, 15 Aug 2013 06:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 RSzX7X7K5ytk; Thu, 15 Aug 2013 06:56:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8019521E8147; Thu, 15 Aug 2013 06:56:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D8595BE53; Thu, 15 Aug 2013 14:56:36 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZeRUhEmBOFj; Thu, 15 Aug 2013 14:56:36 +0100 (IST) Received: from [134.226.63.225] (cswireless63-225.scss.tcd.ie [134.226.63.225]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B4797BE38; Thu, 15 Aug 2013 14:56:36 +0100 (IST) Message-ID: <520CDE14.6040606@cs.tcd.ie> Date: Thu, 15 Aug 2013 14:56:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sam Hartman References: <20130815101738.15648.65106.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-emu-crypto-bind@tools.ietf.org, The IESG , emu-chairs@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Stephen Farrell's Yes on draft-ietf-emu-crypto-bind-04: (with COMMENT) 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, 15 Aug 2013 13:56:49 -0000 Hi Sam, On 08/15/2013 02:44 PM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Farrell writes: > > Stephen> Stephen Farrell has entered the following ballot position > Stephen> COMMENT: ---------------------------------------------------------------------- > > > Stephen> 3.2.3: this confused me "First, the server and peer prove > Stephen> to each other knowledge of the inner MSK. Then, the inner > Stephen> MSK is combined into some outer key material to form the > Stephen> tunnel's keys." Reading that, the implication would be > Stephen> that I form a tunnel, then inside the tunnel do EAP > Stephen> resulting in the inner MSK, and after that I "form the > Stephen> tunnel's keys" which seems impossible as I've used the > Stephen> tunnel already so how can I "form" its keys? Do you mean > Stephen> "confirm" instead? (And a nit: "combined into" seems odd, > Stephen> "combined with" would be clearer for me.) > > > > No your first reading is correct. > Perhaps tunnel's EAP keys would make it more clear. It would. > At the end of tunnel setup after inner EAP methods are run, the MSK and > EMSK for the tunnel are generated. > Obviously the traffic keys for the tunnel are generated much earlier. > > I'm happy if you and Shawn agree on an RFC editor note to do something > like say tunnel's EAP keys and use combined with That'd work for me. Ta, S. > From turners@ieca.com Thu Aug 15 07:16:11 2013 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 9760521E8157 for ; Thu, 15 Aug 2013 07:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.973 X-Spam-Level: X-Spam-Status: No, score=-101.973 tagged_above=-999 required=5 tests=[AWL=0.292, 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 9mOO5aBSb0LF for ; Thu, 15 Aug 2013 07:16:05 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.93.126.19]) by ietfa.amsl.com (Postfix) with ESMTP id 667BA21E814A for ; Thu, 15 Aug 2013 07:16:05 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 84477BA69352F; Thu, 15 Aug 2013 09:16:04 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 56B65BA693479 for ; Thu, 15 Aug 2013 09:16:04 -0500 (CDT) Received: from [96.231.225.44] (port=57634 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1V9yLL-0004Wt-LN; Thu, 15 Aug 2013 09:16:03 -0500 Message-ID: <520CE2A2.4020205@ieca.com> Date: Thu, 15 Aug 2013 10:16:02 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell , Sam Hartman References: <20130815101738.15648.65106.idtracker@ietfa.amsl.com> <520CDE14.6040606@cs.tcd.ie> In-Reply-To: <520CDE14.6040606@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:57634 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: draft-ietf-emu-crypto-bind@tools.ietf.org, The IESG , emu-chairs@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Stephen Farrell's Yes on draft-ietf-emu-crypto-bind-04: (with COMMENT) 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, 15 Aug 2013 14:16:11 -0000 On 8/15/13 9:56 AM, Stephen Farrell wrote: > > Hi Sam, > > On 08/15/2013 02:44 PM, Sam Hartman wrote: >>>>>>> "Stephen" == Stephen Farrell writes: >> >> Stephen> Stephen Farrell has entered the following ballot position >> Stephen> COMMENT: ---------------------------------------------------------------------- >> >> >> Stephen> 3.2.3: this confused me "First, the server and peer prove >> Stephen> to each other knowledge of the inner MSK. Then, the inner >> Stephen> MSK is combined into some outer key material to form the >> Stephen> tunnel's keys." Reading that, the implication would be >> Stephen> that I form a tunnel, then inside the tunnel do EAP >> Stephen> resulting in the inner MSK, and after that I "form the >> Stephen> tunnel's keys" which seems impossible as I've used the >> Stephen> tunnel already so how can I "form" its keys? Do you mean >> Stephen> "confirm" instead? (And a nit: "combined into" seems odd, >> Stephen> "combined with" would be clearer for me.) >> >> >> >> No your first reading is correct. >> Perhaps tunnel's EAP keys would make it more clear. > > It would. > >> At the end of tunnel setup after inner EAP methods are run, the MSK and >> EMSK for the tunnel are generated. >> Obviously the traffic keys for the tunnel are generated much earlier. >> >> I'm happy if you and Shawn agree on an RFC editor note to do something >> like say tunnel's EAP keys and use combined with > > That'd work for me. > Ta, > S. Sam, I'll get Stephen to shoot me some text and we'll add it in as an RFC editor note to get this one approved today. spt From stephen.farrell@cs.tcd.ie Thu Aug 15 07:36:17 2013 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 A5E1721F999C; Thu, 15 Aug 2013 07:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, 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 UkqzPsfAnyXX; Thu, 15 Aug 2013 07:36:11 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id ED60221F9FBE; Thu, 15 Aug 2013 07:36:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2CB88BE3F; Thu, 15 Aug 2013 15:35:56 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE7BqTUlZBqQ; Thu, 15 Aug 2013 15:35:56 +0100 (IST) Received: from [134.226.63.225] (cswireless63-225.scss.tcd.ie [134.226.63.225]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EAD5FBE24; Thu, 15 Aug 2013 15:35:55 +0100 (IST) Message-ID: <520CE74B.6010408@cs.tcd.ie> Date: Thu, 15 Aug 2013 15:35:55 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sam Hartman References: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, The IESG , emu-chairs@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) 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, 15 Aug 2013 14:36:17 -0000 Hi Sam, On 08/14/2013 09:11 PM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Farrell writes: > > Stephen> (1) 3.4: when x.500 names or SubjectAltNames are "exported" > Stephen> is it clear how those are formatted? Maybe a pointer to > Stephen> where that's defined would be good in case implementers get > Stephen> it wrong. You might also want to warn here (or somewhere) > Stephen> about names that contain a null byte in case that attack is > Stephen> used e.g. with a TLS server cert subject name like > Stephen> "CN=www.paypal.com\0.badguy.com" Even though that's really > Stephen> a PKI failure, not detecting it here would be bad too. > > we're talking about the server and peer ID? > I asked the same question and we pondered it during an IETF meeting and > all came to the conclusion that the formatting doesn't matter. > We want to specify what's included but we don't need to specify how > it's formatting. > > The argument that convinced me to drop the issue was that peer id and > server id didn''t seem to be used and probably aren't interoperable. > Someone decided somewhere that EAP methods should have these but didn't > define them well enough to be useful. Ok, I'll make that a comment. Not sure if the text about names with null bytes is worth including or not but handling that as a comment is fine. > Stephen> (3) 7.3: you have a MAY for this separation but also define > Stephen> what would become a cleartext password set of TLVs on the > Stephen> link between the two boxes here. Could you not at least > Stephen> REQUIRE protection (e.g. using IPsec) of that link if the > Stephen> basic password method will be used? > > I would object fairly strongly to IPsec here because I don't think it's > reasonably implementable by the EAP implementation. > Basically no implementation of EAP is going to be in a good position to > manipulate the SPD and figure out whether IPsec is actually used. > > I think RADIUS over TLS and Diameter over TLS are much better security > mechanisms for this. Sure, those would be fine. But the question remains whether the spec needs to say that some such mechanism is required to be used or not. S. > From ietf-secretariat-reply@ietf.org Thu Aug 15 10:26:57 2013 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 D439311E81ED for ; Thu, 15 Aug 2013 10:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.447 X-Spam-Level: X-Spam-Status: No, score=-101.447 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, 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 qvLx71vB8DXY; Thu, 15 Aug 2013 10:26:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9394B11E81DF; Thu, 15 Aug 2013 10:26:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815172657.7676.92098.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 10:26:57 -0700 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: 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, 15 Aug 2013 17:26:58 -0000 State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-m= ethod/ From ietf-secretariat-reply@ietf.org Thu Aug 15 10:32:15 2013 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 B796911E81F3 for ; Thu, 15 Aug 2013 10:32:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Lh5huDTOtj79; Thu, 15 Aug 2013 10:32:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D9611E817D; Thu, 15 Aug 2013 10:32:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-crypto-bind@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815173215.17735.32808.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 10:32:15 -0700 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: 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, 15 Aug 2013 17:32:15 -0000 State changed to IESG Evaluation::Point Raised - writeup needed from IESG E= valuation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ From presnick@qti.qualcomm.com Thu Aug 15 06:57:29 2013 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 2A7B521E8143; Thu, 15 Aug 2013 06:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 X99LnUNg83bX; Thu, 15 Aug 2013 06:57:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0DC921E813D; Thu, 15 Aug 2013 06:57:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130815135722.12903.61534.idtracker@ietfa.amsl.com> Date: Thu, 15 Aug 2013 06:57:22 -0700 X-Mailman-Approved-At: Thu, 15 Aug 2013 10:43:42 -0700 Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org, emu-chairs@tools.ietf.org Subject: [Emu] Pete Resnick's No Objection on draft-ietf-emu-eap-tunnel-method-07: (with COMMENT) 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, 15 Aug 2013 13:57:30 -0000 Pete Resnick has entered the following ballot position for draft-ietf-emu-eap-tunnel-method-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I can't in good conscience make this a DISCUSS point because really, the best you're going to be able to do is hand-wave or wait on a not-yet-published document. But 4.2.15 (like a bunch of other documents) is really introducing an "...a miracle occurs..." solution. It is presuming that there is a user-input username and password in UTF-8, but no discussion of normalization or mappings. If you are OK with false negatives (i.e., in some circumstances people are going to type things that they are absolutely sure are their usernames and passwords, but they are going to fail, and they will be unable to type their "true" usernames or passwords), then you're probably OK doing nothing. If that would be a really bad outcome, to make it more resilient you could look at: http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ (This document is not just about SASL, the filename notwithstanding.) I'd like to say that the document will be published quickly, and maybe if you all pushed on the PRECIS folks it might, but I can't make any promises. And I wouldn't suggest using RFC 4013, because it's going to be obsoleted by the above (for good reasons). I'm glad to discuss this with the authors or the WG, but I won't force you to DISCUSS it. From jsalowey@cisco.com Thu Aug 15 14:54:11 2013 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 585D011E820F for ; Thu, 15 Aug 2013 14:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 03krDDIY6mW1 for ; Thu, 15 Aug 2013 14:54:06 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 52C1821F9991 for ; Thu, 15 Aug 2013 14:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7423; q=dns/txt; s=iport; t=1376603646; x=1377813246; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=StSgzTxIzFKp01+UElQJSXwNA+u/L6762U1V7+HdPTY=; b=EiQfY0slxv6xGp9qTSrGdHojSZedjw84zyBnBr/cUmiv8+rkpK5oUrd1 VQz6digdnMl9VbDClfI3EVKVmfu08x4z2F5Hh5DzajwqM102KHsrs/suo NL7vFAVJun/cztGVbXh3r0gFp3O4V2sN84Ki6km8KA0DUSfi0/PY65A0C I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAE1NDVKtJV2d/2dsb2JhbABSAQUDgwY1UL8VgSMWdIIkAQEBAwEBAQEJYgYFBQsCAQgiCwMWJwslAgQOBQgOh3QGDLocBI8KAwKBDgIxBwoHBgGDA3cDiHWgQYMbgWgCHgICAhw X-IronPort-AV: E=Sophos;i="4.89,888,1367971200"; d="scan'208";a="247874401" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 15 Aug 2013 21:54:05 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r7FLs5aU018146 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 15 Aug 2013 21:54:05 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.136]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 15 Aug 2013 16:54:04 -0500 From: "Joseph Salowey (jsalowey)" To: Stefan Winter Thread-Topic: [Emu] Some proposed error conditions for TEAP Thread-Index: AQHOkDejY4UXy9LBjEiw2wL8xzrc7JmLde0AgAvBXwA= Date: Thu, 15 Aug 2013 21:54:04 +0000 Message-ID: References: <5203718A.6050702@restena.lu> In-Reply-To: <5203718A.6050702@restena.lu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.54] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2B60ABC34F673D4A8EEE0EAF5BEB8BEB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [Emu] Some proposed error conditions for TEAP 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, 15 Aug 2013 21:54:11 -0000 On Aug 8, 2013, at 3:23 AM, Stefan Winter wrote: > Hi, >=20 >> As discussed in Berlin, to get the ball rolling here is an initial >> proposal for some inner method error conditions. >=20 > The question IMHO is: there are many inner EAP methods specified > already, and they don't typically specify or signal most of the error > conditions below to the EAP peer. The TEAP document can't impose change > on all those inner methods; they are what they are. If they tell neither > the EAP peer nor export that information to the TEAP layer, then there > is nothing we can write in the TEAP document that will make it happen. >=20 > This limits the scope of the error conditions to cases where TEAP has > "all in its own hands" - which I believe is limited to the "Optional > Password Authentication" of chapter 3.3.2. >=20 [Joe] I tend to agree that we shouldn't try to address errors that are spec= ific to inner methods. We should stick to things that are TEAP specific.=20 >> In addition to these, might there also be some value in an >> "Information-URL" TLV? The value could point to a web resource that >> provides further information for TEAP connections that are successful bu= t >> where, for example, user notification or action is desirable (e.g., >> password change). >=20 > I like that one. >=20 [Joe] So I would prefer to address this in a separate document. I can see = some issues here. How does one access the URL if they fail to get network = access? I imagine there are some security considerations around connecting= to some URL specified by the server. I suppose it would be OK if the clie= nt can authenticate and trust the server.=20 >> General errors >>=20 >> - Unspecified server problem >> - Unspecified authentication failure >> - Unspecified authorisation failure >> - User account credentials unavailable >> - User account expired >> - User account locked: try again later >> - User account locked: admin intervention required >> - Authentication server unavailable >=20 > I'm not sure about terminology here... "authentication server" often > refers to RADIUS servers, EAP servers, or maybe the authentication > backend that the EAP server consults to do its work. >=20 > Since we are talking about inner method failures, and we came to a stage > where RADIUS is obviously working, because it demonstrated that it can > transport messages to the EAP server; and where the EAP server is > obviously working, because it did the entire phase 1 exchange, the error > conditions above must refer to the "authentication backend" or "identity > management backend" (since that backend contains not just authentication > details for connecting entities, but also authorisation information). I > like that term more than a "server" (the backend could be a flat file in > simple deployments). >=20 > This would mean changing the first and last one to: >=20 > - Unspecified ID Management Backend problem > - ID Management Backend unavailable >=20 [Joe] I think these or some subset of these are OK.=20 >> - Authentication server not trusted >=20 > In phase 2 with Password Authentication, the server identity is not > verified (again). And for Phase 2 being another EAP method, this > untrustedness (as in X.509 verify failure?) would be signalled with a > TLS fatal alert in the inner method TLS setup phase. >=20 [Joe] agree with Stefan >> - Clock skew too great >=20 > Same; clock is irrelevant for password auth. If inner is EAP, the method > running either already has a way to signal this to the EAP peer or not; > nothing TEAP can do about this. >=20 [Joe] Agree with Stefan >> - Invalid inner realm >=20 > That's good. >=20 > Where outer and inner EAP terminate at the same server, it may also be > possible to check if there was a mismatch between inner and outer realm; > which may be administratively prohibited. This would add: >=20 > - Realm mismatch between inner and outer identity >=20 [Joe] I think these are good=20 >> Password errors >>=20 >> - User account unknown >>=20 >> - User account password expired >>=20 >> - User account password incorrect >>=20 >> - User account password change required >=20 > All fine (as in: works for TEAP's password auth - and some inner EAP > methods even signal this, e.g. MSCHAPv2; others may not and there is > nothing TEAP can do if not). [Joe] I'm not in favor of adding these. In general they go against securit= y guidelines about providing too much information on failed authentication.= =20 >=20 >> Challenge-Response errors >>=20 >> - Challenge expired >> - Challenge algorithm mismatch >>=20 [Joe] I don't think we should deal with these kinds of errors as they don'= t involve TEAP. =20 >>=20 >> One time password errors >>=20 >> - Token out of sync: administrator intervention required >> - Token out of sync: PIN change required >> - Token revoked >> - Tokens exhausted >>=20 [Joe] These may be OK, however could these be better handled with the pass= word authentication TLVs? >> Certificate errors >>=20 >> - User certificate not supplied >> - User certificate rejected >>=20 >> - User certificate validation failure >>=20 >> - User certificate expired >> - User certificate revoked >>=20 >> - User certificate algorithm mismatch >>=20 >> - Temporary problem validating user certificate >=20 > All of these refer to specific, existing EAP types which don't usually > provide signalling for these error conditions to their EAP peer. We're > sort of lost with these IMHO. Except for the certificate errors; there > EAP-TLS can signal some of those error conditions with TLS alerts. But > this is again not TEAP's "business". >=20 [Joe] I tend to agree >> Channel binding errors >>=20 >> - Channel binding data required but not supplied >> - Channel binding data did not include required information >> - Channel binding failed >=20 > People who know more about channel binding would have to take a look at > these. Can the inner method detect that its channel binding with outer > failed? Or can that only be done by the outer method? In that case, it's > indeed TEAPs business to generate appropriate errors inside phase 2, but > outside the EAP conversation that is going on inside Phase 2. >=20 > Section 3.8.4 should then specify these error conditions. >=20 [Joe] Aren't these already covered by the messaging from RFC 6677? =20 >> Successful outcomes >>=20 >> - User account expires soon >> - User account credential expires soon >> - User account authorisations change soon >> - Clock skew detected >>=20 >> - Contact administrator for unspecified reason >=20 > Again something we can do for password auth, but not if inner EAP is used= . >=20 [Joe] wouldn't these be better handled using the Password authentication TL= Vs?=20 > Greetings, >=20 > Stefan Winter >=20 > --=20 > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Thu Aug 15 11:02:50 2013 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 7AFA311E80AD; Thu, 15 Aug 2013 11:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOhWGOrfTm80; Thu, 15 Aug 2013 11:02:44 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9E31711E8203; Thu, 15 Aug 2013 11:02:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id D8A942029F; Thu, 15 Aug 2013 14:01:28 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVQ3L0fg9vPV; Thu, 15 Aug 2013 14:01:28 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 15 Aug 2013 14:01:28 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AE5EC8052F; Thu, 15 Aug 2013 14:02:40 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> <520CE74B.6010408@cs.tcd.ie> Date: Thu, 15 Aug 2013 14:02:40 -0400 In-Reply-To: <520CE74B.6010408@cs.tcd.ie> (Stephen Farrell's message of "Thu, 15 Aug 2013 15:35:55 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sun, 18 Aug 2013 19:44:35 -0700 Cc: draft-ietf-emu-eap-tunnel-method@tools.ietf.org, Sam Hartman , The IESG , emu-chairs@tools.ietf.org, emu@ietf.org Subject: Re: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) 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, 15 Aug 2013 18:02:50 -0000 >>>>> "Stephen" == Stephen Farrell writes: Stephen> whether the spec needs to say that some such mechanism is Stephen> required to be used or not. It's very rare we have required-to-use security; typically we settle for MTI. I mean it's good operational advice to require the channel be secure. I'm not sure I'd use encryption within a single box or between VMs on the same hypervisor...but I support a strong operational recommendation and a requirement that TEAP server implementations supporting this separation support confidentiality and integrity for the channel to the inner EAP. From stefan.winter@restena.lu Mon Aug 19 03:54:35 2013 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 EB8FA11E80D3; Mon, 19 Aug 2013 03:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9puEefTk0Pd; Mon, 19 Aug 2013 03:54:35 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 61ADA21F9A70; Mon, 19 Aug 2013 03:54:35 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D0AD410583; Mon, 19 Aug 2013 12:54:33 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id C2BFA1057F; Mon, 19 Aug 2013 12:54:33 +0200 (CEST) Message-ID: <5211F965.3030809@restena.lu> Date: Mon, 19 Aug 2013 12:54:29 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sam Hartman References: <5203718A.6050702@restena.lu> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7PqC6lFKIAMVm6ambJ0uP4BBTmHf3hgaJ" X-Virus-Scanned: ClamAV Cc: emu@ietf.org, iesg@ietf.org Subject: Re: [Emu] Some proposed error conditions for draft-ietf-emu-eap-tunnel-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: Mon, 19 Aug 2013 10:54:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7PqC6lFKIAMVm6ambJ0uP4BBTmHf3hgaJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Stefan> This limits the scope of the error conditions to cases wher= e > Stefan> TEAP has "all in its own hands" - which I believe is limite= d > Stefan> to the "Optional Password Authentication" of chapter 3.3.2.= >=20 > DIsagreed. > AAA servers don't signal all of these up, but AAA servers often signal = a > number of these. > For example in Freeradius I could actually figure out a number of these= > even across an inner tunnel and could easily expand the server to do > better than that. > However if you have nothing else then you are left with inner method > error. Yes, it occured to me afer sending that my mind model was maybe a bit too strict: there is no /protocol/ way for things to transpire from inner to outer; but there may be be other means (like shared memory in the server process) *if* inner and outer terminate at the same server. If the inner method is proxied elsewhere, then we're out of luck in terms of getting specific error conditions from the inner method; "proper" protocol-based signaling would then be required but doesn't exis= t. I guess it comes down to wordsmithing to express this correctly; like "will work for TEAP's simple password auth, and *may* work for inner EAP, if inner and outer termination point are co-located, or otherwise have an unspecified out-of-band protocol of their own for signalling error conditions between inner and outer termination point." Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --7PqC6lFKIAMVm6ambJ0uP4BBTmHf3hgaJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIR+WkACgkQ+jm90f8eFWaY7ACgidLdFXnmZcvpJEaooTMXWioo DvIAnib7AD5tiqF/kQ3XwI0BryHUFbRl =Glsh -----END PGP SIGNATURE----- --7PqC6lFKIAMVm6ambJ0uP4BBTmHf3hgaJ-- From ietf-secretariat-reply@ietf.org Mon Aug 19 09:26:22 2013 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 74F0F11E82A6 for ; Mon, 19 Aug 2013 09:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 CevDySrTxHlW; Mon, 19 Aug 2013 09:26:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BB221F9C32; Mon, 19 Aug 2013 09:25:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-crypto-bind@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819162558.16431.87982.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 09:25:58 -0700 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:26:22 -0000 IESG has approved the document and state has been changed to Approved-annou= ncement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ From iesg-secretary@ietf.org Mon Aug 19 09:26:24 2013 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 0F28911E82A6; Mon, 19 Aug 2013 09:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.463 X-Spam-Level: X-Spam-Status: No, score=-102.463 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 BUr2-njTXRt6; Mon, 19 Aug 2013 09:26:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4BA21F9C5A; Mon, 19 Aug 2013 09:25:58 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819162558.16431.49047.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 09:25:58 -0700 Cc: emu mailing list , emu chair , RFC Editor Subject: [Emu] Document Action: 'EAP Mutual Cryptographic Binding' to Informational RFC (draft-ietf-emu-crypto-bind-04.txt) X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 16:26:24 -0000 The IESG has approved the following document: - 'EAP Mutual Cryptographic Binding' (draft-ietf-emu-crypto-bind-04.txt) as Informational RFC This document is the product of the EAP Method Update Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ Technical Summary EAP tunneled methods require that EAP peers rely on information from the EAP server. Various security related information is carried inside of the tunnel, and are used by the peers. Methods exist to protect the peers against MITM attacks. The document discusses attacks on the tunneled data, and recommends mutual cryptographic binding to protect both parties. Working Group Summary The docuemnt records the consensus of the WG as developed over the last year. Any controversy about the contents has been resolved by updates to the document, and WG consensus was not rough. Document Quality The document provides a clear description of the attacks and recommended solutions. There are no protocol changes in the document, so no implementations are required. Personnel Alan DeKok is the doc shepherd. Sean Turner is the responsible AD. RFC Editor Note Please make the following modifications in section 3.2.3: OLD: First, the server and peer prove to each other knowledge of the inner MSK. Then, the inner MSK is combined into some outer key material to form the tunnel's keys. NEW: First, the server and peer prove to each other knowledge of the inner MSK. Then, the inner MSK is combined with some outer key material to form the tunnel's EAP keys. From ietf-secretariat-reply@ietf.org Mon Aug 19 10:41:39 2013 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 52D2611E82C2 for ; Mon, 19 Aug 2013 10:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.455 X-Spam-Level: X-Spam-Status: No, score=-101.455 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, 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 K1f-mOBeI43a; Mon, 19 Aug 2013 10:41:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C20EB11E82BD; Mon, 19 Aug 2013 10:41:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-crypto-bind@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819174138.7540.5232.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 10:41:38 -0700 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 17:41:39 -0000 State changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ From ietf-secretariat-reply@ietf.org Mon Aug 19 12:47:58 2013 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 6471511E82DC for ; Mon, 19 Aug 2013 12:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.452 X-Spam-Level: X-Spam-Status: No, score=-101.452 tagged_above=-999 required=5 tests=[AWL=-1.071, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, 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 Lc2KXv2dHHOl; Mon, 19 Aug 2013 12:47:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D56F011E82BA; Mon, 19 Aug 2013 12:47:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-crypto-bind@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819194755.615.44242.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 12:47:55 -0700 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 19:47:58 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ From ietf-secretariat-reply@ietf.org Mon Aug 19 12:47:59 2013 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 3883711E82E4 for ; Mon, 19 Aug 2013 12:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.451 X-Spam-Level: X-Spam-Status: No, score=-101.451 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, 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 63Gn46AtN9yo; Mon, 19 Aug 2013 12:47:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1354E11E82C3; Mon, 19 Aug 2013 12:47:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-crypto-bind@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819194755.637.23188.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 12:47:55 -0700 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 19:47:59 -0000 IANA action state changed to In Progress ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ From ietf-secretariat-reply@ietf.org Mon Aug 19 12:48:08 2013 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 E5C2211E82DA for ; Mon, 19 Aug 2013 12:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.451 X-Spam-Level: X-Spam-Status: No, score=-101.451 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, 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 Dr3kBdObrroh; Mon, 19 Aug 2013 12:48:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E99111E82C4; Mon, 19 Aug 2013 12:47:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-crypto-bind@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819194759.615.98216.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 12:47:59 -0700 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 19:48:08 -0000 IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ From ietf-secretariat-reply@ietf.org Mon Aug 19 12:48:08 2013 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 9D2C311E82DA for ; Mon, 19 Aug 2013 12:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.45 X-Spam-Level: X-Spam-Status: No, score=-101.45 tagged_above=-999 required=5 tests=[AWL=-1.069, BAYES_00=-2.599, NO_RELAYS=-0.001, TVD_SPACE_RATIO=2.219, 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 Rhubucr+TKIx; Mon, 19 Aug 2013 12:48:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F58011E82DC; Mon, 19 Aug 2013 12:47:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: emu-chairs@tools.ietf.org, draft-ietf-emu-crypto-bind@tools.ietf.org, emu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130819194759.637.98362.idtracker@ietfa.amsl.com> Date: Mon, 19 Aug 2013 12:47:59 -0700 From: IETF Secretariat Subject: [Emu] ID Tracker State Update Notice: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Aug 2013 19:48:08 -0000 IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-emu-crypto-bind/ From Martin.Stiemerling@neclab.eu Tue Aug 20 08:48:52 2013 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 838D411E8202; Tue, 20 Aug 2013 08:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.561 X-Spam-Level: X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 jEpU9ANviaQD; Tue, 20 Aug 2013 08:48:46 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5E811E8232; Tue, 20 Aug 2013 08:48:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 449EE1054C1; Tue, 20 Aug 2013 17:47:49 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWV9We89XIgt; Tue, 20 Aug 2013 17:47:49 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 239A3105308; Tue, 20 Aug 2013 17:47:24 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Aug 2013 17:47:59 +0200 Message-ID: <52138FAE.3040708@neclab.eu> Date: Tue, 20 Aug 2013 17:47:58 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <20130808192411.10939.54546.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Cc: "" , The IESG , "" , "" Subject: Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS) 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, 20 Aug 2013 15:48:53 -0000 Hi Joe, Sorry for the delayed response -- I have been away for my vacation. On 08/10/2013 01:20 AM, Joseph Salowey (jsalowey) wrote: > > On Aug 8, 2013, at 12:24 PM, Martin Stiemerling > wrote: > >> Martin Stiemerling has entered the following ballot position for >> draft-ietf-emu-eap-tunnel-method-07: Discuss >> ---------------------------------------------------------------------- >> >> DISCUSS: >> ---------------------------------------------------------------------- >> >> >> Two points about Section 3.7. "Fragmentation" >> - Both ends have to wait for either each fragment or fragment ack >> to arrive. However, the timers on how to long to wait before giving >> up waiting for fragments or acks are missing. >> > > [Joe] Retransmission and timeout behavior for EAP is discussed in the > EAP RFC 3748 Section 4.3. The cited section describes retransmission and the associated timeouts for complete messages, but **not** fragments! RFC 3748 says clearly in Section 1: "Fragmentation is not supported within EAP itself; however, individual EAP methods may support this." I assume TEAP is an EAP method that has to write-up how fragmentation is handled, isn't it? > >> - how does the sending TEAP entity determine what the maximum >> transmission unit (MTU) of the path is? >> >> > > [Joe] Typically EAP receives MTU information from the lower layer. > This is described in EAP RFC 3748 section 3.1. Ok, I am fine to clear this position if you add a pointer to RFC 3748, Section 3.1 -- as a reminder for the implementers where to look for guidance. Martin > >> >> > -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From Martin.Stiemerling@neclab.eu Tue Aug 20 08:49:55 2013 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 2BE2411E8202; Tue, 20 Aug 2013 08:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 HTtQ87RkGgKA; Tue, 20 Aug 2013 08:49:50 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D20DA11E8109; Tue, 20 Aug 2013 08:49:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BA95A1054B4; Tue, 20 Aug 2013 17:48:52 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lY6AxoHVm20N; Tue, 20 Aug 2013 17:48:52 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 9CEFF105308; Tue, 20 Aug 2013 17:48:22 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 20 Aug 2013 17:49:19 +0200 Message-ID: <52138FFE.8070307@neclab.eu> Date: Tue, 20 Aug 2013 17:49:18 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Sam Hartman References: <20130808192411.10939.54546.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Cc: "" , "" , "" , The IESG Subject: Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS) 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, 20 Aug 2013 15:49:55 -0000 Hi Sam, On 08/14/2013 10:16 PM, Sam Hartman wrote: >>>>>> "Joseph" == Joseph Salowey (jsalowey) writes: > > Joseph> [Joe] Retransmission and timeout behavior for EAP is > Joseph> discussed in the EAP RFC 3748 Section 4.3. > > Echoing Joe's point, we over in abfab (draft-ietf-abfab-gss-eap) would > be really unhappy if EAP method specs started discussing timeouts. It is not about the EAP timeouts for whole messages, but timeouts for fragments are not defined in RFC 3748 and must be defined somewhere, as well as, what happens if timeouts are exceeded for fragments. Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From hartmans@mit.edu Sat Aug 24 11:42:35 2013 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 98FF911E8169; Sat, 24 Aug 2013 11:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 J0z2p8mfRL9Y; Sat, 24 Aug 2013 11:42:29 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id AB90011E8139; Sat, 24 Aug 2013 11:42:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0A97A202D9; Sat, 24 Aug 2013 14:37:54 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Epr5aMowjWAq; Sat, 24 Aug 2013 14:37:53 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Sat, 24 Aug 2013 14:37:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CD19481233; Sat, 24 Aug 2013 09:31:51 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <5203718A.6050702@restena.lu> <5211F965.3030809@restena.lu> Date: Sat, 24 Aug 2013 09:31:51 -0400 In-Reply-To: <5211F965.3030809@restena.lu> (Stefan Winter's message of "Mon, 19 Aug 2013 12:54:29 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , emu@ietf.org, iesg@ietf.org Subject: Re: [Emu] Some proposed error conditions for draft-ietf-emu-eap-tunnel-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: Sat, 24 Aug 2013 18:42:35 -0000 >>>>> "Stefan" == Stefan Winter writes: I think this is too detailed. The error codes MAY be used. Full stop. Whether you can is a complex policy and implementation discussion best hidden behind a MAY. From hartmans@mit.edu Sat Aug 24 11:42:35 2013 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 A9FC011E8139; Sat, 24 Aug 2013 11:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 E5xQP5n3qodo; Sat, 24 Aug 2013 11:42:29 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id BC05711E8165; Sat, 24 Aug 2013 11:42:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 30035202E8; Sat, 24 Aug 2013 14:37:54 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvfConsMBvfO; Sat, 24 Aug 2013 14:37:53 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Sat, 24 Aug 2013 14:37:53 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7216188297; Sat, 24 Aug 2013 09:41:00 -0400 (EDT) From: Sam Hartman To: Martin Stiemerling References: <20130808192411.10939.54546.idtracker@ietfa.amsl.com> <52138FFE.8070307@neclab.eu> Date: Sat, 24 Aug 2013 09:41:00 -0400 In-Reply-To: <52138FFE.8070307@neclab.eu> (Martin Stiemerling's message of "Tue, 20 Aug 2013 17:49:18 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "" , Sam Hartman , "" , "" , The IESG Subject: Re: [Emu] Martin Stiemerling's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS) 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, 24 Aug 2013 18:42:35 -0000 >>>>> "Martin" == Martin Stiemerling writes: Martin> Hi Sam, Martin> On 08/14/2013 10:16 PM, Sam Hartman wrote: >>>>>>> "Joseph" == Joseph Salowey (jsalowey) >>>>>>> writes: >> Joseph> [Joe] Retransmission and timeout behavior for EAP is Joseph> discussed in the EAP RFC 3748 Section 4.3. >> >> Echoing Joe's point, we over in abfab (draft-ietf-abfab-gss-eap) >> would be really unhappy if EAP method specs started discussing >> timeouts. Martin> It is not about the EAP timeouts for whole messages, but Martin> timeouts for fragments are not defined in RFC 3748 and must Martin> be defined somewhere, as well as, what happens if timeouts Martin> are exceeded for fragments. If an inner method supports fragmentation, then each fragment is a "whole EAP message," in your terminology quoting RFC 3748. More particularly, the interface between EAP and a lower layer says that EAP methods hand EAP a message. The EAP state machine gets a timeout from the lower layer as defined in RFC 3748. The EAP state machine uses the retransmit behavior in RFC 3748. It's possible that a method has internally fragmented some larger (we'll call these fragmentables for the moment) messages into the EAP messages handed to EAP by the method. If so, then EAP has no way to know whether these are fragments or whether the method simply doesn't support fragmentation. At the EAP layer, messages are messages. The difference between messages and fragmentables is only visible within a method. The abstract interface of EAP does not permit methods to influence the retransmission behavior, nor for messages generated from fragmentation to have different retransmission behavior than anything else. I understand that the EAP state machine RFC is informational, but take a look there; it's quite obvious the sorts of things that will break if you try and have retransmission behavior discussed in method specs. If there's something wrong with RFC 3748, fix in an update to that spec and in updates to the state machines. However, other than being quite inefficient, I think the retransmission behavior of EAP is fine. From stefan.winter@restena.lu Mon Aug 26 00:44:38 2013 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 A27BD11E8174 for ; Mon, 26 Aug 2013 00:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-IxeHvXby5f for ; Mon, 26 Aug 2013 00:44:36 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB3D11E8170 for ; Mon, 26 Aug 2013 00:44:35 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 03A921057F; Mon, 26 Aug 2013 09:44:34 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id C8A461057D; Mon, 26 Aug 2013 09:44:33 +0200 (CEST) Message-ID: <521B075D.2020006@restena.lu> Date: Mon, 26 Aug 2013 09:44:29 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <5203718A.6050702@restena.lu> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mL9nqucIptF15ICq0vt4GIovFOcRmiROR" X-Virus-Scanned: ClamAV Cc: "" Subject: Re: [Emu] Some proposed error conditions for TEAP X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2013 07:44:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mL9nqucIptF15ICq0vt4GIovFOcRmiROR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> The question IMHO is: there are many inner EAP methods specified >> already, and they don't typically specify or signal most of the error >> conditions below to the EAP peer. The TEAP document can't impose chang= e >> on all those inner methods; they are what they are. If they tell neith= er >> the EAP peer nor export that information to the TEAP layer, then there= >> is nothing we can write in the TEAP document that will make it happen.= >> >> This limits the scope of the error conditions to cases where TEAP has >> "all in its own hands" - which I believe is limited to the "Optional >> Password Authentication" of chapter 3.3.2. >> >=20 > [Joe] I tend to agree that we shouldn't try to address errors that are = specific to inner methods. We should stick to things that are TEAP speci= fic.=20 Sam's point is also valid though; even if we don't care protocol-wise about what inner EAP methods are doing, an implementation might be lucky and learn about inner method failures via unspecified means. It could then communicate those failures on the TEAP layer; if only our dictionary is flexible enough to be useful for these cases. >>> In addition to these, might there also be some value in an >>> "Information-URL" TLV? The value could point to a web resource that >>> provides further information for TEAP connections that are successful= but >>> where, for example, user notification or action is desirable (e.g., >>> password change). >> >> I like that one. >> >=20 > [Joe] So I would prefer to address this in a separate document. I can = see some issues here. How does one access the URL if they fail to get ne= twork access? I imagine there are some security considerations around co= nnecting to some URL specified by the server. I suppose it would be OK i= f the client can authenticate and trust the server.=20 The suggestion was to send this URL only after a *success*. Then the URL comes from a trusted source, and it can reasonably be expected that the user will have network access. If he still doesn't have network access, it's not TEAP's problem IMHO whether the user can click on the URL and get content. TEAP is just the messenger; the client device needs to take care about acting on the messa= ge. >>> General errors >>> >>> - Unspecified server problem >>> - Unspecified authentication failure >>> - Unspecified authorisation failure >>> - User account credentials unavailable >>> - User account expired >>> - User account locked: try again later >>> - User account locked: admin intervention required >>> - Authentication server unavailable >> >> I'm not sure about terminology here... "authentication server" often >> refers to RADIUS servers, EAP servers, or maybe the authentication >> backend that the EAP server consults to do its work. >> >> Since we are talking about inner method failures, and we came to a sta= ge >> where RADIUS is obviously working, because it demonstrated that it can= >> transport messages to the EAP server; and where the EAP server is >> obviously working, because it did the entire phase 1 exchange, the err= or >> conditions above must refer to the "authentication backend" or "identi= ty >> management backend" (since that backend contains not just authenticati= on >> details for connecting entities, but also authorisation information). = I >> like that term more than a "server" (the backend could be a flat file = in >> simple deployments). >> >> This would mean changing the first and last one to: >> >> - Unspecified ID Management Backend problem >> - ID Management Backend unavailable >> >=20 > [Joe] I think these or some subset of these are OK.=20 >=20 >>> - Authentication server not trusted >> >> In phase 2 with Password Authentication, the server identity is not >> verified (again). And for Phase 2 being another EAP method, this >> untrustedness (as in X.509 verify failure?) would be signalled with a >> TLS fatal alert in the inner method TLS setup phase. >> >=20 > [Joe] agree with Stefan >=20 >>> - Clock skew too great >> >> Same; clock is irrelevant for password auth. If inner is EAP, the meth= od >> running either already has a way to signal this to the EAP peer or not= ; >> nothing TEAP can do about this. >> >=20 > [Joe] Agree with Stefan >=20 >>> - Invalid inner realm >> >> That's good. >> >> Where outer and inner EAP terminate at the same server, it may also be= >> possible to check if there was a mismatch between inner and outer real= m; >> which may be administratively prohibited. This would add: >> >> - Realm mismatch between inner and outer identity >> >=20 >=20 > [Joe] I think these are good=20 >=20 >>> Password errors >>> >>> - User account unknown >>> >>> - User account password expired >>> >>> - User account password incorrect >>> >>> - User account password change required >> >> All fine (as in: works for TEAP's password auth - and some inner EAP >> methods even signal this, e.g. MSCHAPv2; others may not and there is >> nothing TEAP can do if not). >=20 > [Joe] I'm not in favor of adding these. In general they go against sec= urity guidelines about providing too much information on failed authentic= ation.=20 That would be too prescriptive in the spec IMHO. If there are hesitations regarding information leakage, a deployment could configure that these messages are withheld by the server. Other deployments might want to take the risk and send the information for more user convenience.= IMHO, we should define these, but (as all the others actually) make their *usage* optional. >>> Challenge-Response errors >>> >>> - Challenge expired >>> - Challenge algorithm mismatch >>> >=20 > [Joe] I don't think we should deal with these kinds of errors as they = don't involve TEAP. =20 >=20 >>> >>> One time password errors >>> >>> - Token out of sync: administrator intervention required >>> - Token out of sync: PIN change required >>> - Token revoked >>> - Tokens exhausted >>> >=20 > [Joe] These may be OK, however could these be better handled with the = password authentication TLVs? >=20 >>> Certificate errors >>> >>> - User certificate not supplied >>> - User certificate rejected >>> >>> - User certificate validation failure >>> >>> - User certificate expired >>> - User certificate revoked >>> >>> - User certificate algorithm mismatch >>> >>> - Temporary problem validating user certificate >> >> All of these refer to specific, existing EAP types which don't usually= >> provide signalling for these error conditions to their EAP peer. We're= >> sort of lost with these IMHO. Except for the certificate errors; there= >> EAP-TLS can signal some of those error conditions with TLS alerts. But= >> this is again not TEAP's "business". >> >=20 > [Joe] I tend to agree >=20 >>> Channel binding errors >>> >>> - Channel binding data required but not supplied >>> - Channel binding data did not include required information >>> - Channel binding failed >> >> People who know more about channel binding would have to take a look a= t >> these. Can the inner method detect that its channel binding with outer= >> failed? Or can that only be done by the outer method? In that case, it= 's >> indeed TEAPs business to generate appropriate errors inside phase 2, b= ut >> outside the EAP conversation that is going on inside Phase 2. >> >> Section 3.8.4 should then specify these error conditions. >> >=20 > [Joe] Aren't these already covered by the messaging from RFC 6677? =20 Probably. Others here besides me are certainly better informed regarding CBs, but: 5.3.1 has success and failure. The fact that it was requested but not supplied is information which is local to the EAP peer; it knows that it requested it, and knows that it didn't get it -> no protocol signalling involved here. >>> Successful outcomes >>> >>> - User account expires soon >>> - User account credential expires soon >>> - User account authorisations change soon >>> - Clock skew detected >>> >>> - Contact administrator for unspecified reason >> >> Again something we can do for password auth, but not if inner EAP is u= sed. >> >=20 > [Joe] wouldn't these be better handled using the Password authenticatio= n TLVs?=20 Well, if we are going to specify lots of extended responses as above, then these messages here would fit into them equally well. Also, Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV don't seem to have signalling of their own for these things? Greetings, Stefan Winter >=20 >> Greetings, >> >> Stefan Winter >> >> --=20 >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et >> de la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >> >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 --mL9nqucIptF15ICq0vt4GIovFOcRmiROR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIbB2EACgkQ+jm90f8eFWbZSwCeJ4WXUhB6T6cIO+iOOulaHyAP zUMAnAs2atpacSilUT2ruBU77HKMqo8t =Wof6 -----END PGP SIGNATURE----- --mL9nqucIptF15ICq0vt4GIovFOcRmiROR--