From Josh.Howlett@ja.net Mon Sep 2 03:39:46 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 B604911E828A for ; Mon, 2 Sep 2013 03:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6HHO2-4T4c5 for ; Mon, 2 Sep 2013 03:39:39 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 472F211E81D9 for ; Mon, 2 Sep 2013 03:39:38 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 45B681AF3F39_2246AE9B; Mon, 2 Sep 2013 10:39:37 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id 93EAA1AF3F15_2246AE8F; Mon, 2 Sep 2013 10:39:36 +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; Mon, 2 Sep 2013 11:39:35 +0100 From: Josh Howlett To: Stefan Winter , "Joseph Salowey (jsalowey)" Thread-Topic: [Emu] Some proposed error conditions for TEAP Thread-Index: AQHOkDejY4UXy9LBjEiw2wL8xzrc7JmLEVgAgAvBXwCAEFxGgIALQfcA Date: Mon, 2 Sep 2013 10:39:35 +0000 Message-ID: In-Reply-To: <521B075D.2020006@restena.lu> 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 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, 02 Sep 2013 10:39:46 -0000 Apologies for the delayed response. >>>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. >>> >>=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 >>specific.=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. Agreed. My view is that we should make the dictionary as expressive as reasonably possible, while taking care not to impose unnecessary complexity on EAP server implementations (for whatever reason) where these might be unattractive to implement. For these new error conditions, I think it would be sufficient to define the dictionary, and allow implementors to decide what to implement. From the supplicant's perspective, any information is better than none. >>>> 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 >>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 client can authenticate and trust the server. > >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 >message. Agreed. (It is worth noting that PPPoE provides similar functionality using the PADM tag. I am not sure how much use this actually gets, but it does seem to be implemented in various products. In this case the PADM is provided by the other PPP peer, not the EAP server). >>>> 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 >>>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 >>> >>=20 >> [Joe] I think these or some subset of these are OK. I agree that "authentication server" is confusing. Functionally what I had in mind was the entity that is ultimately authoritative for the user's credentials. Your proposal nearly works for me, but I think I would prefer something a bit more specific if possible. >>=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 Ok, there is a misunderstanding here. What I mean is the EAP server not trusting the ID Management System. That might seem a bit odd, but imagine an EAP server trying to authenticate Kerberos against a remote KDC for example. >>=20 >>>> - 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. >>> >>=20 >> [Joe] Agree with Stefan Again this was meant to signal a clock skew between the EAP server and the ID Management System. >>=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 >>>realm; >>> which may be administratively prohibited. This would add: >>> >>> - Realm mismatch between inner and outer identity >>> >>=20 >>=20 >> [Joe] I think these are good >>=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 >>security guidelines about providing too much information on failed >>authentication.=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. Agreed. >>>> 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 >>>> >>>> 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 Stefan, I would apply the same reasoning that you give in your first response in this message. I.e., it is precisely because EAP doesn't provide the signalling, even though the EAP server is fully aware of the error condition, that we can substitute with TEAP-based signalling. >>=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 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. >>> >>=20 >> [Joe] Aren't these already covered by the messaging from RFC 6677? > >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. Aren't these orthogonal issues? RFC 6677 signalling only refers to the CB binding used by the inner method, and not between the TEAP's tunnel and inner method. >>>> 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 >>>used. >>> >>=20 >> [Joe] wouldn't these be better handled using the Password >>authentication TLVs? > >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? Sorry, I don't follow this. Could you elaborate please? Josh. 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 stefan.winter@restena.lu Mon Sep 2 06:54:37 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 B9E7221F9EE5 for ; Mon, 2 Sep 2013 06:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 tGdYgfU4ne+f for ; Mon, 2 Sep 2013 06:54:32 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 261A321F96EF for ; Mon, 2 Sep 2013 06:54:29 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 89C681057F; Mon, 2 Sep 2013 15:54:26 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 78B851057D; Mon, 2 Sep 2013 15:54:26 +0200 (CEST) Message-ID: <5224988F.3050905@restena.lu> Date: Mon, 02 Sep 2013 15:54:23 +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: Josh Howlett References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L4I4FNNDkXw0elvW3nR9lsVXQjHGVIA0m" 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, 02 Sep 2013 13:54:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L4I4FNNDkXw0elvW3nR9lsVXQjHGVIA0m Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Ok, there is a misunderstanding here. What I mean is the EAP server not= > trusting the ID Management System. That might seem a bit odd, but imagi= ne > an EAP server trying to authenticate Kerberos against a remote KDC for > example. That's indeed a different meaning from what I thought it would be. In that case, the error message makes a lot more sense. > Again this was meant to signal a clock skew between the EAP server and = the > ID Management System. Okay. > Stefan, I would apply the same reasoning that you give in your first > response in this message. I.e., it is precisely because EAP doesn't > provide the signalling, even though the EAP server is fully aware of th= e > error condition, that we can substitute with TEAP-based signalling. =2E.. in the cases where luck has it that we know on the TEAP layer what happened elsewhere. Fine for me :-) >> Probably. Others here besides me are certainly better informed regardi= ng >> CBs, but: 5.3.1 has success and failure. The fact that it was requeste= d >> but not supplied is information which is local to the EAP peer; it kno= ws >> that it requested it, and knows that it didn't get it -> no protocol >> signalling involved here. >=20 > Aren't these orthogonal issues? RFC 6677 signalling only refers to the = CB > binding used by the inner method, and not between the TEAP's tunnel and= > inner method. I'll let the CB gurus pick up that one. :-) >>> [Joe] wouldn't these be better handled using the Password >>> authentication TLVs? >> >> 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? >=20 > Sorry, I don't follow this. Could you elaborate please? Joe wants the error messages to be stuffed into the password authentication TLVs. These are: Basic-Password-Auth-Req TLV Basic-Password-Auth-Resp TLV I'm claiming that this can't work, because the server may discover that its backend is inaccessible only after it has sent its Req. Remember that Req is sent from the *server* to the *peer* as in: Server: Req: "User, what's your username and password?" Server: Resp: "johndoe/stupidpassword" Server: ... looking up that combo ... Oh! My backend is gone! Since both Req and Resp have already played their part, none of these two TLVs can carry an error message at this point. The generic Error TLV that we're discussing in this thread is the only place to put such error messages in. Greetings, Stefan Winter >=20 > Josh. >=20 >=20 >=20 > 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 >=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 --L4I4FNNDkXw0elvW3nR9lsVXQjHGVIA0m 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/ iEUEARECAAYFAlIkmJMACgkQ+jm90f8eFWabLACdEM2pF/KLnzbMoHUsfNAL9YW2 SxgAl35uQdzBSDBudf47Xa+SsJgQWLw= =jDUD -----END PGP SIGNATURE----- --L4I4FNNDkXw0elvW3nR9lsVXQjHGVIA0m-- From jsalowey@cisco.com Sun Sep 8 20:05:43 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 B14B111E8162 for ; Sun, 8 Sep 2013 20:05:43 -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 HvingZ1iklVC for ; Sun, 8 Sep 2013 20:05:38 -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 EEF1411E816E for ; Sun, 8 Sep 2013 20:05:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4740; q=dns/txt; s=iport; t=1378695935; x=1379905535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+mRamKtfirholSep16EXoDSlSX5TZr3O2nf7M/qINbM=; b=IgjkI7Q0cG4BzCBADxrZcn7IGpittCK5AXTCfJS6z/PAMoK0L57pbSZG 7N0n3BV4VjWobZ/s1NPrtUL0amPFbcpp7o7US4x921tEOHxZaHW9PnJcR U1bigaSxvoBs+Vl7HTY0gQkUsDBKGYYE3hChUpyiwJtbvJUXSD64ps/Si A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFALw6LVKtJV2Z/2dsb2JhbABRAQiDB4EJwhOBJRZ0giUBAQEDAQwbUgULAgEIIgsDFjIlAgQOAwIIDodmBsVJjj4DAoEKAjEHCg6DBYEAA4h9oF6DIECBKCIg X-IronPort-AV: E=Sophos;i="4.90,866,1371081600"; d="scan'208";a="257099477" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 09 Sep 2013 03:05:24 +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 r8935Oq5013130 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 03:05:24 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.162]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Sun, 8 Sep 2013 22:05:23 -0500 From: "Joseph Salowey (jsalowey)" To: Stefan Winter Thread-Topic: [Emu] Some proposed error conditions for TEAP Thread-Index: AQHOkDejY4UXy9LBjEiw2wL8xzrc7JmLde0AgAvBXwCAEFxGgIALMT6AgAA2boCACkr9gA== Date: Mon, 9 Sep 2013 03:05:23 +0000 Message-ID: References: <5224988F.3050905@restena.lu> In-Reply-To: <5224988F.3050905@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: <0DDAFF958283844AAFD6B4DCA00CC803@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: Mon, 09 Sep 2013 03:05:43 -0000 Here is my proposed revisions for this thread - Add the following successful outcomes (informative messages) 1 - User account expires soon 2 - User account credential expires soon 3 - User account authorisations change soon 4 - Clock skew detected 5 - Contact administrator for unspecified reason=09 Add the following warnings: 1002 - Unspecified authentication infrastructure problem 1003 - Unspecified authentication failure 1004 - Unspecified authorisation failure 1005 - User account credentials unavailable 1006 - User account expired 1007 - User account locked: try again later 1008 - User account locked: admin intervention required 1009 - Authentication infrastructure unavailable 1010 - Authentication infrastructure not trusted 1011 - Clock skew too great 1012 - Invalid inner realm 1013 - Token out of sync: administrator intervention required 1014 - Token out of sync: PIN change required 1015 - Token revoked 1016 - Tokens exhausted 1017 - Challenge expired 1018 - Challenge algorithm mismatch 1019 - Client certificate not supplied 1020 - Client certificate rejected 1021 - Realm mismatch between inner and outer identity Thanks, Joe On Sep 2, 2013, at 6:54 AM, Stefan Winter wrote: > Hi, >=20 >> Ok, there is a misunderstanding here. What I mean is the EAP server not >> trusting the ID Management System. That might seem a bit odd, but imagin= e >> an EAP server trying to authenticate Kerberos against a remote KDC for >> example. >=20 > That's indeed a different meaning from what I thought it would be. In > that case, the error message makes a lot more sense. >=20 >> Again this was meant to signal a clock skew between the EAP server and t= he >> ID Management System. >=20 > Okay. >=20 >> Stefan, I would apply the same reasoning that you give in your first >> response in this message. I.e., it is precisely because EAP doesn't >> provide the signalling, even though the EAP server is fully aware of the >> error condition, that we can substitute with TEAP-based signalling. >=20 > ... in the cases where luck has it that we know on the TEAP layer what > happened elsewhere. >=20 > Fine for me :-) >=20 >>> Probably. Others here besides me are certainly better informed regardin= g >>> 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 know= s >>> that it requested it, and knows that it didn't get it -> no protocol >>> signalling involved here. >>=20 >> Aren't these orthogonal issues? RFC 6677 signalling only refers to the C= B >> binding used by the inner method, and not between the TEAP's tunnel and >> inner method. >=20 > I'll let the CB gurus pick up that one. :-) >=20 >>>> [Joe] wouldn't these be better handled using the Password >>>> authentication 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. >>>=20 >>> Also, Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV don'= t >>> seem to have signalling of their own for these things? >>=20 >> Sorry, I don't follow this. Could you elaborate please? >=20 > Joe wants the error messages to be stuffed into the password > authentication TLVs. These are: >=20 > Basic-Password-Auth-Req TLV > Basic-Password-Auth-Resp TLV >=20 > I'm claiming that this can't work, because the server may discover that > its backend is inaccessible only after it has sent its Req. Remember > that Req is sent from the *server* to the *peer* as in: >=20 > Server: Req: "User, what's your username and password?" > Server: Resp: "johndoe/stupidpassword" > Server: ... looking up that combo ... Oh! My backend is gone! >=20 > Since both Req and Resp have already played their part, none of these > two TLVs can carry an error message at this point. The generic Error TLV > that we're discussing in this thread is the only place to put such error > messages in. >=20 > Greetings, >=20 > Stefan Winter >=20 >>=20 >> Josh. >>=20 >>=20 >>=20 >> 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 >>=20 >=20 >=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 From Josh.Howlett@ja.net Mon Sep 9 01:44:43 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 2B27F21F8CB4 for ; Mon, 9 Sep 2013 01:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.999 X-Spam-Level: X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=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 rOQv-zXRc8OV for ; Mon, 9 Sep 2013 01:44:30 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 7465921E80B6 for ; Mon, 9 Sep 2013 01:44:27 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id CE82620C716E_22D8A67B; Mon, 9 Sep 2013 08:44:23 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id 67EB820C70F3_22D8A67F; Mon, 9 Sep 2013 08:44:23 +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; Mon, 9 Sep 2013 09:44:22 +0100 From: Josh Howlett To: "Joseph Salowey (jsalowey)" , Stefan Winter Thread-Topic: [Emu] Some proposed error conditions for TEAP Thread-Index: AQHOkDejY4UXy9LBjEiw2wL8xzrc7JmLEVgAgAvBXwCAEFxGgIALQfcAgAAltICACkr+gIAAb3IA Date: Mon, 9 Sep 2013 08:44:22 +0000 Message-ID: In-Reply-To: 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="iso-8859-1" Content-ID: <97B0A5D18FD8CC4AA33CA9345C317B9C@ukerna.ac.uk> 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: Mon, 09 Sep 2013 08:44:43 -0000 Joe, Thanks for this. This looks good, but I am missing: - User account credentials incorrect - User account credentials change required And also (using "Inner method" to disambiguate inner method CB from TEAP's own CB): - Inner method's channel binding data required but not supplied - Inner method's channel binding data did not include required information - Inner method's channel binding failed Finally, what of the "Information-URL" TLV proposal? Thanks again, Josh. On 09/09/2013 04:05, "Joseph Salowey (jsalowey)" wrote: >Here is my proposed revisions for this thread - > >Add the following successful outcomes (informative messages) > >1 - User account expires soon >2 - User account credential expires soon >3 - User account authorisations change soon >4 - Clock skew detected >5 - Contact administrator for unspecified reason=09 > >Add the following warnings: > >1002 - Unspecified authentication infrastructure problem >1003 - Unspecified authentication failure >1004 - Unspecified authorisation failure >1005 - User account credentials unavailable >1006 - User account expired >1007 - User account locked: try again later >1008 - User account locked: admin intervention required >1009 - Authentication infrastructure unavailable >1010 - Authentication infrastructure not trusted >1011 - Clock skew too great >1012 - Invalid inner realm >1013 - Token out of sync: administrator intervention required >1014 - Token out of sync: PIN change required >1015 - Token revoked >1016 - Tokens exhausted >1017 - Challenge expired >1018 - Challenge algorithm mismatch >1019 - Client certificate not supplied >1020 - Client certificate rejected >1021 - Realm mismatch between inner and outer identity > >Thanks, > >Joe > > >On Sep 2, 2013, at 6:54 AM, Stefan Winter >wrote: > >> Hi, >>=20 >>> Ok, there is a misunderstanding here. What I mean is the EAP server not >>> trusting the ID Management System. That might seem a bit odd, but >>>imagine >>> an EAP server trying to authenticate Kerberos against a remote KDC for >>> example. >>=20 >> That's indeed a different meaning from what I thought it would be. In >> that case, the error message makes a lot more sense. >>=20 >>> Again this was meant to signal a clock skew between the EAP server and >>>the >>> ID Management System. >>=20 >> Okay. >>=20 >>> Stefan, I would apply the same reasoning that you give in your first >>> response in this message. I.e., it is precisely because EAP doesn't >>> provide the signalling, even though the EAP server is fully aware of >>>the >>> error condition, that we can substitute with TEAP-based signalling. >>=20 >> ... in the cases where luck has it that we know on the TEAP layer what >> happened elsewhere. >>=20 >> Fine for me :-) >>=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. >>>=20 >>> Aren't these orthogonal issues? RFC 6677 signalling only refers to the >>>CB >>> binding used by the inner method, and not between the TEAP's tunnel and >>> inner method. >>=20 >> I'll let the CB gurus pick up that one. :-) >>=20 >>>>> [Joe] wouldn't these be better handled using the Password >>>>> authentication 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. >>>>=20 >>>> Also, Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV >>>>don't >>>> seem to have signalling of their own for these things? >>>=20 >>> Sorry, I don't follow this. Could you elaborate please? >>=20 >> Joe wants the error messages to be stuffed into the password >> authentication TLVs. These are: >>=20 >> Basic-Password-Auth-Req TLV >> Basic-Password-Auth-Resp TLV >>=20 >> I'm claiming that this can't work, because the server may discover that >> its backend is inaccessible only after it has sent its Req. Remember >> that Req is sent from the *server* to the *peer* as in: >>=20 >> Server: Req: "User, what's your username and password?" >> Server: Resp: "johndoe/stupidpassword" >> Server: ... looking up that combo ... Oh! My backend is gone! >>=20 >> Since both Req and Resp have already played their part, none of these >> two TLVs can carry an error message at this point. The generic Error TLV >> that we're discussing in this thread is the only place to put such error >> messages in. >>=20 >> Greetings, >>=20 >> Stefan Winter >>=20 >>>=20 >>> Josh. >>>=20 >>>=20 >>>=20 >>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>> 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 >>>=20 >>=20 >>=20 >> --=20 >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationa= le et >> de la Recherche >> 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >>=20 >> Tel: +352 424409 1 >> Fax: +352 422473 >>=20 > 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 jsalowey@cisco.com Mon Sep 9 08:07: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 7C9CE21E808E for ; Mon, 9 Sep 2013 08:07:15 -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 6YX598yprJIk for ; Mon, 9 Sep 2013 08:07:02 -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 6550021F8447 for ; Mon, 9 Sep 2013 07:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6602; q=dns/txt; s=iport; t=1378738673; x=1379948273; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jUw/KWIYWAaoacj1zuV31fJTFjfiveDOVa7wjsZFE4s=; b=NqviCsu5AHPJhOogbE6HJ8FA/7xjEtuvOYPC1SGD52ZDvvMAoHGpfu36 AdJEa0u0QDB3QIV5fLwnnMFOVwXC/bTeFMEUEm/FXYkqFrsScFHhQss/X c4jrgyMRYXhp2Td6WNHVgo3WikyvXs1UNZJcpb00tn/n2Gu+j1S6dvVZS k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFPhLVKtJXHB/2dsb2JhbABSAQiDB4EJwhWBIhZ0giUBAQEDAQwbTQUFCwIBCBgKCwMWMiUCBA4DAggOh2YGw0eOPgMCgQoCBisHAggOgwWBAAOIfaBegyBAgSgiIA X-IronPort-AV: E=Sophos;i="4.90,866,1371081600"; d="scan'208";a="257353745" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 09 Sep 2013 14:57:53 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r89Evqbj004726 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Sep 2013 14:57:52 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.162]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 09:57:52 -0500 From: "Joseph Salowey (jsalowey)" To: Josh Howlett Thread-Topic: [Emu] Some proposed error conditions for TEAP Thread-Index: AQHOkDejY4UXy9LBjEiw2wL8xzrc7JmLde0AgAvBXwCAEFxGgIALMT6AgAA2boCACkr9gIAAXrYAgABoWQA= Date: Mon, 9 Sep 2013 14:57:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.164.62] Content-Type: text/plain; charset="iso-8859-1" Content-ID: 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: Mon, 09 Sep 2013 15:07:15 -0000 On Sep 9, 2013, at 1:44 AM, Josh Howlett wrote: > Joe, >=20 > Thanks for this. This looks good, but I am missing: >=20 > - User account credentials incorrect > - User account credentials change required [Joe] I am concerned that these error messages reveal too much information = to an attacker.=20 >=20 >=20 > And also (using "Inner method" to disambiguate inner method CB from TEAP'= s > own CB): >=20 > - Inner method's channel binding data required but not supplied > - Inner method's channel binding data did not include required informatio= n > - Inner method's channel binding failed >=20 [Joe] OK thanks, I think I understand your point better now. I'm OK wit= h adding this if there is no objection. =20 >=20 > Finally, what of the "Information-URL" TLV proposal? >=20 [Joe] This seemed to be more of a new feature that I don't feel comfortabl= e adding at this late stage. If there is enough support for it and someone= can provide the text then we can try to add it.=20 > Thanks again, Josh. >=20 > On 09/09/2013 04:05, "Joseph Salowey (jsalowey)" > wrote: >=20 >> Here is my proposed revisions for this thread - >>=20 >> Add the following successful outcomes (informative messages) >>=20 >> 1 - User account expires soon >> 2 - User account credential expires soon >> 3 - User account authorisations change soon >> 4 - Clock skew detected >> 5 - Contact administrator for unspecified reason=09 >>=20 >> Add the following warnings: >>=20 >> 1002 - Unspecified authentication infrastructure problem >> 1003 - Unspecified authentication failure >> 1004 - Unspecified authorisation failure >> 1005 - User account credentials unavailable >> 1006 - User account expired >> 1007 - User account locked: try again later >> 1008 - User account locked: admin intervention required >> 1009 - Authentication infrastructure unavailable >> 1010 - Authentication infrastructure not trusted >> 1011 - Clock skew too great >> 1012 - Invalid inner realm >> 1013 - Token out of sync: administrator intervention required >> 1014 - Token out of sync: PIN change required >> 1015 - Token revoked >> 1016 - Tokens exhausted >> 1017 - Challenge expired >> 1018 - Challenge algorithm mismatch >> 1019 - Client certificate not supplied >> 1020 - Client certificate rejected >> 1021 - Realm mismatch between inner and outer identity >>=20 >> Thanks, >>=20 >> Joe >>=20 >>=20 >> On Sep 2, 2013, at 6:54 AM, Stefan Winter >> wrote: >>=20 >>> Hi, >>>=20 >>>> Ok, there is a misunderstanding here. What I mean is the EAP server no= t >>>> trusting the ID Management System. That might seem a bit odd, but >>>> imagine >>>> an EAP server trying to authenticate Kerberos against a remote KDC for >>>> example. >>>=20 >>> That's indeed a different meaning from what I thought it would be. In >>> that case, the error message makes a lot more sense. >>>=20 >>>> Again this was meant to signal a clock skew between the EAP server and >>>> the >>>> ID Management System. >>>=20 >>> Okay. >>>=20 >>>> Stefan, I would apply the same reasoning that you give in your first >>>> response in this message. I.e., it is precisely because EAP doesn't >>>> provide the signalling, even though the EAP server is fully aware of >>>> the >>>> error condition, that we can substitute with TEAP-based signalling. >>>=20 >>> ... in the cases where luck has it that we know on the TEAP layer what >>> happened elsewhere. >>>=20 >>> Fine for me :-) >>>=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. >>>>=20 >>>> Aren't these orthogonal issues? RFC 6677 signalling only refers to the >>>> CB >>>> binding used by the inner method, and not between the TEAP's tunnel an= d >>>> inner method. >>>=20 >>> I'll let the CB gurus pick up that one. :-) >>>=20 >>>>>> [Joe] wouldn't these be better handled using the Password >>>>>> authentication 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. >>>>>=20 >>>>> Also, Basic-Password-Auth-Req TLV and Basic-Password-Auth-Resp TLV >>>>> don't >>>>> seem to have signalling of their own for these things? >>>>=20 >>>> Sorry, I don't follow this. Could you elaborate please? >>>=20 >>> Joe wants the error messages to be stuffed into the password >>> authentication TLVs. These are: >>>=20 >>> Basic-Password-Auth-Req TLV >>> Basic-Password-Auth-Resp TLV >>>=20 >>> I'm claiming that this can't work, because the server may discover that >>> its backend is inaccessible only after it has sent its Req. Remember >>> that Req is sent from the *server* to the *peer* as in: >>>=20 >>> Server: Req: "User, what's your username and password?" >>> Server: Resp: "johndoe/stupidpassword" >>> Server: ... looking up that combo ... Oh! My backend is gone! >>>=20 >>> Since both Req and Resp have already played their part, none of these >>> two TLVs can carry an error message at this point. The generic Error TL= V >>> that we're discussing in this thread is the only place to put such erro= r >>> messages in. >>>=20 >>> Greetings, >>>=20 >>> Stefan Winter >>>=20 >>>>=20 >>>> Josh. >>>>=20 >>>>=20 >>>>=20 >>>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>>> 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 >>>>=20 >>>=20 >>>=20 >>> --=20 >>> Stefan WINTER >>> Ingenieur de Recherche >>> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nation= ale et >>> de la Recherche >>> 6, rue Richard Coudenhove-Kalergi >>> L-1359 Luxembourg >>>=20 >>> Tel: +352 424409 1 >>> Fax: +352 422473 >>>=20 >>=20 >=20 >=20 > 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 >=20 From Josh.Howlett@ja.net Mon Sep 9 08:22: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 E828211E81FB for ; Mon, 9 Sep 2013 08:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.299 X-Spam-Level: X-Spam-Status: No, score=-101.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 zdC3nrr00gFw for ; Mon, 9 Sep 2013 08:22:44 -0700 (PDT) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6D15321F8F24 for ; Mon, 9 Sep 2013 08:10:53 -0700 (PDT) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id E5FB84A6BA2_22DE4FAB; Mon, 9 Sep 2013 15:10:50 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id AF8F44A6B9C_22DE4FAF; Mon, 9 Sep 2013 15:10:50 +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; Mon, 9 Sep 2013 16:10:50 +0100 From: Josh Howlett To: "Joseph Salowey (jsalowey)" Thread-Topic: [Emu] Some proposed error conditions for TEAP Thread-Index: AQHOkDejY4UXy9LBjEiw2wL8xzrc7JmLEVgAgAvBXwCAEFxGgIALQfcAgAAltICACkr+gIAAb3IAgABXnoCAABRbgA== Date: Mon, 9 Sep 2013 15:10:48 +0000 Message-ID: In-Reply-To: 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 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, 09 Sep 2013 15:22:59 -0000 >> >>- User account credentials incorrect >> - User account credentials change required > >[Joe] I am concerned that these error messages reveal too much >information to an attacker. I agree there are risks if used inappropriately, but nonetheless there are reasonable uses for these (for example, switching it on temporarily when debugging) as these are very common error conditions. I suggest that these be optional to implement and use, and that we have security considerations text that highlights the issue. Happy to propose some text. Josh. 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 jsalowey@cisco.com Tue Sep 10 09:44:54 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 2E56021E815E for ; Tue, 10 Sep 2013 09:44:54 -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 6YX7QmOhtTKH for ; Tue, 10 Sep 2013 09:44:48 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id DE29921E8172 for ; Tue, 10 Sep 2013 09:44:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1245; q=dns/txt; s=iport; t=1378831485; x=1380041085; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=devvx6qzU0gljpztTvXgqlLYBz50PnlbzsEa+nAsvMg=; b=bjh+Qsl6nWIvBVig3Dk4TAqU7lYKl4fZ/tiKrdMbsfP1Bn0QJVOT9RCb i/nl75sKJeBHb30wQgex293sRy5t9kL5LyHX5wm5zobGpI2hMRhJXARQb X0tjWLNKtPpdblPSCDwZSvtzu7hO1GO7MY4gl/vkCh3gbUo/4QKQf/1Wt Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAD5LL1KtJV2b/2dsb2JhbABbgweBCcJAgSUWdIIlAQEBAwE6PwULAgEIIgsJEDIlAgQOBQiHdAbAMY4cgQwCMQcCCIMTgQADqWGDIIFoJB4 X-IronPort-AV: E=Sophos;i="4.90,879,1371081600"; d="scan'208";a="258012238" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 10 Sep 2013 16:44: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 r8AGijRd004649 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 10 Sep 2013 16:44:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.162]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 11:44:45 -0500 From: "Joseph Salowey (jsalowey)" To: Josh Howlett Thread-Topic: [Emu] Some proposed error conditions for TEAP Thread-Index: AQHOkDejY4UXy9LBjEiw2wL8xzrc7JmLde0AgAvBXwCAEFxGgIALMT6AgAA2boCACkr9gIAAXrYAgABoWQCAAAOfAIABrJQA Date: Tue, 10 Sep 2013 16:44:44 +0000 Message-ID: References: In-Reply-To: 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: 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: Tue, 10 Sep 2013 16:44:54 -0000 On Sep 9, 2013, at 8:10 AM, Josh Howlett wrote: >>>=20 >>> - User account credentials incorrect >>> - User account credentials change required >>=20 >> [Joe] I am concerned that these error messages reveal too much >> information to an attacker. >=20 > I agree there are risks if used inappropriately, but nonetheless there ar= e > reasonable uses for these (for example, switching it on temporarily when > debugging) as these are very common error conditions. I suggest that thes= e > be optional to implement and use, and that we have security consideration= s > text that highlights the issue. Happy to propose some text. >=20 [Joe] I'm not really in favor of including things in standards that should= not be used. I am concerned that this could delay the document. If you p= rovide some sample text and no-one objects then I will include this in the = document.=20 > Josh. >=20 >=20 >=20 > 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 >=20 From hartmans@mit.edu Thu Sep 12 13:39: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 8063411E81E0; Thu, 12 Sep 2013 13:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8rf+u9UfUas; Thu, 12 Sep 2013 13:39:28 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3013711E810B; Thu, 12 Sep 2013 13:39:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id A65CD20377; Thu, 12 Sep 2013 16:39:04 -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 CYmi60j4hxug; Thu, 12 Sep 2013 16:39:03 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.103]) (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, 12 Sep 2013 16:39:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 281838E160; Thu, 12 Sep 2013 16:39:24 -0400 (EDT) From: Sam Hartman To: Martin Stiemerling References: <20130808192411.10939.54546.idtracker@ietfa.amsl.com> <52138FFE.8070307@neclab.eu> <5230675A.7020208@gmail.com> Date: Thu, 12 Sep 2013 16:39:24 -0400 In-Reply-To: <5230675A.7020208@gmail.com> (Martin Stiemerling's message of "Wed, 11 Sep 2013 14:51:38 +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: "" , The IESG , "" , Martin Stiemerling , "" , Sam Hartman 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: Thu, 12 Sep 2013 20:39:33 -0000 >>>>> "Martin" == Martin Stiemerling writes: Martin> Sam, Martin> On 08/24/2013 03:41 PM, Sam Hartman wrote: >>>>>>> "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. Martin> So, for the unexperienced EAP people like me, TEAP is the Martin> inner method? TEAP is running within EAP. *sigh* I'm sorry, I used the wrong terminology. Inner method doesn't come up here; that would be a case where say you were running EAP-AKA inside TEAP. Rephrasing to apply to your situation. If an EAP method supports fragmentation, that fragmentation is handled by the method. That is both fragmented and un-fragmented messages within the view of the method are "whole messages," as considered by EAP. We see a similar situation with IP and ethernet. Ethernet (at least the version I learned about back when ethernet was simple) doesn't support fragmentation. Each IP datagram, whether it's a fragment or not, is a whole ethernet frame. As it happens, ethernet doesn't provide end-to-end service, and for a bunch of other reasons tdhat don't apply to EAP, you need to talk about retransmission at the IP layer as well as to some extent at the ethernet layer. However, with EAP, the EAP layer provides a reliable end-to-end service and entirely takes on the retransmission task (unless EAP itself is running over a lower layer that takes on retransmission and sets the EAP retransmit timeout to infinite). A method can fragment, but unlike IP, the fragmentation mechanism is entirely disjoint from retransmission. There are probably inefficiencies here because of that disconnect. however, EAP is not trying to be an efficient transport. And handling retransmission on the EAP side of the boundary and fragmentation on the method side side of the abstraction boundary provides valuable benefits for EAP. Like the state machine between the method and EAP can be lock-step without the method ever triggering an event. That's quite important for the way people have grown to build EAP software. From mls.ietf@gmail.com Wed Sep 11 05:51:42 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 B7A0521E80E3; Wed, 11 Sep 2013 05:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 H4uoPaj+ZJlf; Wed, 11 Sep 2013 05:51:42 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id C445B11E80FC; Wed, 11 Sep 2013 05:51:41 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id r7so3502305bkg.36 for ; Wed, 11 Sep 2013 05:51:40 -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=fHo2LdayvcywP9kKTMIwZKpZEZaRxLphEW0xkkPRlnk=; b=veFObBxpVG0ZMc4Cc0tn1VvtJMTdpYSstEQVbteJLv7tfAxz2pLYgcS1KI+3lTnSqD 5MD39osC3C4Y2dT5FxFxdc1tCF1TGnigsbbv2+0s1Se3rZEecSvV1L5D1eYi+OmXZXV4 w5rF6BUwfJd+rjLELJM2LfDah57oHpQYVPiIaOA1mgy1m3Zv75O7upINQwL4nmxPp9ni loRCGSFXQnN4wn4nxy3X+t1/csNzP/X6kJR/By4m6LaFF8x6Resx6bWUk2ACgxGM/zR5 nkSg/2uZl2ZFNhrL4/ttu0ZsyLJCpv3yW6v7Xx7aS7pAxCpcYLm+VPeedH3k3tKplnHd gpxQ== X-Received: by 10.204.232.207 with SMTP id jv15mr1363337bkb.39.1378903900872; Wed, 11 Sep 2013 05:51:40 -0700 (PDT) Received: from [10.1.1.190] (mito.netlab.nec.de. [195.37.70.39]) by mx.google.com with ESMTPSA id pk7sm7439638bkb.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 05:51:40 -0700 (PDT) Message-ID: <5230675A.7020208@gmail.com> Date: Wed, 11 Sep 2013 14:51:38 +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> <52138FFE.8070307@neclab.eu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 22 Sep 2013 10:53:24 -0700 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, 11 Sep 2013 12:51:42 -0000 Sam, On 08/24/2013 03:41 PM, Sam Hartman wrote: >>>>>> "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. So, for the unexperienced EAP people like me, TEAP is the inner method? TEAP is running within EAP. Martin From hartmans@mit.edu Mon Sep 23 12:08:45 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 2149611E80F6 for ; Mon, 23 Sep 2013 12:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffIcm9yW1l+J for ; Mon, 23 Sep 2013 12:08:38 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5777911E80F8 for ; Mon, 23 Sep 2013 12:08:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 66F3E20397; Mon, 23 Sep 2013 15:07:45 -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 JbBpifNkEsY1; Mon, 23 Sep 2013 15:07:44 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.100]) (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; Mon, 23 Sep 2013 15:07:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0EBD08833F; Mon, 23 Sep 2013 15:08:31 -0400 (EDT) From: Sam Hartman To: emu@ietf.org Date: Mon, 23 Sep 2013 15:08:31 -0400 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: mrw@painless-security.com Subject: [Emu] RFC 6677: empty attribute lists in Channel Binding responses 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, 23 Sep 2013 19:08:45 -0000 We noticed a situation where our AAA server was generating a channel binding response that was rejected by our supplicant code. We looked into things and determined that the server was generating a single octet failure response (code 3) and was including no attributes. After re-reading section 5.3, we believe this is unambiguously permitted and is correct behavior in the situation where we send it. However, it was kind of non-intuitive to get a response back with no information in it. I don't think an erata is required, but I'd appreciate others looking at the spec to confirm our reading. Thanks, --Sam From jsalowey@cisco.com Tue Sep 24 23:21:32 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 B6E4121F9F23; Tue, 24 Sep 2013 23:21:32 -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 sro7olt14gHb; Tue, 24 Sep 2013 23:21:27 -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 C7B4621F99F8; Tue, 24 Sep 2013 23:21:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9749; q=dns/txt; s=iport; t=1380090087; x=1381299687; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kW9UMD7mO+KEDx8AVnY2ueGNcOQnhc4wLLFyh5ro7qc=; b=OeWsiB24WZacamzF+Amk5hcWLj7JmCxktLa25hWLjd6poC1qE/LDnblT Hd1Xwm50GisLS/X9mzA/qFQHrSp7Br6kiUnbc13EL1+h3v5bqWFrFimtD a5o+l18UATZtWkqdIynxsEgHBOSAZRCKDKLtCnQjebWa+O7wnP6ApqpRZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAHV/QlKtJV2b/2dsb2JhbABSBgMBAggCgno4UsAASoEcFnSCJQEBAQMBAQEBNy0HCwULAgEIIg4GBQsnCyUCBA4FCAGHdgYMvAmOCAcDBoEGAjECBQwFB4MFgQADlB+FDJBIgWaBPoFoAgcXBhw X-IronPort-AV: E=Sophos;i="4.90,976,1371081600"; d="scan'208";a="263954385" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 25 Sep 2013 06:21:25 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8P6LPuS007819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 25 Sep 2013 06:21:25 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.212]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 01:21:25 -0500 From: "Joseph Salowey (jsalowey)" To: Stephen Farrell Thread-Topic: [Emu] Stephen Farrell's Discuss on draft-ietf-emu-eap-tunnel-method-07: (with DISCUSS and COMMENT) Thread-Index: AQHOmRfmMuvUmFXY2ki/njj2RNIJepnWkIwA Date: Wed, 25 Sep 2013 06:21:24 +0000 Message-ID: References: <20130814175831.1459.86153.idtracker@ietfa.amsl.com> In-Reply-To: <20130814175831.1459.86153.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.127] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , The IESG , "" , "" 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, 25 Sep 2013 06:21:32 -0000 On Aug 14, 2013, at 10:58 AM, Stephen Farrell w= rote: > Stephen Farrell 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 >=20 > 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. >=20 > (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. >=20 [Joe] We could add a note about the null, is there some text in an existin= g document we could reuse? =20 > (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. >=20 [Joe] We chose to have the dependence so we would rely on the same crypto-a= lgorithms as TLS so our crypto agility would track with TLS. We figured T= LS would track advances in cryptography better than EMU.=20 > (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? >=20 [Joe] Sam's comments pretty much reflect the working group consensus on thi= s topic.=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - 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.) >=20 [Joe] In general no. The closest thing I can think of is NEA which can use= a method such as TEAP for transport, but I don't think this would allow an= attacker to launch a CRIME attack.=20 > - 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? >=20 [Joe] The PAC-lifetime is carried in the PAC-Info which is always send unde= r the protection of the TLS tunnel. Only the PAC-Opaque is sent outside th= e tunnel. > - 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. >=20 [Joe] Clear text means outside the TLS tunnel. EAP state machine requires = that the EAP-Success or EAP-Failure be sent independently of the method. T= his is why TEAP has its own protected result indication and why this sectio= n states that the Peer must not accept a cleartext success or failure befor= e the protected results are received.=20 > - 3.8: this says mutual auth "results" if the peer trusts > the server cert belongs to the server - that sounds > wrong, isn't it? >=20 [Joe] I think this section is terminology challenged. It should basically = replace mutual server authentication with just server authentication.=20 "Several TEAP services including server unauthenticated provisioning, PAC provisioning, certificate provisioning and channel binding depend on the peer trusting the TEAP server. Peers MUST=20 authenticate the server before these peer services are used. TEAP peers MUST track whether server authentication has taken place. Server authentication results if the peer trusts the provided server certificate. Typically this involves both validating the certificate to a trust anchor and confirming the entity named by the certificate is the intended server. Server authentication also results when the procedures of Section 3.3 are used to resume a session in which the the peer and server was previously mutually authenticated. Alternatively, if an inner EAP method providing mutual authentication and an Extended Master Session Key (EMSK) is executed and cryptographic binding with the EMSK compound MAC is present (Section 4.2.13), then the session is mutually authenticated and peer services can be used. =20 TEAP implementations SHOULD NOT use peer services by default unless the session is server authenticated. TEAP peer implementations MUST have a configuration where authentication fails if server authentication cannot be achieved. An additional complication arises when a tunnel method authenticates multiple parties such as authenticating both the peer machine and the peer user to the EAP server. Depending on how authentication is achieved, only some of these parties may have confidence in it. For example if a strong shared secret is used to mutually authenticate the user and the EAP server, the machine may not have confidence that the EAP server is the authenticated party if the machine cannot trust the user not to disclose the shared secret to an attacker. In these cases, the parties who participate in the authentication need to be considered when evaluating whether to use peer services. " > - 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..." >=20 [Joe] Yes. How about: "The peer MUST successfully authenticated the EAP server and validated the= Crypto-Binding TLV as defined in=20 Section 4.2.13 before issuing the request" =20 >=20 > - 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;-) >=20 [Joe] This is meant to use the same mechanism as EST. It is currently out= of sync with the latest version. It should line up: In order to provide linking identity and proof-of-possession by including information specific to the current authenticated TLS session within the signed certification request, the peer generating the request SHOULD obtain the tls-unique value from the TLS subsystem as= defined in Channel Bindings for TLS [RFC5929]. The TEAP peer operations between obtaining = the tls_unique value through generation of the CSR that contains the current tls_unique value and the subsequent verification of this value by the TEAP server are the "phases of the application protocol during which application- layer authentication occurs" that are protected by the synchronization interoperability mechanism described in the Channel Bindings for TLS=20 [RFC5929] section 3.1 interoperability notes. When performing renegotiat= ion,=20 TLS "secure_renegotiation" [RFC5746] MUST be used. The tls-unique value is base 64-encoded as specified in=20 Section 4 of [RFC4648] and the resulting string is placed in the certifi= cation request challenge-password field ( [RFC2985], Section 5.4.1). The challenge-password field is limited to 255 bytes (section 7.4.9 of [RFC5= 246] indicates that no existing cipher suite would result in an issue with this limitation). If tls-unique information is not embedded within the certification request the challenge-password field MUST be empty to indicate that the peer did not include the optional channel-binding information (any value submitted is verified by the server as tls-unique information). The server SHOULD verify the tls-unique information. This ensures that = the authenticated TEAP peer is in possession of the private key used to sign the certification request. > - The secdir review [1] raised a couple of questions that > I think would be good to answer. Did I miss that answer? >=20 [Joe] No, I missed the review. Response in progress. =20 > [1] http://www.ietf.org/mail-archive/web/secdir/current/msg04106.html >=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From hartmans@mit.edu Thu Sep 26 09:30: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 9B9B521F9634 for ; Thu, 26 Sep 2013 09:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 PZ3xFHYDy4KW for ; Thu, 26 Sep 2013 09:30:05 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B28D921F933B for ; Thu, 26 Sep 2013 09:29:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 2438120201; Thu, 26 Sep 2013 12:28:46 -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 JPYfaT0IFSWt; Thu, 26 Sep 2013 12:28:45 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (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, 26 Sep 2013 12:28:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C2DBD80D3A; Thu, 26 Sep 2013 12:29:38 -0400 (EDT) From: Sam Hartman To: Sam Hartman References: Date: Thu, 26 Sep 2013 12:29:38 -0400 In-Reply-To: (Sam Hartman's message of "Mon, 23 Sep 2013 15:08:31 -0400") 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: mrw@painless-security.com, emu@ietf.org Subject: Re: [Emu] RFC 6677: empty attribute lists in Channel Binding responses 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, 26 Sep 2013 16:30:11 -0000 >>>>> "Sam" == Sam Hartman writes: Sam> We noticed a situation where our AAA server was generating a Sam> channel binding response that was rejected by our supplicant Sam> code. Sam> We looked into things and determined that the server was Sam> generating a single octet failure response (code 3) and was Sam> including no attributes. Actually, our debugging code was confusing. The server is generating a code 3, the RADIUS NSID, and a length of 0 for that NSID. After reading section 5.3, I think it's ambiguous whether this is permitted. I'm going to change the server code to generate no NSID or length in this situation because as discussed previously that is clearly permitted. I'd be interested in opinions about what clients should do in the case where tan NSID with 0 length is received. From jsalowey@cisco.com Sun Sep 29 16:42:05 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 212FD21F9D2B for ; Sun, 29 Sep 2013 16:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.392 X-Spam-Level: X-Spam-Status: No, score=-109.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 SzdQQnjhXiux for ; Sun, 29 Sep 2013 16:42:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2C76121F9CBF for ; Sun, 29 Sep 2013 16:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6040; q=dns/txt; s=iport; t=1380498120; x=1381707720; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nBMDIAfAS2Bp7tDHEuaWwltv7ZcI1aeCIHTTxB7XeYo=; b=Aw3MsnYvdbrJgyyvjhhB0BThKx8btYIkoLAS3r5J1ZNkE7ITI3CwS7bZ n/SpMOxtmvkHuFoQRQNDV/HicXP9hnzIxNgEudGTpbiGUGD5B8u+oRqHA ZEAg/HnJqB/yy3zjS5QQWud+FwDrctSS/XgGJNPN5dXL8d0KRapqUPmLM 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjwFACC6SFKtJV2Z/2dsb2JhbABRAQiDBzhGAQEKwHeBHxZ0giUBAQEDAQEBATc0CxACAQgYCgsJECcLJQIEDgMCCId4Bgy7ZASODwMCgQoCBisHAgiDFYEDA6l4gyRAgSgiAh4 X-IronPort-AV: E=Sophos;i="4.90,1006,1371081600"; d="scan'208";a="265960929" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-6.cisco.com with ESMTP; 29 Sep 2013 23:41:59 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8TNfx5L026586 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 29 Sep 2013 23:41:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.23]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Sun, 29 Sep 2013 18:41:59 -0500 From: "Joseph Salowey (jsalowey)" To: "Joseph Salowey (jsalowey)" Thread-Topic: [Emu] Some proposed error conditions for TEAP Thread-Index: AQHOkDejY4UXy9LBjEiw2wL8xzrc7JmLde0AgAvBXwCAEFxGgIALMT6AgAA2boCACkr9gIAAXrYAgABoWQCAAAOfAIABrJQAgB5Q3gA= Date: Sun, 29 Sep 2013 23:41:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.127] Content-Type: text/plain; charset="us-ascii" Content-ID: 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: Sun, 29 Sep 2013 23:42:05 -0000 Below is the text for the Error TLV. This should have the error messages = we discussed. I also move the CSR related error messages to warnings. =20 Cheers, Joe 4.2.6. Error TLV The Error TLV allows an EAP peer or server to indicate errors to the other party. A TEAP packet can contain 0 or more Error TLVs. The Error-Code field describes the type of error. Error Codes 1-999 represent successful outcomes (informative messages), 1000-1999 represent warnings, and codes 2000-2999 represent fatal errors. A fatal Error TLV MUST be accompanied by a Result TLV indicating failure and the conversation is terminated as described in Section 3.6.3. Many of the error codes below refer to errors in inner method processing that may be retrieved if made available by the inner method. Implementations MUST take care that error messages do not reveal too much information to an attacker. For example, the usage of error message 1031 (User account credentials incorrect) is NOT RECOMMENDED, because it allows an attacker to determine valid usernames by differentiating this response from other responses. It should only be used for troubleshooting purposes. The Error TLV is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error-Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M Mandatory, set to one (1) R Reserved, set to zero (0) TLV Type 5 for Error TLV Length 4 Error-Code The Error-Code field is four octets. Currently defined values for Error-Code include: 1 User account expires soon 2 User account credential expires soon 3 User account authorisations change soon 4 Clock skew detected 5 Contact administrator 6 User account credentials change required 1001 Inner Method Error 1002 Unspecified authentication infrastructure problem 1003 Unspecified authentication failure 1004 Unspecified authorisation failure 1005 User account credentials unavailable 1006 User account expired 1007 User account locked: try again later 1008 User account locked: admin intervention required 1009 Authentication infrastructure unavailable 1010 Authentication infrastructure not trusted 1011 Clock skew too great 1012 Invalid inner realm 1013 Token out of sync: administrator intervention required 1014 Token out of sync: PIN change required 1015 Token revoked 1016 Tokens exhausted 1017 Challenge expired 1018 Challenge algorithm mismatch 1019 Client certificate not supplied 1020 Client certificate rejected 1021 Realm mismatch between inner and outer identity 1022 Unsupported Algorithm In Certificate Signing Request 1023 Unsupported Extension In Certificate Signing Request 1024 Bad Identity In Certificate Signing Request 1025 Bad Certificate Signing Request 1026 Internal CA Error 1027 General PKI Error 1028 Inner method's channel binding data required but not supplied 1029 Inner method's channel binding data did not include required information 1030 Inner method's channel binding failed 1031 User account credentials incorrect [USAGE NOT RECOMMENDED] 2001 Tunnel Compromise Error 2002 Unexpected TLVs Exchanged On Sep 10, 2013, at 9:44 AM, Joseph Salowey (jsalowey) = wrote: >=20 > On Sep 9, 2013, at 8:10 AM, Josh Howlett wrote: >=20 >>>>=20 >>>> - User account credentials incorrect >>>> - User account credentials change required >>>=20 >>> [Joe] I am concerned that these error messages reveal too much >>> information to an attacker. >>=20 >> I agree there are risks if used inappropriately, but nonetheless there a= re >> reasonable uses for these (for example, switching it on temporarily when >> debugging) as these are very common error conditions. I suggest that the= se >> be optional to implement and use, and that we have security consideratio= ns >> text that highlights the issue. Happy to propose some text. >>=20 >=20 > [Joe] I'm not really in favor of including things in standards that shou= ld not be used. I am concerned that this could delay the document. If you= provide some sample text and no-one objects then I will include this in th= e document.=20 >=20 >> Josh. >>=20 >>=20 >>=20 >> 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 >>=20 >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From Josh.Howlett@ja.net Mon Sep 30 02:18: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 7396221F9C46 for ; Mon, 30 Sep 2013 02:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.578 X-Spam-Level: X-Spam-Status: No, score=-101.578 tagged_above=-999 required=5 tests=[AWL=1.021, 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 iFd8CfBvbPGa for ; Mon, 30 Sep 2013 02:18:11 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 85CC921F9798 for ; Mon, 30 Sep 2013 02:18:03 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id DA25B20C7E1C_24941C9B; Mon, 30 Sep 2013 09:18:01 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "staffmail.ja.net", Issuer "TERENA SSL CA" (verified OK)) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTPS id 7BB4020C7E12_24941C9F; Mon, 30 Sep 2013 09:18:01 +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; Mon, 30 Sep 2013 10:18:01 +0100 From: Josh Howlett To: "Joseph Salowey (jsalowey)" Thread-Topic: [Emu] Some proposed error conditions for TEAP Thread-Index: AQHOkDejY4UXy9LBjEiw2wL8xzrc7JmLEVgAgAvBXwCAEFxGgIALQfcAgAAltICACkr+gIAAb3IAgABXnoCAABRbgIABm9YAgB5Q3wCAALGwAA== Date: Mon, 30 Sep 2013 09:18:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <9469D101E4349D46B3DA064785DB76E5@ukerna.ac.uk> 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: Mon, 30 Sep 2013 09:18:21 -0000 Looks good to me -- thanks for accommodating this. Josh. On 30/09/2013 00:41, "Joseph Salowey (jsalowey)" wrote: >Below is the text for the Error TLV. This should have the error >messages we discussed. I also move the CSR related error messages to >warnings.=20=20 > >Cheers, > >Joe > >4.2.6. Error TLV > > The Error TLV allows an EAP peer or server to indicate errors to the > other party. A TEAP packet can contain 0 or more Error TLVs. The > Error-Code field describes the type of error. Error Codes 1-999 > represent successful outcomes (informative messages), 1000-1999 > represent warnings, and codes 2000-2999 represent fatal errors. A > fatal Error TLV MUST be accompanied by a Result TLV indicating > failure and the conversation is terminated as described in > Section 3.6.3. > > Many of the error codes below refer to errors in inner method > processing that may be retrieved if made available by the inner > method. Implementations MUST take care that error messages do not > reveal too much information to an attacker. For example, the usage > of error message 1031 (User account credentials incorrect) is NOT > RECOMMENDED, because it allows an attacker to determine valid > usernames by differentiating this response from other responses. It > should only be used for troubleshooting purposes. > > The Error TLV is defined as follows: > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |M|R| TLV Type | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Error-Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > M > > Mandatory, set to one (1) > > > R > > Reserved, set to zero (0) > > > TLV Type > > 5 for Error TLV > > > Length > > 4 > > > Error-Code > > The Error-Code field is four octets. Currently defined values > for Error-Code include: > > > 1 User account expires soon > > 2 User account credential expires soon > > 3 User account authorisations change soon > > 4 Clock skew detected > > 5 Contact administrator > > 6 User account credentials change required > > 1001 Inner Method Error > > 1002 Unspecified authentication infrastructure problem > > 1003 Unspecified authentication failure > > 1004 Unspecified authorisation failure > > 1005 User account credentials unavailable > > 1006 User account expired > > 1007 User account locked: try again later > > 1008 User account locked: admin intervention required > > 1009 Authentication infrastructure unavailable > > 1010 Authentication infrastructure not trusted > > 1011 Clock skew too great > > 1012 Invalid inner realm > > 1013 Token out of sync: administrator intervention > required > > 1014 Token out of sync: PIN change required > > 1015 Token revoked > > 1016 Tokens exhausted > > 1017 Challenge expired > > 1018 Challenge algorithm mismatch > > 1019 Client certificate not supplied > > 1020 Client certificate rejected > > 1021 Realm mismatch between inner and outer identity > > 1022 Unsupported Algorithm In Certificate Signing > Request > > 1023 Unsupported Extension In Certificate Signing > Request > > 1024 Bad Identity In Certificate Signing Request > > 1025 Bad Certificate Signing Request > > 1026 Internal CA Error > > 1027 General PKI Error > > 1028 Inner method's channel binding data required but > not supplied > > 1029 Inner method's channel binding data did not > include required information > > 1030 Inner method's channel binding failed > > 1031 User account credentials incorrect [USAGE NOT > RECOMMENDED] > > 2001 Tunnel Compromise Error > > 2002 Unexpected TLVs Exchanged > > > >On Sep 10, 2013, at 9:44 AM, Joseph Salowey (jsalowey) > wrote: > >>=20 >> On Sep 9, 2013, at 8:10 AM, Josh Howlett wrote: >>=20 >>>>>=20 >>>>> - User account credentials incorrect >>>>> - User account credentials change required >>>>=20 >>>> [Joe] I am concerned that these error messages reveal too much >>>> information to an attacker. >>>=20 >>> I agree there are risks if used inappropriately, but nonetheless there >>>are >>> reasonable uses for these (for example, switching it on temporarily >>>when >>> debugging) as these are very common error conditions. I suggest that >>>these >>> be optional to implement and use, and that we have security >>>considerations >>> text that highlights the issue. Happy to propose some text. >>>=20 >>=20 >> [Joe] I'm not really in favor of including things in standards that >>should not be used. I am concerned that this could delay the document. >>If you provide some sample text and no-one objects then I will include >>this in the document. >>=20 >>> Josh. >>>=20 >>>=20 >>>=20 >>> Janet(UK) is a trading name of Jisc Collections and Janet Limited, a >>> 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 >>>=20 >>=20 >> _______________________________________________ >> Emu mailing list >> Emu@ietf.org >> https://www.ietf.org/mailman/listinfo/emu > 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 turners@ieca.com Mon Sep 30 08:36:47 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 4CBC621F99FB for ; Mon, 30 Sep 2013 08:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.015, 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 ty850RtnabpR for ; Mon, 30 Sep 2013 08:36:40 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.166.3]) by ietfa.amsl.com (Postfix) with ESMTP id DA5EC21F9A72 for ; Mon, 30 Sep 2013 08:36:36 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 9A40143A30501; Mon, 30 Sep 2013 10:36:03 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 7F62E43A304CA for ; Mon, 30 Sep 2013 10:36:03 -0500 (CDT) Received: from [96.231.225.44] (port=56757 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VQfWQ-0003tO-Cn; Mon, 30 Sep 2013 10:36:30 -0500 Message-ID: <52499A7C.20905@ieca.com> Date: Mon, 30 Sep 2013 11:36:28 -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: Martin Stiemerling References: <20130808192411.10939.54546.idtracker@ietfa.amsl.com> <52138FFE.8070307@neclab.eu> <5230675A.7020208@gmail.com> <52492C4D.4020006@gmail.com> In-Reply-To: <52492C4D.4020006@gmail.com> 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 - gator3286.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]:56757 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 22 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Cc: "" , The IESG , "" , Martin Stiemerling , "" , Sam Hartman 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: Mon, 30 Sep 2013 15:36:47 -0000 On 9/30/13 3:46 AM, Martin Stiemerling wrote: > > > On 09/12/2013 10:39 PM, Sam Hartman wrote: >>>>>>> "Martin" == Martin Stiemerling writes: >> >> Martin> Sam, >> Martin> On 08/24/2013 03:41 PM, Sam Hartman wrote: >> >>>>>>> "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. >> >> Martin> So, for the unexperienced EAP people like me, TEAP is the >> Martin> inner method? TEAP is running within EAP. >> >> *sigh* >> I'm sorry, I used the wrong terminology. >> Inner method doesn't come up here; that would be a case where say you >> were running EAP-AKA inside TEAP. >> >> Rephrasing to apply to your situation. >> If an EAP method supports fragmentation, that fragmentation is handled >> by the method. That is both fragmented and un-fragmented messages >> within the view of the method are "whole messages," as considered by >> EAP. >> >> We see a similar situation with IP and ethernet. Ethernet (at least the >> version I learned about back when ethernet was simple) doesn't support >> fragmentation. Each IP datagram, whether it's a fragment or not, is a >> whole ethernet frame. >> >> As it happens, ethernet doesn't provide end-to-end service, and for a >> bunch of other reasons tdhat don't apply to EAP, you need to talk about >> retransmission at the IP layer as well as to some extent at the ethernet >> layer. >> >> However, with EAP, the EAP layer provides a reliable end-to-end service >> and entirely takes on the retransmission task (unless EAP itself is >> running over a lower layer that takes on retransmission and sets the EAP >> retransmit timeout to infinite). >> >> A method can fragment, but unlike IP, the fragmentation mechanism is >> entirely disjoint from retransmission. >> >> There are probably inefficiencies here because of that disconnect. >> however, EAP is not trying to be an efficient transport. And handling >> retransmission on the EAP side of the boundary and fragmentation on the >> method side side of the abstraction boundary provides valuable benefits >> for EAP. Like the state machine between the method and EAP can be >> lock-step without the method ever triggering an event. That's quite >> important for the way people have grown to build EAP software. > > Ok, I see. I will clear. Thanks! spt From internet-drafts@ietf.org Mon Sep 30 20:21:27 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 D65AE21F99F0; Mon, 30 Sep 2013 20:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, 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 B2WasPm-AEnh; Mon, 30 Sep 2013 20:21:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 245A221F999B; Mon, 30 Sep 2013 20:21:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131001032125.31558.94939.idtracker@ietfa.amsl.com> Date: Mon, 30 Sep 2013 20:21:25 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-eap-tunnel-method-08.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 03:21:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of the IE= TF. Title : Tunnel EAP Method (TEAP) Version 1 Author(s) : Hao Zhou Nancy Cam-Winget Joseph Salowey Stephen Hanna Filename : draft-ietf-emu-eap-tunnel-method-08.txt Pages : 107 Date : 2013-09-30 Abstract: This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-eap-tunnel-method-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Sep 30 20:21:30 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 58D7021F99F0 for ; Mon, 30 Sep 2013 20:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, 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 tmj+EyXcKPgI; Mon, 30 Sep 2013 20:21:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACAAA21F84E0; Mon, 30 Sep 2013 20:21:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131001032126.31558.83158.idtracker@ietfa.amsl.com> Date: Mon, 30 Sep 2013 20:21:26 -0700 Subject: [Emu] New Version Notification - draft-ietf-emu-eap-tunnel-method-08.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 03:21:30 -0000 A new version (-08) has been submitted for draft-ietf-emu-eap-tunnel-method: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-tunnel-method-08.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-eap-tunnel-method-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From internet-drafts@ietf.org Mon Sep 30 20:53:32 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 351AA21F9649; Mon, 30 Sep 2013 20:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, 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 Emx-Q1e47ZlH; Mon, 30 Sep 2013 20:53:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50621F9928; Mon, 30 Sep 2013 20:53:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131001035327.31558.9592.idtracker@ietfa.amsl.com> Date: Mon, 30 Sep 2013 20:53:27 -0700 Cc: emu@ietf.org Subject: [Emu] I-D Action: draft-ietf-emu-eap-tunnel-method-09.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 03:53:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the EAP Method Update Working Group of the IE= TF. Title : Tunnel EAP Method (TEAP) Version 1 Author(s) : Hao Zhou Nancy Cam-Winget Joseph Salowey Stephen Hanna Filename : draft-ietf-emu-eap-tunnel-method-09.txt Pages : 107 Date : 2013-09-30 Abstract: This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, Type-Length-Value (TLV) objects are used to convey authentication related data between the EAP peer and the EAP server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-eap-tunnel-method-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Sep 30 20:53: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 24D9621F9A10 for ; Mon, 30 Sep 2013 20:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, 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 IGcFvkr7II+7; Mon, 30 Sep 2013 20:53:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD7B21F9A16; Mon, 30 Sep 2013 20:53:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: emu-chairs@tools.ietf.org, draft-ietf-emu-eap-tunnel-method@tools.ietf.org, emu@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie, barryleiba@computer.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131001035327.31558.17551.idtracker@ietfa.amsl.com> Date: Mon, 30 Sep 2013 20:53:27 -0700 Subject: [Emu] New Version Notification - draft-ietf-emu-eap-tunnel-method-09.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.12 List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 03:53:33 -0000 A new version (-09) has been submitted for draft-ietf-emu-eap-tunnel-method: http://www.ietf.org/internet-drafts/draft-ietf-emu-eap-tunnel-method-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tunnel-method/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-emu-eap-tunnel-method-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat.