From nobody Fri Feb 14 01:09:12 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE87A1A01B3; Fri, 14 Feb 2014 01:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9THqM4nzcoF; Fri, 14 Feb 2014 01:09:00 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 847311A0115; Fri, 14 Feb 2014 01:08:59 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D40DA10580; Fri, 14 Feb 2014 10:08:57 +0100 (CET) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id C1A231057E; Fri, 14 Feb 2014 10:08:57 +0100 (CET) Message-ID: <52FDDD10.1050306@restena.lu> Date: Fri, 14 Feb 2014 10:08:32 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> In-Reply-To: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 X-Forwarded-Message-Id: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P" X-Virus-Scanned: ClamAV Archived-At: http://mailarchive.ietf.org/arch/msg/emu/kUK24Y61c020Geu0drdTzCNmqzI Cc: abfab@ietf.org, "dime@ietf.org" , "" Subject: [Emu] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 09:09:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P Content-Type: multipart/mixed; boundary="------------010603070305000203040701" This is a multi-part message in MIME format. --------------010603070305000203040701 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I've just submitted an -00 on a topic that we've been struggling with in ABFAB recently (but which exists in every EAP-over-AAA scenario, not limited to ABFAB). http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapide= ntity-00.txt Abstract: There are some subtle considerations for an EAP peer regarding the content of the EAP-Response/Identity packet when authenticating with EAP to an EAP server. This document describes two such considerations and suggests workarounds to the associated problems. The issue touches multiple areas and working groups (EAP, EAP methods, RADIUS, Diameter) so I had to do a guesstimate for a proper home. I would think radext is the best match, cc'ing abfab and dime, and also emu even though it's shutting down). If you recall those in-depth discussions about fixing either EAP methods to use UTF-8, or why EAP Identity would need to be restrained to UTF-8 even if a method doesn't do it, then yes: the draft is about that. In ABFAB, we added a ABFAB-specific band-aid sentence to RFC7057: "Circumstances might require that applications need to perform conversion of identities from an application specific character set to UTF-8 or another character set required by a particular EAP method." Which was enough to get the document through IESG, but this should better be fixed more generally for every EAP use case; hence this new dra= ft. It's short and concise - I'd appreciate if you could give it a read and comment. If there's still free time on the agenda, I would also merrily discuss it in London. Greetings, Stefan Winter P.S.: Don't miss my other submission about an EAP Configuration File Format, which I've been told to submit to ops-area/opsawg: http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ Annoucement here: http://www.ietf.org/mail-archive/web/ops-area/current/msg01114.html -------- Original Message -------- Subject: New Version Notification for draft-winter-radext-populating-eapidentity-00.txt Date: Fri, 14 Feb 2014 00:43:29 -0800 From: internet-drafts@ietf.org To: Stefan Winter , "Stefan Winter" A new version of I-D, draft-winter-radext-populating-eapidentity-00.txt has been successfully submitted by Stefan Winter and posted to the IETF repository. Name: draft-winter-radext-populating-eapidentity Revision: 00 Title: Considerations regarding the correct use of EAP-Response/Identity= Document date: 2014-02-14 Group: Individual Submission Pages: 6 URL: http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapide= ntity-00.txt Status: https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidenti= ty/ Htmlized: http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-00 Abstract: There are some subtle considerations for an EAP peer regarding the content of the EAP-Response/Identity packet when authenticating with EAP to an EAP server. This document describes two such considerations and suggests workarounds to the associated problems. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------010603070305000203040701 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------010603070305000203040701-- --kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P 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.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJS/d0RAAoJEMDeajWKOdxmUIoP/2H8SlgdcBJ5j3fRtpG9xaFY FgWs/hdm2cHVRySVM7MvGyvs+/RU1qbNVDodzQcmDrXW1IWT1oPqt0/YGK9PCNIf X8w3qiHwJt7A79+LlMwb1I6bmVzUxpAJuL+Ya+E4Z9/WF4c5RMkbmMGR3z6xwO2P ou+o4/R6IqZGkz5l8ZSqpBW25NqxxBFyI4phMKH/Ap/9XDM4QzOlf7J2AP3uoLk2 Jywo7IrM+THqvZzDcU5lwXlL3YwGVQ/lFgkZnyHSHlmUDSc0v45OShnDZF3Y+YRt 7rmloG4NopJWB8fA/rFVrFa9kyDEP2nTVxMrlf5SBHg0oKpXUzqE/Bis+XmiW+3D yxsUz2vc6CI1CUSf6qQLnc8Mt7ntTKV5kwuTeJW3l4zfMrEhqvad2g7UIc3uWqhh Ei8F03ZShOX33Og7EX8aPVGO7x5/VNr4SJC53rn1nP2GPogFTX3Yv0LXe/R0JR/Z YBtfwAmJk1kvcVi1yNz/Bknfa+8rOV4ow16NR5fSeO2UWcX3I9ocJDuTevRbmBNQ GXovUncKbKjdQ5Fwkj4JD+2QQ26njrM3knSp39v6ij2fIZa2bK+NltN6GvFO1i0H /80Hy0fSvD/DtTfsgEIzzouL4/sJPWuktNxb/amnJzA626KH+5HCeJ/bH5o3gVSg qhVa1A5pJ50NqEJ8pBEz =6yo0 -----END PGP SIGNATURE----- --kcMVN4nVTDgRBdOkJ8plWpnOCckqcg08P-- From nobody Sat Feb 15 15:03:14 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0621A02F1; Sat, 15 Feb 2014 15:03:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mbIDKgxaEOC; Sat, 15 Feb 2014 15:03:06 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD261A00F5; Sat, 15 Feb 2014 15:03:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D7118224017A; Sun, 16 Feb 2014 00:03:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ugd6qGcOh1Du; Sun, 16 Feb 2014 00:03:03 +0100 (CET) Received: from Thor.local (unknown [70.50.217.206]) by power.freeradius.org (Postfix) with ESMTPSA id 717112240128; Sun, 16 Feb 2014 00:03:02 +0100 (CET) Message-ID: <52FFF22A.5010802@deployingradius.com> Date: Sat, 15 Feb 2014 18:03:06 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> In-Reply-To: <52FDDD10.1050306@restena.lu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/emu/6AFESHAjzlRWmdod2tqE9gGlEqc Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" Subject: Re: [Emu] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 23:03:08 -0000 Some comments: Section 3: ... EAP- Response/Identity does not carry encoding information itself, so a conversion between a non-UTF-8 encoding and UTF-8 is not possible for the AAA entity doing the EAP-Response/Identity to User-Name copying. I'm unsure about this. The EAP-Response/Identity field is *supposed* to be UTF-8. So if it's not, the supplicant is non-compliant, and anything can happen. I think the recommendation here for EAP to RADIUS gateways (e.g. Access Points) is to do as little translation as possible. They should just copy the Identity blob into the User-Name attribute. The next paragraph does explain why this is a problem, but the quoted text above seems misleading to me. The AAA entity *can* copy the EAP-Response/Identity to User-Name. It's just data, so that copying is always possible. Consequence: If an EAP method's username is not encoded in UTF-8, and I would suggest "user identifier", to avoid confusion with User-Name. the EAP peer verbatimly uses that method's notion of a username for its EAP-Response/Identity field, then the AAA entity is forced to violate its own specification because it has to, but can not use UTF-8 for its own User-Name attribute. This jeopardizes the subsequent EAP authentication as a whole; request routing may fail or lead to a wrong destinationi, or the AAA payload may be discarded by the recipient due to the malformedness of the User-Name attribute. That is all true. I would note that the EAP-Response/Identity field does *not* have to be taken from the EAP methods user identifier field. They can be completely different. That should be noted here. Where the EAP methods user identifier field is *not* UTF-8, the supplicant MUST provide a UTF-8 compatible string for the EAP-Response/Identity field. How it gets that string is implementation dependent. :( Section 4: Where usernames between configured EAP types in an EAP peer differ, the EAP peer can not rely on the EAP type negotiation mechanism alone to provide useful results. If an EAP authentication gets rejected, the EAP peer SHOULD re-try the authentication using a different EAP- Response/Identity than before. The EAP peer SHOULD try all usernames from the entire set of configured EAP types before declaring final authentication failure. I see why this can be necessary, but it's ugly. EAP peers need to maintain state on the encoding of the usernames which are used in their locally configured EAP types. When constructing an EAP-Response/Identity from that username information, they SHOULD (re-)encode that username as UTF-8 and use the resulting value for the EAP-Response/Identity. If the EAP type is configured for the use of anonymous outer identities, the desired outer identity should also be (re-)encoded in UTF-8 encoding before being put into the EAP-Response/Identity. I would add "or allow the provisioning of an EAP-Response/Identity field independent form the EAP method user identifier" Section 5 It may be worth noting that supplicants should try the most secure EAP methods first (i.e. ones with anonymous outer identity). If those fail, they should proceed to more insecure methods. This prevents leakage. Also, supplicants could cache information about successful authentications. If the system appears to be "the same" as one where EAP method X previously worked, it makes sense to start off with EAP method X. How the supplicant determines that this is "the same" system is a subject for discussion. Alan DeKok. From nobody Mon Feb 17 01:02:53 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1961A0148; Mon, 17 Feb 2014 01:02:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_57=0.6, RP_MATCHES_RCVD=-0.548, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKl3Z80X3Cp0; Mon, 17 Feb 2014 01:02:46 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id AACFC1A02C3; Mon, 17 Feb 2014 01:02:45 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id EC64E10580; Mon, 17 Feb 2014 10:02:41 +0100 (CET) Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id D12F91057E; Mon, 17 Feb 2014 10:02:41 +0100 (CET) Message-ID: <5301D017.8060302@restena.lu> Date: Mon, 17 Feb 2014 10:02:15 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Alan DeKok References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com> In-Reply-To: <52FFF22A.5010802@deployingradius.com> X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K" X-Virus-Scanned: ClamAV Archived-At: http://mailarchive.ietf.org/arch/msg/emu/7oz5a6UeC8_7Z138sfluc8LjT_I Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" Subject: Re: [Emu] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 09:02:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K Content-Type: multipart/mixed; boundary="------------050000050108010500010704" This is a multi-part message in MIME format. --------------050000050108010500010704 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, > Section 3: >=20 > ... EAP- > Response/Identity does not carry encoding information itself, so a > conversion between a non-UTF-8 encoding and UTF-8 is not possible fo= r > the AAA entity doing the EAP-Response/Identity to User-Name copying.= >=20 > I'm unsure about this. The EAP-Response/Identity field is *supposed*= > to be UTF-8. So if it's not, the supplicant is non-compliant, and > anything can happen. Unfortunately, that is not how I read the EAP spec. RFC3748 section 5.1 on the "Identity" packet does not mention UTF-8 for the *Response* at all= =2E It mentions that the *request* MAY contain displayable text, which needs to be UTF-8 if present. For response, no encoding is mandated. The RFC even mentions weirdnesses such as an intermediate NUL character followed by "various options" - but only notes them, they are not forbidden. The use of such a construct breaks the UTF-8 requirement. I totally agree that anything besides UTF-8 in the Response is a bad idea, and these days hopefully a seldom find - but it should be said someplace that it's outright forbidden. Which reminds me that my text speaks of SHOULD NOT in the recommendations (given that I've preliminarily aimed for BCP status, I found a MUST NOT not to be fitting; but maybe it is more spot on nontheless). > I think the recommendation here for EAP to RADIUS gateways (e.g. > Access Points) is to do as little translation as possible. They should= > just copy the Identity blob into the User-Name attribute. And do what if they find that the blob is not UTF-8? Drop the packet? Forward anyway? > The next paragraph does explain why this is a problem, but the quoted= > text above seems misleading to me. The AAA entity *can* copy the > EAP-Response/Identity to User-Name. It's just data, so that copying is= > always possible. Sure; but you create a malformed packet with it - so everybody who consumes that data is at a gamble. > Consequence: If an EAP method's username is not encoded in UTF-8, an= d >=20 > I would suggest "user identifier", to avoid confusion with User-Name.= Sure, no problem. > the EAP peer verbatimly uses that method's notion of a username for > its EAP-Response/Identity field, then the AAA entity is forced to > violate its own specification because it has to, but can not use > UTF-8 for its own User-Name attribute. This jeopardizes the > subsequent EAP authentication as a whole; request routing may fail o= r > lead to a wrong destinationi, or the AAA payload may be discarded by= > the recipient due to the malformedness of the User-Name attribute. >=20 >=20 > That is all true. I would note that the EAP-Response/Identity field > does *not* have to be taken from the EAP methods user identifier field.= > They can be completely different. Will do (the completely different content would be the outer identity). > That should be noted here. Where the EAP methods user identifier > field is *not* UTF-8, the supplicant MUST provide a UTF-8 compatible > string for the EAP-Response/Identity field. How it gets that string is= > implementation dependent. :( Yes, that's why I wrote the (somewhat hollow) statement that it "needs to maintain state of the encoding used". How it does that... no spec can mandate. > Section 4: >=20 > Where usernames between configured EAP types in an EAP peer differ, > the EAP peer can not rely on the EAP type negotiation mechanism alon= e > to provide useful results. If an EAP authentication gets rejected, > the EAP peer SHOULD re-try the authentication using a different EAP-= > Response/Identity than before. The EAP peer SHOULD try all username= s > from the entire set of configured EAP types before declaring final > authentication failure. >=20 > I see why this can be necessary, but it's ugly. I totally agree that it's ugly. Adding "Note: That is ugly." to the spec doesn't provide much added value though :-) I feel strong about stating the problem though. We had an actual real-life support case from a device manufacturer whose handset customers couldn't use eduroam and the manufacturer said our RADIUS infrastructure is broken, because it always rejects before they can even try the configured EAP-TTLS that the user sets. It was totally unthinkable for them that someone would not have a business relationship with 3GPP and that always trying the same 3GPP user identifier when starting EAP would lead nowhere. After a lot of explaining and escalation to some senior engineering, we could make that clear, and the firmware got a fix. Having this described in an RFC to point to will certainly help if such states of mind pop up again someplace in the future. > EAP peers need to maintain state on the encoding of the usernames > which are used in their locally configured EAP types. When > constructing an EAP-Response/Identity from that username information= , > they SHOULD (re-)encode that username as UTF-8 and use the resulting= > value for the EAP-Response/Identity. If the EAP type is configured > for the use of anonymous outer identities, the desired outer identit= y > should also be (re-)encoded in UTF-8 encoding before being put into > the EAP-Response/Identity. >=20 > I would add "or allow the provisioning of an EAP-Response/Identity > field independent form the EAP method user identifier" Well... that degree of freedom exists - outer ID *is* independent from the EAP method's user identifier. I'm not sure what the effect of this (third!) notion of (non-)identity could add? The example of the 3GPP vs. realm.example shows that there may well be *no* common EAP-Response/Identity which actually fits all configured EAP types. > Section 5 >=20 > It may be worth noting that supplicants should try the most secure EA= P > methods first (i.e. ones with anonymous outer identity). If those fail= , > they should proceed to more insecure methods. This prevents leakage. Good idea! > Also, supplicants could cache information about successful > authentications. If the system appears to be "the same" as one where > EAP method X previously worked, it makes sense to start off with EAP > method X. >=20 > How the supplicant determines that this is "the same" system is a > subject for discussion. Interesting thought, and a bit complex. I suggest we discuss this when the draft gets adopted in ... "some" working group. Suggestions welcome := -) Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------050000050108010500010704 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.22 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------050000050108010500010704-- --gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K 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.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTAdAXAAoJEMDeajWKOdxmX44P/jsmlCv0nGs46+wfLCtki4yv ++3m3QiE8jk5KW1Vd2YV0ybTljPCbkZCD+w35cZmFY3yGGeyM8jxvo+GHiInmnf3 BKuK4yI2FpgjE0PZUpPNqYXKRr6FlKEUnPPqsr70xPCie/g+d8M+9MW+fOIwpxqt J24O7M98jDv6cJfLS2GbEDcqg4s/PjGIeSogveQKLsoaQaDaoMRhJmdzt2CyXbZt UyA4CxjxiBEgKVNjkXsM0XW74a5RMOJCelLNXYGAflp2RAoQ2kzg/qJJdXz2d3ZX 6L6AF6Qs5fH2haLq+zj0lVUlyUN+6RlN1yEuZQxOzqGhvpf1fIyM1tKnivEwtq4x KdCPE7/EoNkSVkKEfeHkqOHulKuL3WeYcDrHJTCq24CMYSM1H+8WKkLcDDSrNmqy IQhdkdjoi2cZba4UP1MVeTi6yCdEx68yYfd/CyaUdw5Kdqg1ydnEgdf8e+TuCr4O oqrE136Py9qXahfs7DT0f84pE1n9k6Bl99zVy8NkBVHx0z+PyEftyRsIcwVn48ED zx9DPfT6KCgT2eP4d0f+5Vt9cIZJHoiJKVJhUmqFdXXhyV3aRShIlHRQToybqUHu R/tshmg5A30Mwe6wgAqPEpAP31SRYbv/hS4QEsVk0RclAvkP4ShAXOmUrK/ODrZ+ HNGDPwAa+s1R8Fhlvtrk =s/V4 -----END PGP SIGNATURE----- --gJXNFK4E8sxwPulwxeHSp5lmuLGHGXQ4K-- From nobody Mon Feb 17 05:37:10 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE9C1A04D8; Mon, 17 Feb 2014 05:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtfUAvyaNWGU; Mon, 17 Feb 2014 05:37:03 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 082B21A01EA; Mon, 17 Feb 2014 05:37:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8817D2240186; Mon, 17 Feb 2014 14:36:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nmzz3aXNsDPi; Mon, 17 Feb 2014 14:36:28 +0100 (CET) Received: from Thor.local (unknown [70.50.217.206]) by power.freeradius.org (Postfix) with ESMTPSA id 39D6C22400A9; Mon, 17 Feb 2014 14:36:27 +0100 (CET) Message-ID: <5302105C.6070103@deployingradius.com> Date: Mon, 17 Feb 2014 08:36:28 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com> <5301D017.8060302@restena.lu> In-Reply-To: <5301D017.8060302@restena.lu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/emu/B5ysKoPDjvqBhjWcl_Utavjcfcg Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" Subject: Re: [Emu] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 13:37:06 -0000 Stefan Winter wrote: > Unfortunately, that is not how I read the EAP spec. RFC3748 section 5.1 > on the "Identity" packet does not mention UTF-8 for the *Response* at all. > > It mentions that the *request* MAY contain displayable text, which needs > to be UTF-8 if present. That's worse than I remembered. > For response, no encoding is mandated. The RFC even mentions weirdnesses > such as an intermediate NUL character followed by "various options" - > but only notes them, they are not forbidden. The use of such a construct > breaks the UTF-8 requirement. > > I totally agree that anything besides UTF-8 in the Response is a bad > idea, and these days hopefully a seldom find - but it should be said > someplace that it's outright forbidden. I agree. >> I think the recommendation here for EAP to RADIUS gateways (e.g. >> Access Points) is to do as little translation as possible. They should >> just copy the Identity blob into the User-Name attribute. > > And do what if they find that the blob is not UTF-8? Drop the packet? > Forward anyway? Forward anyways. It's what they do now. We can't mandate that 10^9 EAP supplicants upgrade. It's probably easier to fix the AAA infrastructure to work with broken clients. > I feel strong about stating the problem though. We had an actual > real-life support case from a device manufacturer whose handset > customers couldn't use eduroam and the manufacturer said our RADIUS > infrastructure is broken, because it always rejects before they can even > try the configured EAP-TTLS that the user sets. Weird. > It was totally unthinkable for them that someone would not have a > business relationship with 3GPP and that always trying the same 3GPP > user identifier when starting EAP would lead nowhere. That's just dumb. The way sane vendors deal with this is that they allow the user to choose which identity to use. It's ridiculous for the vendor to force a particular identity on the user / device. > After a lot of explaining and escalation to some senior engineering, we > could make that clear, and the firmware got a fix. Having this described > in an RFC to point to will certainly help if such states of mind pop up > again someplace in the future. Yes. The RFCs are unfortunately silent on a wide variety of topics. RFC 2865 even says: The secret MUST NOT be empty (length 0) since this would allow packets to be trivially forged. Because I ran into a vendor who didn't allow admins to set a shared secret... and always used a zero-length string. It *was* allowed in RFC 2158. I poked the RADIUS WG, and everyone was appalled. >> I would add "or allow the provisioning of an EAP-Response/Identity >> field independent form the EAP method user identifier" > > Well... that degree of freedom exists - outer ID *is* independent from > the EAP method's user identifier. The idea was to allow *provisioning* of the Response/Identity. Automatically deriving it from the method-specific "user identity" is just as bad as automatically using a 3GPP identity. > Interesting thought, and a bit complex. I suggest we discuss this when > the draft gets adopted in ... "some" working group. Suggestions welcome :-) I'd support a "roaming inter-operations" WG. Some of the documents now in RADEXT could move there, and maybe DIME. This document could live there. The goal for the WG would be to define inter-domain standards for authentication, accounting, EAP, etc. Alan DeKok. From nobody Mon Feb 17 08:33:57 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EC11A0405; Mon, 17 Feb 2014 08:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8KAtie8bmloj; Mon, 17 Feb 2014 08:33:50 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 401751A03FF; Mon, 17 Feb 2014 08:33:50 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id D71261A9CA0A_30239EAB; Mon, 17 Feb 2014 16:33:46 +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 AC36F1A9CA0E_30239EAF; Mon, 17 Feb 2014 16:33:46 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.03.0123.003; Mon, 17 Feb 2014 16:33:46 +0000 From: Josh Howlett To: Alan DeKok , Stefan Winter Thread-Topic: [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt Thread-Index: AQHPK792HMF1Fx9jgkuwstO/NcK195q5cwYAgAAxggA= Date: Mon, 17 Feb 2014 16:33:45 +0000 Message-ID: References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com> <5301D017.8060302@restena.lu> <5302105C.6070103@deployingradius.com> In-Reply-To: <5302105C.6070103@deployingradius.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <6B98CB3B6689F04E92AEB0557FCCB94F@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/emu/6CYIPUuTI4hgcLY5eny_rORniLY Cc: "radext@ietf.org" , "abfab@ietf.org" , "dime@ietf.org" , "" Subject: Re: [Emu] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 16:33:52 -0000 > >> Interesting thought, and a bit complex. I suggest we discuss this when >> the draft gets adopted in ... "some" working group. Suggestions welcome >>:-) > > I'd support a "roaming inter-operations" WG. Some of the documents >now in RADEXT could move there, and maybe DIME. This document could >live there. > > The goal for the WG would be to define inter-domain standards for >authentication, accounting, EAP, etc. +1, excellent idea. draft-wierenga-ietf-eduroam, if generalised, could provide a good basis on which to define the issues that need addressing. If it were broader than "roaming" then ABFAB could also fall into scope. 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 nobody Tue Feb 18 16:37:46 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250A21A02AF; Fri, 14 Feb 2014 08:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8IA8fJyqrna; Fri, 14 Feb 2014 08:11:25 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C47C81A02ED; Fri, 14 Feb 2014 08:11:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 15B5B20680; Fri, 14 Feb 2014 11:07:36 -0500 (EST) 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 DfFT4m4NwPMr; Fri, 14 Feb 2014 11:07:35 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (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; Fri, 14 Feb 2014 11:07:35 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 960CB83E59; Fri, 14 Feb 2014 11:11:15 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> Date: Fri, 14 Feb 2014 11:11:15 -0500 In-Reply-To: <52FDDD10.1050306@restena.lu> (Stefan Winter's message of "Fri, 14 Feb 2014 10:08:32 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/emu/N_sTqx-5LUIrVFgMhliD6KsAozY X-Mailman-Approved-At: Tue, 18 Feb 2014 16:37:35 -0800 Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" Subject: Re: [Emu] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:11:31 -0000 Hi. My life has been hectic, and I completely dropped the ball on this! Thanks for doing this. From nobody Tue Feb 18 16:37:49 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D051A0692; Tue, 18 Feb 2014 07:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5C0VS2oHqUD4; Tue, 18 Feb 2014 07:20:02 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 670A61A0209; Tue, 18 Feb 2014 07:20:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 61D4C20686; Tue, 18 Feb 2014 10:16:04 -0500 (EST) 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 5lSYdUSYgdp2; Tue, 18 Feb 2014 10:16:02 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-177-27-27.hsd1.ma.comcast.net [50.177.27.27]) (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; Tue, 18 Feb 2014 10:16:02 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B49F1837F1; Tue, 18 Feb 2014 10:19:53 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> <52FFF22A.5010802@deployingradius.com> <5301D017.8060302@restena.lu> <5302105C.6070103@deployingradius.com> Date: Tue, 18 Feb 2014 10:19:53 -0500 In-Reply-To: <5302105C.6070103@deployingradius.com> (Alan DeKok's message of "Mon, 17 Feb 2014 08:36:28 -0500") 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 Archived-At: http://mailarchive.ietf.org/arch/msg/emu/QfJyN0a5sHgYs27BrYLt0zKNRQA X-Mailman-Approved-At: Tue, 18 Feb 2014 16:37:38 -0800 Cc: abfab@ietf.org, "dime@ietf.org" , "" , "radext@ietf.org" Subject: Re: [Emu] [abfab] [radext] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 15:20:08 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> The idea was to allow *provisioning* of the Alan> Response/Identity. Automatically deriving it from the Alan> method-specific "user identity" is just as bad as Alan> automatically using a 3GPP identity. Unfortunately in contexts like ABFAB, you're only going to have one username. I appreciate that there are environments where you need a different outer username, but I think we want to be moving towards anonymous outer usernames derived from the realm, and I do not support a spec that would make that more difficult. From nobody Wed Feb 19 04:32:32 2014 Return-Path: X-Original-To: emu@ietfa.amsl.com Delivered-To: emu@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBBF1A047F; Wed, 19 Feb 2014 04:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVeakirrNeCU; Wed, 19 Feb 2014 04:32:24 -0800 (PST) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 71D691A05A6; Wed, 19 Feb 2014 04:32:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 6D31B3FB60; Wed, 19 Feb 2014 13:32:20 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TU9C1ZrztsuG; Wed, 19 Feb 2014 13:32:20 +0100 (CET) Received: from inf-205-172.inf.um.es (inf-205-172.inf.um.es [155.54.205.172]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon21.um.es (Postfix) with ESMTPSA id 662313FB5F; Wed, 19 Feb 2014 13:32:16 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Rafa Marin Lopez In-Reply-To: <52FDDD10.1050306@restena.lu> Date: Wed, 19 Feb 2014 13:32:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6347417E-BFC9-426E-B15F-09E9B1C50925@um.es> References: <20140214084329.10393.78739.idtracker@ietfa.amsl.com> <52FDDD10.1050306@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/emu/xddyjEmY6XSaQQV2Y4vQTqyW3y4 Cc: "radext@ietf.org" , abfab@ietf.org, "dime@ietf.org" , "" Subject: Re: [Emu] [abfab] New Version Notification for draft-winter-radext-populating-eapidentity-00.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 12:32:28 -0000 Hi Stefan: I have taken a look to this draft. Regarding the conversion to UTF-8 = nothing to say. Regarding=20 "1. The choice of identity to send in EAP-Response/Identity may have detrimental effects on the subsequent EAP type negotiation." as far as I remember, it was discussed long time ago as a problem of = network selection (http://tools.ietf.org/html/rfc5113). See section 2.2. = Identity Selection. Your approach here (if I properly understood) seems = to allow the user to try all the identities before reporting an error = (note that this may imply association/dissociation processes at = link-layer to re-start the whole authentication process). The approach = there is to provide the user with the required information to select the = right username.=20 In the particular case of WiFi networks it would be also good to take a = look to IEEE 802.11u and hotspot 2.0 (e.g. these slides, which you may = already know, are interesting = http://www.terena.org/activities/tf-mobility/meetings/26/07-11u-Dave.pptx)= Just my 0.02 cents. Best Regards. P.D: Btw, I agree with Alan: it would good to have a "roaming = inter-operations" WG.=20 P.D.2: Among other things, it would be also good if some information = about accessible realms from a NAS could be provided in a dynamic way to = the peer.=20 El 14/02/2014, a las 10:08, Stefan Winter = escribi=F3: > Hello, >=20 > I've just submitted an -00 on a topic that we've been struggling with = in > ABFAB recently (but which exists in every EAP-over-AAA scenario, not > limited to ABFAB). >=20 > = http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapiden= tity-00.txt >=20 > Abstract: > There are some subtle considerations for an EAP peer regarding the > content of the EAP-Response/Identity packet when authenticating with > EAP to an EAP server. This document describes two such > considerations and suggests workarounds to the associated problems. >=20 > The issue touches multiple areas and working groups (EAP, EAP methods, > RADIUS, Diameter) so I had to do a guesstimate for a proper home. I > would think radext is the best match, cc'ing abfab and dime, and also > emu even though it's shutting down). >=20 > If you recall those in-depth discussions about fixing either EAP = methods > to use UTF-8, or why EAP Identity would need to be restrained to UTF-8 > even if a method doesn't do it, then yes: the draft is about that. >=20 > In ABFAB, we added a ABFAB-specific band-aid sentence to RFC7057: > "Circumstances might require that applications need to perform > conversion of identities from an application specific character set to > UTF-8 or another character set required by a particular EAP method." >=20 > Which was enough to get the document through IESG, but this should > better be fixed more generally for every EAP use case; hence this new = draft. >=20 > It's short and concise - I'd appreciate if you could give it a read = and > comment. >=20 > If there's still free time on the agenda, I would also merrily discuss > it in London. >=20 > Greetings, >=20 > Stefan Winter >=20 > P.S.: Don't miss my other submission about an EAP Configuration File > Format, which I've been told to submit to ops-area/opsawg: >=20 > http://datatracker.ietf.org/doc/draft-winter-opsawg-eap-metadata/ >=20 > Annoucement here: > http://www.ietf.org/mail-archive/web/ops-area/current/msg01114.html >=20 > -------- Original Message -------- > Subject: New Version Notification for > draft-winter-radext-populating-eapidentity-00.txt > Date: Fri, 14 Feb 2014 00:43:29 -0800 > From: internet-drafts@ietf.org > To: Stefan Winter , "Stefan Winter" > >=20 >=20 > A new version of I-D, = draft-winter-radext-populating-eapidentity-00.txt > has been successfully submitted by Stefan Winter and posted to the > IETF repository. >=20 > Name: draft-winter-radext-populating-eapidentity > Revision: 00 > Title: Considerations regarding the correct use of = EAP-Response/Identity > Document date: 2014-02-14 > Group: Individual Submission > Pages: 6 > URL: > = http://www.ietf.org/internet-drafts/draft-winter-radext-populating-eapiden= tity-00.txt > Status: > = https://datatracker.ietf.org/doc/draft-winter-radext-populating-eapidentit= y/ > Htmlized: > = http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-00 >=20 >=20 > Abstract: > There are some subtle considerations for an EAP peer regarding the > content of the EAP-Response/Identity packet when authenticating with > EAP to an EAP server. This document describes two such > considerations and suggests workarounds to the associated problems. >=20 >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 >=20 > <0x8A39DC66.asc>_______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es -------------------------------------------------------