From nobody Mon Apr 4 05:25:55 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E150812D6B7 for ; Mon, 4 Apr 2016 05:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 8k8bs3xFmNLu for ; Mon, 4 Apr 2016 05:25:50 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [158.64.1.34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1D612D6AF for ; Mon, 4 Apr 2016 05:25:50 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::1]) by smtp.restena.lu (Postfix) with ESMTPSA id A1CACBB745; Mon, 4 Apr 2016 14:25:47 +0200 (CEST) To: Alan DeKok References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <57025D48.5020009@restena.lu> Date: Mon, 4 Apr 2016 09:25:44 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bfDNDkxlIX7mesoRtw2oA0X8NjdJqcX3D" Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 12:25:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bfDNDkxlIX7mesoRtw2oA0X8NjdJqcX3D Content-Type: multipart/mixed; boundary="ncierwgGwxvAJRgmIhxuWvBpscViksx03" From: Stefan Winter To: Alan DeKok Cc: radext@ietf.org Message-ID: <57025D48.5020009@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> In-Reply-To: <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> --ncierwgGwxvAJRgmIhxuWvBpscViksx03 Content-Type: multipart/mixed; boundary="------------050602030607060807080101" This is a multi-part message in MIME format. --------------050602030607060807080101 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > I suggest referencing RFC 7542, and using it's nomenclature. It refe= rs to "identifiers", as they identify a user. The strings isn't the user= 's "identity". As acknowledged in that document, EAP still uses "identit= y". > > My $0.02 is to use the following terminology: > > * user identifier - the NAI as per Section 1 of RFC 7542 > > * realm identifier - an NAI where the username portion is omitted, or i= s "anonymous" > as per Section 2.4 of RFC 7542. > > That qualification makes it clear *why* the identifiers are different= =2E There's no "inner" and "outer" identities. Just an identifier which= says "authentication is related to realm X". Realm X is then capable of= authenticating the user, because it has a user identifier. That nomenclature change is fine for me. I'll update the document with that in the next rev. > I think the document also needs a recommendation that all EAP identitie= s SHOULD use the NAI format. All new EAP methods SHOULD use UTF-8 for id= entifiers. > > I'd like to make those a MUST, but realistically, we can't. Why? In IETF91 Bernard Aboba was in the room and he actually suggested we do exactly that: EAP-Response/Identity should have been UTF-8 ever since, and not doing that was a mistake - so better to fix it late than never. We are on BCP track and probably we'll have an Updates: relationship with RFC3748 anyway. So it's not impossible to do it. Let's discuss this in the room on Friday. >> Method-specific outer identities are either >> >> * explicitly configured (e.g. string input UI: "Outer Identity")= >> >> * implicitly configured by copying the actual Method-specific >> (Inner) Identity > Along with encoding issues. e.g. EAP-MSCHAPv2 uses a method-specific= identity which is not UTF-8. Copying that field to an outer EAP-Identit= y is... problematic, to be polite. Yes, it's one of the purposes of the document to raise the awareness that a copy (without caring about encodings) is a very bad idea. The text meant to state (but it may have come across differently): inside your supplicant, you can copy around and store the config in any encoding you like. Only when you actually put the string onto the wire (i.e. use it to construct an EAP-Response/Identity) then you need to convert to UTF-8. This means that "what happens in the supplicant stays in the supplicant" - we are only imposing a rule on its outside obervable behaviour. This puts the gentlest-possible requirement on the supplicant: use whatever encodings you are most comfortable with locally - just be aware what that encoding is so that you can convert it to UTF-8 when you need it. >> * implicitly configured by copying the NAI realm of the Method- >> specific (Inner) Identity and prefixing it non-configurably >> with a fixed privacy-preserving local username part like >> "anonymous" or the empty string (see [RFC7542]) > I would call this the "realm" identifier. And make it clear that the= "outer" EAP-Identity SHOULD map to the "realm identifier", but it doesn'= t always... which is why we give them different names. I'll try to reformulate in the next rev. If you don't like the result, text suggestions will be welcome :-) > >> Please let me know if this makes things clearer. > Any attempt to make this clearer is better than the mess we have now.= Good, that sets a low bar :-) Stefan > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------050602030607060807080101 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/MacGPG2 v2 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----- --------------050602030607060807080101-- --ncierwgGwxvAJRgmIhxuWvBpscViksx03-- --bfDNDkxlIX7mesoRtw2oA0X8NjdJqcX3D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXAl1JAAoJEMDeajWKOdxmMXUP/j95XFvH87RlZD7Sid19U7z6 FAv4gy3ESDkjDdc2D1fs0yOZUetQ+LG+kCv48MnHHpQI1l5e+8SReUy4sS+jKK8D gGPGDqZpJdn4thYXUortVtlSJHYq/HQPr3JBXIYGVYe4mvTK3e8tfIf/NUgzdOAh q5GrAy+ihdnNnJta/4wenQM0OCDk2sq8LiGvZ3LRuNIVXOi3xkoMZauCj7AUAuuT E9YhyAm0yyicaVgKM+hVRMhmlGZju7aojG2bKJTfKiW9jpAWW0pmPQuFYZgKtJI3 vnOBTqMQRMwoofB1VqkRX0kS1uxqbZFZo9g9e+qYVs4B1GASjZynKT0Mt4DBCHP7 Df9SsaMnkpN2fnjZ4nGJml5hylFTbMXUC4qjESHZIODZd/H2Dv1tk0Nka1bKsj77 /vLF8qm2FqXekePDu46KfQ61K3wMGvEJV6/tKk0rgUm86yS6S6CASW5nW4z22See CfRVbO1KAav4NF3gk6y//eqQgWORclY6zWLxlZwpynq/lQA6e2oRX8JQ/bEL111c L6EA24rjiRnPFwCwRR63VHCcJDIDbIDIvcML/WSqUaN7P7ZK0ZwpXmVA/lEtGQt0 x5juDrs7a7euoX6C/636n6gak4FFXOdmQYHzFnQWzv+1mf4eIo+CaRR/pmb1EFVX IsFLZU//FrzsYTCBc8To =U5M8 -----END PGP SIGNATURE----- --bfDNDkxlIX7mesoRtw2oA0X8NjdJqcX3D-- From nobody Mon Apr 4 05:52:19 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 849DA12D6D0 for ; Mon, 4 Apr 2016 05:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 Y2cxsi4wBi-8 for ; Mon, 4 Apr 2016 05:52:15 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A31D12D163 for ; Mon, 4 Apr 2016 05:52:15 -0700 (PDT) Received: from dhcp-9b1e.meeting.ietf.org (dhcp-9b1e.meeting.ietf.org [31.133.155.30]) by smtp.restena.lu (Postfix) with ESMTPSA id 704B9BB73F; Mon, 4 Apr 2016 14:52:12 +0200 (CEST) To: Alan DeKok References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <57026378.1020702@restena.lu> Date: Mon, 4 Apr 2016 09:52:08 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oXHSXkBR34oh4TGmWGlMa2UTk1UX0A6ta" Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 12:52:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --oXHSXkBR34oh4TGmWGlMa2UTk1UX0A6ta Content-Type: multipart/mixed; boundary="xjUrHmr9VW1wlI21Ivr5EpoX2reTuT0RE" From: Stefan Winter To: Alan DeKok Cc: radext@ietf.org Message-ID: <57026378.1020702@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> In-Reply-To: <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> --xjUrHmr9VW1wlI21Ivr5EpoX2reTuT0RE Content-Type: multipart/mixed; boundary="------------050807080303030005050004" This is a multi-part message in MIME format. --------------050807080303030005050004 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, >> It really depends on the point of view, I think. Those outer IDs can b= e >> configured per method, and they are dependent on the inner ID of "thei= r" >> method - they need to have a routing component which matches the inner= >> ID so that the request terminates at the correct EAP server. > Define "matches". i.e. how UTF-8 identifiers can be "matched" to ide= ntifiers in other character sets. > > It's not easy. > > My $0.02 is that we have to be very careful about terminology here. = And make it clear in the document *why* we're being clear on terminology.= There is a string A for the realm identifier. There is a string B for the user identifier in a given EAP method. There is a dependency between the two: A must be chosen so that the EAP method which uses B will actually reach an EAP server which is prepared to handle B. If "match" is not a good choice of word, maybe "dependency between" is? The consequence, no matter the chosen word, is: when multiple EAP methods are configured (there are multiple instances of B) then there may need to be more than instance of A as well. Point taken: A is not part of the EAP method payload. But it needs to exist, and be available for transmission, and there has to be a possibility to configure more than one instance of A, depending on which B is tried in the method. Many UIs pack the A string into the configuration items for the EAP method around B. Granted, that's not the conceptually the cleanest place, but it's a viable choice (but we don't mind UI anyway). There is not necessarily a 1:1 relationship (multiple instances of B might share a common A) but there is an n:m relationship with n < m. That's as close to a definition I get right now. >> It's true that they are not actually used inside the EAP method's >> payload on the wire; they are rather an abstract property of the EAP >> method that is solely used to populate the choice of candidates for >> EAP-Response/Identity and for transmission before the actual EAP metho= d >> payload is underway. >> >> Formulation suggestions warmly welcome. > I like my distinction between the "realm identifier" and "user identi= fier". The "user identifier" can be method specific, but SHOULD be the N= AI.=20 I think the discussion with Sam has gotten to a point where the following was agreed: inner method identity SHOULD be the NAI for new EAP methods, and where pe= rmitted by existing EAP methods inner method identity SHOULD otherwise be taken from the existing EAP met= hod, which is likely NOT UTF-8 > The "realm identifier" MUST be an NAI with no user name portion, or a = user name of "anonymous". Well the empty string is a good suggestion, but why is "anonymous" better than "someone", "wonttell", "secret" or "streng-geheim"? Is there any specific reason why we should put strong wording around one particular English string? An EAP server operator here in Buenos Aires might want "anonimico" or so :-) > That avoids any "inner" and "outer" discussion, which is also method-= specific. > > i.e. an EAP method has a "user identifier" which is placed into a met= hod-specific identity field. An EAP method also has a "realm identifier"= , which identifies the realm for which the EAP method is relevant. Where= the EAP method has "inner" and "outer" identities, the realm identifier = MUST be used for the outer identity, and the user identifier MUST be used= for the inner identity. > > When we re-euse existing terminology for these identifiers, we have t= o explain in each case why the EAP-Identity here is not, in fact the same= as the EAP-Identity in another situation... even though they have the sa= me name. That's confusing. Yes, point taken. Terminology update pending. >> Yes, I don't like that either; the NAI is a good choice if you have a >> choice - but there are situations where you don't. I think the later >> points made in the thread provide a clear insight here: SHOULD, unless= >> your method architecture demands otherwise. > And where there are inner/outer identities, the outer identity / real= m identifier MUST be an NAI. Here again I think we discussed that a MUST is too much. It would be more like a SHOULD, unless local requirements mandate otherwise. I believe we shold acknowledge and accomodate the reality of DOMAIN/user in some places out there. Greetings, Stefan Winter --------------050807080303030005050004 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/MacGPG2 v2 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----- --------------050807080303030005050004-- --xjUrHmr9VW1wlI21Ivr5EpoX2reTuT0RE-- --oXHSXkBR34oh4TGmWGlMa2UTk1UX0A6ta Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXAmN4AAoJEMDeajWKOdxmRjAQAKJRaNJDtxrBtxVvKidq7MWM wHz3/rd3oICkfEgKy6241HXbTMqqAD8Vx+P0GeInUPD06de3uLY1ZYAgVFiRAEGf 94HDW5RF6oYFbVnqJ1FhDysH8Sd9FAghqEUCJbu3lm9oQddL8OSodzULFWt1mGS+ BYoUk4dbgM2hRif8TFWZChpVSwPhCK3NQ7zZ5t5RFVvBRuNF6Zzk8pdgQtPnOzUW 7rZGyGOGdMhYm7PYyCxoKObqLM2X32oQvcOqu/y3VUgvjTJ4vLM/tWPkUCWAP9G2 qf4Rc8G5cNiI2WGX2NqFarJ2nFcByiggvZhxi9jNHVzTBs1SbXnKhSB/SlYwMgRs CHelUzUGJg3l7HXarC8iLrAlw8cUGeu8Ro5TQ6nCRP+CVn7zVkx4Y6yK4LiYcxbJ Lt5iei5qu2BYAwNycIUyWzFXnIXZjnK6g/wzdPlqoN8pIWCUYk7g+0QgWoR9PAHa seXDuEEorMNQ6vj9OL4TVEbi8d0i0qBASCLN+W99qado2qeXEUVAOqAwST1l36Cz D+iY3FEOAJ3c9dAlLN4QZF7g+SGVeaeHI1BPmTKyxvUId220idlsCbQoVPm8QAjM fb4dGI0HdIvmwTdespwpXx4Z3iW6rQNl48gHZO3RK5wbA0Szv6sljZ5OWwcRJvTB JHWgovPZn3VB/bWcLJQl =CYBb -----END PGP SIGNATURE----- --oXHSXkBR34oh4TGmWGlMa2UTk1UX0A6ta-- From nobody Mon Apr 4 06:06:46 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB7812D11B for ; Mon, 4 Apr 2016 06:06:44 -0700 (PDT) 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=unavailable autolearn_force=no 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 M9M3wGZu9DlS for ; Mon, 4 Apr 2016 06:06:43 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 28D4212D159 for ; Mon, 4 Apr 2016 06:00:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 3AB2C1911; Mon, 4 Apr 2016 13:00:02 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VkkSdSXPoq3K; Mon, 4 Apr 2016 13:00:02 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id A92B7BEE; Mon, 4 Apr 2016 13:00:01 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <57025D48.5020009@restena.lu> Date: Mon, 4 Apr 2016 09:00:18 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <57025D48.5020009@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 13:06:45 -0000 On Apr 4, 2016, at 8:25 AM, Stefan Winter wrote: > Why? In IETF91 Bernard Aboba was in the room and he actually suggested > we do exactly that: EAP-Response/Identity should have been UTF-8 ever > since, and not doing that was a mistake - so better to fix it late than > never. I'm OK with that. > The text meant to state (but it may have come across differently): > inside your supplicant, you can copy around and store the config in any > encoding you like. Only when you actually put the string onto the wire > (i.e. use it to construct an EAP-Response/Identity) then you need to > convert to UTF-8. That makes sense. > This means that "what happens in the supplicant stays in the supplicant" > - we are only imposing a rule on its outside obervable behaviour. This > puts the gentlest-possible requirement on the supplicant: use whatever > encodings you are most comfortable with locally - just be aware what > that encoding is so that you can convert it to UTF-8 when you need it. I can only hope that supplicant vendors read, understand, and update. Alan DeKok. From nobody Mon Apr 4 06:08:14 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A624C12D179 for ; Mon, 4 Apr 2016 06:08:12 -0700 (PDT) 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 autolearn_force=no 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 wai3DXUI4NtZ for ; Mon, 4 Apr 2016 06:08:11 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id EC0F512D146 for ; Mon, 4 Apr 2016 06:08:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 5AFE51B19; Mon, 4 Apr 2016 13:08:10 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vJa2BjyGqLf; Mon, 4 Apr 2016 13:08:10 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id CF239BEE; Mon, 4 Apr 2016 13:08:09 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <57026378.1020702@restena.lu> Date: Mon, 4 Apr 2016 09:08:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5565C2F8-5D21-4D39-B914-1645B4185F3E@deployingradius.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 13:08:12 -0000 On Apr 4, 2016, at 8:52 AM, Stefan Winter = wrote: > There is a string A for the realm identifier. > There is a string B for the user identifier in a given EAP method. >=20 > There is a dependency between the two: A must be chosen so that the = EAP > method which uses B will actually reach an EAP server which is = prepared > to handle B. >=20 > If "match" is not a good choice of word, maybe "dependency between" = is? Yes. "Match" implies string comparison. Which doesn't work for UTF-8 = to non-UTF-8 strings. If both strings are UTF-8, then in general, A will be a subset of B. = However, one realm MAY have multiple user identifier spaces. This is = because the realm identifier will identify an organization, and the user = identifier may identity a subset of that organization. e.g. "example.com" may have users "user@sales.example.com", = "ceo@example.com", and "others@example.org" (if .com bought .org) > The consequence, no matter the chosen word, is: when multiple EAP > methods are configured (there are multiple instances of B) then there > may need to be more than instance of A as well. Yes. Getting the dependency here is critical. My thoughts are that = the key should be the user identifier. When authenticating user X, = realm Y and EAP method E must be used. > Point taken: A is not part of the EAP method payload. But it needs to > exist, and be available for transmission, and there has to be a > possibility to configure more than one instance of A, depending on = which > B is tried in the method. Many UIs pack the A string into the > configuration items for the EAP method around B. Granted, that's not = the > conceptually the cleanest place, but it's a viable choice (but we = don't > mind UI anyway). >=20 > There is not necessarily a 1:1 relationship (multiple instances of B > might share a common A) but there is an n:m relationship with n < m. Yes. But that also means the dependency must be B -> A, not A -> B. If the dependency is B -> A, then multiple B's share an A, and it = doesn't really matter, because no one can tell. If the dependency is A -> B, then when you choose A, you have no real = idea which B to use. > I think the discussion with Sam has gotten to a point where the > following was agreed: >=20 > inner method identity SHOULD be the NAI for new EAP methods, and where = permitted by existing EAP methods >=20 > inner method identity SHOULD otherwise be taken from the existing EAP = method, which is likely NOT UTF-8 Yes. > Well the empty string is a good suggestion, but why is "anonymous" > better than "someone", "wonttell", "secret" or "streng-geheim"? Is = there > any specific reason why we should put strong wording around one > particular English string? An EAP server operator here in Buenos Aires > might want "anonimico" or so :-) The realm identifier SHOULD be "@realm". "anonymous" is allowed by = the NAI RFC for backwards compatibility, but is deprecated. "anonymous@" SHOULD NOT be used. > Here again I think we discussed that a MUST is too much. It would be > more like a SHOULD, unless local requirements mandate otherwise. I > believe we shold acknowledge and accomodate the reality of DOMAIN/user > in some places out there. I'm inclined to disagree. The realm identifier MUST be an NAI. It's for public consumption. = The user identifier can have a different form, as it's usually buried = inside of an inner-tunnel exchange. Only the end user and home EAP = server see it. Alan DeKok. From nobody Tue Apr 5 08:48:25 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CABA12D5C0 for ; Tue, 5 Apr 2016 08:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 woFGbwcC1A2V for ; Tue, 5 Apr 2016 08:48:21 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [158.64.1.34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4887C12D615 for ; Tue, 5 Apr 2016 08:48:18 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::1]) by smtp.restena.lu (Postfix) with ESMTPSA id ECA93BB731; Tue, 5 Apr 2016 17:48:14 +0200 (CEST) To: Alan DeKok References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <5565C2F8-5D21-4D39-B914-1645B4185F3E@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <5703DE3A.2070705@restena.lu> Date: Tue, 5 Apr 2016 12:48:10 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5565C2F8-5D21-4D39-B914-1645B4185F3E@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ttsj2wDip2wpxSEeWUU5k3NPpoJREMQxN" Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 15:48:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ttsj2wDip2wpxSEeWUU5k3NPpoJREMQxN Content-Type: multipart/mixed; boundary="NuCeV4LKflakpd1xmwK5IaAttDBOOQ4mC" From: Stefan Winter To: Alan DeKok Cc: radext@ietf.org Message-ID: <5703DE3A.2070705@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <5565C2F8-5D21-4D39-B914-1645B4185F3E@deployingradius.com> In-Reply-To: <5565C2F8-5D21-4D39-B914-1645B4185F3E@deployingradius.com> --NuCeV4LKflakpd1xmwK5IaAttDBOOQ4mC Content-Type: multipart/mixed; boundary="------------040008050502010304030801" This is a multi-part message in MIME format. --------------040008050502010304030801 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, good... we seem to be converging on most points! >> There is a string A for the realm identifier. >> There is a string B for the user identifier in a given EAP method. >> >> There is a dependency between the two: A must be chosen so that the EA= P >> method which uses B will actually reach an EAP server which is prepare= d >> to handle B. >> >> If "match" is not a good choice of word, maybe "dependency between" is= ? > Yes. "Match" implies string comparison. Which doesn't work for UTF-= 8 to non-UTF-8 strings. > > If both strings are UTF-8, then in general, A will be a subset of B. = However, one realm MAY have multiple user identifier spaces. This is be= cause the realm identifier will identify an organization, and the user id= entifier may identity a subset of that organization. > > e.g. "example.com" may have users "user@sales.example.com", "ceo@exam= ple.com", and "others@example.org" (if .com bought .org) Yes. I'll make that clear in the next rev. It's why I wrote n < m is a possibility. Multiple configured EAP methods with different user identifiers may share a commonly usable realm identifier. This is where EAP type negotiation can be of help. The worries in the I-D are mostly about the cases where different realm idenfiers need to be used; then they all need to be tried. >> The consequence, no matter the chosen word, is: when multiple EAP >> methods are configured (there are multiple instances of B) then there >> may need to be more than instance of A as well. > Yes. Getting the dependency here is critical. My thoughts are that = the key should be the user identifier. When authenticating user X, realm= Y and EAP method E must be used. The one thing that worries me here is that you introduce the new concept of a "user"; and that you seem to imply that X -> E -> Y is a deterministic choice. While E -> is a clear "follows from" arrow, the X -> E is not: a user (as in "human being") may have multiple credentials, and multiple configured EAP types on his machine. Say, I have a client certificate for EAP-TLS, a username/password for EAP-TTLS and a SIM card for EAP-AKA'. In that case, user X does not yield a unique choice for E. It is up to the user's preference, or the network's acceptance of credential types which one to use. I'd prefer to leave the notion of a user out of the document. So far, we are only talking about multiple EAP types which are configured on a system. Whether they all relate to the same human being is not very relevant. The choice of EAP method is largely out of the hands of the user - he has all those types configured in the hope that one of them gets him online. There may be a preference configured on the system, and if yes, that should be honoured. But we can talk about the config item "preference" without introducing the notion of a user. >> Point taken: A is not part of the EAP method payload. But it needs to >> exist, and be available for transmission, and there has to be a >> possibility to configure more than one instance of A, depending on whi= ch >> B is tried in the method. Many UIs pack the A string into the >> configuration items for the EAP method around B. Granted, that's not t= he >> conceptually the cleanest place, but it's a viable choice (but we don'= t >> mind UI anyway). >> >> There is not necessarily a 1:1 relationship (multiple instances of B >> might share a common A) but there is an n:m relationship with n < m. > Yes. But that also means the dependency must be B -> A, not A -> B. > > If the dependency is B -> A, then multiple B's share an A, and it doe= sn't really matter, because no one can tell. > > If the dependency is A -> B, then when you choose A, you have no real= idea which B to use. This one is clear: of course you need to choose B first, and then use the A that corresponds to this choice. >> I think the discussion with Sam has gotten to a point where the >> following was agreed: >> >> inner method identity SHOULD be the NAI for new EAP methods, and where= permitted by existing EAP methods >> >> inner method identity SHOULD otherwise be taken from the existing EAP = method, which is likely NOT UTF-8 > Yes. > >> Well the empty string is a good suggestion, but why is "anonymous" >> better than "someone", "wonttell", "secret" or "streng-geheim"? Is the= re >> any specific reason why we should put strong wording around one >> particular English string? An EAP server operator here in Buenos Aires= >> might want "anonimico" or so :-) > The realm identifier SHOULD be "@realm". "anonymous" is allowed by t= he NAI RFC for backwards compatibility, but is deprecated. > > "anonymous@" SHOULD NOT be used. Ok. >> Here again I think we discussed that a MUST is too much. It would be >> more like a SHOULD, unless local requirements mandate otherwise. I >> believe we shold acknowledge and accomodate the reality of DOMAIN/user= >> in some places out there. > I'm inclined to disagree. > > The realm identifier MUST be an NAI. It's for public consumption. T= he user identifier can have a different form, as it's usually buried insi= de of an inner-tunnel exchange. Only the end user and home EAP server se= e it. Public consumption is a big word: EAP is often used within closed enterprise environments. EAP methods may only travel to a single AAA/EAP server without any choices in routing. In those cases, the form of the realm identifier is irrelevant; all identifiers get routed along the "one and only" default route. I totally agree that the idenfiers really should be a NAI as soon as roaming comes into play. The wording "MUST" without the qualifier ... "in a roaming environment" (= or "if the EAP session is sent to a different entity") is then too harsh.= I'd be happy to add the MUST with that extra qualifier; and to leave clo= sed enterprise EAP deployments alone. Greetings, Stefan Winter=20 --------------040008050502010304030801 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/MacGPG2 v2 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----- --------------040008050502010304030801-- --NuCeV4LKflakpd1xmwK5IaAttDBOOQ4mC-- --Ttsj2wDip2wpxSEeWUU5k3NPpoJREMQxN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXA946AAoJEMDeajWKOdxm2WgQAMjLBL27Wn9+U3grVnj2zpvQ SngAfulUxzjSxOL1167lk7B6wi6McAtDFLhtQI7ZozqQ4Ao7Rws+TNZnjhbnEJYW 4M/YJga2qESK3EwhcfUxxh3YZGOTJE56EpPkzyRse0NpvKi1GlXU0ifm4+OC8Qgr qsTuVhkvvurbhUYfsEhO0fpfWZFpQjX6r3/UdVOqZTak/zcbJuvVQ3O8uWsuBLjq 3AhZoAqTSGmgaTJv9SFES/TcQdN3wlCGlPTDmLxwH51xpAKUeCn/MRCfWpdrrwmi bS+c5QmTqD+UOUC1c+7YSp/0untgq+kOgEgnGNvX8hENZaEPzC02Cdu084vymnbE dLTq1MtFJqDMbDvJVp8LuOdXAmq7q1LAIwn1Xx58+BsLwnqMMm9eL3kBvjMy/tx4 NS2FamIsB9TiajN0zHwQRjBvnN0pNJHAVVGzOXLzR6O3BYsQBo0u87E6iVeSgXFz 6fGcYUftHKvxUf5z8+7c3HlbHQegZKjoagAGuESi5jbC8do5dAcEcGWmN8YZs4tR F5TwvqoKr0y32t8eMjLFrzCvDfkzK/iHcgf5TUot1MxqBEllpkZwyUNlmLQOcrpc /LrnFHrf0jwfkeuTmNAw4YeA81Xux4IWEeIgGL98y4soqpQ1mGwugyQEO2Kya+l6 MKShoUIJJy+E40Z7jnho =itpO -----END PGP SIGNATURE----- --Ttsj2wDip2wpxSEeWUU5k3NPpoJREMQxN-- From nobody Tue Apr 5 14:23:22 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA6612D88B for ; Tue, 5 Apr 2016 14:23:21 -0700 (PDT) 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 autolearn_force=no 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 Vur16os6FVtL for ; Tue, 5 Apr 2016 14:23:18 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 185A112D11E for ; Tue, 5 Apr 2016 14:23:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 038551AB6; Tue, 5 Apr 2016 21:23:15 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0rlAaWk8qMl; Tue, 5 Apr 2016 21:23:14 +0000 (UTC) Received: from [192.168.120.60] (OTWAON1140W-LP140-03-1176332297.dsl.bell.ca [70.29.104.9]) by mail.networkradius.com (Postfix) with ESMTPSA id 92E44221; Tue, 5 Apr 2016 21:23:14 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <5703DE3A.2070705@restena.lu> Date: Tue, 5 Apr 2016 17:23:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <5565C2F8-5D21-4D39-B914-1645B4185F3E@deployingradius.com> <5703DE3A.2070705@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 21:23:21 -0000 On Apr 5, 2016, at 11:48 AM, Stefan Winter = wrote: > The one thing that worries me here is that you introduce the new = concept > of a "user"; and that you seem to imply that X -> E -> Y is a > deterministic choice. "entity being authenticated", commonly user or device. > Say, I have a client certificate for EAP-TLS, a username/password for > EAP-TTLS and a SIM card for EAP-AKA'. All for the same realm and SSID? This is where it gets vague... there should only be one EAP = configuration for a particular way of getting network access. > In that case, user X does not yield a unique choice for E. It is up to > the user's preference, or the network's acceptance of credential types > which one to use. I'd be wary of allowing multiple EAP configurations for one network = access method. It involves users, who we know make mistakes. > I'd prefer to leave the notion of a user out of the document. So far, = we > are only talking about multiple EAP types which are configured on a > system. Whether they all relate to the same human being is not very > relevant. The choice of EAP method is largely out of the hands of the > user - he has all those types configured in the hope that one of them > gets him online. There may be a preference configured on the system, = and > if yes, that should be honoured. But we can talk about the config item > "preference" without introducing the notion of a user. Yes. > Public consumption is a big word: EAP is often used within closed > enterprise environments. EAP methods may only travel to a single = AAA/EAP > server without any choices in routing. In those cases, the form of the > realm identifier is irrelevant; all identifiers get routed along the > "one and only" default route. What people do in their own networks is their own business. But there = is a definite overlap with public networks. If private enterprises are *at any point* interested in connecting = their networks to a public infrastructure, they should be compatible = with that infrastructure from day 1. Migration from "internal" = identifiers to "public" identifiers is a nightmare. i.e. there is no large benefit in using identifiers in an internal = format. Therefore, we recommend using ones which are compatible with = public networks. > I totally agree that the idenfiers really should be a NAI as soon as > roaming comes into play. Even before. Migration is nightmare. These people shouldn't think = that they're smarter than everyone else on the planet. They're not. = They should use NAIs, because it's the best thing we know. > The wording "MUST" without the qualifier ... "in a roaming = environment" (or "if the EAP session is sent to a different entity") is = then too harsh. I'd be happy to add the MUST with that extra qualifier; = and to leave closed enterprise EAP deployments alone. Sure. And say that close enterprise deployments SHOULD use the NAI, for = reasons outlined above. Alan DeKok. From nobody Wed Apr 6 14:56:29 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCCD12D53D for ; Wed, 6 Apr 2016 14:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 PLfa8IrYZo0w for ; Wed, 6 Apr 2016 14:56:25 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8347F12D1E0 for ; Wed, 6 Apr 2016 14:56:25 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::1]) by smtp.restena.lu (Postfix) with ESMTPSA id 322D3BB725; Wed, 6 Apr 2016 23:56:20 +0200 (CEST) To: Alan DeKok References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <5565C2F8-5D21-4D39-B914-1645B4185F3E@deployingradius.com> <5703DE3A.2070705@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <570585FA.9080309@restena.lu> Date: Wed, 6 Apr 2016 18:56:10 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cgoF7eFlqI1VGPBJ0aMVjTilpljjVW2OG" Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 21:56:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cgoF7eFlqI1VGPBJ0aMVjTilpljjVW2OG Content-Type: multipart/mixed; boundary="WMDcX9EVhAus8502Axiq0x0BoKCO1oV3Q" From: Stefan Winter To: Alan DeKok Cc: radext@ietf.org Message-ID: <570585FA.9080309@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <5565C2F8-5D21-4D39-B914-1645B4185F3E@deployingradius.com> <5703DE3A.2070705@restena.lu> In-Reply-To: --WMDcX9EVhAus8502Axiq0x0BoKCO1oV3Q Content-Type: multipart/mixed; boundary="------------060603040806030600010703" This is a multi-part message in MIME format. --------------060603040806030600010703 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > On Apr 5, 2016, at 11:48 AM, Stefan Winter w= rote: >> The one thing that worries me here is that you introduce the new conce= pt >> of a "user"; and that you seem to imply that X -> E -> Y is a >> deterministic choice. > "entity being authenticated", commonly user or device. > >> Say, I have a client certificate for EAP-TLS, a username/password for >> EAP-TTLS and a SIM card for EAP-AKA'. > All for the same realm and SSID? > > This is where it gets vague... there should only be one EAP configura= tion for a particular way of getting network access. WI-Fi gets more complicated over time. Thinking in SSID only is not future-proof :-/ Passpoint brought the new capability of identifying a joinable network not by SSID, but by many other properties; for the sake of my argument below let's look at the one which is a mobile operator's MCC/MNC code. Assume there is a Wi-Fi network with an SSID "eduroam" and a Passpoint MCC/MNC roaming code of 123/45. Assume further that you have a PEAP credential for eduroam and a SIM card of the 123/45 operator. The device now sees the network, and realises that it can join with PEAP because the SSID is "eduroam" and with EAP-AKA' because the MCC/MNC code matches the SIM credentials. Which one is actually chosen? Who knows. So here we see one network with two usable EAP types for the same entity that wants to connect. This is not very far-fetched: it's going to be somewhat common whenever a Wi-Fi offloading deal with a mobile operator is in place. >> In that case, user X does not yield a unique choice for E. It is up to= >> the user's preference, or the network's acceptance of credential types= >> which one to use. > I'd be wary of allowing multiple EAP configurations for one network a= ccess method. It involves users, who we know make mistakes. Luckily, it *may* be deterministic without the user. I believe the Passpoint specs state that Passpoint properties are supposed to "beat" normal SSID discovery. In the example above, this /probably/ means that the device will always join with EAP-AKA'. This is not as deterministic as it would seem though: it's easy to construct more pathological cases. Like a network which has the MCC/MNC passpoint property (EAP-AKA') but also a Roaming Consortium OI passpoint property for a non-cellular roaming consortium of choice (say, with a EAP-TLS client certificate). Now there are two passpoint properties, attached to two different EAP types. Who wins? I don't think this is well-defined. But I'd be happy to be proven wrong if anyone happens to know. In any case, a pool of more than one EAP type for more than one network is something that should be considered. >> I'd prefer to leave the notion of a user out of the document. So far, = we >> are only talking about multiple EAP types which are configured on a >> system. Whether they all relate to the same human being is not very >> relevant. The choice of EAP method is largely out of the hands of the >> user - he has all those types configured in the hope that one of them >> gets him online. There may be a preference configured on the system, a= nd >> if yes, that should be honoured. But we can talk about the config item= >> "preference" without introducing the notion of a user. > Yes. > >> Public consumption is a big word: EAP is often used within closed >> enterprise environments. EAP methods may only travel to a single AAA/E= AP >> server without any choices in routing. In those cases, the form of the= >> realm identifier is irrelevant; all identifiers get routed along the >> "one and only" default route. > What people do in their own networks is their own business. But ther= e is a definite overlap with public networks. > > If private enterprises are *at any point* interested in connecting th= eir networks to a public infrastructure, they should be compatible with t= hat infrastructure from day 1. Migration from "internal" identifiers to = "public" identifiers is a nightmare. > > i.e. there is no large benefit in using identifiers in an internal fo= rmat. Therefore, we recommend using ones which are compatible with publi= c networks. > >> I totally agree that the idenfiers really should be a NAI as soon as >> roaming comes into play. > Even before. Migration is nightmare. These people shouldn't think = that they're smarter than everyone else on the planet. They're not. The= y should use NAIs, because it's the best thing we know. > >> The wording "MUST" without the qualifier ... "in a roaming environment= " (or "if the EAP session is sent to a different entity") is then too har= sh. I'd be happy to add the MUST with that extra qualifier; and to leave = closed enterprise EAP deployments alone. > Sure. > > And say that close enterprise deployments SHOULD use the NAI, for rea= sons outlined above. Ok. Greetings, Stefan Winter > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------060603040806030600010703 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/MacGPG2 v2 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----- --------------060603040806030600010703-- --WMDcX9EVhAus8502Axiq0x0BoKCO1oV3Q-- --cgoF7eFlqI1VGPBJ0aMVjTilpljjVW2OG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXBYYAAAoJEMDeajWKOdxm9GMQALrTq1HAkOeAx9trHpiUbTBT mYpsT18MX54Mo0u1ZFPG6Lh3cwIjmqTRpqRHS6GnIEoWKxebP9sGToAmt7mYBbvG yHATp3ZFo0gvwSBGWtCPOm552HxvIc0eJI1yHLCrJ09duURrz9ujOFAATZea7r1S T/PE/2tjOIlDSJ1Fas2bbf+hRTOGCWg/bjUBXFEfA+6lLykjtcnqn4glQsnbZb1G wa0y5vomV2BlsINa9PbkWUDj+HqpbtdO8QWVOttU85k9zgGpq79fXNq64eAM9sIX BMoUAgDR1RslAztqodY+XI1+Q4lrVQTDYv+jB3ZWSCrhZB+Vyv9VXXAODjiv0YBq LBQvHkyq3+LxGl8DbihW/NIxfvQveObSkg2ZIXDaakgoVVDYL4WIMjh/charn69g 7tQJxYyGC62+XjrR8pYYG2y7gxeS6QvAyaLlcgSSSEZJJWPwcWTreM7dq5vXFzz3 vQ1u/BurjmB5rLFzrLwZZKNiaIOo7TWvhYkpYZQPP58MOSf5ufEImV+630QotZpb GapRhWqBc6cRKodSN5JAgzvvU8ZjEaEcq8EQjR7jZA18rZKsMDSfnAa+WjIapqqY 54l/GcrmJyfBgsfRiX2qdQZf/dwDFX2CWWxG/auTTMfd+nuL2R/pkhhKB1r53+vX vKr1RyXMpItbMKdqnj5W =C0kc -----END PGP SIGNATURE----- --cgoF7eFlqI1VGPBJ0aMVjTilpljjVW2OG-- From nobody Wed Apr 6 16:01:51 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1633E12D6C8 for ; Wed, 6 Apr 2016 16:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qDbKLi9S1rqL for ; Wed, 6 Apr 2016 16:01:48 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4483012D635 for ; Wed, 6 Apr 2016 16:01:48 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id n1so42483571pfn.2 for ; Wed, 06 Apr 2016 16:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rE9OTnWQinS/bfKqKQwgVXOC3uWhQakbE+OnChO5Zxg=; b=CHidpIDN0MKdpwkPfSRD7nJlb89kuE0cAVD/EsvqdYZNMTWw011l4hnpSlMNWgDXEC hqajWWpwN4HwpBna4/fIkQPjxcPQCCzkTgWTuabJNeAJbfRDsPREJWWqaNDiW7z1Se27 k/xM7Mqv+jW2vHWAq6UWqru/w9BrbmgD5I8pcMNPdvyXLX/+vC/smKh55CLABARbi50s I3CV7tLY6sjRf6jUosP/vvlDvp3gWTChvn0YX74Gi/f8WKDzZKALDDKlrzA37mlYzAM6 gi22R8zgs9OG6hjSK2RfVLuidLqzex/Y8sxQyJUKEIIj7zD8QuYk2SMQ+iVakf1ahdxL /0HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rE9OTnWQinS/bfKqKQwgVXOC3uWhQakbE+OnChO5Zxg=; b=iglpL4HqXM6rJX7+D6taKPPSAr0SO8DaRa0odXQs3qeymvPSKBwHRWXA0xxWO1/01b fqL9YpqpBiPyzbt1BqN944SFQZENI4qYLbaawr7QPxqDY6aA1rxEBOuf8d1jbux+q+Od tSyKzXfd74Bisw2/hLTLZnZjCD/E2WGTqBjh3Xtq+xCKvxD3sSTFcXU4eXILnPlAGR66 IcNG4TNVt4E0A4lkzv13nD9JYscFzAwrOM0SzakxPGNN/pa+tn0gDg15YhsFJCP2O4v1 I82WIPXyeus4ud3hNZfcm7DQIp6c/AAq9OIKTDIQ8IRKCo78OKsVOp0Aq/WHvwvalg9P C7kg== X-Gm-Message-State: AD7BkJLKyfyCOwMYDEgIkcrtneEOBBLnYoGRMbvIbUk/1eR9F6umZLcINDTFXVvPSiZh6w== X-Received: by 10.98.79.203 with SMTP id f72mr42347545pfj.102.1459983707790; Wed, 06 Apr 2016 16:01:47 -0700 (PDT) Received: from [192.168.1.104] (c-71-227-237-49.hsd1.wa.comcast.net. [71.227.237.49]) by smtp.gmail.com with ESMTPSA id ko9sm7228985pab.37.2016.04.06.16.01.47 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 16:01:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Wed, 6 Apr 2016 16:01:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <139777BD-37D5-4950-9409-4ADC3608C6AA@gmail.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> To: Sam Hartman Archived-At: Cc: Winter Stefan , radext@ietf.org, Alan DeKok Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 23:01:50 -0000 On Mar 21, 2016, at 9:09 AM, Sam Hartman w= rote: >=20 > I am really sad to read this discussion. > Unfortunately, I'm moving away from the IETF, and I am not going to have > the energy to participate in this, but I think we're going to make a > huge mess with this approach. [BA] I completely agree. > Here are some issues I don't think this captures very well. >=20 > 1) It's not clear to me that in implementations the phase1/outer > identity is really part of a method, so much as part of the EAP stack. [BA] Agree. In modern EAP methods the EAP-Response/Identity is always part o= f the EAP stack. RFC 3748 makes this clear.=20 > At least in TTLS, I don't think the outer identity is ever actually > carried in the method payloads, so I'm not actually sure that as a > matter of protocol it is a method concept, even if it is carried in > method-specific data structures in some implementations. >=20 > 2) Alan's proposal to use NAI for method identifiers is tempting but > seems like a really bad idea to me. =20 [BA] I agree. Also, trying to retrofit this on existing methods is very like= ly to introduce interop failures.=20 > It depends a lot of the underlying > authentication technology. Trying to shove an X.500 subject, a Kerberos > principal, or whatever a concrete implementation of an OAUTH-based EAP > method would use into NAI seems like a really bad idea, no matter how > convenient it would be for a RADIUS implementation. >=20 > I'm hoping that someone who will be involved in the working group on an > ongoing basis shares my concerns and is willing to champion them. [BA] I share your concerns though I'm also spending more time outside IETF t= hese days (in groups more attuned to open source).=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Wed Apr 6 17:06:32 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD5C12D1BA for ; Wed, 6 Apr 2016 17:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pv5aPp0g0xwq for ; Wed, 6 Apr 2016 17:06:28 -0700 (PDT) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0F5012D51B for ; Wed, 6 Apr 2016 17:06:28 -0700 (PDT) Received: by mail-pa0-x235.google.com with SMTP id td3so42674105pab.2 for ; Wed, 06 Apr 2016 17:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=guMTcIPzEKOV10bsGO8erBpZf3xpZF2O8tmKFxTYg4o=; b=R3CkEFyJ2ypzK88LDxcJM7tWkKNPvXWFRJe7dJFmk+JztT8eQEE/p17Ko8jCDwwZAP glpAP5aHSTCzWV38/pN2/TM5QNupGWVxM5ilFc9EcCZETG+cgXPJtU8+gxCYzgXCJVrR DAeDlE9moU7txtXI8IeKdSQ4EVykCSAQGCd//SnGWTywYZd6D0nlIWSzW8fGZhUg8aA2 JadmOnbywdSOOqMI7LHqp/CY7H//24iForbkK/9q6TERs9VxKT5p0OzRTEYvrrNQ6eMo h3D3jWElfcBzpBDzde9z3WOeUKGrD6zSXD7w7z9rfF4xmpheUPbkDrX3sZeooyvlDIa4 B0NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=guMTcIPzEKOV10bsGO8erBpZf3xpZF2O8tmKFxTYg4o=; b=FGC5PKeNTcfGCkGOjRq6OuMotgwJTD5bvXG6PjpeKYyBwMNXaNAhzK/exFO/+7nFX3 ix8+KdATe4cizCv8wFM4HuCe964bXSsCVG1GcOmKnmFDWEDyNmDw01UIL2oezR/iaWP7 7CvtLRdxnmUL3sHOT5LeXOZgVlHedBybnrhA8c2Jy5TvnTqkGMKxGOIVFO1cE2Xh7Hwy ys5621XZFFZj7V2XJQ0QDT2QknyLNdLTd/4IVOzrURpZl/fBEFe3d9IdqNxo5YaaKwGl w0r1kiBVH4gIy7iu7A5h8XXbh08H8iJKN2Wv72N1Nvqb6TzjXSymIhyCTlx3hFGaV8yO gL1g== X-Gm-Message-State: AD7BkJLaLA67RNwCa68rEppijZQFoBUWR/++vvcRyClLHjd9d9Zo3BZM3e/LP2IvLVmhHg== X-Received: by 10.66.118.7 with SMTP id ki7mr197375pab.152.1459987587948; Wed, 06 Apr 2016 17:06:27 -0700 (PDT) Received: from [10.234.82.41] ([50.141.111.93]) by smtp.gmail.com with ESMTPSA id ta2sm7377505pab.42.2016.04.06.17.06.27 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 17:06:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Wed, 6 Apr 2016 17:06:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> To: Alan DeKok Archived-At: Cc: Sam Hartman , radext@ietf.org, Winter Stefan Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 00:06:31 -0000 On Mar 21, 2016, at 9:20 AM, Alan DeKok wrote: >=20 > The outer identity is usually derived from the inner identity. [BA] No. Where anonymity is supported, the outer identity is anonymous and t= he inner is not. Also, the inner may not be an NAI (e.g. for PAP or MS-CHAPv= 1/v2).=20 > The recommendation to use the NAI is really a plea of "PLEASE, whatever yo= u do, DON'T invent a new user identifier. Use the NAI". [BA] For new methods, sure. But imposing this on legacy methods will break t= hem. > The rules should be: >=20 > - outer identity =3D=3D realm identifier, and SHOULD be taken from configu= ration. It SHOULD NOT be taken from the inner method, as there is no guaran= tee that the inner identity is even UTF-8 [BA] Yes! > - inner method identity SHOULD be the NAI for new EAP methods, and where p= ermitted by existing EAP methods [BA] Yes. >=20 > - inner method identity SHOULD otherwise be taken from the existing EAP me= thod, which is likely NOT UTF-8 [BA] Yup.= From nobody Wed Apr 6 17:10:36 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88FA12D51B for ; Wed, 6 Apr 2016 17:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ElRx3aBhN8PP for ; Wed, 6 Apr 2016 17:10:32 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5755F12D635 for ; Wed, 6 Apr 2016 17:10:32 -0700 (PDT) Received: by mail-pa0-x22a.google.com with SMTP id zm5so42829538pac.0 for ; Wed, 06 Apr 2016 17:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AuikDYgs5xgoqlqEg3EorIxlkU36azizwiRRE+e/pUo=; b=JhVQGguD4noWCOb8myDg45Z9gbyI9nIaS5Z81PanuZWrBwoFFurAsBsjGJvDdEktyI +RgxySpfPhFGOMP1Y9GzVY07xmHIAomidJePiOOIS07i/kMXKwOBzFrIXnvlv15/FATS g7oP/pSDO+1FYIA3YwUb3eFuVCF2eixPglSeyXukOxrNMCNaOaWQ5DrlYi5UnuDfXLtk 2EnHsvxKGeHMwbjSTV2jzdYDnj9DURqlEoij47jsDWxS8MJ+YtMV6S3zQFpH1J1sRouW 8lcWmhrlB8Vax8SauOFnRu6h9U3DMQhHzhxG6DomZwcqcrUPAdeuxaWFqQemD/7bd0pg /fMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AuikDYgs5xgoqlqEg3EorIxlkU36azizwiRRE+e/pUo=; b=QlB9Vj6VYyafUi/DKL/A39QcT2VlL0AOCjydWMuGfAX7F3gtvk2MGO7/32d/TwUfzZ CfnKtldAxN7NJPwfpUhnG4tmaFE045XJclp1MCNzKKl21VasjmB8XQptrtnP90gTBtdH lRBwh4fztvx0qp1GKGIpkhQCk8Yk0ZuF0U45gwSpCXGrt56FVnMFeY6/7yYcV+SOEq5f D1PS0s/5blcoGXIS8C+GqaTHOWDgCMdLTZr2ipDUlku8PfSwLfo93A89S1Ux0h6OGAIO DFrF6BMobGzog55bYLqDTyCl+JUz0bLYw3v/rb2Slf0o+imckQJ4GO8r36JfBK5ysg8v F68w== X-Gm-Message-State: AD7BkJLDYCidwtePKwNyFGnd2QCL39GP0euA1JYyi/HX7g0oA3JH1Gn4qwFBL3kHcjSkDw== X-Received: by 10.66.222.41 with SMTP id qj9mr230281pac.136.1459987831987; Wed, 06 Apr 2016 17:10:31 -0700 (PDT) Received: from [10.234.82.41] ([50.141.111.93]) by smtp.gmail.com with ESMTPSA id 87sm7373078pfq.93.2016.04.06.17.10.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 17:10:31 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13E238) In-Reply-To: <57025D48.5020009@restena.lu> Date: Wed, 6 Apr 2016 17:10:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <23B3ADC1-A2AA-4B44-A979-263469B7C672@gmail.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <57025D48.5020009@restena.lu> To: Stefan Winter Archived-At: Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 00:10:35 -0000 On Apr 4, 2016, at 5:25 AM, Stefan Winter wrote: >=20 > Why? In IETF91 Bernard Aboba was in the room and he actually suggested > we do exactly that: EAP-Response/Identity should have been UTF-8 ever > since, and not doing that was a mistake - so better to fix it late than > never. [BA] I believe this was the intent in RFC 3748, so we can clarify this now (= and update RFC 3748).=20 > We are on BCP track and probably we'll have an Updates: relationship > with RFC3748 anyway. So it's not impossible to do it. Let's discuss this > in the room on Friday. [BA] Yes.= From nobody Wed Apr 6 17:17:10 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C81112D804 for ; Wed, 6 Apr 2016 17:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kvUVh4Mjj8OJ for ; Wed, 6 Apr 2016 17:17:07 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8F312D7DB for ; Wed, 6 Apr 2016 17:17:04 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id 184so43679096pff.0 for ; Wed, 06 Apr 2016 17:17:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=opRFXBNLimN9UK/4sYak1iM4bVnHHNUWo1SBFNeVQGo=; b=Ca8CvA3DoT7EQpB2AgQAz+e9MD0aoRgZVtQhcX3OPCBOwnq0dYQcGdOtrYor6MLjVs 8NQ+qFxgx9MvBIi9S/PZYiFyvDq2GDbYGKSWZXThZQlBx1JZnEPf4pR/OppwlOWPOrF1 4fXNe3kDOjxzfVZHvI2C7sSCFnCGk6UZxZNyfQbDPpzZK8w7WjK/8Kq5+I5RRbC6Rg2s YeOOsRDqhuH9l/Sh5M2CylXyLr+Yz4P+8O4cKItE9zcyIMTJVJINBub7v7YZpH2jXdzq FDjPf8nnhBOtaME1wFyGcvgxPKGwr1EvNgFURQpxcHtjVR581F5AYagriTnGFHXoKJRi nl7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=opRFXBNLimN9UK/4sYak1iM4bVnHHNUWo1SBFNeVQGo=; b=kGdXMTpvavuwmUo3yF0SzWQtzR9wQc2MrFN2GyV+xHGD6FF53MwWie+cNAKshy8iy8 WpABx22xkFv0VWZTz25CyRY2OMJ29MieIWdriVll3IbEo9YyIoWE0sMf8tswssCYINJ3 oQFXx1pV6SGnfpLbkOJR+ec8XQNB5GmlLG8safHRGjSI2HAGAYg4soVFBH6dtOjqF023 XIZfxhqu31Narsa7E0JQiWVHz9i26DDkQQpZ9wktNO/cwVQfgFFXF0TgvPhr8gvE601F bXKQuQfz4Yc1n9LlzZkPbzTY6Idyhh1ZvbhtmWAvF4VFDDNIHDp5NSnB433JJpJBiA9K ulhA== X-Gm-Message-State: AD7BkJKY27ydkMnVjOnAsmtbGVclGt6nNvc2lWf49E5HvYulftcSNk9z35+2qwGzL7t6mg== X-Received: by 10.98.68.71 with SMTP id r68mr218485pfa.119.1459988224200; Wed, 06 Apr 2016 17:17:04 -0700 (PDT) Received: from [10.234.82.41] ([50.141.111.93]) by smtp.gmail.com with ESMTPSA id vv8sm7431249pab.22.2016.04.06.17.17.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 17:17:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (13E238) In-Reply-To: <57026378.1020702@restena.lu> Date: Wed, 6 Apr 2016 17:17:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> To: Stefan Winter Archived-At: Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 00:17:08 -0000 On Apr 4, 2016, at 5:52 AM, Stefan Winter wrote: >=20 > There is a string A for the realm identifier. > There is a string B for the user identifier in a given EAP method. >=20 > There is a dependency between the two: A must be chosen so that the EAP > method which uses B will actually reach an EAP server which is prepared > to handle B. [BA] Be careful. The statement is true for the EAP-Response/Identity, but ma= y not be true for an EAP-method specific identity, which might not be an NAI= . Even if it is an NAI, the results may depend on things like the federation= structure of the underlying LDAP directory. We are very much outside RADIU= S-land with EAP-method specific identities. > The consequence, no matter the chosen word, is: when multiple EAP > methods are configured (there are multiple instances of B) then there > may need to be more than instance of A as well. [BA] Only one EAP-Response/Identity is permitted in RFC 3748. That is fundam= ental to EAP.=20 From nobody Wed Apr 6 17:37:28 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C1212D7FE for ; Wed, 6 Apr 2016 17:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0XzVW87eF9oD for ; Wed, 6 Apr 2016 17:37:24 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2407212D7F1 for ; Wed, 6 Apr 2016 17:37:24 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id e6so79832068vkh.2 for ; Wed, 06 Apr 2016 17:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qFMLu1XYXmQmn8U3QrFy0ZWgwVK2ZoRpFvN2Ke67cEI=; b=X8DLTN9iDwf/1AP9qsrt0qeCOk26ZGdAtVUA/Vgq8FjzOTOqWAVdqtD9zaQMIb3Kt/ FvIkBMTwQocoVRkw7u7aHTymbLXOtzhEJDo/VYtDl/AJgJdedOC4IuGcGQFQiwfRqS0X 3/JtHXlvCqMCuVJADe7nb7camSWD0CrDSHXMtgh9SN20Mjj7Mrr0V0kiFWO3vVC7Wdid m8/5GzMKGUQQ/FKuAkBC57JqcAGEP8xwv2hAp6ynVufh9PllQuISG11uZtJQZyCyrZy8 9xn0tJY3GoMokhBecnTp5TfAvfyBdXZK31k8N/G+5WbSfw3zMl4u/3P+RO84R9r9Wx6P Ru5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qFMLu1XYXmQmn8U3QrFy0ZWgwVK2ZoRpFvN2Ke67cEI=; b=VFyf0a/9PuuRt0mswuyAmbc36ozvILeCNUJfBh0+1ZG2nC1BvW5ZCZh+Lz0neCqJVr 2GXY9jgn0QLX6eo5Z6BVh++oqPYXtkAuJZWKcczSJSPMp3TmVviUM4+l9H7y8i3cCrQU EXE1iRhKZ1XKTG34fY4lTyRRMS1aymfMYXfZYNyHpUgpVdMOaVJEo/TJ3UrdXnQkgGtW 1YbjRMy2U/N2Ip3zOcreJHOoacB2atL6GhKf9q2QJqJRAMLJXqeaZEtU26o1EVjTbY+9 WAM33c+cqsm/6YoNkS2zkWra5VECYVrQLksp2KIEhYDZpT/sy6nlCC61eHktTXaFlZ3M 1SvQ== X-Gm-Message-State: AD7BkJLlqTXu/ub0PUrKAt1xzKuwUnLPclVItJfUAim3nDzoyMxoMxZ480UrC29SBf/TrdOK26Bl2PAFVoLHEA== X-Received: by 10.159.40.68 with SMTP id c62mr111402uac.100.1459989443148; Wed, 06 Apr 2016 17:37:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.40 with HTTP; Wed, 6 Apr 2016 17:37:03 -0700 (PDT) In-Reply-To: References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <5565C2F8-5D21-4D39-B914-1645B4185F3E@deployingradius.com> <5703DE3A.2070705@restena.lu> From: Bernard Aboba Date: Wed, 6 Apr 2016 17:37:03 -0700 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=94eb2c04334e228c9e052fda48f4 Archived-At: Cc: Winter Stefan , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 00:37:27 -0000 --94eb2c04334e228c9e052fda48f4 Content-Type: text/plain; charset=UTF-8 Alan said: "All for the same realm and SSID? This is where it gets vague... there should only be one EAP configuration for a particular way of getting network access. " [BA] Indeed - anything else invites a bid-down attack. For example, EAP-SIM is vulnerable to attack and should NEVER be allowed on an SSID where it is not expected. "Identifiers should be an NAI when roaming comes into play" [BA] The EAP-Response/Identity should be an NAI - for roaming and other reasons. But the EAP-method specific identity is not used for external routing, so how does roaming come into play with that? " What people do in their own networks is their own business. But there is a definite overlap with public networks. " [BA] Only in some *very* specific scenarios used in failed schemes such as WiMax (where there was routing based on EAP-specific Identities). Overall, I think we should STRONGLY discourage that - so that WiMAX will not have died in vain. "And say that close enterprise deployments SHOULD use the NAI, for reasons outlined above." [BA] Enterprise deployments are *exactly* the kind of deployments that would be most likely to be broken by forcing use of an NAI for method-specific identities, because they often migrate in stages. Such a recommendation would only be safe in the very last phase of a migration to the cloud, when legacy on-premise equipment has been completely replaced by cloud-based authentication where the NAI is a virtual requirement. On Tue, Apr 5, 2016 at 2:23 PM, Alan DeKok wrote: > On Apr 5, 2016, at 11:48 AM, Stefan Winter > wrote: > > The one thing that worries me here is that you introduce the new concept > > of a "user"; and that you seem to imply that X -> E -> Y is a > > deterministic choice. > > "entity being authenticated", commonly user or device. > > > Say, I have a client certificate for EAP-TLS, a username/password for > > EAP-TTLS and a SIM card for EAP-AKA'. > > All for the same realm and SSID? > > This is where it gets vague... there should only be one EAP > configuration for a particular way of getting network access. > > > In that case, user X does not yield a unique choice for E. It is up to > > the user's preference, or the network's acceptance of credential types > > which one to use. > > I'd be wary of allowing multiple EAP configurations for one network > access method. It involves users, who we know make mistakes. > > > I'd prefer to leave the notion of a user out of the document. So far, we > > are only talking about multiple EAP types which are configured on a > > system. Whether they all relate to the same human being is not very > > relevant. The choice of EAP method is largely out of the hands of the > > user - he has all those types configured in the hope that one of them > > gets him online. There may be a preference configured on the system, and > > if yes, that should be honoured. But we can talk about the config item > > "preference" without introducing the notion of a user. > > Yes. > > > Public consumption is a big word: EAP is often used within closed > > enterprise environments. EAP methods may only travel to a single AAA/EAP > > server without any choices in routing. In those cases, the form of the > > realm identifier is irrelevant; all identifiers get routed along the > > "one and only" default route. > > What people do in their own networks is their own business. But there > is a definite overlap with public networks. > > If private enterprises are *at any point* interested in connecting their > networks to a public infrastructure, they should be compatible with that > infrastructure from day 1. Migration from "internal" identifiers to > "public" identifiers is a nightmare. > > i.e. there is no large benefit in using identifiers in an internal > format. Therefore, we recommend using ones which are compatible with > public networks. > > > I totally agree that the idenfiers really should be a NAI as soon as > > roaming comes into play. > > Even before. Migration is nightmare. These people shouldn't think > that they're smarter than everyone else on the planet. They're not. They > should use NAIs, because it's the best thing we know. > > > The wording "MUST" without the qualifier ... "in a roaming environment" > (or "if the EAP session is sent to a different entity") is then too harsh. > I'd be happy to add the MUST with that extra qualifier; and to leave closed > enterprise EAP deployments alone. > > Sure. > > And say that close enterprise deployments SHOULD use the NAI, for > reasons outlined above. > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > --94eb2c04334e228c9e052fda48f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alan said:=C2=A0

"All for the same realm and SSID?

=C2=A0 This is where it = gets vague... there should only be one EAP configuration for a particular w= ay of getting network access.
&qu= ot;

[BA] Indeed - anything else invites a bid-down= attack.=C2=A0 For example, EAP-SIM is vulnerable to attack and should NEVE= R be allowed on an SSID where it is not expected. =C2=A0

"Identifiers should be an NAI when roaming comes into play"= ;

[BA] The EAP-Response/Identity should be an NAI = - for roaming and other reasons.=C2=A0 But the EAP-method specific identity= is not used for external routing, so how does roaming come into play with = that?

"=C2= =A0What people do in their own netw= orks is their own business.=C2=A0 But there is a definite overlap with publ= ic networks.
"

[BA] Only in = some *very* specific scenarios used in failed schemes such as WiMax (where = there was routing based on EAP-specific Identities).=C2=A0 Overall, I think= we should STRONGLY discourage that - so that WiMAX will not have died in v= ain.=C2=A0

"= And say that close enterprise deployments SHOULD use the NAI, for reasons o= utlined above."

[BA] Enterprise deploy= ments are *exactly* the kind of deployments that would be most likely to be= broken by forcing use of an NAI for method-specific identities, because th= ey often migrate in stages.=C2=A0 Such a recommendation would only be safe = in the very last phase of a migration to the cloud, when legacy on-premise = equipment has been completely replaced by cloud-based authentication where = the NAI is a virtual requirement. =C2=A0

=C2=A0

On Tue, = Apr 5, 2016 at 2:23 PM, Alan DeKok <aland@deployingradius.com&= gt; wrote:
On Apr= 5, 2016, at 11:48 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
> The one thing that worries me here is that you introduce the new conce= pt
> of a "user"; and that you seem to imply that X -> E ->= Y is a
> deterministic choice.

=C2=A0 "entity being authenticated", commonly user or devi= ce.

> Say, I have a client certificate for EAP-TLS, a username/password for<= br> > EAP-TTLS and a SIM card for EAP-AKA'.

=C2=A0 All for the same realm and SSID?

=C2=A0 This is where it gets vague... there should only be one EAP configur= ation for a particular way of getting network access.

> In that case, user X does not yield a unique choice for E. It is up to=
> the user's preference, or the network's acceptance of credenti= al types
> which one to use.

=C2=A0 I'd be wary of allowing multiple EAP configurations for o= ne network access method.=C2=A0 It involves users, who we know make mistake= s.

> I'd prefer to leave the notion of a user out of the document. So f= ar, we
> are only talking about multiple EAP types which are configured on a > system. Whether they all relate to the same human being is not very > relevant. The choice of EAP method is largely out of the hands of the<= br> > user - he has all those types configured in the hope that one of them<= br> > gets him online. There may be a preference configured on the system, a= nd
> if yes, that should be honoured. But we can talk about the config item=
> "preference" without introducing the notion of a user.

=C2=A0 Yes.

> Public consumption is a big word: EAP is often used within closed
> enterprise environments. EAP methods may only travel to a single AAA/E= AP
> server without any choices in routing. In those cases, the form of the=
> realm identifier is irrelevant; all identifiers get routed along the > "one and only" default route.

=C2=A0 What people do in their own networks is their own business.= =C2=A0 But there is a definite overlap with public networks.

=C2=A0 If private enterprises are *at any point* interested in connecting t= heir networks to a public infrastructure, they should be compatible with th= at infrastructure from day 1.=C2=A0 Migration from "internal" ide= ntifiers to "public" identifiers is a nightmare.

=C2=A0 i.e. there is no large benefit in using identifiers in an internal f= ormat.=C2=A0 Therefore, we recommend using ones which are compatible with p= ublic networks.

> I totally agree that the idenfiers really should be a NAI as soon as > roaming comes into play.

=C2=A0 Even before.=C2=A0 Migration is=C2=A0 nightmare.=C2=A0 These = people shouldn't think that they're smarter than everyone else on t= he planet.=C2=A0 They're not.=C2=A0 They should use NAIs, because it= 9;s the best thing we know.

> The wording "MUST" without the qualifier ... "in a roam= ing environment" (or "if the EAP session is sent to a different e= ntity") is then too harsh. I'd be happy to add the MUST with that = extra qualifier; and to leave closed enterprise EAP deployments alone.

=C2=A0 Sure.

=C2=A0 And say that close enterprise deployments SHOULD use the NAI, for re= asons outlined above.

=C2=A0 Alan DeKok.

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

--94eb2c04334e228c9e052fda48f4-- From nobody Thu Apr 7 13:42:36 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A8812D175 for ; Thu, 7 Apr 2016 13:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 2sm7J8KVpTNU for ; Thu, 7 Apr 2016 13:42:30 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B7312D6C2 for ; Thu, 7 Apr 2016 13:42:25 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id 028AFBB744; Thu, 7 Apr 2016 22:42:22 +0200 (CEST) To: Bernard Aboba References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <5706C62B.6040200@restena.lu> Date: Thu, 7 Apr 2016 17:42:19 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="91de70drC9LdMQD7uls2tIVqCIpRivn4U" Archived-At: Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:42:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --91de70drC9LdMQD7uls2tIVqCIpRivn4U Content-Type: multipart/mixed; boundary="RgTnXp7HCs0N8cSOSHe7JTafSsrvaDMVU" From: Stefan Winter To: Bernard Aboba Cc: Alan DeKok , radext@ietf.org Message-ID: <5706C62B.6040200@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> In-Reply-To: <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> --RgTnXp7HCs0N8cSOSHe7JTafSsrvaDMVU Content-Type: multipart/mixed; boundary="------------070304090301020109010504" This is a multi-part message in MIME format. --------------070304090301020109010504 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > On Apr 4, 2016, at 5:52 AM, Stefan Winter wr= ote: >> There is a string A for the realm identifier. >> There is a string B for the user identifier in a given EAP method. >> >> There is a dependency between the two: A must be chosen so that the EA= P >> method which uses B will actually reach an EAP server which is prepare= d >> to handle B. > [BA] Be careful. The statement is true for the EAP-Response/Identity, b= ut may not be true for an EAP-method specific identity, which might not b= e an NAI. Even if it is an NAI, the results may depend on things like the= federation structure of the underlying LDAP directory. We are very much= outside RADIUS-land with EAP-method specific identities. Absolutely: the I-D is exclusively about the contents of EAP-Response/Identity. The newly coined term "realm identifier" is meant to mean "a candidate for a UTF-8 string to be put into EAP-Response/Identity". That is, there is a really arbitrary method-specific identity - no format requirements, no encoding requirements: that's the B above. When you decide to use the corresponding EAP method in your authentication attempt, then you'll need to get that realm identifier A, and A needs to be good enough to make the EAP-method payload end up at an EAP server that can handle it. Where you get that A from is undefined, and EAP method implementations / OS UIs have their own ideas about it. (e.g. use identical strings for both without asking the user; or provide a config item that the user needs to fill out; or ...). The important thing here is the sequence: you choose an EAP method with a user identifier B, then you determine the realm identifier A to use as a basis for what to send in EAP-Response/Identity. >> The consequence, no matter the chosen word, is: when multiple EAP >> methods are configured (there are multiple instances of B) then there >> may need to be more than instance of A as well. > [BA] Only one EAP-Response/Identity is permitted in RFC 3748. That is f= undamental to EAP.=20 Sure. Nobody disputes that. The concern in the I-D is that you may have multiple EAP methods configured in your supplicant. Those may require the use of more than one realm identifier (e.g. @eduroam.org for PEAP and @mnc45.mcc123.3gppnetwork.org for AKA') and that you consequently *would* need more than one EAP-Response/Identity to route both alternatives correctly. Since that is not possible, the only solution if you really want to try both EAP methods is to run an EAP conversation with one A. And then, if that doesn't succeed, you run a second EAP conversation with the other A. Only when you've tried all your EAP methods and none authenticated you, give up and tell the user he is busted. This is actually written in the draft. Greetings, Stefan Winter --------------070304090301020109010504 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/MacGPG2 v2 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----- --------------070304090301020109010504-- --RgTnXp7HCs0N8cSOSHe7JTafSsrvaDMVU-- --91de70drC9LdMQD7uls2tIVqCIpRivn4U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXBsYrAAoJEMDeajWKOdxmOrMP/RD9cawnHkZdPyN3UQmAGaCe 8iEdC7RVkLJxp8QJKC6a0n/BAjBmZ5gyeXRJQ4oWsPZQU9Wu0TDftXmxiMQFJ72V KJeanJtx1/F5yWn7kr8wkzH/GmW6H9qctH1k9LXNO0lB+ZUFwlMvb/321wDN1uCD h9+RxyN5NTzFDscFrO5ohI34mBjbG2bjSEPLWG/a4gWhT+CPlvPOgjYFhFEaipOP 0MZS3ZhW703JcUBiKLRC9r2PlBgmF2/d6WRl4fAMylGTYNlODGZbK+5bbNyC4ML0 7Yi7Fg1lY9wV9eji2bQwiwJdpC6Fl6YtmR3qrZHqIq+seMGnayYR3dZNudzjfHue rvuk+XxHznkQJ6pYWfEhUyVQnIaNAMZWQWwFzSlfH2G7SpgvI9wPRiuD8GaqNVpE aE6Fg+S1TFj3RzeGnFVywN9xsNLRBhFSGgGsGBbrGGRyMA6pwo4t3eHOFQjXsyTH d91Q16zShA+Nb9quG3+b5tEE8OWz/v1Rgw2i6F1OiAdTBU8QcZ+a8way/Y53wV/n sWHHlKnsvnBo5mZSulMd4QIrLo94TSgOHSgvLABH59WYNu2fS5dn2cF8VpWDgnl1 ULaCu/Whi+ltk6g2AqasR6NcmmObAf7wGURi6fjgLZEjk6m046llnn7ZMsoLdgN/ 1iM5A7um2WKv0806Eznt =9yV/ -----END PGP SIGNATURE----- --91de70drC9LdMQD7uls2tIVqCIpRivn4U-- From nobody Thu Apr 7 13:46:07 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FC212D175 for ; Thu, 7 Apr 2016 13:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 yhDn4QlzBSuw for ; Thu, 7 Apr 2016 13:46:03 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFCC12D10C for ; Thu, 7 Apr 2016 13:46:03 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id E8048BB744; Thu, 7 Apr 2016 22:45:59 +0200 (CEST) To: Bernard Aboba , Alan DeKok References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <5565C2F8-5D21-4D39-B914-1645B4185F3E@deployingradius.com> <5703DE3A.2070705@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <5706C704.2010404@restena.lu> Date: Thu, 7 Apr 2016 17:45:56 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IgGRmLWrFileMG2I0GoXVOAqewOHHVRKa" Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:46:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IgGRmLWrFileMG2I0GoXVOAqewOHHVRKa Content-Type: multipart/mixed; boundary="d8INfFaSFXE8FnAsH0btlqdxcSFS94m8q" From: Stefan Winter To: Bernard Aboba , Alan DeKok Cc: radext@ietf.org Message-ID: <5706C704.2010404@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <5565C2F8-5D21-4D39-B914-1645B4185F3E@deployingradius.com> <5703DE3A.2070705@restena.lu> In-Reply-To: --d8INfFaSFXE8FnAsH0btlqdxcSFS94m8q Content-Type: multipart/mixed; boundary="------------020709090406040104070807" This is a multi-part message in MIME format. --------------020709090406040104070807 Content-Type: multipart/alternative; boundary="------------060408020900020100070707" --------------060408020900020100070707 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, reading this, I think all that's needed is the re-iteration: we are talking about mandating structure in realm identifiers ("things that end up in EAP-Response/Identity") - not method-specific identities. Greetings, Stefan Winter On 06.04.16 21:37, Bernard Aboba wrote: > Alan said:=20 > > "All for the same realm and SSID? > > This is where it gets vague... there should only be one EAP > configuration for a particular way of getting network access. > " > > [BA] Indeed - anything else invites a bid-down attack. For example, > EAP-SIM is vulnerable to attack and should NEVER be allowed on an SSID > where it is not expected. =20 > > "Identifiers should be an NAI when roaming comes into play" > > [BA] The EAP-Response/Identity should be an NAI - for roaming and > other reasons. But the EAP-method specific identity is not used for > external routing, so how does roaming come into play with that? > > " What people do in their own networks is their own business. But > there is a definite overlap with public networks. > " > > [BA] Only in some *very* specific scenarios used in failed schemes > such as WiMax (where there was routing based on EAP-specific > Identities). Overall, I think we should STRONGLY discourage that - so > that WiMAX will not have died in vain.=20 > > "And say that close enterprise deployments SHOULD use the NAI, for > reasons outlined above." > > [BA] Enterprise deployments are *exactly* the kind of deployments that > would be most likely to be broken by forcing use of an NAI for > method-specific identities, because they often migrate in stages.=20 > Such a recommendation would only be safe in the very last phase of a > migration to the cloud, when legacy on-premise equipment has been > completely replaced by cloud-based authentication where the NAI is a > virtual requirement. =20 > > =20 > > On Tue, Apr 5, 2016 at 2:23 PM, Alan DeKok > wrote: > > On Apr 5, 2016, at 11:48 AM, Stefan Winter > > wrote:= > > The one thing that worries me here is that you introduce the new > concept > > of a "user"; and that you seem to imply that X -> E -> Y is a > > deterministic choice. > > "entity being authenticated", commonly user or device. > > > Say, I have a client certificate for EAP-TLS, a > username/password for > > EAP-TTLS and a SIM card for EAP-AKA'. > > All for the same realm and SSID? > > This is where it gets vague... there should only be one EAP > configuration for a particular way of getting network access. > > > In that case, user X does not yield a unique choice for E. It is > up to > > the user's preference, or the network's acceptance of credential > types > > which one to use. > > I'd be wary of allowing multiple EAP configurations for one > network access method. It involves users, who we know make mistake= s. > > > I'd prefer to leave the notion of a user out of the document. So > far, we > > are only talking about multiple EAP types which are configured on= a > > system. Whether they all relate to the same human being is not ve= ry > > relevant. The choice of EAP method is largely out of the hands > of the > > user - he has all those types configured in the hope that one of > them > > gets him online. There may be a preference configured on the > system, and > > if yes, that should be honoured. But we can talk about the > config item > > "preference" without introducing the notion of a user. > > Yes. > > > Public consumption is a big word: EAP is often used within closed= > > enterprise environments. EAP methods may only travel to a single > AAA/EAP > > server without any choices in routing. In those cases, the form > of the > > realm identifier is irrelevant; all identifiers get routed along = the > > "one and only" default route. > > What people do in their own networks is their own business. But > there is a definite overlap with public networks. > > If private enterprises are *at any point* interested in > connecting their networks to a public infrastructure, they should > be compatible with that infrastructure from day 1. Migration from > "internal" identifiers to "public" identifiers is a nightmare. > > i.e. there is no large benefit in using identifiers in an > internal format. Therefore, we recommend using ones which are > compatible with public networks. > > > I totally agree that the idenfiers really should be a NAI as soon= as > > roaming comes into play. > > Even before. Migration is nightmare. These people shouldn't > think that they're smarter than everyone else on the planet.=20 > They're not. They should use NAIs, because it's the best thing we > know. > > > The wording "MUST" without the qualifier ... "in a roaming > environment" (or "if the EAP session is sent to a different > entity") is then too harsh. I'd be happy to add the MUST with that > extra qualifier; and to leave closed enterprise EAP deployments alo= ne. > > Sure. > > And say that close enterprise deployments SHOULD use the NAI, > for reasons outlined above. > > Alan DeKok. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------060408020900020100070707 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

reading this, I think all that's needed is the re-iteration: we are talking about mandating structure in realm identifiers ("things that end up in EAP-Response/Identity") - not method-specific identities.

Greetings,

Stefan Winter

On 06.04.16 21:37, Bernard Aboba wrote:
Alan said:=A0

"All for the same realm and= SSID?

=A0 This is where it gets vague.= =2E. there should only be one EAP configuration for a particular way of getting network access.
"

[BA] Indeed - anything else invites a bid-down attack.=A0 Fo= r example, EAP-SIM is vulnerable to attack and should NEVER be allowed on an SSID where it is not expected. =A0

"Identifiers should be an NAI when roaming comes into play"<= /div>

[BA] The EAP-Response/Identity should be an NAI - for roaming and other reasons.=A0 But the EAP-method specific identity is not used for external routing, so how does roaming come into play with that?

"=A0What people do in their own networks is their own business.=A0 But there is a definite overlap with public networks.
"

[BA] Only in some *very* specific scenarios used in failed schemes such as WiMax (where there was routing based on EAP-specific Identities).=A0 Overall, I think we should STRONGL= Y discourage that - so that WiMAX will not have died in vain.=A0<= /div>

"And say that close enterprise deployments SHOULD use the NAI, for reasons outlined above."

[BA] Enterprise deployments are *exactly* the kind of deployments that would be most likely to be broken by forcing use of an NAI for method-specific identities, because they often migrate in stages.=A0 Such a recommendation would only be= safe in the very last phase of a migration to the cloud, when legacy on-premise equipment has been completely replaced by cloud-based authentication where the NAI is a virtual requirement. =A0

=A0

On Tue, Apr 5, 2016 at 2:23 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Apr 5, 2016, at 11:48 AM, Stefan Winter <<= a moz-do-not-send=3D"true" href=3D"mailto:stefan.winter@restena.lu">stefan.win= ter@restena.lu> wrote:
> The one thing that worries me here is that you introduce the new concept
> of a "user"; and that you seem to imply that X -> E -> Y is a
> deterministic choice.

=A0 "entity being authenticated", commonly user or device.

> Say, I have a client certificate for EAP-TLS, a username/password for
> EAP-TTLS and a SIM card for EAP-AKA'.

=A0 All for the same realm and SSID?

=A0 This is where it gets vague... there should only be one EAP configuration for a particular way of getting network access.

> In that case, user X does not yield a unique choice for E. It is up to
> the user's preference, or the network's acceptance of credential types
> which one to use.

=A0 I'd be wary of allowing multiple EAP configuration= s for one network access method.=A0 It involves users, who we know make mistakes.

> I'd prefer to leave the notion of a user out of the document. So far, we
> are only talking about multiple EAP types which are configured on a
> system. Whether they all relate to the same human being is not very
> relevant. The choice of EAP method is largely out of the hands of the
> user - he has all those types configured in the hope that one of them
> gets him online. There may be a preference configured on the system, and
> if yes, that should be honoured. But we can talk about the config item
> "preference" without introducing the notion of a user.

=A0 Yes.

> Public consumption is a big word: EAP is often used within closed
> enterprise environments. EAP methods may only travel to a single AAA/EAP
> server without any choices in routing. In those cases, the form of the
> realm identifier is irrelevant; all identifiers get routed along the
> "one and only" default route.

=A0 What people do in their own networks is their own business.=A0 But there is a definite overlap with public networks.

=A0 If private enterprises are *at any point* interested in connecting their networks to a public infrastructure, they should be compatible with that infrastructure from day 1.=A0 Migration from "internal" identifiers to "public" identifiers is a nightmare.

=A0 i.e. there is no large benefit in using identifiers in an= internal format.=A0 Therefore, we recommend using ones which are compatible with public networks.

> I totally agree that the idenfiers really should be a NAI as soon as
> roaming comes into play.

=A0 Even before.=A0 Migration is=A0 nightmare.=A0 Thes= e people shouldn't think that they're smarter than everyone else on the planet.=A0 They're not.=A0 They should use NAIs, because it's the best thing we know.

> The wording "MUST" without the qualifier ... "in a roaming environment" (or "if the EAP session is sent to a different entity") is then too harsh. I'd be happy to add the MUST with that extra qualifier; and to leave closed enterprise EAP deployments alone.

=A0 Sure.

=A0 And say that close enterprise deployments SHOULD use the NAI, for reasons outlined above.

=A0 Alan DeKok.

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.o= rg/mailman/listinfo/radext



_______________________________________________
radext mailing list
rad=
ext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------060408020900020100070707-- --------------020709090406040104070807 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/MacGPG2 v2 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----- --------------020709090406040104070807-- --d8INfFaSFXE8FnAsH0btlqdxcSFS94m8q-- --IgGRmLWrFileMG2I0GoXVOAqewOHHVRKa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXBscEAAoJEMDeajWKOdxm/8YP/1mgzDNmT8j9/DnG72JEGw2r UtP3PGMGU7GGOUk/OLaZcbW5HpMsYPWIU4CFYPc7+nF8gFB9piA5MKnXUWEtbl39 VMOqQundvEQ1QIlkZLyB4FmqRjXdurdNSAAKzgN8WISNfqJIIDM5FwlI/qReTV13 /rgFOhB98erRvCZbamyHRE3zq0ssy5vvZDgSyfpndZjlKVpYG7Gs19+WDgUr/V9U 763GvGeRDD9Ubb7zEkeZAUgCHcXjpbUoSAcIbU4kJgQxSGEd+s/HwRok/ytDh28u T9z+TdxCaKJWYCNvSOxw/FJttmHDDNz9JrcFqVM1E/+AQO11eeH78mIYDXBGlN17 +TrfNqFbpDSxQplA52RnLEBJp+F/YdUITZ8u/lBNwN3glEGbbB4enNcqaRfbY4Bt LdxKYXEGXpWhgm0JtU6huXlRByzAGi8xHqVWdYWNyt87V/9cC2dEvmBn1gM4hTbS zYTZsIlSY4wuN2xxIMTlkyJNRiUMtYSsCEIICUTevHoZgpNB58TNYC/03nLnEXO3 p8yCETYawfKAeNuy/Tqd/guNlzAXb+7tQ5ybCCuuwdb0NtAyg4rSlTIMJ6AaWmom ScUYGTatD8PdsxuRFLj+pqfQgCL2tyBSam69p96Y4LAmqU0jt6Ok8ZaCFlPFEXb9 6XpDWqr27MjArx5YarSL =GgQM -----END PGP SIGNATURE----- --IgGRmLWrFileMG2I0GoXVOAqewOHHVRKa-- From nobody Thu Apr 7 14:18:28 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A55B12D70A for ; Thu, 7 Apr 2016 14:18:27 -0700 (PDT) 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 autolearn_force=no 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 59p6DHYvoXzX for ; Thu, 7 Apr 2016 14:18:25 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id E3C6412D622 for ; Thu, 7 Apr 2016 14:18:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 278A41918; Thu, 7 Apr 2016 21:18:24 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXwqA4PVNQ9u; Thu, 7 Apr 2016 21:18:24 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id 7504D124C; Thu, 7 Apr 2016 21:18:23 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <5706C62B.6040200@restena.lu> Date: Thu, 7 Apr 2016 17:18:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org, Bernard Aboba Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:18:27 -0000 On Apr 7, 2016, at 4:42 PM, Stefan Winter = wrote: > Sure. Nobody disputes that. The concern in the I-D is that you may = have > multiple EAP methods configured in your supplicant. Those may require > the use of more than one realm identifier (e.g. @eduroam.org for PEAP > and @mnc45.mcc123.3gppnetwork.org for AKA') and that you consequently > *would* need more than one EAP-Response/Identity to route both > alternatives correctly. I think in the majority of cases, the mapping of SSID to EAP type is = 1-1. That's how supplicants are designed and implemented today. > Since that is not possible, the only solution if you really want to = try > both EAP methods is to run an EAP conversation with one A. And then, = if > that doesn't succeed, you run a second EAP conversation with the other > A. Only when you've tried all your EAP methods and none authenticated > you, give up and tell the user he is busted. That worries me. It's new behaviour. We're not clear if this will = work, or when it will work, or how it will work. Alan DeKok. From nobody Thu Apr 7 14:20:34 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5DF12D713 for ; Thu, 7 Apr 2016 14:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 WGIY1l9tGtcX for ; Thu, 7 Apr 2016 14:20:31 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768E112D6FB for ; Thu, 7 Apr 2016 14:20:27 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id 057C5BB746; Thu, 7 Apr 2016 23:20:23 +0200 (CEST) To: Bernard Aboba , Alan DeKok References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <5706CF11.7050803@restena.lu> Date: Thu, 7 Apr 2016 18:20:17 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="umUqKWXKCq3Ek3xhkF12wk5iTdNdqVsrS" Archived-At: Cc: Sam Hartman , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:20:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --umUqKWXKCq3Ek3xhkF12wk5iTdNdqVsrS Content-Type: multipart/mixed; boundary="agu6CG3CDtpNDSDQ1EvJbQo1xUskgWVaH" From: Stefan Winter To: Bernard Aboba , Alan DeKok Cc: Sam Hartman , radext@ietf.org Message-ID: <5706CF11.7050803@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> In-Reply-To: --agu6CG3CDtpNDSDQ1EvJbQo1xUskgWVaH Content-Type: multipart/mixed; boundary="------------040407040501010606080902" This is a multi-part message in MIME format. --------------040407040501010606080902 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > On Mar 21, 2016, at 9:20 AM, Alan DeKok wro= te: >> The outer identity is usually derived from the inner identity. > [BA] No. Where anonymity is supported, the outer identity is anonymous = and the inner is not. Also, the inner may not be an NAI (e.g. for PAP or = MS-CHAPv1/v2).=20 "Derived from" does not mean they have to be *identical*. If say an inner is "stefan.winter@restena.lu" then it's easily possible to derive from that an outer ID "@restena.lu". Of course it *can* be configured separately without mangling anything from inner (and that's arguably good, because you never know what you find inside the EAP method). And of course it *can* be identical in some cases (which is arguably bad because it doesn't provide privacy). Real life BTW typically swings to "identical" in many UIs because when you click on a .1X Wi-Fi network, devices which did not get prior config info typically ask for "username" and "password" and nothing else. In which case the supplicant uses "username" both for EAP-Response/Identity and as an inner ID for the EAP method which gets negotiated. All in all, "usually" describes the situation quite well IMHO. >> The recommendation to use the NAI is really a plea of "PLEASE, whateve= r you do, DON'T invent a new user identifier. Use the NAI". > [BA] For new methods, sure. But imposing this on legacy methods will br= eak them. > >> The rules should be: >> >> - outer identity =3D=3D realm identifier, and SHOULD be taken from con= figuration. It SHOULD NOT be taken from the inner method, as there is no= guarantee that the inner identity is even UTF-8 > [BA] Yes! > > >> - inner method identity SHOULD be the NAI for new EAP methods, and whe= re permitted by existing EAP methods > [BA] Yes. > > >> - inner method identity SHOULD otherwise be taken from the existing EA= P method, which is likely NOT UTF-8 > [BA] Yup. --------------040407040501010606080902 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/MacGPG2 v2 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----- --------------040407040501010606080902-- --agu6CG3CDtpNDSDQ1EvJbQo1xUskgWVaH-- --umUqKWXKCq3Ek3xhkF12wk5iTdNdqVsrS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXBs8RAAoJEMDeajWKOdxmh7oP/jnuvZ1gk63bTkummmrSZq4/ Il6/9VUTPC3jH+24GKOSCgiMq4P55ngQm+SDKF5TJXHRTjNMqEfcYMALLPy4S8Ed dUhhsptO0X2jih4sEBQ+E0CYP1azvJOIuo5hIvFN/z9Fi110xKLPBoW5sFlfceYe xa1PWZRmvGjIlJblqPKsqLuTRoX6Ybl2exyTttAauoOi6NxbxQNc3nRRLfbCOjNZ rrjFpIsk4uv1T03mNEbCFaVY8KMDYnRiYCWsY1KMdF4ZK68uzWjW8HJuPkytKF8/ KvCG+r7nZibpV3xKLIBHLKd6URUoSS6BTbvOiXoW298a/Od1G1IfwaY49VjB/49H BRGLC+Ol/zZQ0mqlQjbD8kToq2s0B31JeyJIaDa2jEt4lQ62ch62HWzHm3F1XTuD MxBUQwongfL58ASWbjTVyRd15lGgD7mhCHtdf872CA3aHfzbFldNqVekICYB9vtp tWuJIQq8PcD9LEF8jpCSdcGdVLxynRxza7bf20ZsfD368MXDP8HHV5XKFDbUEdEb PZ75iIxCjBtYacIAdU0XRVbOEueXRgcx2nTDz0xuinKBwRKF37Yw+W0RYr82KtZg YmKKnFHuru0MAHQdZMwy5bz3NZDgwditnKBp4ZspRxRGL8xBhi4K2fowjHbkBBg8 EJTrM0u4q7ZHMdCu0SDJ =nzhJ -----END PGP SIGNATURE----- --umUqKWXKCq3Ek3xhkF12wk5iTdNdqVsrS-- From nobody Thu Apr 7 14:24:15 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46E9B12D6F8 for ; Thu, 7 Apr 2016 14:24:14 -0700 (PDT) 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 autolearn_force=no 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 43n0dfadxVHE for ; Thu, 7 Apr 2016 14:24:04 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 51EB912D718 for ; Thu, 7 Apr 2016 14:24:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id AFC0F1918; Thu, 7 Apr 2016 21:24:03 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GR-2odw0Ahr; Thu, 7 Apr 2016 21:24:03 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id E9CC2BEE; Thu, 7 Apr 2016 21:24:02 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <5706CF11.7050803@restena.lu> Date: Thu, 7 Apr 2016 17:24:22 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <69F71DF4-EEBA-400D-9247-E0E571AB6FF4@deployingradius.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <5706CF11.7050803@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Sam Hartman , radext@ietf.org, Bernard Aboba Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:24:14 -0000 On Apr 7, 2016, at 5:20 PM, Stefan Winter = wrote: >=20 > Hi, >> On Mar 21, 2016, at 9:20 AM, Alan DeKok = wrote: >>> The outer identity is usually derived from the inner identity. >> [BA] No. Where anonymity is supported, the outer identity is = anonymous and the inner is not. Also, the inner may not be an NAI (e.g. = for PAP or MS-CHAPv1/v2).=20 >=20 > "Derived from" does not mean they have to be *identical*. If say an > inner is "stefan.winter@restena.lu" then it's easily possible to = derive > from that an outer ID "@restena.lu". Or "DOMAIN\user" maps to "@example.com" Because the system administrators at the company know (a) the local AD = domain name, and (b) the public realm of the company. Alan DeKok. From nobody Thu Apr 7 14:25:14 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A376A12D724 for ; Thu, 7 Apr 2016 14:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.505 X-Spam-Level: X-Spam-Status: No, score=0.505 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no 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 WCb4nH3Rq4bG for ; Thu, 7 Apr 2016 14:25:12 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [158.64.1.34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F28112D714 for ; Thu, 7 Apr 2016 14:25:12 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id 0F373BB73A; Thu, 7 Apr 2016 23:25:05 +0200 (CEST) To: Alan DeKok References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <5706D020.7000907@restena.lu> Date: Thu, 7 Apr 2016 18:24:48 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tFXsu9RJbDJIiSrLJAukhlHH22SuMJmc0" Archived-At: Cc: radext@ietf.org, Bernard Aboba Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:25:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tFXsu9RJbDJIiSrLJAukhlHH22SuMJmc0 Content-Type: multipart/mixed; boundary="vqP2bGGEat2qMQiwLvR2He5VD6Evcne5c" From: Stefan Winter To: Alan DeKok Cc: Bernard Aboba , radext@ietf.org Message-ID: <5706D020.7000907@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> In-Reply-To: --vqP2bGGEat2qMQiwLvR2He5VD6Evcne5c Content-Type: multipart/mixed; boundary="------------080802010103000702070202" This is a multi-part message in MIME format. --------------080802010103000702070202 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, >> Sure. Nobody disputes that. The concern in the I-D is that you may hav= e >> multiple EAP methods configured in your supplicant. Those may require >> the use of more than one realm identifier (e.g. @eduroam.org for PEAP >> and @mnc45.mcc123.3gppnetwork.org for AKA') and that you consequently >> *would* need more than one EAP-Response/Identity to route both >> alternatives correctly. > I think in the majority of cases, the mapping of SSID to EAP type is = 1-1. That's how supplicants are designed and implemented today. Sure, SSID -> EAP type is typically unique. 802.11 Roaming Consortium OI -> EAP type is as well. So when a network with the configured SSID also emits the same Roaming Consortium OI? All of a sudden the supplicant has two choices. >> Since that is not possible, the only solution if you really want to tr= y >> both EAP methods is to run an EAP conversation with one A. And then, i= f >> that doesn't succeed, you run a second EAP conversation with the other= >> A. Only when you've tried all your EAP methods and none authenticated >> you, give up and tell the user he is busted. > That worries me. It's new behaviour. We're not clear if this will w= ork, or when it will work, or how it will work. > Me, too. The addition of IEEE 802.11 Interworking to the mix brings a whole new set of complexity. The alternative though is: try one of the methods, and if that account doesn't work / has no credit / expired then you are stranded - even though there would be an alternative EAP method to log on with, and possibly successfully? Greetings, Stefan Winter --------------080802010103000702070202 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/MacGPG2 v2 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----- --------------080802010103000702070202-- --vqP2bGGEat2qMQiwLvR2He5VD6Evcne5c-- --tFXsu9RJbDJIiSrLJAukhlHH22SuMJmc0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXBtAgAAoJEMDeajWKOdxm3HEQALnaP18dsC5mqTj9bDh+kBuY JMRulR2FkKwpnz/UJQBtgpbFqUhn1vHIcK4NgLnET8cAcSC4CDATASMz6e86ggvT sR0Sz4KKLfxQXMOC8UFiln9Tng6sGrdlkcssRtYPoeYMvrzLiBfwVx/u6Lcz8yJ1 ZBdrAiC1YPJyFaFZJ0BR5GAs1MMlb3GQMndSfZ9E8Nc3yDVZFb6+izvWUAPFTgor ZMdMLsDxZ+XeZakd3kLswVuYoNw3XJ+XX07N0OkkpiqRTiOV4nGgX2uDRuLaUFau kx1hKyd0prWcaXxQdaZMHHjKveOjtQWejNcknGFDZjoauvHZqfyJdiHVXojniptG bznna9KETvapLoybcW3PuwBXvaC6IneeJMtFHnDWNDLYA2cmVdHOsp0XSwUzcasu woU1728lsPE5vWsaGhQqXOf4mkgYmEBBshdxSe3xl18aGfFKCqSn6ofetr+i/NMg anY4E2xLy0sse9uOTeP+BZSqK8CYsMCcyqsdL/Vj9DORRA7XWazpmLwp5gNWWLWv vPYRrWkmR0PQniU55yQ5g9PmQMBa6CaBEd3yTCBaTV7XQ1lTXfYliip0voCyzuN1 Nr2gB3++gOiOhZY7Qh74qY0uOzoExUeU63dVxm7REhFcyDVxEJ/qhq6GcOQvXXCo n3A41acyPA6AgFxyfUNR =K/dP -----END PGP SIGNATURE----- --tFXsu9RJbDJIiSrLJAukhlHH22SuMJmc0-- From nobody Thu Apr 7 14:49:42 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0614112D5E7 for ; Thu, 7 Apr 2016 14:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 c5G80LZnlMDw for ; Thu, 7 Apr 2016 14:49:38 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A6512D14D for ; Thu, 7 Apr 2016 14:49:38 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id t129so30405581vkg.2 for ; Thu, 07 Apr 2016 14:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d1EnZkvEBiQNlnIZ6VHjVh0vtutWhE8BjlKvcfXrb2M=; b=eVLPrqF93RboVdU3Akd6Juk1Rhybe11STTMZdddlpkWwQlznu7XWBb97SQi328R46k LplMmRqjt9EJvdlylG/s8aZfXWdIkrfIoq4fNFtjIBPDg+MD4i+C1LTgyIwuNKoUZ+tS +o1qCW54AyTfIMDvJxxpndT054uVoESB3SXF2EQO4MtOX+guC1IAIiKvWKbko/DavgXB JZ+5ELguOgGoiSa/5yv1FAf9obxI+OXoPeYSBr/DYdWXwNsxiMnQbIazS0xKLt2/GbF0 YwnAUI7sCpcgNYEOBMdNiWa29nkvvmFpfEHIjJVskioW0AyGzRPwhKsdcyytaBrsheHv mLUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d1EnZkvEBiQNlnIZ6VHjVh0vtutWhE8BjlKvcfXrb2M=; b=h454EZGd74LnkyNLpeF4Pp3n0s93tRYyT02MKOfxXQ0yiiowykpS9G+rj/THHWSX8f FF8VPJNULw0FlmQm4YfGEMT0teV6zAMrluImW7gwW6x/C8JeeDJD+lzYxz7+lEAhYgtX jvVgqq2O/qS3gmiblO1bivbfQVa0m6f6EBP1pNjvc0E8TKjvz22XyQF7Xpu2IMoS5qW4 v6EOzfwmO0mAaA+gja+LjzkTP7oCUriIRtr5+ZalWMcUt482hYmRAHPJJ9NmOHwSiTqP xxgufiSBkITGKM04GJ3JpZ621RiW3XJ4Be/lFncDDF3qKZETedfCJdpX3JIyhq44oS9y WM7A== X-Gm-Message-State: AD7BkJJyQ/2jvcHt50iHkfMY1Iag5rkSmTDCZkkvI2IKXkc84UM9tqTvgsFaRF2dYuJilURBe2IHqEF38kRbQA== X-Received: by 10.176.64.225 with SMTP id i88mr2516179uad.9.1460065777525; Thu, 07 Apr 2016 14:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.40 with HTTP; Thu, 7 Apr 2016 14:49:18 -0700 (PDT) In-Reply-To: References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> From: Bernard Aboba Date: Thu, 7 Apr 2016 14:49:18 -0700 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=94eb2c12370a04aa33052fec0ec6 Archived-At: Cc: Winter Stefan , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:49:41 -0000 --94eb2c12370a04aa33052fec0ec6 Content-Type: text/plain; charset=UTF-8 Alan said: " That worries me. It's new behaviour. We're not clear if this will work, or when it will work, or how it will work." [BA] RFC 3748 and the EAP State Machine (RFC 4137) forbids chaining of EAP methods outside a tunnel. I know of no EAP implementation that supports this. So in general, it will not work - and moreover, is forbidden by the standard. On Thu, Apr 7, 2016 at 2:18 PM, Alan DeKok wrote: > On Apr 7, 2016, at 4:42 PM, Stefan Winter > wrote: > > Sure. Nobody disputes that. The concern in the I-D is that you may have > > multiple EAP methods configured in your supplicant. Those may require > > the use of more than one realm identifier (e.g. @eduroam.org for PEAP > > and @mnc45.mcc123.3gppnetwork.org for AKA') and that you consequently > > *would* need more than one EAP-Response/Identity to route both > > alternatives correctly. > > I think in the majority of cases, the mapping of SSID to EAP type is > 1-1. That's how supplicants are designed and implemented today. > > > Since that is not possible, the only solution if you really want to try > > both EAP methods is to run an EAP conversation with one A. And then, if > > that doesn't succeed, you run a second EAP conversation with the other > > A. Only when you've tried all your EAP methods and none authenticated > > you, give up and tell the user he is busted. > > That worries me. It's new behaviour. We're not clear if this will > work, or when it will work, or how it will work. > > Alan DeKok. > > --94eb2c12370a04aa33052fec0ec6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alan said:=C2=A0

"=C2=A0 That worries me.=C2=A0 It's new behaviour.=C2= =A0 We're not clear if this will work, or when it will work, or how it = will work."

[BA] RFC 3748 and the EAP = State Machine (RFC 4137) forbids chaining of EAP methods outside a tunnel.= =C2=A0 I know of no EAP implementation that supports this.=C2=A0
= So in general, it will not work - and moreover, is forbidden by the standar= d.=C2=A0

On Thu, Apr 7, 2016 at 2:18 PM, Alan DeKok <aland@deployingradi= us.com> wrote:
On Apr 7, 2016, at 4:42 PM, Stefan Winter <stefan.winter@restena.lu> wrote:
> Sure. Nobody disputes that. The concern in the I-D is that you may hav= e
> multiple EAP methods configured in your supplicant. Those may require<= br> > the use of more than one realm identifier (e.g. @eduroam.org for PEAP
> and @mnc45.mcc123.3gppnetwork.org for AKA') and that= you consequently
> *would* need more than one EAP-Response/Identity to route both
> alternatives correctly.

=C2=A0 I think in the majority of cases, the mapping of SSID to EAP = type is 1-1.=C2=A0 That's how supplicants are designed and implemented = today.

> Since that is not possible, the only solution if you really want to tr= y
> both EAP methods is to run an EAP conversation with one A. And then, i= f
> that doesn't succeed, you run a second EAP conversation with the o= ther
> A. Only when you've tried all your EAP methods and none authentica= ted
> you, give up and tell the user he is busted.

=C2=A0 That worries me.=C2=A0 It's new behaviour.=C2=A0 We'r= e not clear if this will work, or when it will work, or how it will work.
=C2=A0 Alan DeKok.


--94eb2c12370a04aa33052fec0ec6-- From nobody Thu Apr 7 14:52:44 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB9C12D640 for ; Thu, 7 Apr 2016 14:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 VC-6WLgqIKmu for ; Thu, 7 Apr 2016 14:52:41 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D25812D14B for ; Thu, 7 Apr 2016 14:52:41 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id k1so116797608vkb.0 for ; Thu, 07 Apr 2016 14:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CM1A9Yb6Kh1XWBSTcr2Rjnk+1/I2Bxf69lIbDI5aHOw=; b=iN0mtEwl3dt3MHOLiSbeOHR2HCP6HdnFn5v8HkEPPKO7/3wist/cuJQ+NuBe0RIJHM mKWNphPFkrmsxE2Dc2CsmlABycDeYL10YWob5fRLEGD8BGlmL0pSUGcX0DkTWWqqTN0Z dSueMoTnsHn3HaqRrjx6T6fv+NWsIzdhEJpET8txYI2Y5kl0/MDn667HJ04C3VZrSSS1 qoaWZkKlA/x8jqv9t7kOeUZeBbCBA/JbZEWZO2SOV7vT7F1OAkyITGkqSrUeYXwuIwMX 59oWkMxDgNnyE7ldxlaqujwo9+5rjxEHhFqDfW5Q3Pf5C/7f1Fggp94ye8fpN0nxfTKr XOXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CM1A9Yb6Kh1XWBSTcr2Rjnk+1/I2Bxf69lIbDI5aHOw=; b=RsSh0RRrOC/Gxwv9vigvC+eEcw/+WKH4p0g5rPM+N7f3DSPtDavQsjuLwOrRWF9lKF DYv4qi3pv6PE3TiQuWKvCtE6D9DXlEfbfcGezbnRpdTsep/b2rm7EvSAxO+nZ3SYf/iU MKAKkm2OriPNn8g24ymUJqN74X/ywf90w1E+PZ40fJP/GDABlZmHQrYBNnMwuEkbf1pd mosc+2ChrB8GDseUPlVlzCqMbFkQSqB1sc872H/0X5p0ZDvZHGRgJ87fIPwSNcJm0vVR BhGAFn6rAkTgvnYoGI2Od/hjsOQBSH3hF0EAfGgT/X7CjncCqpXF34OupmI9CX3UqKmj DGgQ== X-Gm-Message-State: AD7BkJINjj84h01pdlLNGO+ntzswBKhV+4ZTHUA20uEF1GRzNTF9yW9oPhSBqQ6t/9x3xahtj3Q2GspUx0sHtA== X-Received: by 10.159.40.68 with SMTP id c62mr2574519uac.100.1460065960429; Thu, 07 Apr 2016 14:52:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.40 with HTTP; Thu, 7 Apr 2016 14:52:20 -0700 (PDT) In-Reply-To: <69F71DF4-EEBA-400D-9247-E0E571AB6FF4@deployingradius.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <5706CF11.7050803@restena.lu> <69F71DF4-EEBA-400D-9247-E0E571AB6FF4@deployingradius.com> From: Bernard Aboba Date: Thu, 7 Apr 2016 14:52:20 -0700 Message-ID: To: Alan DeKok Content-Type: multipart/alternative; boundary=94eb2c04334eeb9067052fec1875 Archived-At: Cc: Winter Stefan , radext@ietf.org, Sam Hartman Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:52:43 -0000 --94eb2c04334eeb9067052fec1875 Content-Type: text/plain; charset=UTF-8 Alan said: " Or "DOMAIN\user" maps to "@example.com" Because the system administrators at the company know (a) the local AD domain name, and (b) the public realm of the company." [BA] It is difficult to generalize, because it can be company-specific. For example, within Microsoft, REDMOND\bernarda happens to map to bernarda@redmond.corp.microsoft.com but how would any implementation know this? On Thu, Apr 7, 2016 at 2:24 PM, Alan DeKok wrote: > On Apr 7, 2016, at 5:20 PM, Stefan Winter > wrote: > > > > Hi, > >> On Mar 21, 2016, at 9:20 AM, Alan DeKok > wrote: > >>> The outer identity is usually derived from the inner identity. > >> [BA] No. Where anonymity is supported, the outer identity is anonymous > and the inner is not. Also, the inner may not be an NAI (e.g. for PAP or > MS-CHAPv1/v2). > > > > "Derived from" does not mean they have to be *identical*. If say an > > inner is "stefan.winter@restena.lu" then it's easily possible to derive > > from that an outer ID "@restena.lu". > > Or "DOMAIN\user" maps to "@example.com" > > Because the system administrators at the company know (a) the local AD > domain name, and (b) the public realm of the company. > > Alan DeKok. > > --94eb2c04334eeb9067052fec1875 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alan said:=C2=A0

"=C2=A0 Or "DOMAIN\user" maps to "@example.com"

=C2=A0 Because the system administrators at the company know (a) the l= ocal AD domain name, and (b) the public realm of the company."<= /div>

[BA] It is difficult to generalize, because it can= be company-specific.=C2=A0 For example, within Microsoft, REDMOND\bernarda= happens to map to b= ernarda@redmond.corp.microsoft.com but how would any implementation kno= w this? =C2=A0

On Thu, Apr 7, 2016 at 2:24 PM, Alan DeKok <<= a href=3D"mailto:aland@deployingradius.com" target=3D"_blank">aland@deployi= ngradius.com> wrote:
On Apr 7, 2016, at 5:20 PM, Stefan Winter <stefan.winter@restena.lu> wrote:
>
> Hi,
>> On Mar 21, 2016, at 9:20 AM, Alan DeKok <aland@deployingradius.com> wrote:
>>> The outer identity is usually derived from the inner identity.=
>> [BA] No. Where anonymity is supported, the outer identity is anony= mous and the inner is not. Also, the inner may not be an NAI (e.g. for PAP = or MS-CHAPv1/v2).
>
> "Derived from" does not mean they have to be *identical*. If= say an
> inner is "stefan.wint= er@restena.lu" then it's easily possible to derive
> from that an outer ID "@restena.lu".

=C2=A0 Or "DOMAIN\user" maps to "@example.com"

=C2=A0 Because the system administrators at the company know (a) the local = AD domain name, and (b) the public realm of the company.

=C2=A0 Alan DeKok.


--94eb2c04334eeb9067052fec1875-- From nobody Thu Apr 7 14:57:20 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144B912D721 for ; Thu, 7 Apr 2016 14:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.284 X-Spam-Level: X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SgLGaaDCjmzw for ; Thu, 7 Apr 2016 14:57:17 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A5612D6F0 for ; Thu, 7 Apr 2016 14:57:17 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id e185so116857972vkb.1 for ; Thu, 07 Apr 2016 14:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sqfaic/+P3CdU1nvYNLoHjU5ebX8YJa6+HC1ERYGH7M=; b=ewCyglBgrNj84QJHWVsiwHDbXyEO+hPc078eLdc1XLycxeYuYGha8arUr51lHFIydc 9LUdjyYl3xvO8ewVBQFebgMGgTiXCCmPwl43zo+sPwQOWWf4FZAqo98FqDOce4fd2UNS PhYfL3GWceOchAzjlnP7rb/xtXtSPs4dfXwfiZs9EpAgSBJye4A14M/nPg4Hg9NX1/O5 eqvJqmjwjzu1MySSqvbHKVMUl+GlJF4Yo2XcZnRJFjXYmrwcAPqaittNrTCRBqhFaozm eGubpczXXn7zPBhCu8Pco8Q66vec6VD0zlFMN39EajEk2EjCYcvAOnfBx9HJ7rRDzqXA YBNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sqfaic/+P3CdU1nvYNLoHjU5ebX8YJa6+HC1ERYGH7M=; b=ebDD77dKL5zQ5uYjpRxzrAtkZUAETW6enaQAkuHpKKGNmlLMG9QbCD+ou8xq1KUSch qmKsXCxrL0SKKPkGBFIBbA3Ken6/bCoMfrk/MroYnRlZ3poW5ygePEranbS7DxsHYsMP +/8dep5IEZ+BdwxSB4WZ8JycUSZ6bXJvmxqR+8bhtJcef+MHaf1xsCuVS5bHVpwGJucg ajfo+myvSKFqGFhirscg/aYFYud6rmHOfeDc1//R5EYnubfI06e+WBbK+0Xj4ZDVhE8T TY/KVxDZQ1rWrfMCBMSba7m8L3HhzDz5sVsGNAapNr+jSsZGVhmTe6VpL4kEh+B90mNx rzdw== X-Gm-Message-State: AD7BkJLeR32ghhvKLPmlDoBvcech/7BP9lztkyGYlyA8lmrvq4FeDXC1d9ZH1jNHqXpHVYvWfg/MUtr7f0B1/w== X-Received: by 10.159.39.9 with SMTP id a9mr2203505uaa.116.1460066236397; Thu, 07 Apr 2016 14:57:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.40 with HTTP; Thu, 7 Apr 2016 14:56:56 -0700 (PDT) In-Reply-To: <5706D020.7000907@restena.lu> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> From: Bernard Aboba Date: Thu, 7 Apr 2016 14:56:56 -0700 Message-ID: To: Stefan Winter Content-Type: multipart/alternative; boundary=94eb2c12339c5e7e6c052fec29e4 Archived-At: Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:57:19 -0000 --94eb2c12339c5e7e6c052fec29e4 Content-Type: text/plain; charset=UTF-8 Stefan said: "Me, too. The addition of IEEE 802.11 Interworking to the mix brings a whole new set of complexity. The alternative though is: try one of the methods, and if that account doesn't work / has no credit / expired then you are stranded - even though there would be an alternative EAP method to log on with, and possibly successfully? " [BA] As Alan noted, the mapping of IEEE 802.11 SSID to EAP method is typically 1:1. This is a major obstacle to deployment of more complex schemes, particularly since it is increasingly easy to add SSIDs since support for "virtual APs" has become more and more common. Just because something is complicated doesn't mean it is worthwhile - particularly if it requires major changes to existing standards. On Thu, Apr 7, 2016 at 2:24 PM, Stefan Winter wrote: > Hi, > > >> Sure. Nobody disputes that. The concern in the I-D is that you may have > >> multiple EAP methods configured in your supplicant. Those may require > >> the use of more than one realm identifier (e.g. @eduroam.org for PEAP > >> and @mnc45.mcc123.3gppnetwork.org for AKA') and that you consequently > >> *would* need more than one EAP-Response/Identity to route both > >> alternatives correctly. > > I think in the majority of cases, the mapping of SSID to EAP type is > 1-1. That's how supplicants are designed and implemented today. > > Sure, SSID -> EAP type is typically unique. 802.11 Roaming Consortium OI > -> EAP type is as well. > > So when a network with the configured SSID also emits the same Roaming > Consortium OI? All of a sudden the supplicant has two choices. > > >> Since that is not possible, the only solution if you really want to try > >> both EAP methods is to run an EAP conversation with one A. And then, if > >> that doesn't succeed, you run a second EAP conversation with the other > >> A. Only when you've tried all your EAP methods and none authenticated > >> you, give up and tell the user he is busted. > > That worries me. It's new behaviour. We're not clear if this will > work, or when it will work, or how it will work. > > > > Me, too. The addition of IEEE 802.11 Interworking to the mix brings a > whole new set of complexity. > > The alternative though is: try one of the methods, and if that account > doesn't work / has no credit / expired then you are stranded - even > though there would be an alternative EAP method to log on with, and > possibly successfully? > > Greetings, > > Stefan Winter > --94eb2c12339c5e7e6c052fec29e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stefan said:=C2=A0

"Me, too. The addition of IEEE 802.11 Interworking to the= mix brings a
whole new set of= complexity.

The alternative though is: try one o= f the methods, and if that account
doesn't work / has no credit / expired th= en you are stranded - even
though there would be an alternative EAP method to lo= g on with, and
possibly successfully?
= "

[BA] As Alan noted, the mapping of IEEE 802= .11 SSID to EAP method is typically 1:1.=C2=A0 This is a major obstacle to = deployment of more complex schemes, particularly since it is increasingly e= asy to add SSIDs since support for "virtual APs" has become more = and more common.

Just because something is complic= ated doesn't mean it is worthwhile - particularly if it requires major = changes to existing standards. =C2=A0



On Thu, Apr 7= , 2016 at 2:24 PM, Stefan Winter <stefan.winter@restena.lu><= /span> wrote:
Hi,

>> Sure. Nobody disputes that. The concern in the I-D is that you may= have
>> multiple EAP methods configured in your supplicant. Those may requ= ire
>> the use of more than one realm identifier (e.g. @eduroam.org for PEAP=
>> and @mnc45.mcc123.3gppnetwork.org for AKA') and = that you consequently
>> *would* need more than one EAP-Response/Identity to route both
>> alternatives correctly.
>=C2=A0 =C2=A0I think in the majority of cases, the mapping of SSID to E= AP type is 1-1.=C2=A0 That's how supplicants are designed and implement= ed today.

Sure, SSID -> EAP type is typically unique. 802.11 Roaming Consor= tium OI
-> EAP type is as well.

So when a network with the configured SSID also emits the same Roaming
Consortium OI? All of a sudden the supplicant has two choices.

>> Since that is not possible, the only solution if you really want t= o try
>> both EAP methods is to run an EAP conversation with one A. And the= n, if
>> that doesn't succeed, you run a second EAP conversation with t= he other
>> A. Only when you've tried all your EAP methods and none authen= ticated
>> you, give up and tell the user he is busted.
>=C2=A0 =C2=A0That worries me.=C2=A0 It's new behaviour.=C2=A0 We= 9;re not clear if this will work, or when it will work, or how it will work= .
>

Me, too. The addition of IEEE 802.11 Interworking to the mix brings = a
whole new set of complexity.

The alternative though is: try one of the methods, and if that account
doesn't work / has no credit / expired then you are stranded - even
though there would be an alternative EAP method to log on with, and
possibly successfully?

Greetings,

Stefan Winter

--94eb2c12339c5e7e6c052fec29e4-- From nobody Thu Apr 7 15:03:32 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C8E12D622 for ; Thu, 7 Apr 2016 15:03:31 -0700 (PDT) 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 autolearn_force=no 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 1qqT11nRHR5U for ; Thu, 7 Apr 2016 15:03:30 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4AD12D5E7 for ; Thu, 7 Apr 2016 15:03:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id AD0761AF4; Thu, 7 Apr 2016 22:03:29 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSXeMgm3vuuJ; Thu, 7 Apr 2016 22:03:29 +0000 (UTC) Received: from [192.168.120.60] (24-246-5-242.cable.teksavvy.com [24.246.5.242]) by mail.networkradius.com (Postfix) with ESMTPSA id 01EF4BEE; Thu, 7 Apr 2016 22:03:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Thu, 7 Apr 2016 18:03:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <20E4156D-F288-48B5-833B-9C74B3AED58F@deployingradius.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <5706CF11.7050803@restena.lu> <69F71DF4-EEBA-400D-9247-E0E571AB6FF4@deployingradius.com> To: Bernard Aboba X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Winter Stefan , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:03:32 -0000 > On Apr 7, 2016, at 5:52 PM, Bernard Aboba = wrote: >=20 > Alan said:=20 >=20 > " Or "DOMAIN\user" maps to "@example.com" >=20 > Because the system administrators at the company know (a) the local = AD domain name, and (b) the public realm of the company." >=20 > [BA] It is difficult to generalize, because it can be = company-specific. For example, within Microsoft, REDMOND\bernarda = happens to map to bernarda@redmond.corp.microsoft.com but how would any = implementation know this? =20 It doesn't. The administrator needs to know this, and to provision it. The implementation just knows that it uses byte string A for a "realm" = identifier, and byte string B for an EAP-MSCHAPv2 identifier. We should make it *very* clear in the document that the implementation = should be *provisioned* with the identifiers. And should not *derive* = them. Alan DeKok. From nobody Thu Apr 7 15:59:19 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBAA12D763; Thu, 7 Apr 2016 15:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 SYpRaAVnuMpt; Thu, 7 Apr 2016 15:59:15 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A81812D50B; Thu, 7 Apr 2016 15:59:15 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 73E3A324651; Fri, 8 Apr 2016 00:59:13 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [10.114.50.58]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 576AE238056; Fri, 8 Apr 2016 00:59:13 +0200 (CEST) Received: from OPEXCNORM4D.corporate.adroot.infra.ftgroup ([fe80::604f:15da:866b:fd8b]) by OPEXCNORM72.corporate.adroot.infra.ftgroup ([fe80::b14e:a56e:a38:474d%21]) with mapi id 14.03.0279.002; Fri, 8 Apr 2016 00:59:13 +0200 From: To: "radext@ietf.org" , "dime@ietf.org" Thread-Topic: Remote participation Thread-Index: AdGRIRkE9GJLEAjCT0C3CeEnDaDzQg== Date: Thu, 7 Apr 2016 22:59:12 +0000 Message-ID: <25612_1460069953_5706E641_25612_496_1_6B7134B31289DC4FAF731D844122B36E01E32715@OPEXCNORM4D.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.3.14.165416 Archived-At: Subject: [radext] Remote participation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:59:17 -0000 To remotely attend to IETF sessions via Meetecho, you have to register: https://www.ietf.org/meeting/remote-registration.html There is no fee to be a remote participant. regards, Lionel ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Fri Apr 8 06:32:23 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E55312D830 for ; Fri, 8 Apr 2016 06:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.506 X-Spam-Level: X-Spam-Status: No, score=0.506 tagged_above=-999 required=5 tests=[BAD_CREDIT=2.415, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no 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 toBult69ycQP for ; Fri, 8 Apr 2016 06:32:19 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [158.64.1.34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9B712D711 for ; Fri, 8 Apr 2016 06:32:19 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id C57FDB5EAD; Fri, 8 Apr 2016 15:32:15 +0200 (CEST) To: Bernard Aboba References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <5707B2DB.90002@restena.lu> Date: Fri, 8 Apr 2016 10:32:11 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3GmO1WgTPN1XG8T3UOiPHNr8p8cAUlewE" Archived-At: Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:32:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3GmO1WgTPN1XG8T3UOiPHNr8p8cAUlewE Content-Type: multipart/mixed; boundary="Da97Jt4F18AR865jBmPu553eBlxG1SS2f" From: Stefan Winter To: Bernard Aboba Cc: Alan DeKok , radext@ietf.org Message-ID: <5707B2DB.90002@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> In-Reply-To: --Da97Jt4F18AR865jBmPu553eBlxG1SS2f Content-Type: multipart/mixed; boundary="------------030606050001050308070608" This is a multi-part message in MIME format. --------------030606050001050308070608 Content-Type: multipart/alternative; boundary="------------070407010403070100060504" --------------070407010403070100060504 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, > [BA] As Alan noted, the mapping of IEEE 802.11 SSID to EAP method is > typically 1:1. This is a major obstacle to deployment of more complex > schemes, particularly since it is increasingly easy to add SSIDs since > support for "virtual APs" has become more and more common. > > Just because something is complicated doesn't mean it is worthwhile - > particularly if it requires major changes to existing standards.=20 What major changes are you talking about? IEEE 802.11 Interworking is an existing standard. Stefan > > > > On Thu, Apr 7, 2016 at 2:24 PM, Stefan Winter > > wrote: > > Hi, > > >> Sure. Nobody disputes that. The concern in the I-D is that you > may have > >> multiple EAP methods configured in your supplicant. Those may > require > >> the use of more than one realm identifier (e.g. @eduroam.org > for PEAP > >> and @mnc45.mcc123.3gppnetwork.org > for AKA') and that you > consequently > >> *would* need more than one EAP-Response/Identity to route both > >> alternatives correctly. > > I think in the majority of cases, the mapping of SSID to EAP > type is 1-1. That's how supplicants are designed and implemented > today. > > Sure, SSID -> EAP type is typically unique. 802.11 Roaming > Consortium OI > -> EAP type is as well. > > So when a network with the configured SSID also emits the same Roam= ing > Consortium OI? All of a sudden the supplicant has two choices. > > >> Since that is not possible, the only solution if you really > want to try > >> both EAP methods is to run an EAP conversation with one A. And > then, if > >> that doesn't succeed, you run a second EAP conversation with > the other > >> A. Only when you've tried all your EAP methods and none > authenticated > >> you, give up and tell the user he is busted. > > That worries me. It's new behaviour. We're not clear if this > will work, or when it will work, or how it will work. > > > > Me, too. The addition of IEEE 802.11 Interworking to the mix brings= a > whole new set of complexity. > > The alternative though is: try one of the methods, and if that acco= unt > doesn't work / has no credit / expired then you are stranded - even= > though there would be an alternative EAP method to log on with, and= > possibly successfully? > > Greetings, > > Stefan Winter > > --------------070407010403070100060504 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi,

[BA] As Alan noted, the mapping of IEEE 802.11 SSI= D to EAP method is typically 1:1.=C2=A0 This is a major obstacle to= deployment of more complex schemes, particularly since it is increasingly easy to add SSIDs since support for "virtual APs" has become more and more common.

Just because something is complicated doesn't mean it is worthwhile - particularly if it requires major changes to existing standards.=C2=A0

What major changes are you talking about?

IEEE 802.11 Interworking is an existing standard.

Stefan




On Thu, Apr 7, 2016 at 2:24 PM, Stefan= Winter <= stefan.winter@restena.lu> wrote:
Hi,

>> Sure. Nobody disputes that. The concern in the I-D is that you may have
>> multiple EAP methods configured in your supplicant. Those may require
>> the use of more than one realm identifier (e.g. @<= a moz-do-not-send=3D"true" href=3D"http://eduroam.org" rel=3D"noreferrer" target=3D"_blank">eduroam.org for PEAP
>> and @mnc45.mcc123.3gppnet= work.org for AKA') and that you consequently
>> *would* need more than one EAP-Response/Identity to route both
>> alternatives correctly.
>=C2=A0 =C2=A0I think in the majority of cases, the mapp= ing of SSID to EAP type is 1-1.=C2=A0 That's how supplicants are designed and implemented today.

Sure, SSID -> EAP type is typically unique. 802.11 Roaming Consortium OI
-> EAP type is as well.

So when a network with the configured SSID also emits the same Roaming
Consortium OI? All of a sudden the supplicant has two choices.

>> Since that is not possible, the only solution if you really want to try
>> both EAP methods is to run an EAP conversation with one A. And then, if
>> that doesn't succeed, you run a second EAP conversation with the other
>> A. Only when you've tried all your EAP methods and none authenticated
>> you, give up and tell the user he is busted.
>=C2=A0 =C2=A0That worries me.=C2=A0 It's new behaviour.= =C2=A0 We're not clear if this will work, or when it will work, or how it will work.
>

Me, too. The addition of IEEE 802.11 Interworking to the mix brings a
whole new set of complexity.

The alternative though is: try one of the methods, and if that account
doesn't work / has no credit / expired then you are stranded - even
though there would be an alternative EAP method to log on with, and
possibly successfully?

Greetings,

Stefan Winter


--------------070407010403070100060504-- --------------030606050001050308070608 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/MacGPG2 v2 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----- --------------030606050001050308070608-- --Da97Jt4F18AR865jBmPu553eBlxG1SS2f-- --3GmO1WgTPN1XG8T3UOiPHNr8p8cAUlewE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXB7LcAAoJEMDeajWKOdxmqWMQAKz9SwYpJDAyBzX8QDmMGrbC qUXni6HSY+yth96YQiqlxJXtitV5UlurKyCK7qz3a5zrD9UCfuLyL5xwNaycB6f3 7PCdr5J7vyLx74EwR7csdVePW4SgXUqNAorjn3x7pO6jTLZBwxB415+5jl1yDWjL nZQVMPxoUggogIclWrpxuScYeZ3E7uwdKgF2tfg6+iqB4H7LVCZ9xCmTwMhFPB0k l38ktjRp4EAFmnGfVerCWrdyOekChJinn1ZWYdrXDmXCQuluV3HDzeOWrH2HwrHz AqG0GsYU9SOsNTPCGiKi2s56KDtKO4Dk/hXxEz8MRjrKVgbSP/wwkP8CezWHUD+v +D++8IfRPmtfaSYfDqrpbBduZ+3ldNPAMmQjhQrAjV83yrJwShlKawi5LsSXBkDM fLiyQOkZjl4EQEIm3txBLCjuRMml4p+cteccSXaaRCdiB5bbmiSHKHoie1VsCEm4 LHsNd7vs5s0HvBaLw448C20ykJ75jQPVvDWlJdjCXZRA87smbLODMdZ1okTjG7gY Wl5S8g/0UXYrbXbALHYLufPIrcZBlsBgHscTwlh0DIzhDnJmW8EuA/MzM5+F3665 PQ5QMRm4+IP+0czYjMtXoPZL3DXpaaZwhFKGr1W7JxdzQHieYhU8ja4Rov/u2LGd WunPbC2nOu4znMeXUpwy =daYX -----END PGP SIGNATURE----- --3GmO1WgTPN1XG8T3UOiPHNr8p8cAUlewE-- From nobody Fri Apr 8 06:34:19 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4C4912D64A for ; Fri, 8 Apr 2016 06:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 DE1lsjTJ9kgY for ; Fri, 8 Apr 2016 06:34:11 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [158.64.1.34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A02F12D8AB for ; Fri, 8 Apr 2016 06:34:11 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id 029DDBB743 for ; Fri, 8 Apr 2016 15:34:08 +0200 (CEST) To: radext@ietf.org References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <5707B34E.4060009@restena.lu> Date: Fri, 8 Apr 2016 10:34:06 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="IVperpVDJ11tiCO9KFh8vKVG9V7flaloE" Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:34:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --IVperpVDJ11tiCO9KFh8vKVG9V7flaloE Content-Type: multipart/mixed; boundary="0XmAu7t1MTajQ9Hh1vkPxkD5UhGsRBlTX" From: Stefan Winter To: radext@ietf.org Message-ID: <5707B34E.4060009@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> In-Reply-To: --0XmAu7t1MTajQ9Hh1vkPxkD5UhGsRBlTX Content-Type: multipart/mixed; boundary="------------070403000507020408060409" This is a multi-part message in MIME format. --------------070403000507020408060409 Content-Type: multipart/alternative; boundary="------------070604010800040705060102" --------------070604010800040705060102 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > > " That worries me. It's new behaviour. We're not clear if this will > work, or when it will work, or how it will work." > > [BA] RFC 3748 and the EAP State Machine (RFC 4137) forbids chaining of > EAP methods outside a tunnel. I know of no EAP implementation that > supports this.=20 > So in general, it will not work - and moreover, is forbidden by the > standard. I don't think anybody in this whole thread ever talked about EAP method chaining. It's all about running an entirely separate second EAP conversation (this time, choosing a different EAP type, consequently with a different realm idntifier) if the first one didn't have a favourable outcome. Stefan > > On Thu, Apr 7, 2016 at 2:18 PM, Alan DeKok > wrote: > > On Apr 7, 2016, at 4:42 PM, Stefan Winter > > wrote:= > > Sure. Nobody disputes that. The concern in the I-D is that you > may have > > multiple EAP methods configured in your supplicant. Those may > require > > the use of more than one realm identifier (e.g. @eduroam.org > for PEAP > > and @mnc45.mcc123.3gppnetwork.org > for AKA') and that you > consequently > > *would* need more than one EAP-Response/Identity to route both > > alternatives correctly. > > I think in the majority of cases, the mapping of SSID to EAP > type is 1-1. That's how supplicants are designed and implemented > today. > > > Since that is not possible, the only solution if you really want > to try > > both EAP methods is to run an EAP conversation with one A. And > then, if > > that doesn't succeed, you run a second EAP conversation with the > other > > A. Only when you've tried all your EAP methods and none > authenticated > > you, give up and tell the user he is busted. > > That worries me. It's new behaviour. We're not clear if this > will work, or when it will work, or how it will work. > > Alan DeKok. > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------070604010800040705060102 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,


"=A0 That worries me.=A0 It= 's new behaviour.=A0 We're not clear if this will work, or when it will work, or how it will work."

[BA] RFC 3748 and the EAP State Machine (RFC 4137) forbids chaining of EAP methods outside a tunnel.=A0 I know of no EAP implementation that supports this.=A0
So in general, it will not work - and moreover, is forbidden by the standard.

I don't think anybody in this whole thread ever talked about EAP method chaining.

It's all about running an entirely separate second EAP conversation (this time, choosing a different EAP type, consequently with a different realm idntifier) if the first one didn't have a favourable outcome.

Stefan


On Thu, Apr 7, 2016 at 2:18 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Apr 7, 2016, at 4:42 PM, Stefan Winter <stefan.win= ter@restena.lu> wrote:
> Sure. Nobody disputes that. The concern in the I-D is that you may have
> multiple EAP methods configured in your supplicant. Those may require
> the use of more than one realm identifier (e.g. @eduroam.org for PEAP
> and @mnc45.mcc123.3gppnet= work.org for AKA') and that you consequently
> *would* need more than one EAP-Response/Identity to route both
> alternatives correctly.

=A0 I think in the majority of cases, the mapping of SSID to EAP type is 1-1.=A0 That's how supplicants are designed and implemented today.

> Since that is not possible, the only solution if you really want to try
> both EAP methods is to run an EAP conversation with one A. And then, if
> that doesn't succeed, you run a second EAP conversation with the other
> A. Only when you've tried all your EAP methods and none authenticated
> you, give up and tell the user he is busted.

=A0 That worries me.=A0 It's new behaviour.=A0 We're n= ot clear if this will work, or when it will work, or how it will work.

=A0 Alan DeKok.




_______________________________________________
radext mailing list
rad=
ext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------070604010800040705060102-- --------------070403000507020408060409 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/MacGPG2 v2 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----- --------------070403000507020408060409-- --0XmAu7t1MTajQ9Hh1vkPxkD5UhGsRBlTX-- --IVperpVDJ11tiCO9KFh8vKVG9V7flaloE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXB7NOAAoJEMDeajWKOdxm7k0P/3QRyan0R0VASPF1Q7lGfRW/ /voatgRgeXutrnwcBdxwwaUZG0DPZ/MT5yln2dd+AGGuAHQMvdnacPvy3rFkx1Fg OByoZc+7rxqeC05OtAEbKsBk/X5AbXeIjtXfFPScJ7XnPgp4CXGbWgLrp7RabFXH MXw8WO/ME7/8+W0OFiebDLZXTT1NdbSnDT4NC4aDVyfnbw6j5enGkYBls8nEineS FUl+/yfyhZzG7y9aWhBA1OTCZhUSc6ke8scKW2ro0U4BMTnyjub2ojyV7G9iStQ3 Tpsid8SEOrdsnd4L7DI6fNtJYZDkca+OxZxhkVsLbJignjtADpcxz2IQfo4nAdWv OMHVxwpwIIvcNhEvKaMv9JqrrT959MJfFCIQRwIOaTu8egC4eVGgMLW16EYC2b+x kJ9UhmYvz7LoJjLUjFM4Dvjh0N9b+8pyotnkaYvzcWvq9jt1Ac5vXB1uA7UMijCe 8dMG8oV564uxe3pdI2ddF5yotoNaW4Joc3J5tTGjIbcNsSMRwDEM0pIAk8vNR4oh IESf/ppwicWD5voKWZKkJExzLYxo/K/zUe1qXt5iMPy3C4NwFDWBE9CzoYBF9j9U MBdaP378sl3Zcmp9Sx0TC62Xe7yrMxw6mMCYTJ2ooGzNsMdMHbTrzDLRKLisMNBp NI/5iCMCUNeFcQkawGf9 =sFPM -----END PGP SIGNATURE----- --IVperpVDJ11tiCO9KFh8vKVG9V7flaloE-- From nobody Fri Apr 8 06:39:34 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA9B12D8C6 for ; Fri, 8 Apr 2016 06:39:34 -0700 (PDT) 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 autolearn_force=no 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 7tCq6mLHryqg for ; Fri, 8 Apr 2016 06:39:21 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 0B48112D774 for ; Fri, 8 Apr 2016 06:39:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 5442812AB; Fri, 8 Apr 2016 13:39:16 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cd7TjbHPqkM; Fri, 8 Apr 2016 13:39:16 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id B7CFC796; Fri, 8 Apr 2016 13:39:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <5707B2DB.90002@restena.lu> Date: Fri, 8 Apr 2016 09:39:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org, Bernard Aboba Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:39:34 -0000 On Apr 8, 2016, at 9:32 AM, Stefan Winter = wrote: > What major changes are you talking about? Retrying the same SSID with a different set of credentials is a big = change. No one does it today. It's hard to know what is the "correct" = thing to do. Alan DeKok. From nobody Fri Apr 8 06:44:50 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B8B12D589 for ; Fri, 8 Apr 2016 06:44:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 NDkFCFplMTnK for ; Fri, 8 Apr 2016 06:44:47 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02BCC12D0FF for ; Fri, 8 Apr 2016 06:44:47 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id 1A3CFBB72A; Fri, 8 Apr 2016 15:44:43 +0200 (CEST) To: Alan DeKok References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <5707B5C9.2000403@restena.lu> Date: Fri, 8 Apr 2016 10:44:41 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Uvbh4luRe6A8cJ4VgN91PfaScPa7aXtWN" Archived-At: Cc: radext@ietf.org, Bernard Aboba Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:44:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Uvbh4luRe6A8cJ4VgN91PfaScPa7aXtWN Content-Type: multipart/mixed; boundary="4umfccbeE46HOqowxg962QXHeA4CPuWAk" From: Stefan Winter To: Alan DeKok Cc: Bernard Aboba , radext@ietf.org Message-ID: <5707B5C9.2000403@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> In-Reply-To: <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> --4umfccbeE46HOqowxg962QXHeA4CPuWAk Content-Type: multipart/mixed; boundary="------------060609030400040202070402" This is a multi-part message in MIME format. --------------060609030400040202070402 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, >> What major changes are you talking about? > Retrying the same SSID with a different set of credentials is a big c= hange. No one does it today. It's hard to know what is the "correct" th= ing to do. > But those are no protocol changes. It's supplicants doing an extra step which is completely compliant with existing standards. And really, please do consider the examples I used earlier in this thread: situations where multiple sets of credentials are applicable to a single hotspot are becoming a reality right now. Thinking "SSID" is simply not sufficient any more. I'd rephrase your sentence above as "Retrying the same Wi-Fi hotspot with a different set of credentials because that hotspot matches multiple network selection criteria is a big change". But those multiple network selection criteria are hitting the street. We should be prepared for it. Greetings, Stefan --------------060609030400040202070402 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/MacGPG2 v2 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----- --------------060609030400040202070402-- --4umfccbeE46HOqowxg962QXHeA4CPuWAk-- --Uvbh4luRe6A8cJ4VgN91PfaScPa7aXtWN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXB7XJAAoJEMDeajWKOdxmW2QP/jtbjO9fgL2ec5/DQ4cvahJs z8yAL0WvPAkMWLW06dM8rIDtuo/qzb1RNmj30h1NefgimCm6s9Fo+olbcQRE/tFq ttkvbbhvV78UliS83qV1Vbt2fmmGkyn8OZnlFFwxheVtHMarUSo+AJ41tzPT+r52 GPJLFwscBjh26YoKeOKZVMtsh+zfCJh/ffSu3va5rCCTfygQyM1wVvHFYbSBdl39 bBJwFuZTY9EM0sfQZEPSBe34tXTOUQcTS5N2t4OwvXMd/aETRQMQEq86aTkvrinZ 9sgjPOtJVAukI++/aOJtIt3Xz95IaxMb447p0MEQcsjZpWyhzkDS3tyfj2MlC91m QFhm9nbwh1XvYDDbQSCfE6D1Dnq6fdrCfG0pRYBetxYI85WYqYGkxEJKLcgNDyaU HZmoBF9V3c0suqh9+3LcCEjzo/WBYusQlmkrD28dsPebCf7UwXou6jbT9PLjAnLu aJc0fXPALHZlkA6gIQem5B+ihgKsbYhGcNY677KFMv1RLIFMR+FEtV4BwNWBEjMz pUuFobj3coz4tXo6WTEqI6/ohuo3biVg4zFuJMw7M73FJox2CfLnXLkVDBQPIT/k lpauLqry0R/VtBb+G5nVh0QtyMQfL77Kk4hDp8sbs0FIrt24291+TYTjcegWbxg9 kh69IcRwDvVxETcReLIk =lVb/ -----END PGP SIGNATURE----- --Uvbh4luRe6A8cJ4VgN91PfaScPa7aXtWN-- From nobody Fri Apr 8 06:49:01 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975D112D8E6 for ; Fri, 8 Apr 2016 06:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 1NU9jusQqLHM for ; Fri, 8 Apr 2016 06:48:32 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1BBB12D8C9 for ; Fri, 8 Apr 2016 06:48:25 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id CC71DBB743 for ; Fri, 8 Apr 2016 15:48:23 +0200 (CEST) To: radext@ietf.org References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <5707B6A5.3060209@restena.lu> Date: Fri, 8 Apr 2016 10:48:21 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <5707B5C9.2000403@restena.lu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="h9g2ITlsI8c4LiDa7UcjnQM7pbvQunAVR" Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 13:48:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --h9g2ITlsI8c4LiDa7UcjnQM7pbvQunAVR Content-Type: multipart/mixed; boundary="bpDwoMbamDIdi3GnhDnmTBsH1IGgcRE9M" From: Stefan Winter To: radext@ietf.org Message-ID: <5707B6A5.3060209@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> In-Reply-To: <5707B5C9.2000403@restena.lu> --bpDwoMbamDIdi3GnhDnmTBsH1IGgcRE9M Content-Type: multipart/mixed; boundary="------------050801050704030506020504" This is a multi-part message in MIME format. --------------050801050704030506020504 Content-Type: multipart/alternative; boundary="------------090102070503090500050107" --------------090102070503090500050107 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > And really, please do consider the examples I used earlier in this > thread: situations where multiple sets of credentials are applicable to= > a single hotspot are becoming a reality right now. Speaking of those examples: I guess it would really help readers of the draft if those were included in the I-D. I'll be sure to add them, along with some beautiful ASCII art. Greetings, Stefan Winter > > Thinking "SSID" is simply not sufficient any more. I'd rephrase your > sentence above as > > "Retrying the same Wi-Fi hotspot with a different set of credentials > because that hotspot matches multiple network selection criteria is a > big change". > > But those multiple network selection criteria are hitting the street. W= e > should be prepared for it. > > Greetings, > > Stefan > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------090102070503090500050107 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

And really, please do consider the examples I used e=
arlier in this
thread: situations where multiple sets of credentials are applicable to
a single hotspot are becoming a reality right now.

Speaking of those examples: I guess it would really help readers of the draft if those were included in the I-D. I'll be sure to add them, along with some beautiful ASCII art.

Greetings,

Stefan Winter


Thinking "SSID" is simply not sufficient any more. I'd rephrase your
sentence above as

"Retrying the same Wi-Fi hotspot with a different set of credentials
because that hotspot matches multiple network selection criteria is a
big change".

But those multiple network selection criteria are hitting the street. We
should be prepared for it.

Greetings,

Stefan



_______________________________________________
radext mailing list
rad=
ext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------090102070503090500050107-- --------------050801050704030506020504 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/MacGPG2 v2 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----- --------------050801050704030506020504-- --bpDwoMbamDIdi3GnhDnmTBsH1IGgcRE9M-- --h9g2ITlsI8c4LiDa7UcjnQM7pbvQunAVR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXB7alAAoJEMDeajWKOdxm4c0P/RrOIEqMdjFO8JOUI6mkkqF5 6syvH4AgvczWn8Jb6ekNcRWDB7exx//ZmkpKSl/wdwk/TqIzsDyxgYJyywlcTW41 2q8Del2naajowHH0kIppN1BP2qdgo3HgeNtlKUpdhmrznhXKnwurWxgaJNSKZ/Rk OZWt9RiY6QLMmrXC3emaEkZ3AIXPIi7R/VvP4AND7SSu8J8JOzHuY2oy1H7+M1NI rmdjKpeEgQJi4tUdDlM8dWvoBc2gXnl8v/vEoUnqs1qIqpMIVHxU0rJSmTAlMnBO gtcOnNnmYZGkuY+uIkOLR10Y81JPSCdcl8FAvpaZjddhQax2UsKhY3FoSsP4b5Wd lx7nQFd73hYdJUTDIQwLpiIps/7WblH+pip+cKVyB6B6VgNmW9dfAWt/bmipBZcX TV5jVIVYBr++lmpufTyHcujRGidsOrlsrWM3JM/hxbKEnkfp7oZLrcwbGYYwVygO WhhoSm185846XZpuW2q+e47ZMSW29WKMJc5q7lfs/IGknApuH+YgK0A2/hg/stTN FIRdHn7oMn6MQz6ldFiyRcPt81V/cHzwGBvn4/0DeTE/3EKOYFpo2Fx1AuHK5fkH knoa/ASD1R9I1VXNgp3cjWavAnEz1uw5GmEypYAjqouRm/uKInHE9/A0XM05x2/k HzPL2bGGVdrUnByF5xji =lCdC -----END PGP SIGNATURE----- --h9g2ITlsI8c4LiDa7UcjnQM7pbvQunAVR-- From nobody Fri Apr 8 07:03:32 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A1712D8FF for ; Fri, 8 Apr 2016 07:03:30 -0700 (PDT) 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 autolearn_force=no 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 5uDlwVLcsfE9 for ; Fri, 8 Apr 2016 07:03:27 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCD312D8E8 for ; Fri, 8 Apr 2016 07:03:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 537FB772; Fri, 8 Apr 2016 14:03:26 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ud2JIAd20Cys; Fri, 8 Apr 2016 14:03:26 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 0B1C1221; Fri, 8 Apr 2016 14:03:24 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: <5707B5C9.2000403@restena.lu> Date: Fri, 8 Apr 2016 10:03:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3D30C6C4-6AE5-4A93-9216-BF9AC13C4014@deployingradius.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> To: Winter Stefan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: radext@ietf.org, Bernard Aboba Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:03:31 -0000 On Apr 8, 2016, at 9:44 AM, Stefan Winter = wrote: > But those are no protocol changes. It's supplicants doing an extra = step > which is completely compliant with existing standards. Sure. But they are behavioural changes. > And really, please do consider the examples I used earlier in this > thread: situations where multiple sets of credentials are applicable = to > a single hotspot are becoming a reality right now. Ugh. This means that people see a need for it, but not necessarily = that they're doing it *right*. Which means that this document is even more time-sensitive. > But those multiple network selection criteria are hitting the street. = We > should be prepared for it. Who is doing this, and why? Alan DeKok. From nobody Fri Apr 8 07:12:04 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A47812D90B for ; Fri, 8 Apr 2016 07:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no 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 rscROIjEsAgc for ; Fri, 8 Apr 2016 07:12:00 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BAD112D906 for ; Fri, 8 Apr 2016 07:12:00 -0700 (PDT) Received: from viper.local (unknown [IPv6:2001:a18:1:40::2]) by smtp.restena.lu (Postfix) with ESMTPSA id 5360EB5EAD; Fri, 8 Apr 2016 16:11:57 +0200 (CEST) To: Alan DeKok References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> <3D30C6C4-6AE5-4A93-9216-BF9AC13C4014@deployingradius.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <5707BC2A.9030901@restena.lu> Date: Fri, 8 Apr 2016 11:11:54 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <3D30C6C4-6AE5-4A93-9216-BF9AC13C4014@deployingradius.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="mWHvgOsQaJpDeqweWMoSPW9TS12tAI4ij" Archived-At: Cc: radext@ietf.org, Bernard Aboba Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:12:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --mWHvgOsQaJpDeqweWMoSPW9TS12tAI4ij Content-Type: multipart/mixed; boundary="w0NirK4dQOsSs9hKkvuk1BjNa9eWX2JrJ" From: Stefan Winter To: Alan DeKok Cc: Bernard Aboba , radext@ietf.org Message-ID: <5707BC2A.9030901@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> <3D30C6C4-6AE5-4A93-9216-BF9AC13C4014@deployingradius.com> In-Reply-To: <3D30C6C4-6AE5-4A93-9216-BF9AC13C4014@deployingradius.com> --w0NirK4dQOsSs9hKkvuk1BjNa9eWX2JrJ Content-Type: multipart/mixed; boundary="------------090102080500090408030808" This is a multi-part message in MIME format. --------------090102080500090408030808 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, >> But those multiple network selection criteria are hitting the street. = We >> should be prepared for it. > Who is doing this, and why? > Wi-Fi offloading: ordinary Wi-Fi hotspots partner with cellular providers. The Wi-Fi network still has its SSID and users - 802.11 Interworking throws in new users to the same hotspot based on their SIM card. As soon as the first user has an SSID-based account with the Wi-Fi provider *and* a matching SIM card in his device, the ambiguity begins. Stefan --------------090102080500090408030808 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/MacGPG2 v2 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----- --------------090102080500090408030808-- --w0NirK4dQOsSs9hKkvuk1BjNa9eWX2JrJ-- --mWHvgOsQaJpDeqweWMoSPW9TS12tAI4ij Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQIcBAEBCgAGBQJXB7wqAAoJEMDeajWKOdxm28oP/3tTz95SetFPUX2Du0tNUIB7 POsyaJ+CNYEk8duW8SO8Rvh8NGTMyFh6LomAJ/ttUmta3kBXVV29qvjcxp0WyhBv WL4T2lTUInzZnU22A0BDsI/hPZkPVlz6XX6+vSBm+RgkpqRYHF1raC9Pn0WpAcZM a1v6D4wLu+HaTv+3MW8uOLOU2dewji1PXAQ5Qe++nEfdgoqbDLUHPcskjCmn+Pea 7DsIU9zVPi60UNuTTxnLOZKUoe5VuCgG4bCdsr+sxIwPlnwNcjtCibgAv3++LcTl vhqSTjIhIwU7ccd7KnOAYh/orFX2oDNGQvC9AYvSTMPGOD1t6qFcgdINBj7RjRFf RqRoYiLN1rg4AT217r3CRgvYCWvRWbekvgkKk45jkA3N79LGrSuo5prFThRfl3o9 TnkHIEvNXCAql97ZBgW3iNUU/7XQm0WlbFcyFRbp+VL3NDGN+fLtDtbfxpqnkS/L aZ/MitDyNgl9MVA4dD2RLw484uCLdPjSq9ezBjA8QaPMBZRsHMADG0SAo+A9EDH8 YNb4BcTz4puln/lXLXXikPRBlqIXLu2H34GvUhOZbR+NG7cqhQHIGLPzO1Kioek4 U32g39FJVtPt18dWsSACXS4Db8O11IAwk93rsk+V+BL1U4c/FrO+4jCwyIjkiEy6 DViKXxdwTldrIQ0/q9qU =XT6j -----END PGP SIGNATURE----- --mWHvgOsQaJpDeqweWMoSPW9TS12tAI4ij-- From nobody Fri Apr 8 07:26:05 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F0112D52A for ; Fri, 8 Apr 2016 07:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 wfMEzhGXXXqO for ; Fri, 8 Apr 2016 07:26:02 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C4212D6EB for ; Fri, 8 Apr 2016 07:26:01 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id k1so139798967vkb.0 for ; Fri, 08 Apr 2016 07:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dROlnT0zh1jG8nxXsgZOn4o3aktVG2Kyja8+he4q3Mg=; b=0fg3EUVwhYOK8j1+qK/ztWe05sZD/cOXkZnTH8B5nLby1RdG21kaj78QA+mEpVGvqy j/OElGUsUNpS7Lh2drL32SFeaVq5vGLSKDue+BvZnyikuHN/lftwruEB5b3tHXSbNvID 3c09db5xeIfVDyKcXPROPeeaAcCeUPInXrAVD7jVkSNYuCmenNEkWQ40AR4Fh+baMHAk d+XR0nSSevxTjbCQOasK0Ahgzaw/lL+H4cOA5aT1RZZU3krnn8JEV4XKb48Je1rioAth g5DZBhQ6IMwOkGaFA2OZiZfSNgT5ghIOoYgR8PaGdn6m2svB9WYyWX4nKTqfRjkU9CbB yj/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dROlnT0zh1jG8nxXsgZOn4o3aktVG2Kyja8+he4q3Mg=; b=db4+dyvH9fOsCYKp4Wj/VO9x0lnudaBscQXfGNrDuMDWMiTNKW4WrkYWNsGCBPyHZk h5+2eR0qsg31IQbydASlHNEffQvn5ZPA8CQTgyOhHZXmZHmO4mWsM+pb8aNAVhEZFMV1 DOI8ntitJlNykbejJV0dJANzVHfzw1Wj+o3hEQOVpOO3pzxKjFlty/guOd2cs3nnJ4ds Zb6ujWHmNelmGz/Ak+tBEQjUJme8p743rxnbhsD8SB2Ci+DYq9wvoGf3mOLTY5OEoyO0 KL0C9hWzlmRb2KN743bL+fWEMtfr3FsBSzRQ5ueGMxahIFiDG/vE8/mooMnKBm8a09kQ etYA== X-Gm-Message-State: AD7BkJKSFsm/lCQ3uGaK5OeKo173R5Movep2ulge5n1PHJHbUuKjioBaCt2HBHcdD+L2QPaiFsyUq55f1rb3Lg== X-Received: by 10.31.188.142 with SMTP id m136mr4317353vkf.89.1460125560855; Fri, 08 Apr 2016 07:26:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.40 with HTTP; Fri, 8 Apr 2016 07:25:41 -0700 (PDT) In-Reply-To: <5707B5C9.2000403@restena.lu> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> From: Bernard Aboba Date: Fri, 8 Apr 2016 07:25:41 -0700 Message-ID: To: Stefan Winter Content-Type: multipart/alternative; boundary=001a1143026e61e23f052ff9f934 Archived-At: Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:26:04 -0000 --001a1143026e61e23f052ff9f934 Content-Type: text/plain; charset=UTF-8 Stefan said: " But those multiple network selection criteria are hitting the street. We should be prepared for it. " [BA] They are "hitting the street" in the same sense that an egg thrown from a tall building will "hit the street" - and go "splat!" We don't change the side walk just because people throw rotten eggs from tall buildings. The reality is that "IEEE 802.11 internetworking" has virtually no deployment today. Is *any* major OS vendor (iOS, Android, etc.) intending to implement this? If not, we can very happily ignore it. In fact, I'd claim it is our *duty* to ignore it, rather than trying to turn EAP into IMS. On Fri, Apr 8, 2016 at 6:44 AM, Stefan Winter wrote: > Hi, > > >> What major changes are you talking about? > > Retrying the same SSID with a different set of credentials is a big > change. No one does it today. It's hard to know what is the "correct" > thing to do. > > > > But those are no protocol changes. It's supplicants doing an extra step > which is completely compliant with existing standards. > > And really, please do consider the examples I used earlier in this > thread: situations where multiple sets of credentials are applicable to > a single hotspot are becoming a reality right now. > > Thinking "SSID" is simply not sufficient any more. I'd rephrase your > sentence above as > > "Retrying the same Wi-Fi hotspot with a different set of credentials > because that hotspot matches multiple network selection criteria is a > big change". > > But those multiple network selection criteria are hitting the street. We > should be prepared for it. > > Greetings, > > Stefan > --001a1143026e61e23f052ff9f934 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stefan said:=C2=A0

"
But those multiple network selection criteria are = hitting the street. We
should be prepared for it.
"

[BA] They are "hitting the= street" in the same sense that an egg thrown from a tall building wil= l "hit the street" - and go "splat!"

We don't change the side walk just because people throw rotten e= ggs from tall buildings.

The reality is that "= ;IEEE 802.11 internetworking" has virtually no deployment today.=C2=A0=

Is *any* major OS vendor (iOS, Android, etc.) int= ending to implement this?=C2=A0

If not, we can ver= y happily ignore it.=C2=A0 In fact, I'd claim it is our *duty* to ignor= e it, rather than trying to turn EAP into IMS.=C2=A0

On Fri, Apr 8, 2016 at 6:44= AM, Stefan Winter <stefan.winter@restena.lu> wrote:<= br>
Hi,

>> What major changes are you talking about?
>=C2=A0 =C2=A0Retrying the same SSID with a different set of credentials= is a big change.=C2=A0 No one does it today.=C2=A0 It's hard to know w= hat is the "correct" thing to do.
>

But those are no protocol changes. It's supplicants doing an ext= ra step
which is completely compliant with existing standards.

And really, please do consider the examples I used earlier in this
thread: situations where multiple sets of credentials are applicable to
a single hotspot are becoming a reality right now.

Thinking "SSID" is simply not sufficient any more. I'd rephra= se your
sentence above as

"Retrying the same Wi-Fi hotspot with a different set of credentials because that hotspot matches multiple network selection criteria is a
big change".

But those multiple network selection criteria are hitting the street. We should be prepared for it.

Greetings,

Stefan

--001a1143026e61e23f052ff9f934-- From nobody Fri Apr 8 07:31:07 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B30C12D90C for ; Fri, 8 Apr 2016 07:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 7MQXKFDRgrL0 for ; Fri, 8 Apr 2016 07:31:01 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2501812D90B for ; Fri, 8 Apr 2016 07:31:01 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id c4so139912067vkb.3 for ; Fri, 08 Apr 2016 07:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5SVrd1paKUCgvpuSrfM9bw6E5AdreXdkkoLQxOABh58=; b=eBHDZOiKSbZu0/Ep+FICFMfEmfAaqMiXNjtGYz3eQyTvvNoHuKUgKvWv/b8odcYnSj jjWRDZya9lpdC8U73w+gsCz/3WZOSKWfVhZ37YV/Hsl/DIoSxNKRsQhQO1PYyzZZPbh7 wp9zV3zLvjUt2RJJG74r2MYL6R0wHbuIcSIX4mWWqx7OQva1Bku4hlTxqBT4NZygj5tq MEoLSshcPm4G8WMs78FXphVyaYEjlNti1FMjv72VL4rhe8dFyWLeGcxQ9NYsb4+mn5WE 2afWz3nhmsrocx/u4QB/OViR3Y6Ujqbql1cZxW79gD3zwnIp0+s4/dTMaZo+iLCCTb/a FTiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5SVrd1paKUCgvpuSrfM9bw6E5AdreXdkkoLQxOABh58=; b=dYL2BxRZc6WRfVYs/S2vzsniS2BkKn6xo2xJSoZYpMkh7dYJEGRK3dXKJ/4VCGbfzZ KB6j+zfaBc4Oc4qpqs0vEF3kkg9Ti1ObrR6v8AGWACbyzlPJ1Zeg1jitO6dctwuFtWUQ CHD44IPt7sHGtR9LljGY0Mrqnu9neVFp5c0xC4mSZYoJklxDRedC4rFfIgNRKksnbbqT UcqWYT2MTTK5F81f/5QhU8kMP7BwdLz8yMVMyRsURP23Rw+WqFMl4vs1mC+vjZLPOxKX tH2AP6AfaHMUeEPI6cqlwsMCpekwAp+J3xhrim5lZ3NjyVsokmNUQNvdQaOt3FaJfzWT 1H3Q== X-Gm-Message-State: AD7BkJLEZgabr7lqXSswqzKdcQFzgBbuE9lngEE9CPMA8L0wP/iMePDtkMExVCiHKHePw7thEUiUXhp7WeWfXw== X-Received: by 10.31.181.206 with SMTP id e197mr4625729vkf.74.1460125860225; Fri, 08 Apr 2016 07:31:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.4.40 with HTTP; Fri, 8 Apr 2016 07:30:40 -0700 (PDT) In-Reply-To: <5707BC2A.9030901@restena.lu> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> <3D30C6C4-6AE5-4A93-9216-BF9AC13C4014@deployingradius.com> <5707BC2A.9030901@restena.lu> From: Bernard Aboba Date: Fri, 8 Apr 2016 07:30:40 -0700 Message-ID: To: Stefan Winter Content-Type: multipart/alternative; boundary=001a11439e4c39eb68052ffa0b0a Archived-At: Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:31:06 -0000 --001a11439e4c39eb68052ffa0b0a Content-Type: text/plain; charset=UTF-8 Stefan said: "Wi-Fi offloading: ordinary Wi-Fi hotspots partner with cellular providers. The Wi-Fi network still has its SSID and users - 802.11 Interworking throws in new users to the same hotspot based on their SIM card. As soon as the first user has an SSID-based account with the Wi-Fi provider *and* a matching SIM card in his device, the ambiguity begins." [BA] The Wi-Fi hotspot could just as easily create a new SSID for the cellular network, and then it would "just work" with existing implementations. Sorry, but the mere existance of an undeployed standard is not a good reason to make major changes in the implementation of 3+ billion devices, especially when operational choices exist that would make those changes unnecessary. On Fri, Apr 8, 2016 at 7:11 AM, Stefan Winter wrote: > Hi, > > >> But those multiple network selection criteria are hitting the street. We > >> should be prepared for it. > > Who is doing this, and why? > > > > Wi-Fi offloading: ordinary Wi-Fi hotspots partner with cellular > providers. The Wi-Fi network still has its SSID and users - 802.11 > Interworking throws in new users to the same hotspot based on their SIM > card. As soon as the first user has an SSID-based account with the Wi-Fi > provider *and* a matching SIM card in his device, the ambiguity begins. > > Stefan > --001a11439e4c39eb68052ffa0b0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stefan said:=C2=A0

"Wi-Fi offloading: ordinary Wi-Fi hotspots partner with c= ellular
providers. The Wi-Fi n= etwork still has its SSID and users - 802.11
Interworking throws in new users to= the same hotspot based on their SIM
<= span style=3D"font-size:12.8px">card. As soon as the first user has an SSID= -based account with the Wi-Fi
provider *and* a matching SIM card in his dev= ice, the ambiguity begins."

[BA] The W= i-Fi hotspot could just as easily create a new SSID for the cellular networ= k, and then it would "just work" with existing implementations.= =C2=A0

Sorry, but the mere existance of an undeplo= yed standard is not a good reason to make major changes in the implementati= on of 3+ billion devices, especially when operational choices exist that wo= uld make those changes unnecessary.=C2=A0

On Fri, Apr 8, 2016 at 7:11 AM, Stefan = Winter <stefan.winter@restena.lu> wrote:
Hi,

>> But those multiple network selection criteria are hitting the stre= et. We
>> should be prepared for it.
>=C2=A0 =C2=A0Who is doing this, and why?
>

Wi-Fi offloading: ordinary Wi-Fi hotspots partner with cellular
providers. The Wi-Fi network still has its SSID and users - 802.11
Interworking throws in new users to the same hotspot based on their SIM
card. As soon as the first user has an SSID-based account with the Wi-Fi provider *and* a matching SIM card in his device, the ambiguity begins.

Stefan

--001a11439e4c39eb68052ffa0b0a-- From nobody Fri Apr 8 07:33:13 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B16E12D80F for ; Fri, 8 Apr 2016 07:33:12 -0700 (PDT) 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 autolearn_force=no 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 Hl9ZK6AggrRW for ; Fri, 8 Apr 2016 07:33:11 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 07AFA12D1D6 for ; Fri, 8 Apr 2016 07:33:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 58DF216FD; Fri, 8 Apr 2016 14:33:10 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9ZiL8yDHnCB; Fri, 8 Apr 2016 14:33:10 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id C96CD772; Fri, 8 Apr 2016 14:33:09 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Alan DeKok In-Reply-To: Date: Fri, 8 Apr 2016 10:33:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <516ABB35-CE5C-4EC5-90C4-8DD93C779FB6@deployingradius.com> References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> To: Bernard Aboba X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Winter Stefan , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 14:33:12 -0000 On Apr 8, 2016, at 10:25 AM, Bernard Aboba = wrote: >=20 > Stefan said:=20 >=20 > " > But those multiple network selection criteria are hitting the street. = We > should be prepared for it. > " I would lean towards "discourage", rather than "be prepared" > [BA] They are "hitting the street" in the same sense that an egg = thrown from a tall building will "hit the street" - and go "splat!" >=20 > We don't change the side walk just because people throw rotten eggs = from tall buildings. >=20 > The reality is that "IEEE 802.11 internetworking" has virtually no = deployment today.=20 >=20 > Is *any* major OS vendor (iOS, Android, etc.) intending to implement = this?=20 >=20 > If not, we can very happily ignore it. In fact, I'd claim it is our = *duty* to ignore it, rather than trying to turn EAP into IMS.=20 I would say ignoring it is insufficient. We should explain why it's a = bad idea. Trying credentials until one works is a *terrible* idea. I understand = why people do it, but I also understand why people nail their feet to = the floor: incompetence, lack of attention, etc. For the case Stefan mentioned, the choice of credentials is simple, = and can be made once, when the new credentials are provisioned. The = cheapest one is used. The alternative is to over-bill the user, which they will complain = about. This says that the 802.1X config utility Stefan is also pushing needs = to have an way of describing cost (or preference of credentials), so = that the decision process can be documented, and made automatically. Alan DeKok. From nobody Fri Apr 8 09:00:35 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8963D12D547 for ; Fri, 8 Apr 2016 09:00:33 -0700 (PDT) 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 autolearn_force=no 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 oP-h-lIq94ri for ; Fri, 8 Apr 2016 09:00:30 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 2F84B12D1AB for ; Fri, 8 Apr 2016 09:00:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.networkradius.com (Postfix) with ESMTP id 8C0D712AB for ; Fri, 8 Apr 2016 16:00:26 +0000 (UTC) Received: from mail.networkradius.com ([127.0.0.1]) by localhost (mail-server.vmhost2.networkradius.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_grlLemb5xe for ; Fri, 8 Apr 2016 16:00:26 +0000 (UTC) Received: from [192.168.20.14] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by mail.networkradius.com (Postfix) with ESMTPSA id 3D87F772 for ; Fri, 8 Apr 2016 16:00:26 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Fri, 8 Apr 2016 12:00:24 -0400 To: radext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [radext] CoA-proxy wording X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 16:00:33 -0000 As discussed today: ... Due to the requirements of Section 2.3 of [RFC5176], a Visited Network MUST remove Operator-Name and Operator-NAS-Identifier from any CoA-Request or Disconnect-Request packet prior to proxying that packet to a CoA server. This requirement can be phrased more generically. All attributes added by a RADIUS proxy when sending packets from the Visited Network to the Home Network Network MUST be removed by the equivalent CoA proxy from packets which travel the reverse path. ... From nobody Mon Apr 11 00:03:15 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF90A12E643 for ; Mon, 11 Apr 2016 00:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no 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 s8GBDZ6XpTaB for ; Mon, 11 Apr 2016 00:03:10 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DE2812DDD3 for ; Mon, 11 Apr 2016 00:03:09 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 6917B43B01; Mon, 11 Apr 2016 09:03:06 +0200 (CEST) To: Bernard Aboba References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <570B4C2A.8060504@restena.lu> Date: Mon, 11 Apr 2016 09:03:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="X5C6dATNXMP9wDRCBasGv7bOM47Pe5b5M" Archived-At: Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 07:03:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X5C6dATNXMP9wDRCBasGv7bOM47Pe5b5M Content-Type: multipart/mixed; boundary="jlMLJpnG2axouAdx8LwSVGneXaNKMpkxr" From: Stefan Winter To: Bernard Aboba Cc: Alan DeKok , radext@ietf.org Message-ID: <570B4C2A.8060504@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> In-Reply-To: --jlMLJpnG2axouAdx8LwSVGneXaNKMpkxr Content-Type: multipart/mixed; boundary="------------010708090706050906080905" This is a multi-part message in MIME format. --------------010708090706050906080905 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, > Is *any* major OS vendor (iOS, Android, etc.) intending to implement th= is?=20 Funny that you ask this question. It is part of the Windows 10 Wi-Fi conf= ig: https://msdn.microsoft.com/en-us/library/windows/desktop/ms706965%28v=3Dv= s.85%29.aspx You may want to take a look at "WLANProfile -> Hotspot2 -> NAIRealm / Network3GPP / RoamingConsortium" fields particularly. And it is also in iOS and Mac OS X. https://developer.apple.com/library/ios/featuredarticles/iPhoneConfigurat= ionProfileRef/Introduction/Introduction.html#//apple_ref/doc/uid/TP400102= 06-CH1-SW30 The parts "RoamingConsortiumOIs, NAIRealmNames, MCCAndMNCs are the important bits here. Also, note how "SSID_STR" states: "In iOS 7.0 and later, this is optional if a DomainName value is provided". Finally, even Android (extra emphasis on EVEN) has introduced support in Android M: https://developer.android.com/reference/android/net/wifi/WifiConfiguratio= n.html Things to look for here is roamingConsortiumIDs, the method isPasspoint() etc. They do miss the MCC/MNC bits admittedly, but it's Android after all and they have to lag behind *somewhere* :-) > If not, we can very happily ignore it. In fact, I'd claim it is our > *duty* to ignore it, rather than trying to turn EAP into IMS.=20 The answer to the previous question was a Yes. Greetings, Stefan Winter >=20 > On Fri, Apr 8, 2016 at 6:44 AM, Stefan Winter > wrote: >=20 > Hi, >=20 > >> What major changes are you talking about? > > Retrying the same SSID with a different set of credentials is a= big change. No one does it today. It's hard to know what is the "corre= ct" thing to do. > > >=20 > But those are no protocol changes. It's supplicants doing an extra = step > which is completely compliant with existing standards. >=20 > And really, please do consider the examples I used earlier in this > thread: situations where multiple sets of credentials are applicabl= e to > a single hotspot are becoming a reality right now. >=20 > Thinking "SSID" is simply not sufficient any more. I'd rephrase you= r > sentence above as >=20 > "Retrying the same Wi-Fi hotspot with a different set of credential= s > because that hotspot matches multiple network selection criteria is= a > big change". >=20 > But those multiple network selection criteria are hitting the stree= t. We > should be prepared for it. >=20 > Greetings, >=20 > Stefan >=20 >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette 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 --------------010708090706050906080905 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 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----- --------------010708090706050906080905-- --jlMLJpnG2axouAdx8LwSVGneXaNKMpkxr-- --X5C6dATNXMP9wDRCBasGv7bOM47Pe5b5M 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 iQIcBAEBCgAGBQJXC0wqAAoJEMDeajWKOdxmu/IQALNJshuM6aGTcZzKbXKLn33/ r73pNZ/2XIHkYZBKbwGIN3+9VHtIP9gA3mTDnssHGfJotydPANKx5PxFnnNLJ9T5 rpfDjeVKGo2YMq7CoCWguS9Yuplf/k/xpXVbCM6+LPMoAREO12G7FsSfiNWT0KPB 7I/RiVZnU2rz0y164O1wn3DVkCg7pUJjTjTEna5aqp47sKuMeLOMCYUZS59DrjSH 2/dw7YMnH1s3pcNZ5P5Sx/hb6L8ITjhHSpHWsOJM8hy4V7cgGofCZBDbso5gYyv1 J/aWuZwaVnIDMzTF5xf8Azxr+kPVHYMMlhDeFWYaYneKPa/t+gNFT8LvVYB6rILB Sx62DwiQ064hIRw9J5rnjrLdrSqJx/63kx9kTosDC5wEP0ckOBkBxZR8rCwTKNQv pEjm78+Pe/zrqGMaXM0rvz54OUUv0wl75DHfExsBQGBxZck6W0M97DWabGIPlpHN hg6TgPu1bIedqa+YjRXXntc7ETa1BCXnWXf524eP8rbgKfiypYXML6WSxAmKN9Ny nXedNMbohlk8MhaU1egAbTuPRs3QsZErTMdGGcM/STJkGHywRCka0SdWuSiAtkxw Dqw0HCjtNFz2LDUNNHY3Khvjmzxscgkoj3th/KDbjrndIf7TUWg3r70u+BgAOPHb hyNS69u4JV6NJ0IJRGUI =I/qJ -----END PGP SIGNATURE----- --X5C6dATNXMP9wDRCBasGv7bOM47Pe5b5M-- From nobody Mon Apr 11 00:09:29 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009C312E79A for ; Mon, 11 Apr 2016 00:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no 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 UlON8G6nxa_P for ; Mon, 11 Apr 2016 00:09:26 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3756312E799 for ; Mon, 11 Apr 2016 00:09:26 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id C8A3543B01; Mon, 11 Apr 2016 09:09:24 +0200 (CEST) To: Bernard Aboba References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> <3D30C6C4-6AE5-4A93-9216-BF9AC13C4014@deployingradius.com> <5707BC2A.9030901@restena.lu> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <570B4DA4.4000908@restena.lu> Date: Mon, 11 Apr 2016 09:09:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TShVxidNU1VbmrNHg4fDtMxKWJWpV1Wkh" Archived-At: Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 07:09:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TShVxidNU1VbmrNHg4fDtMxKWJWpV1Wkh Content-Type: multipart/mixed; boundary="SkR4ta5X2EGOuFSHpBmRcrisoAi5nkith" From: Stefan Winter To: Bernard Aboba Cc: radext@ietf.org, Alan DeKok Message-ID: <570B4DA4.4000908@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-populating-eapidentity-00.txt References: <20160321142112.31928.83414.idtracker@ietfa.amsl.com> <56F00537.2070802@restena.lu> <50E9CC89-F169-40F5-A049-40A5AE1FD572@deployingradius.com> <56F0FAD0.2010005@restena.lu> <8380480A-234A-438B-9DB1-03F129C7D3C8@deployingradius.com> <57026378.1020702@restena.lu> <8AFF671E-6E04-42C2-9B3F-E1C42F4EC709@gmail.com> <5706C62B.6040200@restena.lu> <5706D020.7000907@restena.lu> <5707B2DB.90002@restena.lu> <9C54A63D-9554-4AA4-A8E0-7207B1CA25E7@deployingradius.com> <5707B5C9.2000403@restena.lu> <3D30C6C4-6AE5-4A93-9216-BF9AC13C4014@deployingradius.com> <5707BC2A.9030901@restena.lu> In-Reply-To: --SkR4ta5X2EGOuFSHpBmRcrisoAi5nkith Content-Type: multipart/mixed; boundary="------------020202020606060900040103" This is a multi-part message in MIME format. --------------020202020606060900040103 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, > [BA] The Wi-Fi hotspot could just as easily create a new SSID for the > cellular network, and then it would "just work" with existing > implementations.=20 But they don't. Probably because popular advice in the Wi-Fi world is: don't add more SSIDs, the beacon time will clog up the network. Folks have been saying that for a decade (and as deployers, we've been hit by this; where eduroam would not be added by a commercial vendor because the extra SSID was unpopular on their side), and as an unsurprising consequence, people are looking for alternatives to yet-another-SSID. > Sorry, but the mere existance of an undeployed standard is not a good > reason to make major changes in the implementation of 3+ billion > devices, especially when operational choices exist that would make thos= e > changes unnecessary.=20 It seems like you want to start a fight against the existence of Interworking, Passpoint, and/or the mindset of people considering deploying it. That may even be a good idea in general - I have mixed feelings about Passpoint, too. But radext is not the place to fight this fight. We really have little to do with it, except that there are consequences for EAP method selection. And as my other mail already alluded too, supplicants are already being implemented and shipped; which makes it logical to provide words of wisdom to proper implementation. We are even already late, considering that finished code is out in the wild already. I strongly suggest not to go down a rathole of "Passpoint sucks, we must boycot it!" here. There are certainly other venues where such a plea is more on-topic. Greetings, Stefan Winter >=20 > On Fri, Apr 8, 2016 at 7:11 AM, Stefan Winter > wrote: >=20 > Hi, >=20 > >> But those multiple network selection criteria are hitting the st= reet. We > >> should be prepared for it. > > Who is doing this, and why? > > >=20 > Wi-Fi offloading: ordinary Wi-Fi hotspots partner with cellular > providers. The Wi-Fi network still has its SSID and users - 802.11 > Interworking throws in new users to the same hotspot based on their= SIM > card. As soon as the first user has an SSID-based account with the = Wi-Fi > provider *and* a matching SIM card in his device, the ambiguity beg= ins. >=20 > Stefan >=20 >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette 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 --------------020202020606060900040103 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 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----- --------------020202020606060900040103-- --SkR4ta5X2EGOuFSHpBmRcrisoAi5nkith-- --TShVxidNU1VbmrNHg4fDtMxKWJWpV1Wkh 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 iQIcBAEBCgAGBQJXC02kAAoJEMDeajWKOdxm6Q4P/1AtkpMa5c1bRZfMWvmMz2X2 64VWx0w+gQ3ouWeVx2eqkFdravGXJSgU5yiMREZhKeN/dwJ87emIWyeKSH1nrUME bkr+eAeOTY4FOHPU7RMeMiE92t0z9ZCXkjlWoOVkFh4DT9j5y903YPYI+z7heUxO WA9LTTOJtQB/UrhuitkwIk9mfYfr3dqRZIRUCx72cs6LVps0l9LS4yo5KIufYt8U B0kbmuzvde+Hxxt/Y/1rcifNjCkkB8WIytpcW0/y4l1DaRFIuSNZ3pJRJCl2xI06 wiwrM1DnRcJXd1bBK/0gArPnxuWhCf/h1ajAvRhGexTu23fKraOI/hfOwQXzTKCG Hpdjqj/tFzz7TLTJCiQdGUKwFJCR6y59uG0GkPKwpuVPElLyyM9XPx0nn9nabsIU f+chB9Y/TNKRYvxa/v9kbxgD8v8kljoVkxcfandNyAFLjI6dUl3g+GLeABOFtcBV xgFTfwN88U7/ohAYSAAQl/c+5pUrL+IeY8lr3BSSvlHnEbXcXp8Hz3/QlL88pPlE ilHybliWfvty4p//OTjK4S4FRiinSssgFnBNE9gLxiCtA0loZTyu/8l5us67GT6P PI+bvJZhFeVgqMpCDoPbUEtG0DA35BW3dXpzbUlABUkGHDbCUxUqWY8Pcqf+ezae ORXdta4F4+zvCwXJZv3i =+sHw -----END PGP SIGNATURE----- --TShVxidNU1VbmrNHg4fDtMxKWJWpV1Wkh-- From nobody Mon Apr 11 02:27:16 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAEF12E0A8 for ; Mon, 11 Apr 2016 02:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no 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 a0xlcUERtLlm for ; Mon, 11 Apr 2016 02:27:13 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522B112DE1E for ; Mon, 11 Apr 2016 02:27:13 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id DF2EE43B02 for ; Mon, 11 Apr 2016 11:27:11 +0200 (CEST) To: radext@ietf.org From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <570B6DEF.6000808@restena.lu> Date: Mon, 11 Apr 2016 11:27:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="BQTjQngC14TKxAafeB7gFEWq1OXfjbsNl" Archived-At: Subject: [radext] meeting minutes online X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 09:27:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BQTjQngC14TKxAafeB7gFEWq1OXfjbsNl Content-Type: multipart/mixed; boundary="pxbtcajN5opsR0ECfX73sQiMmIgb9MeK3" From: Stefan Winter To: radext@ietf.org Message-ID: <570B6DEF.6000808@restena.lu> Subject: meeting minutes online --pxbtcajN5opsR0ECfX73sQiMmIgb9MeK3 Content-Type: multipart/mixed; boundary="------------070700000706010707000306" This is a multi-part message in MIME format. --------------070700000706010707000306 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, thanks to the outstanding work of Mohamed Boucadair, we have excellent meeting minutes on the meeting materials now. Please do have a look and let the list know if you have any objections: https://www.ietf.org/proceedings/95/minutes/minutes-95-radext 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 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette 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 --------------070700000706010707000306 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 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----- --------------070700000706010707000306-- --pxbtcajN5opsR0ECfX73sQiMmIgb9MeK3-- --BQTjQngC14TKxAafeB7gFEWq1OXfjbsNl 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 iQIcBAEBCgAGBQJXC23vAAoJEMDeajWKOdxmYl0P/RPMtjH4JnRd+8Fd5v9EKxjl t4KL5ZCH0eRZm+rjgDqcOcSyN/uiZ9Yyi4qNUja40KUrTjONiSDRPzTOdvVhze10 AaTVHo5geHG5pqCCFeo88hARTYF0IIiKR9iWFKiu2lQKdgTogv/I/PkNm6uQEa7l 0f+9MhUonwHwU2UK0VxBm5WBtO4WdPNAlBtTnmVTko/CoJS9elt5wd1jIwkkbXeR pQvr2Em028Z1sYMPtNMpTSiVzuhlPEbFNUqt2ig7195VTiYxW0qk6YNs5B+LOwb7 Tww/wFcSE61dOzjaP1X1nUIYyoeAbtQuPawWiMR2aHkH3LtX9BhhK1ebSn0mdANF BJI8gs2QNIc4Et/p5hsxsnaznluOZrdevvXGCN987LSxhc5xyco9Cp5RD8rTaNPd 1wRmz3HKJvGk/UIEPtNww9F8K2I4HZiKGfx0Y3yJAmDBXuTQvsulN0rTSOw1jBKZ C9c3WDMMgmv7jSXUWHsMyM2gy8+cfwcgDMjJHapbFJzGrqdRzAqG5Ma03fvmhIMA pntnKFBgaTQfEtsh0g9rCHX6+8MWA2TenHIuegxhMMwfxHLnlCSge6xoEtz5sBSh n5Mybss9ng6ZmWFFIYMbciM8k8lXlfP1jvsqrXNyfZKCcBa3RVPSd3ZxlUgilNiZ nfsKw11l08vvOSmQt4iH =immL -----END PGP SIGNATURE----- --BQTjQngC14TKxAafeB7gFEWq1OXfjbsNl-- From nobody Mon Apr 11 13:14:44 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E160F12F37E; Mon, 11 Apr 2016 13:14:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160411201439.13060.36145.idtracker@ietfa.amsl.com> Date: Mon, 11 Apr 2016 13:14:39 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-bigger-packets-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2016 20:14:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : Larger Packets for RADIUS over TCP Author : Sam Hartman Filename : draft-ietf-radext-bigger-packets-06.txt Pages : 9 Date : 2016-04-11 Abstract: The RADIUS over TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of RADIUS packet proves problematic. This specification extends the RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action which requires IESG approval. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-bigger-packets-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-bigger-packets-06 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 nobody Tue Apr 12 01:25:41 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B1D12DB12 for ; Tue, 12 Apr 2016 01:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no 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 oMXm5ATSZUeP for ; Tue, 12 Apr 2016 01:25:38 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE23C12D7D4 for ; Tue, 12 Apr 2016 01:25:37 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 3707D43B03 for ; Tue, 12 Apr 2016 10:25:36 +0200 (CEST) To: radext@ietf.org References: <20160411201439.13060.36145.idtracker@ietfa.amsl.com> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: <570CB100.1070302@restena.lu> Date: Tue, 12 Apr 2016 10:25:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <20160411201439.13060.36145.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aAeu7L47GJt2mmt9LJppRHfTrVuGT6dO0" Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-bigger-packets-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 08:25:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aAeu7L47GJt2mmt9LJppRHfTrVuGT6dO0 Content-Type: multipart/mixed; boundary="FVSJI2vXh5F5MiaQm9fVgkaSf4uhKfAtB" From: Stefan Winter To: radext@ietf.org Message-ID: <570CB100.1070302@restena.lu> Subject: Re: [radext] I-D Action: draft-ietf-radext-bigger-packets-06.txt References: <20160411201439.13060.36145.idtracker@ietfa.amsl.com> In-Reply-To: <20160411201439.13060.36145.idtracker@ietfa.amsl.com> --FVSJI2vXh5F5MiaQm9fVgkaSf4uhKfAtB Content-Type: multipart/mixed; boundary="------------070207090402050703060508" This is a multi-part message in MIME format. --------------070207090402050703060508 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, thanks for this new rev. It looks to me like it addresses the secdir draft (except for one issue). It does not address the nits recorded in https://tools.ietf.org/wg/radext/trac/ticket/197 yet. Greetings, Stefan Winter Am 11.04.2016 um 22:14 schrieb internet-drafts@ietf.org: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the RADIUS EXTensions of the IETF. >=20 > Title : Larger Packets for RADIUS over TCP > Author : Sam Hartman > Filename : draft-ietf-radext-bigger-packets-06.txt > Pages : 9 > Date : 2016-04-11 >=20 > Abstract: > The RADIUS over TLS experiment described in RFC 6614 has opened > RADIUS to new use cases where the 4096-octet maximum size limit of > RADIUS packet proves problematic. This specification extends the > RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS > packets. This specification compliments other ongoing work to permi= t > fragmentation of RADIUS authorization information. This document > registers a new RADIUS code, an action which requires IESG approval.= >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-radext-bigger-packets-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-bigger-packets-06= >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 2, avenue de l'Universit=E9 L-4365 Esch-sur-Alzette 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 --------------070207090402050703060508 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 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----- --------------070207090402050703060508-- --FVSJI2vXh5F5MiaQm9fVgkaSf4uhKfAtB-- --aAeu7L47GJt2mmt9LJppRHfTrVuGT6dO0 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 iQIcBAEBCgAGBQJXDLEAAAoJEMDeajWKOdxm3Z0QAKkzmQkvpYxBCLpkh0lv5wpD oCu95xGLj03fNT0mJrUMYccMDSWK/eu9kqA0zYPv83Txzdoi+TQGd/1H++HlJ+SP 0Mq7n+siqVMaIIsQfXEd6G9Z/gCBHuLiBNRkyWTJOmDNLQHz9T4PnTP8uAwCN4X1 EQQkE8C43L5ju6asK+8XdbE61EwYIPcEF3bT6RdG2tOmN7ok8qrA3V9jzKmkNpVJ us3V9qBV9Af7KHhyW1I/3NXX7g5ATlhOuZ4dQO2kA2JgiwlR9IVFjpO0ODsnAEaZ HsF4tphPEu3PHVvUP15d2V4PX/bLJUZ4CQTiqlDd6ORkfkFVVgwBisoVrYRehEjo ReVq0cfP0u2hwIvhOQ0rZBS632xAclHkcl/B3REgItdkCVBqfEYNwD2dhlds3M76 YrQp63AjrTmGcxx/knlpdtiyR9sIBzdgXS09v0J+qNlxX8BNZf7ctrYAWQBq5EPV 5biaebV1detURHVrIYdPYvuYGUpXFts3WzNei4WfyQGLfLk3amTSb6R+dWKJdu9K MTqiRdD8H9SUSIcz44c4gJF0OX/9/Y6XwZTlZiH8M9d4sXDNZIoq2XFELlDyy7Sb HF7mMPQkK+l2Ws0PYyTljfT0WCmxxXDXh68B7jKg12cTl2OqeMf61eNs7znOpya4 4OJHWrCNFspIzej2e8vk =PeRt -----END PGP SIGNATURE----- --aAeu7L47GJt2mmt9LJppRHfTrVuGT6dO0-- From nobody Tue Apr 12 05:17:21 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7095B12EC1F for ; Tue, 12 Apr 2016 05:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.297 X-Spam-Level: X-Spam-Status: No, score=-5.297 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 cWJf4-5yUgqt for ; Tue, 12 Apr 2016 05:17:17 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2006A12E182 for ; Tue, 12 Apr 2016 05:17:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DB5EDBE32; Tue, 12 Apr 2016 13:17:15 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKr20dXC3tqe; Tue, 12 Apr 2016 13:17:08 +0100 (IST) Received: from [10.87.49.100] (unknown [86.42.21.187]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id ADFBCBE2F; Tue, 12 Apr 2016 13:17:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1460463428; bh=H6d9hmqV5OZtI4SXdiAyaFuon76mIMamqd5knCjrOm4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=d2Uto7jrCqrd50XE0BLq09sXdaKbnHrprC5zGdC31NERMMi1NzNx2rOD/JAakAEBk QWGQ/zIAqYyV8TwXdw3OlibGlZuHbDtkTnvn7Ijsv2xU/Pnmt1392EkrHKCySXKhaT nH+rpd4LRf370jVflh/GCk11JboIVgaFfXs9fxl4= To: Stefan Winter , radext@ietf.org References: <20160411201439.13060.36145.idtracker@ietfa.amsl.com> <570CB100.1070302@restena.lu> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <570CE742.8060709@cs.tcd.ie> Date: Tue, 12 Apr 2016 13:17:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <570CB100.1070302@restena.lu> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="EVdFNODo6WJkGUeoObeO9Hb5Uuq0CknV4" Archived-At: Subject: Re: [radext] I-D Action: draft-ietf-radext-bigger-packets-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 12:17:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --EVdFNODo6WJkGUeoObeO9Hb5Uuq0CknV4 Content-Type: multipart/mixed; boundary="eh2DKJaSvB5wT6Oppj8Gwo59sG8bpsNEx" From: Stephen Farrell To: Stefan Winter , radext@ietf.org Message-ID: <570CE742.8060709@cs.tcd.ie> Subject: Re: [radext] I-D Action: draft-ietf-radext-bigger-packets-06.txt References: <20160411201439.13060.36145.idtracker@ietfa.amsl.com> <570CB100.1070302@restena.lu> In-Reply-To: <570CB100.1070302@restena.lu> --eh2DKJaSvB5wT6Oppj8Gwo59sG8bpsNEx Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/04/16 09:25, Stefan Winter wrote: > Hello, >=20 > thanks for this new rev. It looks to me like it addresses the secdir > draft (except for one issue). >=20 > It does not address the nits recorded in > https://tools.ietf.org/wg/radext/trac/ticket/197 yet. Please go ahead and fix those. I've put this on the May 5th telechat (April 21st is pretty full already) so you've time. But sooner is of course better too:-) Cheers, S. >=20 > Greetings, >=20 > Stefan Winter >=20 > Am 11.04.2016 um 22:14 schrieb internet-drafts@ietf.org: >> >> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories. >> This draft is a work item of the RADIUS EXTensions of the IETF. >> >> Title : Larger Packets for RADIUS over TCP >> Author : Sam Hartman >> Filename : draft-ietf-radext-bigger-packets-06.txt >> Pages : 9 >> Date : 2016-04-11 >> >> Abstract: >> The RADIUS over TLS experiment described in RFC 6614 has opened >> RADIUS to new use cases where the 4096-octet maximum size limit of >> RADIUS packet proves problematic. This specification extends the >> RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS >> packets. This specification compliments other ongoing work to perm= it >> fragmentation of RADIUS authorization information. This document >> registers a new RADIUS code, an action which requires IESG approval= =2E >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-radext-bigger-packets-06 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-bigger-packets-0= 6 >> >> >> Please note that it may take a couple of minutes from the time of subm= ission >> 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/ >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> >=20 >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --eh2DKJaSvB5wT6Oppj8Gwo59sG8bpsNEx-- --EVdFNODo6WJkGUeoObeO9Hb5Uuq0CknV4 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 iQEcBAEBCAAGBQJXDOdDAAoJEC88hzaAX42iER4H+wZAKNmj2AgimF9OU6G9vPwF 4dVX2FLCJ5vPPzWlJeeY1x6h96ehEGlS3iQypneQD+M53IPZk588WNj3hJ+0DQFa hcMFwPKiAKypB8aL8Ddf5gkCVqJ9TSJaz14qyNiG9DIVk6srMUuT+/YEu5TrjkJR bZD4Q3T+VUZCt1rt73oBFv5HxmMlrl6opsXsIBIGwdcOldXidPTDxuv+Qw2MtrEx pWFKBfKswKnQJZ+U6ehIs71M+PqwgBTkcVNMwkCQiuIBcbYHxCJStY6PXdNVIe8i DMlDnmEszBAQEUXQKntpmwxFh9Z4k05rLS0BCNgPFsDZY6RHFoz476fTF6/ZS/c= =fVvw -----END PGP SIGNATURE----- --EVdFNODo6WJkGUeoObeO9Hb5Uuq0CknV4-- From nobody Tue Apr 12 07:47:35 2016 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5672612DDAB for ; Tue, 12 Apr 2016 07:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no 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 mYYV9D0tuENx for ; Tue, 12 Apr 2016 07:47:30 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE05912DDA7 for ; Tue, 12 Apr 2016 07:47:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 55A7F20B50; Tue, 12 Apr 2016 10:43:50 -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 cjkOSK8EuTzS; Tue, 12 Apr 2016 10:43:50 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-133-245-84.hsd1.ma.comcast.net [50.133.245.84]) (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, 12 Apr 2016 10:43:50 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 500078724F; Tue, 12 Apr 2016 10:47:25 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <20160411201439.13060.36145.idtracker@ietfa.amsl.com> <570CB100.1070302@restena.lu> Date: Tue, 12 Apr 2016 10:47:25 -0400 In-Reply-To: <570CB100.1070302@restena.lu> (Stefan Winter's message of "Tue, 12 Apr 2016 10:25:36 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-bigger-packets-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 14:47:32 -0000 My apology. I'd forgotten about that ticket. From nobody Tue Apr 12 07:48:55 2016 Return-Path: X-Original-To: radext@ietf.org Delivered-To: radext@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D0A12DDA6; Tue, 12 Apr 2016 07:48:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160412144853.32149.41245.idtracker@ietfa.amsl.com> Date: Tue, 12 Apr 2016 07:48:53 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-bigger-packets-07.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.17 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 14:48:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions of the IETF. Title : Larger Packets for RADIUS over TCP Author : Sam Hartman Filename : draft-ietf-radext-bigger-packets-07.txt Pages : 9 Date : 2016-04-12 Abstract: The RADIUS over TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum size limit of RADIUS packet proves problematic. This specification extends the RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action which requires IESG approval. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-radext-bigger-packets-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-radext-bigger-packets-07 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/