From nobody Thu Jul 2 17:27:27 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B821ACEDB for ; Thu, 2 Jul 2015 17:27:26 -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 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 t-CVHAW2NLzh for ; Thu, 2 Jul 2015 17:27:25 -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 7FF6C1ACED8 for ; Thu, 2 Jul 2015 17:27:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 84DD72070D for ; Thu, 2 Jul 2015 20:27:15 -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 qfb6bLAY4msj for ; Thu, 2 Jul 2015 20:27:15 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-65-96-232-173.hsd1.ma.comcast.net [65.96.232.173]) (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 for ; Thu, 2 Jul 2015 20:27:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 34B2A87E85; Thu, 2 Jul 2015 20:27:17 -0400 (EDT) From: Sam Hartman To: radext@ietf.org Date: Thu, 02 Jul 2015 20:27:17 -0400 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: Subject: [radext] Where are we with bigger-packets X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2015 00:27:27 -0000 I want to confirm the chairs aren't waiting for anything from me. my recollection is that I'm waiting on a write-up? --Sam From nobody Fri Jul 3 01:02:15 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17121A0273 for ; Fri, 3 Jul 2015 01:02:14 -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, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id so0-Z5lQGApK for ; Fri, 3 Jul 2015 01:02:13 -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 186061A0267 for ; Fri, 3 Jul 2015 01:02: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 EA8EA43A96 for ; Fri, 3 Jul 2015 10:02:11 +0200 (CEST) Message-ID: <55964183.1020907@restena.lu> Date: Fri, 03 Jul 2015 10:02:11 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "radext@ietf.org" References: In-Reply-To: OpenPGP: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lafmCf4GUHG8pLUG602kEFTmBu59gjDSd" Archived-At: Subject: Re: [radext] Where are we with bigger-packets X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2015 08:02:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lafmCf4GUHG8pLUG602kEFTmBu59gjDSd Content-Type: multipart/mixed; boundary="------------020805030900070107090106" This is a multi-part message in MIME format. --------------020805030900070107090106 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > I want to confirm the chairs aren't waiting for anything from me. > my recollection is that I'm waiting on a write-up? That's by and large correct. There was a WGLC on the -03 version starting 31 March 2015. It had no comments on the text, only a few "I support adoption" (which was not asked asked for at that moment in time).= Since there were no comments worth discussing during WGLC, we are now in principle ready for advancement to Shepherd write-up and IETF Last Call. There is one bit missing, which will need to be part of the Write-up and was asked for in the WGLC: Sam, as the only author of this draft, could you replay to this question as raised in the WGLC announcement mail: "In addition, following the strategy for promoting compliance with the IPR disclosure rules (RFC6702), the chairs would like to check whether there are claims of Intellectual Property Rights (IPR) on the document that need to be disclosed. Therefore, the following questions are addressed to the WG and Especially Authors and Contributors of the draft:= Are you personally aware of any IPR that applies to draft-ietf-radext-bigger-packets-03? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please reply to this email message regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor." Thanks, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 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 --------------020805030900070107090106 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----- --------------020805030900070107090106 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----- --------------020805030900070107090106-- --lafmCf4GUHG8pLUG602kEFTmBu59gjDSd 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 iQIcBAEBCgAGBQJVlkGDAAoJEMDeajWKOdxmSoUQAI5fSxB7t15Ba1hmCZXRuhcs 3TrNIKpcijZFUVjzrqsV1S8HuE/EdqufMA8nounwutVUy/WLpFVOL0DITojc/Xt0 TN6pjflKQFe35neEK9Yj0nnojEzV9WVQAUCMnkbui5pR6xvUlRMHp3RAQ2EUz0XD ma0jLzkEA6yXObtASYSWQqIn3cl5TUzQ3DwopHcaWpCh68gThdmk3YikBoLrwfmn 2D99uYfDqWXsXVTwA6IaYLuTIh7LtMmFA5z5dgukejXoUolYjCIPHC9XUeRJgD1Y pTy1VhhBKSUNKBTiXF5yms7AJkHe9hfThlgIAvJWp94jh+fQ34I8ZZ00AGelEw6j clFh12LNc+qfYMQ/Al82ibErmXS4A7RkuwZX4c0cQDtp8VX97I8aObUPNaPlEHnA guTttXiNZqGjW3U1s938lJZHzFO01aHv8Rew8xnu+Mz4My/S3M3hF6SYB28k8TAq vRWYvaB9J6gXTRbLLZPEt/JlTIjFPUtfPDV3vWvMCD3QAtCnFIJHjnsznBNyi7Mw F1cmPRdqdTBM/TB8EPnEJu2oqaxiWE3FEAirBKmh5ETGtasjsrHg+OSaFk2sk28H F6mbYcLtFy+5i8VIEDbt2iB629BpfNDZA2q5TYL83WQyMdEfO2MP67shheYIm15p MRgXRt9Vt2lueArSoUKF =Kt8d -----END PGP SIGNATURE----- --lafmCf4GUHG8pLUG602kEFTmBu59gjDSd-- From nobody Fri Jul 3 01:32:04 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184EB1AC44B for ; Fri, 3 Jul 2015 01:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KveIk3ZA5uZm for ; Fri, 3 Jul 2015 01:32:01 -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 615E21AC431 for ; Fri, 3 Jul 2015 01:32:01 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2C1823B46A7; Fri, 3 Jul 2015 10:32:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 064B14C056; Fri, 3 Jul 2015 10:32:00 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0235.001; Fri, 3 Jul 2015 10:31:59 +0200 From: To: Dean cheng , Alan DeKok Thread-Topic: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-ext-03 Thread-Index: AdC1aovPh+9LQWbtQzGtyXOhuRem7A== Date: Fri, 3 Jul 2015 08:31:59 +0000 Message-ID: <22144_1435912320_55964880_22144_239_1_6B7134B31289DC4FAF731D844122B36E01CB4CD3@OPEXCLILM43.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.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.2.125417 Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-ext-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2015 08:32:03 -0000 Thank for the review, comment and update. With the version -05, the document is now ready for IESG submission. Next Steps: - Shepherd assignment - IESG submission - IETF LC Regards, Lionel -----Message d'origine----- De=A0: Dean cheng [mailto:dean.cheng@huawei.com]=20 Envoy=E9=A0: jeudi 23 avril 2015 10:17 =C0=A0: Alan DeKok Cc=A0: radext@ietf.org; radext-chairs@tools.ietf.org; MORAND Lionel IMT/OLN Objet=A0: RE: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-e= xt-03 Alan - thanks for the review and catch. It is now fixed in the 05 text: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ip-port-radius-ext-05 Cheers Dean > -----Original Message----- > From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok > Sent: Wednesday, April 22, 2015 12:30 PM > To: Dean cheng > Cc: radext@ietf.org; radext-chairs@tools.ietf.org;=20 > lionel.morand@orange.com > Subject: Re: [radext] Start of WGLC for=20 > draft-ietf-radext-ip-port-radius-ext- > 03 >=20 > On Apr 22, 2015, at 6:21 AM, Dean cheng wrote: > > We've just posted the 04 text that addressed comments posted by Alan. > > It is: > > > > http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-04 >=20 > On a quick scan, it looks good. The only minor nit is the ASCII=20 > art. You have a field ending at the end of a line, and then continuing o= n the next line: >=20 > ... | Field-Name | > | Field-Name | ... >=20 > It should just be: >=20 > ... | Field-Name > Field-Name | ... >=20 > i.e. without the last | on the first line, and the first | on the next = line. >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ 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 Jul 3 11:57:31 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A591A1BFF for ; Fri, 3 Jul 2015 11:57:30 -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 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 HReurIKn1nFc for ; Fri, 3 Jul 2015 11:57:28 -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 9C1F11A1BF8 for ; Fri, 3 Jul 2015 11:57:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 854C92071D; Fri, 3 Jul 2015 14:57:17 -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 wOjaAS7hlV5E; Fri, 3 Jul 2015 14:57:17 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-65-96-232-173.hsd1.ma.comcast.net [65.96.232.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 3 Jul 2015 14:57:17 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id ADFC688D2F; Fri, 3 Jul 2015 14:57:18 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <55964183.1020907@restena.lu> Date: Fri, 03 Jul 2015 14:57:18 -0400 In-Reply-To: <55964183.1020907@restena.lu> (Stefan Winter's message of "Fri, 03 Jul 2015 10:02:11 +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] Where are we with bigger-packets X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 03 Jul 2015 18:57:30 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> There is one bit missing, which will need to be part of the Stefan> Write-up and was asked for in the WGLC: Stefan> Sam, as the only author of this draft, could you replay to Stefan> this question as raised in the WGLC announcement mail: Stefan> "In addition, following the strategy for promoting Stefan> compliance with the IPR disclosure rules (RFC6702), the Stefan> chairs would like to check whether there are claims of Stefan> Intellectual Property Rights (IPR) on the document that need Stefan> to be disclosed. Therefore, the following questions are Stefan> addressed to the WG and Especially Authors and Contributors Stefan> of the draft: Stefan> Are you personally aware of any IPR that applies to Stefan> draft-ietf-radext-bigger-packets-03? If so, has this IPR Stefan> been disclosed in compliance with IETF IPR rules? (See RFCs Stefan> 3979, 4879, 3669, and 5378 for more details.) The question you asked requests significantly more information than is consistent with our IPR policies. Especially for this draft this is a matter of principle, but I'd be comfortable with a formulation that distinguished information authors are required under policy to provide from information they are encouraged to provide. One of the most obvious cases where authors are not required to disclose all IPR they are aware of is IPR that is conditionally infringed depending on implementation choices. I'll say that under our policy, I am required to file 0 disclosures and all 0 of them have been filed. I'd also like to draw your attention to a note I sent a while back regarding content we want to call out in the proto writeup. This document registers RADIUS packet type codes which require IESG approval to register. So I sent the following note to the list: -------------------- Hi. I realize we are far away from a shepherd writeup, but I wanted to bring up this issue now. The RADIUS packet type codes registry requires IESG approval to register. My recommendation is that during IETF last call we explicitly call out the request to the IESG to approve the registration/call out to the community that the IESG is evaluating such a registration. I think that should be sufficient for an experimental document to make this allocation. It's already in the abstract and intro and IANA considerations text. From nobody Mon Jul 6 01:28:13 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE5E1A9087 for ; Mon, 6 Jul 2015 01:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.791 X-Spam-Level: X-Spam-Status: No, score=0.791 tagged_above=-999 required=5 tests=[BAYES_50=0.8, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Si1kO_Q26wXi for ; Mon, 6 Jul 2015 01:28:09 -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 BF8A11A9086 for ; Mon, 6 Jul 2015 01:28:08 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id AB9B940D7A for ; Mon, 6 Jul 2015 10:28:06 +0200 (CEST) Message-ID: <559A3C16.7040004@restena.lu> Date: Mon, 06 Jul 2015 10:28:06 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: radext@ietf.org References: <55964183.1020907@restena.lu> In-Reply-To: OpenPGP: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VImhu9MxJAEIDrrK0THxR4IOkipxVrf20" Archived-At: Subject: Re: [radext] Where are we with bigger-packets X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jul 2015 08:28:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VImhu9MxJAEIDrrK0THxR4IOkipxVrf20 Content-Type: multipart/mixed; boundary="------------010706040506060001000000" This is a multi-part message in MIME format. --------------010706040506060001000000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > The question you asked requests significantly more information than is > consistent with our IPR policies. Especially for this draft this is > a matter of principle, but I'd be comfortable with a formulation that > distinguished information authors are required under policy to provide= > from information they are encouraged to provide. One of the most > obvious cases where authors are not required to disclose all IPR they > are aware of is IPR that is conditionally infringed depending on > implementation choices. The question used the suggestion wording of RFC6702, Appendix A.4. Even if it is not formally required to use that wording, I for one consider this a "sane default". If you don't like that formulation, the best way forward would probably be to rev RFC6702. > I'll say that under our policy, I am required to file 0 disclosures and= > all 0 of them have been filed. Thank you. > I'd also like to draw your attention to a note I sent a while back > regarding content we want to call out in the proto writeup. > This document registers RADIUS packet type codes which require IESG > approval to register. > So I sent the following note to the list: >=20 > -------------------- >=20 > Hi. > I realize we are far away from a shepherd writeup, but I wanted to brin= g > up this issue now. >=20 > The RADIUS packet type codes registry requires IESG approval to > register. > My recommendation is that during IETF last call we explicitly call out > the request to the IESG to approve the registration/call out to the > community that the IESG is evaluating such a registration. > I think that should be sufficient for an experimental document to make > this allocation. >=20 > It's already in the abstract and intro and IANA considerations text. I'll keep this in mind for the shepherd writeup. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 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 --------------010706040506060001000000 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----- --------------010706040506060001000000-- --VImhu9MxJAEIDrrK0THxR4IOkipxVrf20 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 iQIcBAEBCgAGBQJVmjwWAAoJEMDeajWKOdxmg8sQAJc+lGOeZsqrImtgFkNZn2GH qINZtyHzZlBuAZi599samqtK6hmgDrgYPnEIG3n1QpEWWmrazoRF/p9oy+c4JqNZ L0KUrnhyuGfuzJ6VlpL1254q3UxMA9cz3LDL2eBab/bwNO2/lBVcSHHwxrmq8Vzz xRCKDD0JMqtdTQBipUDHE/YTGjaW001O+BPGxiOAiL15WezT/DkgWlnyby+F0chm UALs3TryoNKrMl4vwuEpdcIKD9zFHF8YqMRp9rfKkOaVzG2XrHp85GQjX1mH3NF2 3WBmKj8o7bI6s4uYSkeWqiLgyGOGzCeVglmKZaI3VZaIAGOJeuHjqMKJSXMP2/6H mscBw2dM04cVFwNBtXK2SKCLr6sZ41WDTgK0N82SLGgqCixeYdyXEOdWUM8br1Mm qOegDLeZX7yP0T6fwfL46iRc+mx3qkm4PktO59WOODP2HKcPwuCbzVuOebpkS29T iqy7t4hvBm+P+xtKkNBdGgzf2dL2ZqcMdwf9+MVSfuD49ECgV/HkaOv38EDyuzgg UweKBX5y4jSzc4JajMRAzmdFbJ+HV5sWPCfW6l5dlVUp9hmSjGepJx0KvHqSlcdu DbdrHor1UPSjRm8BR1/2NY/QeYFqYy54SBLXyUEXLNG91ezigQdF5IkvTT3ZLS+f LHbR51ikkmh1ovl5Gucv =83mJ -----END PGP SIGNATURE----- --VImhu9MxJAEIDrrK0THxR4IOkipxVrf20-- From nobody Mon Jul 6 07:29:29 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473E31A8896 for ; Mon, 6 Jul 2015 07:29:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yxlQi0sKbn2w for ; Mon, 6 Jul 2015 07:29:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3966C1A8890 for ; Mon, 6 Jul 2015 07:29:26 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 8A0662AC759 for ; Mon, 6 Jul 2015 16:29:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6347A384049 for ; Mon, 6 Jul 2015 16:29:24 +0200 (CEST) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0235.001; Mon, 6 Jul 2015 16:29:23 +0200 From: To: "radext@ietf.org" Thread-Topic: draft-klammorrissette-radext-very-common-vsas-00. Thread-Index: AdC39+S3DivrGAxESQG8w1I7mmlosA== Date: Mon, 6 Jul 2015 14:29:23 +0000 Message-ID: <26385_1436192964_559A90C4_26385_1606_1_B3EB239AAD96834ABDBBFBC253923E79CF825F@OPEXCLILM44.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.2.124516 Archived-At: Subject: [radext] draft-klammorrissette-radext-very-common-vsas-00. X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jul 2015 14:29:28 -0000 Hi, We've just submitted a new draft targeted to radext. We got the idea of cra= fting this draft in the context of the Broadband Forum inventorying the RA= DIUS attributes it needs.=20 We saw there were attributes which have been widely used in different fixe= d network and part of many vendor dictionaries.=20 So in a spirit close to RFC7268, we proposes this draft: draft-klammorrisse= tte-radext-very-common-vsas-00. Your remarks & comments are welcome. Regards. Frederic Klamm ___________________________________________________________________________= ______________________________________________ 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 Mon Jul 6 15:55:30 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9321A00EE; Mon, 6 Jul 2015 15:55:29 -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 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 ACRR6ceNqqV2; Mon, 6 Jul 2015 15:55:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C8B1A006D; Mon, 6 Jul 2015 15:55:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706225527.12089.54865.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 15:55:27 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] Benoit Claise's No Objection on charter-ietf-radext-05-01: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 22:55:29 -0000 Benoit Claise has entered the following ballot position for charter-ietf-radext-05-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-radext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Editorial improvement: Remove "Furthermore" in the second paragraph. Instead of duplicating the RFC type ( "This will be a standards track document.") in the charter and the milestones , consider mentioning it only in the milestones ("Nov 2016 - Data Types as Informational RFC") advantage #1: strong AD advice, it can still be changed if the WG has got a good reason advantage #2: it avoids discrepancies between the charter text and the milestones. Look at the data types document :-) From nobody Tue Jul 7 12:49:08 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6E41A88C4; Tue, 7 Jul 2015 12:49:07 -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 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 eeBcI0955R4q; Tue, 7 Jul 2015 12:49:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 006C91A88BD; Tue, 7 Jul 2015 12:49:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150707194905.9566.61587.idtracker@ietfa.amsl.com> Date: Tue, 07 Jul 2015 12:49:05 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] Barry Leiba's No Objection on charter-ietf-radext-05-01: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 19:49:07 -0000 Barry Leiba has entered the following ballot position for charter-ietf-radext-05-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-radext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with Benoît's suggestion about the intended status of the documents. "Verbatimly"? I suppose we can make up adverbs on the fly, but you might consider just deleted that (non-)word as unnecessary. From nobody Wed Jul 8 11:05:35 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D991A6EE2; Wed, 8 Jul 2015 11:05: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 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 8iwKhNfzunCd; Wed, 8 Jul 2015 11:05:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A411A3BA3; Wed, 8 Jul 2015 11:05:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Brian Haberman" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708180533.30559.57910.idtracker@ietfa.amsl.com> Date: Wed, 08 Jul 2015 11:05:33 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] Brian Haberman's No Objection on charter-ietf-radext-05-01: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 18:05:34 -0000 Brian Haberman has entered the following ballot position for charter-ietf-radext-05-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-radext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 2119 keywords in a charter? From nobody Thu Jul 9 05:15:39 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0439C1A89C7; Thu, 9 Jul 2015 05:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmlsXZmu5jjO; Thu, 9 Jul 2015 05:15:37 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450: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 313D81AD351; Thu, 9 Jul 2015 05:15:33 -0700 (PDT) Received: by wiwl6 with SMTP id l6so16870510wiw.0; Thu, 09 Jul 2015 05:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m4cY5h3FzF8Ye9Oeq4sKImYSwKBlZeEjCt5bX9oNv2o=; b=zwy6RcOoQOWX6fhaYpe3GjEq2xkO2mP0TLyVjO6Ze8IBgAYiEVQfQpT/vFP40hHnWq 8cfzRIa9bzWogohvZrXMkNPj9kbDvauTBDotxII0a641cUescLXjb/p39Iw2bDXINQLU 5CjSb2nvwqG0OlP4m1G3PCQ+aEb8KXpziBaUG9CYSB21reHhp/+HURh5yqNIMd7QuqwB KE1m0d+SSQvb94PEwRFXA3d0Yq3bHKspv+1jsIqTUvYKyWh+I1Z39uDtzupwwNsh3Pbb QnaIcgJzfjbD7rfxLMquMYk3hf3YBpt2eDE972QoTe5pWtxpelTGeOos2j+TUaISaemJ 4fZA== MIME-Version: 1.0 X-Received: by 10.180.86.168 with SMTP id q8mr115929723wiz.80.1436444131950; Thu, 09 Jul 2015 05:15:31 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Thu, 9 Jul 2015 05:15:31 -0700 (PDT) In-Reply-To: <20150708180533.30559.57910.idtracker@ietfa.amsl.com> References: <20150708180533.30559.57910.idtracker@ietfa.amsl.com> Date: Thu, 9 Jul 2015 08:15:31 -0400 Message-ID: From: Kathleen Moriarty To: Brian Haberman Content-Type: multipart/alternative; boundary=bcaec5555030398583051a703698 Archived-At: Cc: "radext@ietf.org" , The IESG Subject: Re: [radext] Brian Haberman's No Objection on charter-ietf-radext-05-01: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 12:15:39 -0000 --bcaec5555030398583051a703698 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 8, 2015 at 2:05 PM, Brian Haberman wrote: > Brian Haberman has entered the following ballot position for > charter-ietf-radext-05-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-radext/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 2119 keywords in a charter? > > It's been removed, thank you. -- Best regards, Kathleen --bcaec5555030398583051a703698 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jul 8, 2015 at 2:05 PM, Brian Haberman <brian@innovatio= nslab.net> wrote:
Brian Ha= berman has entered the following ballot position for
charter-ietf-radext-05-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-r= adext/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

2119 keywords in a charter?

It's been removed, thank you.=C2=A0


--

Best regards,
Kathleen
--bcaec5555030398583051a703698-- From nobody Thu Jul 9 05:16:11 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BE61A89C7; Thu, 9 Jul 2015 05:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xh-o8YpIxsVQ; Thu, 9 Jul 2015 05:16:05 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450: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 518BB1A8A58; Thu, 9 Jul 2015 05:16:05 -0700 (PDT) Received: by wifm2 with SMTP id m2so16860355wif.1; Thu, 09 Jul 2015 05:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SoLto8Rk3Yoz4muZmE2gBfpFRFL0EAOBjQBUy31ym44=; b=r3iQnQidxmZCSKJT9o/DAjVjjEWM1OMw4LIYreex4i/GBrgkpqMYJgbyffU85mtL3z QgonmjBchxYxJifLoUc24/YJah2Xm+9pBNdmXRCoLthmQJsygffvYf1iLqjjBww2G5jK XSNoyWSPJID1Y6Xb/Tr+lca8K3Ub2fszvBirGvdySweLYdtrWPr6MvGq9nU5WeMALsYK 7tJZWp8hBEbZTklawGOHZNCC0RMYsMd73/b+je+f6iiOg/5Gp/qIcZzIhHN75DobUaZO OCqahVE3Dwwd2y64zWgjgIG5KGXA1U379NoqYxa7phfZ83DTCtAVQ+BsqAIfPkLsyOEA IFLw== MIME-Version: 1.0 X-Received: by 10.180.75.4 with SMTP id y4mr83919276wiv.1.1436444164094; Thu, 09 Jul 2015 05:16:04 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Thu, 9 Jul 2015 05:16:04 -0700 (PDT) In-Reply-To: <20150707194905.9566.61587.idtracker@ietfa.amsl.com> References: <20150707194905.9566.61587.idtracker@ietfa.amsl.com> Date: Thu, 9 Jul 2015 08:16:04 -0400 Message-ID: From: Kathleen Moriarty To: Barry Leiba Content-Type: multipart/alternative; boundary=f46d043c820823ff4f051a7038c1 Archived-At: Cc: "radext@ietf.org" , The IESG Subject: Re: [radext] Barry Leiba's No Objection on charter-ietf-radext-05-01: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 12:16:07 -0000 --f46d043c820823ff4f051a7038c1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jul 7, 2015 at 3:49 PM, Barry Leiba wrote= : > Barry Leiba has entered the following ballot position for > charter-ietf-radext-05-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-radext/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with Beno=C3=AEt's suggestion about the intended status of the > documents. > > "Verbatimly"? I suppose we can make up adverbs on the fly, but you might > consider just deleted that (non-)word as unnecessary. > This has been fixed, thank you. --=20 Best regards, Kathleen --f46d043c820823ff4f051a7038c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jul 7, 2015 at 3:49 PM, Barry Leiba <barryleiba@computer= .org> wrote:
Barry Leiba ha= s entered the following ballot position for
charter-ietf-radext-05-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-r= adext/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I agree with Beno=C3=AEt's suggestion about the intended status of the<= br> documents.

"Verbatimly"?=C2=A0 I suppose we can make up adverbs on the fly, = but you might
consider just deleted that (non-)word as unnecessary.
=
This has been fixed, thank you.=C2=A0



--

Best regards,
Kathleen
--f46d043c820823ff4f051a7038c1-- From nobody Thu Jul 9 05:17:33 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D381AD2EE; Thu, 9 Jul 2015 05:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKpTgzgxt035; Thu, 9 Jul 2015 05:17:27 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::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 136451A8A58; Thu, 9 Jul 2015 05:17:27 -0700 (PDT) Received: by wiwl6 with SMTP id l6so16919669wiw.0; Thu, 09 Jul 2015 05:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dsCzOA+eFKpncaKnnzWDlniQmPdoNHv54gjjgsa8HTQ=; b=uvnyWMxiAjLgE3JKZ3sgCAu2hWQHSHzJLCmkEXhJ2MEeMwfzBVGNZrMv0j9x8HfG/A VlmyDckkGOamWVCvJfqIKPrjnnMnAJRUu6QNMTgTT+oaR/XScX+ZQGWafgssJAOf8O8V lP3SAOenljoJT/Z+StdtnX5unTMhTVb0c/Is2QGZ1hd2inyL303TLh2oHeHHaRfHNYhb jd9IfzQlJFUcx7zlhXszpmCE9S8rxhwW/m8aoe19YFP6vKwu+mCROpuSMIye9mXMIaOU jrRhhIoeRl7l+TVHov6O/7DATqjA9p+Bfns3nfwCEQDci8kSgcwd/+vEYSO+TE62HP6c TVoA== MIME-Version: 1.0 X-Received: by 10.180.86.73 with SMTP id n9mr119760373wiz.78.1436444245862; Thu, 09 Jul 2015 05:17:25 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Thu, 9 Jul 2015 05:17:25 -0700 (PDT) In-Reply-To: <20150706225527.12089.54865.idtracker@ietfa.amsl.com> References: <20150706225527.12089.54865.idtracker@ietfa.amsl.com> Date: Thu, 9 Jul 2015 08:17:25 -0400 Message-ID: From: Kathleen Moriarty To: Benoit Claise , "radext-chairs@tools.ietf.org" Content-Type: multipart/alternative; boundary=f46d0442806e03af17051a703d3a Archived-At: Cc: "radext@ietf.org" , The IESG Subject: Re: [radext] Benoit Claise's No Objection on charter-ietf-radext-05-01: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 12:17:29 -0000 --f46d0442806e03af17051a703d3a Content-Type: text/plain; charset=UTF-8 On Mon, Jul 6, 2015 at 6:55 PM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > charter-ietf-radext-05-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-radext/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Editorial improvement: Remove "Furthermore" in the second paragraph. > > Instead of duplicating the RFC type ( "This will be a standards track > document.") in the charter and the milestones , consider mentioning it > only in the milestones ("Nov 2016 - Data Types as Informational RFC") > advantage #1: strong AD advice, it can still be changed if the WG has got > a good reason > advantage #2: it avoids discrepancies between the charter text and the > milestones. Look at the data types document :-) > > > I'd like to make any changes prior to our call in less than 2 hours, what is the WG chairs opinion on this suggestion? It makes sense to me to fix. -- Best regards, Kathleen --f46d0442806e03af17051a703d3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jul 6, 2015 at 6:55 PM, Benoit Claise <bclaise@cisco.com&g= t; wrote:
Benoit Claise has entere= d the following ballot position for
charter-ietf-radext-05-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-r= adext/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Editorial improvement: Remove "Furthermore" in the second paragra= ph.

Instead of duplicating the RFC type ( "This will be a standards track<= br> document.") in the charter and the milestones , consider mentioning it=
only in the milestones ("Nov 2016 - Data Types as Informational RFC&qu= ot;)
advantage #1: strong AD advice, it can still be changed if the WG has got a good reason
advantage #2: it avoids discrepancies between the charter text and the
milestones. Look at the data types document :-)


I'd like to make any changes prior to our call in= less than 2 hours, what is the WG chairs opinion on this suggestion?=C2=A0= It makes sense to me to fix.=C2=A0


<= br>
--

Be= st regards,
Kathleen
--f46d0442806e03af17051a703d3a-- From nobody Thu Jul 9 05:21:58 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A13B1AD34C; Thu, 9 Jul 2015 05:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXh7QrYhaAvP; Thu, 9 Jul 2015 05:21:42 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153191AD35A; Thu, 9 Jul 2015 05:21:42 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 68E9F1B86EC; Thu, 9 Jul 2015 14:21:40 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.17]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 44702180051; Thu, 9 Jul 2015 14:21:40 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0235.001; Thu, 9 Jul 2015 14:21:39 +0200 From: To: Kathleen Moriarty , Benoit Claise , "radext-chairs@tools.ietf.org" Thread-Topic: [radext] Benoit Claise's No Objection on charter-ietf-radext-05-01: (with COMMENT) Thread-Index: AQHQuD7f9W/ZomNF80+Z6n84GsZoTp3S8GiAgAAh2GA= Date: Thu, 9 Jul 2015 12:21:38 +0000 Message-ID: <848_1436444500_559E6754_848_11607_1_6B7134B31289DC4FAF731D844122B36E01CBC48F@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20150706225527.12089.54865.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01CBC48FOPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.9.111516 Archived-At: Cc: "radext@ietf.org" , The IESG Subject: Re: [radext] Benoit Claise's No Objection on charter-ietf-radext-05-01: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 12:21:53 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01CBC48FOPEXCLILM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0sgd2l0aCBCZW5vaXQgKEkgZG8gaGF2ZSB0byBhZ3JlZSB3aXRoIGhpbSDimLogKQ0KDQpJdCBp cyBqdXN0IG5lZWRlZCB0byByZW1vdmUgdGhlIGxhc3Qgc2VudGVuY2UgaW4gdGhlIGJ1bGxldCAi Q09BIHByb3h5aW5nIiBhbmQgIkRhdGEgVHlwZXMiLg0KDQpSZWdhcmRzLA0KDQpMaW9uZWwNCg0K RGUgOiByYWRleHQgW21haWx0bzpyYWRleHQtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBk ZSBLYXRobGVlbiBNb3JpYXJ0eQ0KRW52b3nDqSA6IGpldWRpIDkganVpbGxldCAyMDE1IDE0OjE3 DQrDgCA6IEJlbm9pdCBDbGFpc2U7IHJhZGV4dC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCkNjIDog cmFkZXh0QGlldGYub3JnOyBUaGUgSUVTRw0KT2JqZXQgOiBSZTogW3JhZGV4dF0gQmVub2l0IENs YWlzZSdzIE5vIE9iamVjdGlvbiBvbiBjaGFydGVyLWlldGYtcmFkZXh0LTA1LTAxOiAod2l0aCBD T01NRU5UKQ0KDQoNCg0KT24gTW9uLCBKdWwgNiwgMjAxNSBhdCA2OjU1IFBNLCBCZW5vaXQgQ2xh aXNlIDxiY2xhaXNlQGNpc2NvLmNvbTxtYWlsdG86YmNsYWlzZUBjaXNjby5jb20+PiB3cm90ZToN CkJlbm9pdCBDbGFpc2UgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yDQpjaGFydGVyLWlldGYtcmFkZXh0LTA1LTAxOiBObyBPYmplY3Rpb24NCg0KV2hlbiByZXNw b25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8g YWxsDQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZl ZWwgZnJlZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pDQoN Cg0KDQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2Fu IGJlIGZvdW5kIGhlcmU6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9jaGFydGVy LWlldGYtcmFkZXh0Lw0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KQ09NTUVOVDoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KRWRpdG9yaWFsIGltcHJvdmVtZW50OiBSZW1vdmUgIkZ1cnRoZXJtb3JlIiBpbiB0aGUg c2Vjb25kIHBhcmFncmFwaC4NCg0KSW5zdGVhZCBvZiBkdXBsaWNhdGluZyB0aGUgUkZDIHR5cGUg KCAiVGhpcyB3aWxsIGJlIGEgc3RhbmRhcmRzIHRyYWNrDQpkb2N1bWVudC4iKSBpbiB0aGUgY2hh cnRlciBhbmQgdGhlIG1pbGVzdG9uZXMgLCBjb25zaWRlciBtZW50aW9uaW5nIGl0DQpvbmx5IGlu IHRoZSBtaWxlc3RvbmVzICgiTm92IDIwMTYgLSBEYXRhIFR5cGVzIGFzIEluZm9ybWF0aW9uYWwg UkZDIikNCmFkdmFudGFnZSAjMTogc3Ryb25nIEFEIGFkdmljZSwgaXQgY2FuIHN0aWxsIGJlIGNo YW5nZWQgaWYgdGhlIFdHIGhhcyBnb3QNCmEgZ29vZCByZWFzb24NCmFkdmFudGFnZSAjMjogaXQg YXZvaWRzIGRpc2NyZXBhbmNpZXMgYmV0d2VlbiB0aGUgY2hhcnRlciB0ZXh0IGFuZCB0aGUNCm1p bGVzdG9uZXMuIExvb2sgYXQgdGhlIGRhdGEgdHlwZXMgZG9jdW1lbnQgOi0pDQoNCkknZCBsaWtl IHRvIG1ha2UgYW55IGNoYW5nZXMgcHJpb3IgdG8gb3VyIGNhbGwgaW4gbGVzcyB0aGFuIDIgaG91 cnMsIHdoYXQgaXMgdGhlIFdHIGNoYWlycyBvcGluaW9uIG9uIHRoaXMgc3VnZ2VzdGlvbj8gIEl0 IG1ha2VzIHNlbnNlIHRvIG1lIHRvIGZpeC4NCg0KDQoNCi0tDQoNCkJlc3QgcmVnYXJkcywNCkth dGhsZWVuDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll ZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3Bp ZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= --_000_6B7134B31289DC4FAF731D844122B36E01CBC48FOPEXCLILM43corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPk9LIHdpdGggQmVub2l0IChJIGRvIGhhdmUgdG8gYWdyZWUgd2l0aCBoaW0NCjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29s b3I6IzFGNDk3RCI+Sjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPiApPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi Pkl0IGlzIGp1c3QgbmVlZGVkIHRvIHJlbW92ZSB0aGUgbGFzdCBzZW50ZW5jZSBpbiB0aGUgYnVs bGV0ICZxdW90O0NPQSBwcm94eWluZyZxdW90OyBhbmQgJnF1b3Q7RGF0YSBUeXBlcyZxdW90Oy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TGlvbmVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJhZGV4dCBbbWFpbHRvOnJhZGV4dC1i b3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gS2F0aGxlZW4gTW9yaWFydHk8 YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgOSBqdWlsbGV0IDIwMTUgMTQ6MTc8YnI+ DQo8Yj7DgCZuYnNwOzo8L2I+IEJlbm9pdCBDbGFpc2U7IHJhZGV4dC1jaGFpcnNAdG9vbHMuaWV0 Zi5vcmc8YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IHJhZGV4dEBpZXRmLm9yZzsgVGhlIElFU0c8YnI+ DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbcmFkZXh0XSBCZW5vaXQgQ2xhaXNlJ3MgTm8gT2Jq ZWN0aW9uIG9uIGNoYXJ0ZXItaWV0Zi1yYWRleHQtMDUtMDE6ICh3aXRoIENPTU1FTlQpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdWwgNiwgMjAxNSBhdCA2OjU1IFBNLCBCZW5v aXQgQ2xhaXNlICZsdDs8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20iIHRhcmdldD0i X2JsYW5rIj5iY2xhaXNlQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5CZW5vaXQg Q2xhaXNlIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxicj4N CmNoYXJ0ZXItaWV0Zi1yYWRleHQtMDUtMDE6IE5vIE9iamVjdGlvbjxicj4NCjxicj4NCldoZW4g cmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5 IHRvIGFsbDxicj4NCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxp bmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzPGJyPg0KaW50cm9kdWN0b3J5IHBhcmFncmFwaCwg aG93ZXZlci4pPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2NoYXJ0ZXItaWV0Zi1yYWRleHQvIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvY2hhcnRlci1p ZXRmLXJhZGV4dC88L2E+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CkNPTU1FTlQ6PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCjxicj4NCkVkaXRvcmlhbCBpbXByb3Zl bWVudDogUmVtb3ZlICZxdW90O0Z1cnRoZXJtb3JlJnF1b3Q7IGluIHRoZSBzZWNvbmQgcGFyYWdy YXBoLjxicj4NCjxicj4NCkluc3RlYWQgb2YgZHVwbGljYXRpbmcgdGhlIFJGQyB0eXBlICggJnF1 b3Q7VGhpcyB3aWxsIGJlIGEgc3RhbmRhcmRzIHRyYWNrPGJyPg0KZG9jdW1lbnQuJnF1b3Q7KSBp biB0aGUgY2hhcnRlciBhbmQgdGhlIG1pbGVzdG9uZXMgLCBjb25zaWRlciBtZW50aW9uaW5nIGl0 PGJyPg0Kb25seSBpbiB0aGUgbWlsZXN0b25lcyAoJnF1b3Q7Tm92IDIwMTYgLSBEYXRhIFR5cGVz IGFzIEluZm9ybWF0aW9uYWwgUkZDJnF1b3Q7KTxicj4NCmFkdmFudGFnZSAjMTogc3Ryb25nIEFE IGFkdmljZSwgaXQgY2FuIHN0aWxsIGJlIGNoYW5nZWQgaWYgdGhlIFdHIGhhcyBnb3Q8YnI+DQph IGdvb2QgcmVhc29uPGJyPg0KYWR2YW50YWdlICMyOiBpdCBhdm9pZHMgZGlzY3JlcGFuY2llcyBi ZXR3ZWVuIHRoZSBjaGFydGVyIHRleHQgYW5kIHRoZTxicj4NCm1pbGVzdG9uZXMuIExvb2sgYXQg dGhlIGRhdGEgdHlwZXMgZG9jdW1lbnQgOi0pPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdkIGxpa2UgdG8gbWFrZSBhbnkgY2hhbmdlcyBw cmlvciB0byBvdXIgY2FsbCBpbiBsZXNzIHRoYW4gMiBob3Vycywgd2hhdCBpcyB0aGUgV0cgY2hh aXJzIG9waW5pb24gb24gdGhpcyBzdWdnZXN0aW9uPyZuYnNwOyBJdCBtYWtlcyBzZW5zZSB0byBt ZSB0byBmaXguJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5LYXRobGVlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_6B7134B31289DC4FAF731D844122B36E01CBC48FOPEXCLILM43corp_-- From nobody Thu Jul 9 06:32:44 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C75F1A908A; Thu, 9 Jul 2015 06:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gTbNhxdcNmtI; Thu, 9 Jul 2015 06:32:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C38021A9084; Thu, 9 Jul 2015 06:32:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150709133239.28834.79131.idtracker@ietfa.amsl.com> Date: Thu, 09 Jul 2015 06:32:39 -0700 Archived-At: Cc: radext@ietf.org Subject: [radext] Spencer Dawkins' No Objection on charter-ietf-radext-05-02: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 13:32:41 -0000 Spencer Dawkins has entered the following ballot position for charter-ietf-radext-05-02: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-radext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This text is garbled: When a NAS is simply performs an exact copy of an EAP-Identity into a User-Name, invalid packets might be produced. In this text: - Data Types. RFC 2865 defines a number of data types, but later documents do not use those types in a consistent way. This work item will define data types, and update the IANA RADIUS Attribute Type registry so that each attribute has a data type. Where necessary, it will correct issues with previous specifications. This will be a standards track document. I'm not understanding if there are are constraints about backward compatibility between data types from this work and RFC 2865. If that's unknown, or obvious, that's fine, of course. In this text: Larger Packets. Support RADIUS packets greater than 4096-octets over RADIUS transports with this capability. Is this doing anything that would benefit from TSVWG review? I'm guessing not, but wanted to ask. From nobody Thu Jul 9 06:54:04 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2DE1A90EC; Thu, 9 Jul 2015 06:54:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGoz0y29YT1F; Thu, 9 Jul 2015 06:54:01 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 CBE2C1A90E7; Thu, 9 Jul 2015 06:54:00 -0700 (PDT) Received: by widjy10 with SMTP id jy10so245703989wid.1; Thu, 09 Jul 2015 06:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g2QX/rD5trIdaLfJNeACPsYQW7etbhdqYzGeWYjNjEw=; b=0ZGDnmiqNACi4qZDrRHXe6nOFrJpL2iN89LCryiw/XyxIMjnm8hpUUyK0HbV5irlZJ fww8Uz9cO1oPv274XIdaB5GSG+IBVu+swUHT/VCoIBiUVxN/8po4hzIaVuSOu+Uk0+pu 7pkB+xKI2X0pjXwnjwTKQvoUIKMK5VaQAno+3DRJ+looJ42PnPOPJsgEIJ/O60sx5lpE JqO77OiUVmUOfEojve/TNK1mVA7jVg/xd4+dcqxBcYnqywqF9K+82YpwmOyVi5subin+ JtHxA3hfiZpJK9KEXbTMPSYRV7nvTbLqdSGdi+mLmxht8gQ42JAtMuDGU35dOcFgMZmv 7OXQ== MIME-Version: 1.0 X-Received: by 10.180.86.168 with SMTP id q8mr116718694wiz.80.1436450039549; Thu, 09 Jul 2015 06:53:59 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Thu, 9 Jul 2015 06:53:59 -0700 (PDT) In-Reply-To: <848_1436444500_559E6754_848_11607_1_6B7134B31289DC4FAF731D844122B36E01CBC48F@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20150706225527.12089.54865.idtracker@ietfa.amsl.com> <848_1436444500_559E6754_848_11607_1_6B7134B31289DC4FAF731D844122B36E01CBC48F@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Thu, 9 Jul 2015 09:53:59 -0400 Message-ID: From: Kathleen Moriarty To: "" Content-Type: multipart/alternative; boundary=bcaec55550305853d6051a719661 Archived-At: Cc: Benoit Claise , "radext@ietf.org" , The IESG , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Benoit Claise's No Objection on charter-ietf-radext-05-01: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 13:54:03 -0000 --bcaec55550305853d6051a719661 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Great, update has been made. We just have Spencer's comments outstanding (they just came in). Thank you, Kathleen On Thu, Jul 9, 2015 at 8:21 AM, wrote: > OK with Benoit (I do have to agree with him J ) > > > > It is just needed to remove the last sentence in the bullet "COA proxying= " > and "Data Types". > > > > Regards, > > > > Lionel > > > > *De :* radext [mailto:radext-bounces@ietf.org] *De la part de* Kathleen > Moriarty > *Envoy=C3=A9 :* jeudi 9 juillet 2015 14:17 > *=C3=80 :* Benoit Claise; radext-chairs@tools.ietf.org > *Cc :* radext@ietf.org; The IESG > *Objet :* Re: [radext] Benoit Claise's No Objection on > charter-ietf-radext-05-01: (with COMMENT) > > > > > > > > On Mon, Jul 6, 2015 at 6:55 PM, Benoit Claise wrote: > > Benoit Claise has entered the following ballot position for > charter-ietf-radext-05-01: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-radext/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Editorial improvement: Remove "Furthermore" in the second paragraph. > > Instead of duplicating the RFC type ( "This will be a standards track > document.") in the charter and the milestones , consider mentioning it > only in the milestones ("Nov 2016 - Data Types as Informational RFC") > advantage #1: strong AD advice, it can still be changed if the WG has got > a good reason > advantage #2: it avoids discrepancies between the charter text and the > milestones. Look at the data types document :-) > > I'd like to make any changes prior to our call in less than 2 hours, > what is the WG chairs opinion on this suggestion? It makes sense to me t= o > fix. > > > > > > -- > > > > Best regards, > > Kathleen > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation 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 de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --=20 Best regards, Kathleen --bcaec55550305853d6051a719661 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Great, update has been made.=C2=A0 We just have Spencer= 9;s comments outstanding (they just came in).

Thank you,=
Kathleen

On Thu, Jul 9, 2015 at 8:21 AM, <lionel.morand@orang= e.com> wrote:

OK with Be= noit (I do have to agree with him J )<= /p>

=C2= =A0

It is just= needed to remove the last sentence in the bullet "COA proxying" = and "Data Types".

=C2= =A0

Regards,

=C2= =A0

Lionel<= /u>

=C2= =A0

De=C2=A0: rade= xt [mailto:rad= ext-bounces@ietf.org] De la part de Kathleen Moriarty
Envoy=C3=A9=C2=A0: jeudi 9 juillet 2015 14:17
=C3=80=C2=A0: Benoit Claise; radext-chairs@tools.ietf.org
Cc=C2=A0: radex= t@ietf.org; The IESG
Objet=C2=A0: Re: [radext] Benoit Claise's No Objection on charte= r-ietf-radext-05-01: (with COMMENT)

=C2=A0

=C2=A0

=C2=A0

On Mon, Jul 6, 2015 at 6:55 PM, Benoit Claise <bclaise@cisco.com&= gt; wrote:

Benoit Claise has ent= ered the following ballot position for
charter-ietf-radext-05-01: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-radext/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Editorial improvement: Remove "Furthermore" in the second paragra= ph.

Instead of duplicating the RFC type ( "This will be a standards track<= br> document.") in the charter and the milestones , consider mentioning it=
only in the milestones ("Nov 2016 - Data Types as Informational RFC&qu= ot;)
advantage #1: strong AD advice, it can still be changed if the WG has got a good reason
advantage #2: it avoids discrepancies between the charter text and the
milestones. Look at the data types document :-)

I'd like to make any changes prior to our call i= n less than 2 hours, what is the WG chairs opinion on this suggestion?=C2= =A0 It makes sense to me to fix.=C2=A0



=C2=A0

--

=C2=A0

Best regards,

Kathleen

______________________________________________________________________=
___________________________________________________

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 message=
s electroniques 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.



--

Best regards,
Kath= leen
--bcaec55550305853d6051a719661-- From nobody Thu Jul 9 06:57:38 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C4B1A90FD; Thu, 9 Jul 2015 06:57: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 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 U7BQKe8tRESR; Thu, 9 Jul 2015 06:57:31 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9D11A90E2; Thu, 9 Jul 2015 06:57:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7A67F2240929; Thu, 9 Jul 2015 15:57:30 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QlLHSm6ii2q; Thu, 9 Jul 2015 15:57:29 +0200 (CEST) Received: from [192.168.2.12] (bas1-ottawa11-1176122299.dsl.bell.ca [70.26.51.187]) by power.freeradius.org (Postfix) with ESMTPSA id 86A2C22403FA; Thu, 9 Jul 2015 15:57:28 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <20150709133239.28834.79131.idtracker@ietfa.amsl.com> Date: Thu, 9 Jul 2015 09:57:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1FD2F7BC-926D-4DD8-B986-6C9A984AC857@deployingradius.com> References: <20150709133239.28834.79131.idtracker@ietfa.amsl.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: radext@ietf.org, The IESG Subject: Re: [radext] Spencer Dawkins' No Objection on charter-ietf-radext-05-02: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 13:57:33 -0000 On Jul 9, 2015, at 9:32 AM, Spencer Dawkins = wrote: > In this text: >=20 > - Data Types. RFC 2865 defines a number of data types, but later=09= > documents do not use those types in a consistent way. This = work > item=09 > will define data types, and update the IANA RADIUS Attribute Type=09= > registry so that each attribute has a data type. Where = necessary, > it=09 > will correct issues with previous specifications. This will = be a=09 > standards track document. >=20 > I'm not understanding if there are are constraints about backward > compatibility between data types from this work and RFC 2865. If = that's > unknown, or obvious, that's fine, of course. The data types are wire compatible, and have identical meaning to = those defined in RFC 2865. The spec is required because data types are = being promoted to well-defined, and IANA managed entities. This spec = has no impact on existing implementations. It mainly affects how RFCs = are written. > In this text: >=20 > Larger Packets. Support RADIUS packets greater than 4096-octets over=09= > RADIUS transports with this capability. >=20 > Is this doing anything that would benefit from TSVWG review? I'm = guessing > not, but wanted to ask. The large packet support is limited to RADIUS over TCP. So it's just = more application data over TCP, which means TSVWG review is probably = unnecessary. Alan DeKok. From nobody Thu Jul 9 06:59:41 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345051A911B; Thu, 9 Jul 2015 06:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM-wqJcd7xFs; Thu, 9 Jul 2015 06:59:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C47B61A9147; Thu, 9 Jul 2015 06:59:21 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 502F9374918; Thu, 9 Jul 2015 15:59:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.33]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 33062384073; Thu, 9 Jul 2015 15:59:20 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM42.corporate.adroot.infra.ftgroup ([fe80::d5fd:9c7d:2ee3:39d9%19]) with mapi id 14.03.0235.001; Thu, 9 Jul 2015 15:59:19 +0200 From: To: Spencer Dawkins , The IESG Thread-Topic: [radext] Spencer Dawkins' No Objection on charter-ietf-radext-05-02: (with COMMENT) Thread-Index: AQHQuku9eeFgej4g8kOnNEySOl49Q53TI3YA Date: Thu, 9 Jul 2015 13:59:18 +0000 Message-ID: <30711_1436450360_559E7E38_30711_5397_1_6B7134B31289DC4FAF731D844122B36E01CBC7CF@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20150709133239.28834.79131.idtracker@ietfa.amsl.com> In-Reply-To: <20150709133239.28834.79131.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.9.132415 Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Spencer Dawkins' No Objection on charter-ietf-radext-05-02: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 13:59:30 -0000 Hi Spencer, please below. regards, Lionel -----Message d'origine----- De=A0: radext [mailto:radext-bounces@ietf.org] De la part de Spencer Dawkins Envoy=E9=A0: jeudi 9 juillet 2015 15:33 =C0=A0: The IESG Cc=A0: radext@ietf.org Objet=A0: [radext] Spencer Dawkins' No Objection on charter-ietf-radext-05-= 02: (with COMMENT) Spencer Dawkins has entered the following ballot position for charter-ietf-radext-05-02: No Objection When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-radext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This text is garbled: When a=09 NAS is simply performs an exact copy of an EAP-Identity into a User-Name,=09 invalid packets might be produced. [LM] obviously, the text should be: "When a NAS simply performs an exact co= py of an EAP-Identity into a User-Name, invalid packets might be produced." =20=20=20=20 In this text: =20=20=20=20 - Data Types. RFC 2865 defines a number of data types, but later=09 documents do not use those types in a consistent way. This work item=09 will define data types, and update the IANA RADIUS Attribute Type=09 registry so that each attribute has a data type. Where necessary, it=09 will correct issues with previous specifications. This will be a=09 standards track document. =20=20=20=20=20=20 I'm not understanding if there are are constraints about backward compatibi= lity between data types from this work and RFC 2865. If that's unknown, or = obvious, that's fine, of course. [LM] There is no backward compatibility issues. It is more about clarifying= the data type used for each existing attribute (to avoid some ambiguities)= and update accordingly the current attribute type registry to add a new co= lumn with the data type. And this will be also useful for the creation of n= ew attributes. In this text: Larger Packets. Support RADIUS packets greater than 4096-octets over=09 RADIUS transports with this capability. =20 Is this doing anything that would benefit from TSVWG review? I'm guessing n= ot, but wanted to ask. [LM] Not sure to understand why there would be the need for a specific revi= ew of TSVWG, which might be anyway be involved during the IETF last call. = For clarification, in the present case, we are not over UDP but over TCP _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ 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 Thu Jul 9 07:14:34 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8ED1A9174; Thu, 9 Jul 2015 07:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV21vRIBI3DA; Thu, 9 Jul 2015 07:14:31 -0700 (PDT) Received: from mail-vn0-x236.google.com (mail-vn0-x236.google.com [IPv6:2607:f8b0:400c:c0f::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 AF5711A9172; Thu, 9 Jul 2015 07:14:30 -0700 (PDT) Received: by vnbf1 with SMTP id f1so23532032vnb.10; Thu, 09 Jul 2015 07:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/BuUkgSWc3E/ECGSmgd75gJD46TH1IKpU1sWJl6a0c4=; b=ErcTMDHrhIHWiuSDH4nPOtM6lAPwv7poduVfJKcsvA0zYOEWJ8O5SfnbdfVs4nEAy3 fe6Xx7xgFOgbHfn75kcIlhd9CRlacugpOjfA0RAUOUg3e2aDXYycHJ0UpceVzUg6P72v 5qSy017mo0aouirTjTGarp2vWyMM54zdjAXBxcJZZc6CB9P0hzVHvbrbsTmQ/WH+mb+1 2ALG26ZO2138QbpGdq7+oJiobAHQWFAvim5YkrgsuOKeKptbWBs39Qdg0fo5ghbZRML/ V0Q6RlCEWa3DEjpb8S0GzKTMy1Diuw5331X9G1k13reWDXUWkzd6+OIAec5l5QSvb+KT qfBw== MIME-Version: 1.0 X-Received: by 10.52.13.198 with SMTP id j6mr14999361vdc.94.1436451269983; Thu, 09 Jul 2015 07:14:29 -0700 (PDT) Received: by 10.31.63.1 with HTTP; Thu, 9 Jul 2015 07:14:29 -0700 (PDT) In-Reply-To: <30711_1436450360_559E7E38_30711_5397_1_6B7134B31289DC4FAF731D844122B36E01CBC7CF@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <20150709133239.28834.79131.idtracker@ietfa.amsl.com> <30711_1436450360_559E7E38_30711_5397_1_6B7134B31289DC4FAF731D844122B36E01CBC7CF@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Thu, 9 Jul 2015 09:14:29 -0500 Message-ID: From: Spencer Dawkins at IETF To: lionel.morand@orange.com Content-Type: multipart/alternative; boundary=20cf303347d3af4259051a71dffc Archived-At: Cc: "radext@ietf.org" , The IESG Subject: Re: [radext] Spencer Dawkins' No Objection on charter-ietf-radext-05-02: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 14:14:33 -0000 --20cf303347d3af4259051a71dffc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also saw Alan's response ... thanks for both. On Thu, Jul 9, 2015 at 8:59 AM, wrote: > Hi Spencer, > > please below. > > regards, > > Lionel > > -----Message d'origine----- > De : radext [mailto:radext-bounces@ietf.org] De la part de Spencer Dawkin= s > Envoy=C3=A9 : jeudi 9 juillet 2015 15:33 > =C3=80 : The IESG > Cc : radext@ietf.org > Objet : [radext] Spencer Dawkins' No Objection on > charter-ietf-radext-05-02: (with COMMENT) > > Spencer Dawkins has entered the following ballot position for > charter-ietf-radext-05-02: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-radext/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > This text is garbled: > > When a > NAS is simply performs an exact copy of an EAP-Identity into a > User-Name, > invalid packets might be produced. > > [LM] obviously, the text should be: "When a NAS simply performs an exact > copy of an EAP-Identity into a User-Name, invalid packets might be > produced." Thanks. > In this text: > > - Data Types. RFC 2865 defines a number of data types, but later > documents do not use those types in a consistent way. This wor= k > item > will define data types, and update the IANA RADIUS Attribute Type > registry so that each attribute has a data type. Where > necessary, > it > will correct issues with previous specifications. This will be= a > standards track document. > > I'm not understanding if there are are constraints about backward > compatibility between data types from this work and RFC 2865. If that's > unknown, or obvious, that's fine, of course. > > [LM] There is no backward compatibility issues. It is more about > clarifying the data type used for each existing attribute (to avoid some > ambiguities) and update accordingly the current attribute type registry t= o > add a new column with the data type. And this will be also useful for the > creation of new attributes. That wasn't clear to me (both documents were defining data types). Saying that this work is clarifying, rather than defining, would be clearer. > In this text: > > Larger Packets. Support RADIUS packets greater than 4096-octets over > RADIUS transports with this capability. > > Is this doing anything that would benefit from TSVWG review? I'm guessing > not, but wanted to ask. > > [LM] Not sure to understand why there would be the need for a specific > review of TSVWG, which might be anyway be involved during the IETF last > call. For clarification, in the present case, we are not over UDP but ov= er > TCP That's what I hoped. My reason for asking was to avoid late surprises that could happen earlier :-) Thanks, Spencer --20cf303347d3af4259051a71dffc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also saw Alan's response ... thanks for both.

On Thu, Jul 9, 2015 at 8= :59 AM, <lionel.morand@orange.com> wrote:
Hi Spencer,

please below.

regards,

Lionel

-----Message d'origine-----
De=C2=A0: radext [mailto:radext-= bounces@ietf.org] De la part de Spencer Dawkins
Envoy=C3=A9=C2=A0: jeudi 9 juillet 2015 15:33
=C3=80=C2=A0: The IESG
Cc=C2=A0: radext@ietf.org
Objet=C2=A0: [radext] Spencer Dawkins' No Objection on charter-ietf-rad= ext-05-02: (with COMMENT)

Spencer Dawkins has entered the following ballot position for
charter-ietf-radext-05-02: No Objection

When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-r= adext/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This text is garbled:

=C2=A0 =C2=A0 When a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 NAS is simply performs an exact copy of an EAP-= Identity into a
User-Name,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 invalid packets might be produced.

[LM] obviously, the text should be: "When a NAS simply performs= an exact copy of an EAP-Identity into a User-Name, invalid packets might b= e produced."

Thanks.
=C2=A0<= /div>
In this text:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Data Types. RFC 2865 defines a number of data= types, but later
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 documents do not use those types in a co= nsistent way.=C2=A0 This work
item
=C2=A0 =C2=A0 =C2=A0 will define data types, and update the IANA RADIUS Att= ribute Type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 registry so that each attribute has a da= ta type.=C2=A0 Where necessary,
it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 will correct issues with previous specif= ications.=C2=A0 This will be a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 standards track document.

I'm not understanding if there are are constraints about backward compa= tibility between data types from this work and RFC 2865. If that's unkn= own, or obvious, that's fine, of course.

[LM] There is no backward compatibility issues. It is more about cla= rifying the data type used for each existing attribute (to avoid some ambig= uities) and update accordingly the current attribute type registry to add a= new column with the data type. And this will be also useful for the creati= on of new attributes.

That wasn't clear= to me (both documents were defining data types). Saying that this work is = clarifying, rather than defining, would be clearer.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">In this text:

=C2=A0Larger Packets. Support RADIUS packets greater than 4096-octets over<= br> =C2=A0RADIUS transports with this capability.

Is this doing anything that would benefit from TSVWG review? I'm guessi= ng not, but wanted to ask.

[LM] Not sure to understand why there would be the need for a specif= ic review of TSVWG, which might be anyway be involved during the IETF last = call.=C2=A0 For clarification, in the present case, we are not over UDP but= over TCP

That's what I hoped. My reaso= n for asking was to avoid late surprises that could happen earlier :-)

Thanks,

Spencer=C2=A0
--20cf303347d3af4259051a71dffc-- From nobody Thu Jul 9 07:19:04 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F481A9174; Thu, 9 Jul 2015 07:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiJ4oYlLy_Ii; Thu, 9 Jul 2015 07:18:57 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c: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 76FDB1A9148; Thu, 9 Jul 2015 07:18:56 -0700 (PDT) Received: by wgck11 with SMTP id k11so225134553wgc.0; Thu, 09 Jul 2015 07:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lNOIZMwnYPp5o83DyMZrHpBWr0PxueXJ1vZVmIEWPms=; b=CcmYBc8uBMLTscaHATeXXWR+SQlkNM6dF3cJMbtrpjy6HnhxLjWpgFVnjdnDiO/csV XeV54zrYN30n2tznnrNCUrrd5XRDhXzuLff8w3aCzI8OKtiRmFMnYhMm77G5i2rEdpU6 7Q3orw1FQMMVzh65n32iSRsYg9MU5mSOfqSeqJRfMFyWmpDstJS6slf63gOy6rSPfc60 iGKtrVIo7ADsdgR1r9wn99ISkZ2tb9AIiRAqA/0fpEUcR9LzDjTMYtCQnZ0TgPZKdqxW q+uBTMhimoTllyeFyysSLa5s/m8iduxw2cTtLeEAZnro5VQG0auVWzL90Gv4Auz+OU4H I6IQ== MIME-Version: 1.0 X-Received: by 10.180.95.67 with SMTP id di3mr83877776wib.78.1436451535278; Thu, 09 Jul 2015 07:18:55 -0700 (PDT) Received: by 10.28.31.194 with HTTP; Thu, 9 Jul 2015 07:18:55 -0700 (PDT) In-Reply-To: References: <20150709133239.28834.79131.idtracker@ietfa.amsl.com> <30711_1436450360_559E7E38_30711_5397_1_6B7134B31289DC4FAF731D844122B36E01CBC7CF@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Thu, 9 Jul 2015 10:18:55 -0400 Message-ID: From: Kathleen Moriarty To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=f46d044287e27f59a2051a71efbe Archived-At: Cc: "radext@ietf.org" , The IESG , "" Subject: Re: [radext] Spencer Dawkins' No Objection on charter-ietf-radext-05-02: (with COMMENT) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 14:18:59 -0000 --f46d044287e27f59a2051a71efbe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the catch, Spencer... On Thu, Jul 9, 2015 at 10:14 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > I also saw Alan's response ... thanks for both. > > On Thu, Jul 9, 2015 at 8:59 AM, wrote: > >> Hi Spencer, >> >> please below. >> >> regards, >> >> Lionel >> >> -----Message d'origine----- >> De : radext [mailto:radext-bounces@ietf.org] De la part de Spencer >> Dawkins >> Envoy=C3=A9 : jeudi 9 juillet 2015 15:33 >> =C3=80 : The IESG >> Cc : radext@ietf.org >> Objet : [radext] Spencer Dawkins' No Objection on >> charter-ietf-radext-05-02: (with COMMENT) >> >> Spencer Dawkins has entered the following ballot position for >> charter-ietf-radext-05-02: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/charter-ietf-radext/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> This text is garbled: >> >> When a >> NAS is simply performs an exact copy of an EAP-Identity into a >> User-Name, >> invalid packets might be produced. >> >> [LM] obviously, the text should be: "When a NAS simply performs an exact >> copy of an EAP-Identity into a User-Name, invalid packets might be >> produced." > > > Thanks. > This has been fixed and I am responsible for the wording, thanks for catching it! I think the charter now addresses all comments. Kathleen > > >> In this text: >> >> - Data Types. RFC 2865 defines a number of data types, but later >> documents do not use those types in a consistent way. This wo= rk >> item >> will define data types, and update the IANA RADIUS Attribute Type >> registry so that each attribute has a data type. Where >> necessary, >> it >> will correct issues with previous specifications. This will b= e >> a >> standards track document. >> >> I'm not understanding if there are are constraints about backward >> compatibility between data types from this work and RFC 2865. If that's >> unknown, or obvious, that's fine, of course. >> >> [LM] There is no backward compatibility issues. It is more about >> clarifying the data type used for each existing attribute (to avoid some >> ambiguities) and update accordingly the current attribute type registry = to >> add a new column with the data type. And this will be also useful for th= e >> creation of new attributes. > > > That wasn't clear to me (both documents were defining data types). Saying > that this work is clarifying, rather than defining, would be clearer. > > >> In this text: >> >> Larger Packets. Support RADIUS packets greater than 4096-octets over >> RADIUS transports with this capability. >> >> Is this doing anything that would benefit from TSVWG review? I'm guessin= g >> not, but wanted to ask. >> >> [LM] Not sure to understand why there would be the need for a specific >> review of TSVWG, which might be anyway be involved during the IETF last >> call. For clarification, in the present case, we are not over UDP but o= ver >> TCP > > > That's what I hoped. My reason for asking was to avoid late surprises tha= t > could happen earlier :-) > > Thanks, > > Spencer > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > --=20 Best regards, Kathleen --f46d044287e27f59a2051a71efbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the catch, Spencer...

On Thu, Jul 9, 2015 at 10:14 AM, Spence= r Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
I also saw Alan= 's response ... thanks for both.

On Thu, Jul 9, 2015 at 8:59 AM, = <lionel.morand@orange.com> wrote:
Hi Spencer,

please below.

regards,

Lionel

-----Message d'origine-----
De=C2=A0: radext [mailto:radext-bounces@ietf.org] De la part de Spencer Dawkins
Envoy=C3=A9=C2=A0: jeudi 9 juillet 2015 15:33
=C3=80=C2=A0: The IESG
Cc=C2=A0: radext@ietf.= org
Objet=C2=A0: [radext] Spencer Dawkins' No Objection on charter-ietf-rad= ext-05-02: (with COMMENT)

Spencer Dawkins has entered the following ballot position for
charter-ietf-radext-05-02: No Objection

When responding, please keep the subject line intact and reply to all email= addresses included in the To and CC lines. (Feel free to cut this introduc= tory paragraph, however.)



The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-r= adext/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This text is garbled:

=C2=A0 =C2=A0 When a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 NAS is simply performs an exact copy of an EAP-= Identity into a
User-Name,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 invalid packets might be produced.

[LM] obviously, the text should be: "When a NAS simply performs= an exact copy of an EAP-Identity into a User-Name, invalid packets might b= e produced."

Thanks.
=

This has been fixed and = I am responsible for the wording, thanks for catching it!

I think the charter now addresses all comments.
Kathleen= =C2=A0
=C2=A0
In this text:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Data Types. RFC 2865 defines a number of data= types, but later
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 documents do not use those types in a co= nsistent way.=C2=A0 This work
item
=C2=A0 =C2=A0 =C2=A0 will define data types, and update the IANA RADIUS Att= ribute Type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 registry so that each attribute has a da= ta type.=C2=A0 Where necessary,
it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 will correct issues with previous specif= ications.=C2=A0 This will be a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 standards track document.

I'm not understanding if there are are constraints about backward compa= tibility between data types from this work and RFC 2865. If that's unkn= own, or obvious, that's fine, of course.

[LM] There is no backward compatibility issues. It is more about cla= rifying the data type used for each existing attribute (to avoid some ambig= uities) and update accordingly the current attribute type registry to add a= new column with the data type. And this will be also useful for the creati= on of new attributes.

That wasn'= t clear to me (both documents were defining data types). Saying that this w= ork is clarifying, rather than defining, would be clearer.
=C2=A0
In this text:
=C2=A0Larger Packets. Support RADIUS packets greater than 4096-octets over<= br> =C2=A0RADIUS transports with this capability.

Is this doing anything that would benefit from TSVWG review? I'm guessi= ng not, but wanted to ask.

[LM] Not sure to understand why there would be the need for a specif= ic review of TSVWG, which might be anyway be involved during the IETF last = call.=C2=A0 For clarification, in the present case, we are not over UDP but= over TCP

That's what I hoped. M= y reason for asking was to avoid late surprises that could happen earlier := -)

Thanks,

Spencer=C2=A0<= /div>

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




--

Best regards,
Ka= thleen
--f46d044287e27f59a2051a71efbe-- From nobody Fri Jul 10 08:46:38 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E701B29D8; Fri, 10 Jul 2015 08:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APlxnmjug67j; Fri, 10 Jul 2015 08:46:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1800E1B2A01; Fri, 10 Jul 2015 08:46:33 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150710154633.29053.42049.idtracker@ietfa.amsl.com> Date: Fri, 10 Jul 2015 08:46:33 -0700 Archived-At: Cc: radext WG Subject: [radext] WG Action: Rechartered RADIUS EXTensions (radext) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 15:46:35 -0000 The RADIUS EXTensions (radext) working group in the Operations and Management Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. RADIUS EXTensions (radext) ------------------------------------------------ Current Status: Active WG Chairs: Stefan Winter Lionel Morand Assigned Area Director: Kathleen Moriarty Mailing list Address: radext@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/radext Archive: https://mailarchive.ietf.org/arch/browse/radext/ Charter: The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol pending approval of the new work from the Area Director and clarify its usage and definition. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restriction is imposed on extensions considered by the RADEXT WG: All documents produced must specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539. The WG will review its existing RFCs' document track categories and where necessary or useful change document tracks, with minor changes in the documents if needed. Any changes to document tracks require approval by the responsible Area Director. Work Items The immediate goals of the RADEXT working group are to address the following issues: - CoA proxying. RFC 5176 permits proxying of CoA and Disconnect messages, but makes no provisions for how that is done in a roaming environment. This work item will provide descriptions of how to use the Operator-Name attribute in a roaming environment to proxy CoA packets in a way that ensures only authorized proxies can send these packets to the home CoA server. - Encoding Rules for EAP-Response/Identity packets over RADIUS. Neither EAP (RFC3748) nor EAP over RADIUS (RFC3579) demand specific character encoding and normalisation rules for EAP Identity responses. RADIUS (RFC2865) requires User-Name attributes to be encoded in UTF-8. When a NAS simply performs an exact copy of an EAP-Identity into a User-Name, invalid packets might be produced. This document will suggest restrictions on EAP Identities so that transport over AAA becomes correct under all circumstances (UTF-8) and deterministic (normalisation). - Data Types. RFC 2865 defines a number of data types, but later documents do not use those types in a consistent way. This work item will define data types, and update the IANA RADIUS Attribute Type registry so that each attribute has a data type. Where necessary, it will correct issues with previous specifications. - Larger Packets. Support RADIUS packets greater than 4096-octets over RADIUS transports with this capability. - RADIUS Attributes for IP Port Configuration and Reporting. These attributes are used by devices that implement IP port ranges to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behaviors. These attributes can be used in the context of address sharing (e.g., NAT44 [RFC3022], Dual-Stack Lite AFTR [RFC6333], CGN [RFC6888], NAT64 [RFC6146], Provider WLAN (e.g., [TR-146]), etc.). Milestones: Done - Dynamic Discovery I-D submitted as a Proposed Standard RFC Done - RFC 4282bis submitted as a Proposed Standard RFC Done - RADIUS packet fragmentation submitted as an Experimental RFC Nov 2015 - Larger Packets for RADIUS over TCP I-D submitted as an Experimental RFC Nov 2015 - Submit CoA Proxying as Standards Track RFC Mar 2016 - IP Port RADIUS Extensions as Standards Track RFC Nov 2016 - Submit Populating EAP Identity as BCP RFC Nov 2016 - Data Types as Informational RFC From nobody Fri Jul 17 00:29:31 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A73A1B3064 for ; Fri, 17 Jul 2015 00:29:30 -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, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3nA5mQ0NEHF for ; Fri, 17 Jul 2015 00:29:28 -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 2A3721B2FD5 for ; Fri, 17 Jul 2015 00:29:28 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id D975E43A96 for ; Fri, 17 Jul 2015 09:29:26 +0200 (CEST) Message-ID: <55A8AED6.5080005@restena.lu> Date: Fri, 17 Jul 2015 09:29:26 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "radext@ietf.org" OpenPGP: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AM4mi5r01KnCOx4IWiIX49esc7vpWu7XJ" Archived-At: Subject: [radext] Adoption of draft-dekok-radext-datatypes-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 17 Jul 2015 07:29:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AM4mi5r01KnCOx4IWiIX49esc7vpWu7XJ Content-Type: multipart/mixed; boundary="------------000604020401030304010109" This is a multi-part message in MIME format. --------------000604020401030304010109 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, now that we have successfully rechartered, we can adopt the queue of new documents which were waiting on that. In anticipation of the recharter, we already started an Adoption Call for draft-dekok-radext-datatypes-05 on 31 March 2015. Back in the day, there was unanimous consent on the list by a substantial amount of people to adopt this document. Alan, please resubmit draft-dekok-radext-datatypes-05 as draft-ietf-radext-datatypes-00. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------000604020401030304010109 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----- --------------000604020401030304010109-- --AM4mi5r01KnCOx4IWiIX49esc7vpWu7XJ 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 iQIcBAEBCgAGBQJVqK7WAAoJEMDeajWKOdxm4dYP/A7U4yNkLEmW7ViS6U0QNR6B /C4ZKWMAqZvkqp36mVAitLVzYSsPDxDNBUwN6Gl75LELAqQpbrQE3q8SbMoBN2gi 0Ii/ymXW4C3oVwoFH2+67jk9g9LL64wGUezjM1vUUHQnzkFrXVXo9BWfPnaveUvr VawS5nq5YAQTBT1wCNwtK3I9Jpch5zg22nqScGVFpbIvm/ddx+gLbofC9FctG2TO F96JehbLtHBLK4Vfmm1Cq7AnSbe5vYstB0MEvGomKQlNkgKE8FV08h4BD/Xc6+7O Sban7Y7C6Jo4l7i6wUZNgwo7GEoZdZcmguDGg4qloEGJf5N2ZcgZhV1SdQGKlg8U PJgv64tXtYMezQyghY4ipp7Q/9cXa1D06+Mvkc45bR3btL4d4w4Noo2SBa262t2y HpQjY52Fh5cBqsnK4aKj3E9unzwk8XYOmdfBDd+DqSFSjeMAplc4bIIDJs5tL0KX yMDf6na1QG0EjCwugueREfijp7MMinfYUHpx5MNoFBFk1fm7HbfTHW+dwYo0tYyZ XQ8CB5FKysXPNPyhhDjTr6H4/g0AUNQj309zKY+Ky97n8Rb5YE0DzqbllqLNI5B5 djCm9JSYN1Cu6uwGvbCBMLdZsZoq4HYGGJGceZHTA0iZvH5PaD+rUJJupmPAJSLO rVv3oLDTw+Q3JblfGrla =1G71 -----END PGP SIGNATURE----- --AM4mi5r01KnCOx4IWiIX49esc7vpWu7XJ-- From nobody Mon Jul 20 02:13:55 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49491A014C for ; Mon, 20 Jul 2015 02:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhQT8CWd1ot9 for ; Mon, 20 Jul 2015 02:13:51 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B571A0123 for ; Mon, 20 Jul 2015 02:13:51 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id E986F1B843C; Mon, 20 Jul 2015 11:13:49 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.58]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id C126E1800F9; Mon, 20 Jul 2015 11:13:49 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 11:13:49 +0200 From: To: Alan DeKok Thread-Topic: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 Thread-Index: AQHQa91KGZAmzf18QgisvgcZtEu1t50210cAgAAkHgCAAOankIAADHYAgKzMUuA= Date: Mon, 20 Jul 2015 09:13:48 +0000 Message-ID: <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> In-Reply-To: <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.19.175415 Archived-At: Cc: Aboba Bernard , Sam Hartman , "radext-chairs@tools.ietf.org" , "radext@ietf.org" Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 09:13:53 -0000 Hi, During this "call for adoption" period, a lot of support was received and i= t was considered that it is an important work to move forward. The only rem= aining issue was to ensure that RADEXT was the best place for such activity= , as it is not strictly in the remit of RADEXT. So the result was somehow d= ependent on the adoption of the new RADEXT charter, in which the objective = to work on the encoding of the EAP identities was included. It was the oppo= rtunity for IETF people to raise concerns about doing this work in RADEXT, = that was not the case. The new charter was approved two weeks ago and I think that it is now OK to= adopt this document as working group document. A mail was also sent to oth= er interested WGs (DIME, EMU, EAP) to make them aware of this work in RADEX= T. We will discuss this point during the RADEXT session this afternoon and we = will later confirm the adoption on the mailing list. Regards, Lionel=20 -----Message d'origine----- De=A0: Alan DeKok [mailto:aland@deployingradius.com]=20 Envoy=E9=A0: mercredi 1 avril 2015 14:04 =C0=A0: MORAND Lionel IMT/OLN Cc=A0: Aboba Bernard; Sam Hartman; radext@ietf.org; radext-chairs@tools.iet= f.org Objet=A0: Re: [radext] Start of Call for Adoption for draft-winter-radext-p= opulating-eapidentity-01 On Apr 1, 2015, at 5:30 AM, wrote: > Adopting this work will mean adopting the new charter that will be anyway= discussed at the AD/IESG level. Along this process, we will notify DIME, E= MU and EAP mailing lists to let them know that we are working on this issue= and they will be invited to comment the document on RADEXT mailing list an= d during RADEXT sessions. If there is any concern raised during this proces= s, we will manage it at this stage. >=20 > Does it sound acceptable for everyone? I'm OK with that. Alan DeKok. ___________________________________________________________________________= ______________________________________________ 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 Mon Jul 20 04:12:46 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10021A1BD9 for ; Mon, 20 Jul 2015 04:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmUTJ__5iOrk for ; Mon, 20 Jul 2015 04:12:43 -0700 (PDT) Received: from BLU004-OMC2S8.hotmail.com (blu004-omc2s8.hotmail.com [65.55.111.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C075C1A1BD2 for ; Mon, 20 Jul 2015 04:12:42 -0700 (PDT) Received: from BLU181-W94 ([65.55.111.73]) by BLU004-OMC2S8.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 20 Jul 2015 04:12:41 -0700 X-TMN: [opSfHrOcvEBenvX35pinwuSR0FQTm+Z6] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_bb9d0580-91aa-46f4-aef7-f0eec784de0e_" From: Bernard Aboba To: "radext@ietf.org" Date: Mon, 20 Jul 2015 04:12:40 -0700 Importance: Normal In-Reply-To: <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup>, , <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup>, , , , <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com>, <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2015 11:12:41.0574 (UTC) FILETIME=[FEB6F060:01D0C2DC] Archived-At: Subject: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 11:12:45 -0000 --_bb9d0580-91aa-46f4-aef7-f0eec784de0e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One of the fundamental assumptions of this document is that the EAP-Respons= e/Identity is somehow determined from the method-specific identities. This= is not correct=2C as RFC 3748 Section 5.1 makes clear:=20 =20 It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use. EAP Methods SHOULD include a method-specific mechanism for obtaining the identity=2C so that they do not have to rely on the Identity Response. Identity Requests and Responses are sent in cleartext=2C so an attacker may snoop on the identity=2C or even modify or spoof identity exchanges. To address these threats=2C it is preferable for an EAP method to include an identity exchange that supports per-packet authentication=2C integrity and replay protection=2C and confidentiality. The Identity Response may not be the appropriate identity for the method=3B it may have been truncated or obfuscated so as to provide privacy=2C or it may have been decorated for routing purposes. Where the peer is configured to only accept authentication methods supporting protected identity exchanges=2C the peer MAY provide an abbreviated Identity Response (such as omitting the peer-name portion of the NAI [RFC2486]). For further discussion of identity protection=2C see Section 7.3. =20 The above text makes it clear that the EAP-Response/Identity and method-spe= cific Identities used within individual EAP methods are separate and distin= ct. The method-specific identities need not be in NAI format=2C or encoded= in UTF-8. Therefore attempts to convert them to NAI format can frequently= fail. Also=2C the EAP-Response/Identity is frequently anonymous and is us= ed to prevent a snooping attacker from obtaining the method-specific identi= ties=2C which are typically encrypted. For this reason and others describe= d below=2C it is not advisable for EAP implementations to determine the EAP= -Response/Identity based on the method-specific identities.=20 =20 Most EAP methods created subsequent to RFC 3748 have incorporated their own= Identity Exchanges=2C and those methods are therefore not influenced by th= e EAP-Response/Identity. Since the EAP-Response/Identity is distinct from= the method-specific identity=2C the recommendations of Section 4 will not = have an effect on EAP authentication=2C other than perhaps forcing the sele= ction of a different EAP server: =20 =20 If an EAP authentication gets rejected=2C the EAP peer SHOULD re-try the= authentication using a different EAP-Response/Identity than before. The EAP peer SHOULD try all user identifiers from the entire set of configured EAP types before declaring final authentication failure. =20 The advice has a number of major downsides. Since most authentication fail= ures will be due to mistyping the password=2C responding to an authenticati= on failure by retrying all conceivable user identities will lead to major d= elays and very high levels of user annoyance. By responding to an authenti= cation failure by trying method-specific identities=2C implementations woul= d divulge identity information that was designed to be kept secret=2C compr= omising privacy. Also=2C an implementation following this advice would util= ize method-specific identities that may not be in the appropriate format or= character encoding for an EAP-Response/Identity. =20 =20 EAP peers need to maintain state on the encoding of the user identifiers which are used in their locally configured EAP types. When constructing an EAP-Response/Identity from that user identifier=2C they MUST (re-)encode that user identifier as UTF-8 and use the resulting value for the EAP-Response/Identity. If the EAP type is configured for the use of anonymous outer identities=2C the desired outer identity MUST also be (re-)encoded in UTF-8 encoding before being put into the EAP-Response/Identity. =20 Since RFC 3748 makes it clear that the EAP-Response/Identity is not related= to the method-specific identity=2C constructing the EAP-Response/Identity = from the method-specific one is inadvisable. The re-encoding described ab= ove may not be possible for a variety of reasons=2C including the fact that= the method-specific identity need not be in NAI form at all. =20 =20 =20 =20 =20 =20 =20 =20 =20 = --_bb9d0580-91aa-46f4-aef7-f0eec784de0e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
One of the fundamental assumptio= ns of this document is that the EAP-Response/Identity is somehow determined= from the method-specific identities. =3B This is not correct=2C as RFC= 3748 Section 5.1 makes clear:
 =3B
 =3B =3B =3B&nbs= p=3B =3B It is RECOMMENDED that the Identity Response be used primarily= for
 =3B =3B =3B =3B =3B routing purposes and selec= ting which EAP method to use. =3B EAP
 =3B =3B =3B = =3B =3B Methods SHOULD include a method-specific mechanism for obtainin= g
 =3B =3B =3B =3B =3B the identity=2C so that they = do not have to rely on the Identity
 =3B =3B =3B =3B&nbs= p=3B Response. =3B Identity Requests and Responses are sent in cleartex= t=2C
 =3B =3B =3B =3B =3B so an attacker may snoop o= n the identity=2C or even modify or spoof
 =3B =3B =3B = =3B =3B identity exchanges. =3B To address these threats=2C it is p= referable
 =3B =3B =3B =3B =3B for an EAP method to = include an identity exchange that supports
 =3B =3B =3B = =3B =3B per-packet authentication=2C integrity and replay protection=2C= and
 =3B =3B =3B =3B =3B confidentiality. =3B T= he Identity Response may not be the appropriate
 =3B =3B =3B=  =3B =3B identity for the method=3B it may have been truncated or o= bfuscated
 =3B =3B =3B =3B =3B so as to provide priv= acy=2C or it may have been decorated for
 =3B =3B =3B = =3B =3B routing purposes. =3B Where the peer is configured to only = accept
 =3B =3B =3B =3B =3B authentication methods s= upporting protected identity exchanges=2C
 =3B =3B =3B = =3B =3B the peer MAY provide an abbreviated Identity Response (such as<= br> =3B =3B =3B =3B =3B omitting the peer-name portion = of the NAI [RFC2486]). =3B For further
 =3B&nb= sp=3B =3B =3B =3B discussion of identity protection=2C see Section 7.3.
=  =3B
The above text makes it clear that the EAP-Response/Identity an= d method-specific Identities used within individual EAP methods are separat= e and distinct. =3B The method-specific identities need not be in NAI f= ormat=2C or encoded in UTF-8. =3B Therefore attempts to convert them to= NAI format can frequently fail. =3B Also=2C the EAP-Response/Identity = is frequently anonymous and =3Bis used to =3Bprevent a snooping att= acker from obtaining the method-specific identities=2C which are typically = encrypted.  =3BFor this reason and others described below=2C it is not = advisable for EAP implementations to determine the EAP-Response/Identity ba= sed on the method-specific identities.
 =3B
Most EAP methods cre= ated subsequent to RFC 3748 have incorporated their own Identity Exchanges= =2C =3Band those methods =3Bare therefore not influenced by the EAP= -Response/Identity. =3B =3B Since the EAP-Response/Identity is dist= inct from the method-specific identity=2C the recommendations of Section 4 = will not have an effect =3Bon =3BEAP authentication=2C other than p= erhaps forcing the selection of a different EAP server: =3B =3B  =3B
 =3B =3B If an EAP authentication =3Bgets rejected= =2C the EAP peer SHOULD re-try the authentication using a
 =3B = =3B different EAP-Response/Identity than before. =3B The EAP peer SHOUL= D try
 =3B =3B all user identifiers from the entire set of confi= gured EAP types
 =3B =3B before declaring final authentication f= ailure.
 =3B
The advice has a number of major downsides. =3B = Since most authentication failures will be due to mistyping the password=2C= responding to an authentication failure by retrying all conceivable user i= dentities will lead to major delays and very high levels of user annoyance.=  =3B By responding to an authentication failure by trying =3Bmethod= -specific identities=2C implementations would divulge identity information = that was designed to be kept secret=2C compromising privacy. Also=2C an imp= lementation following this advice would utilize method-specific identities = that may not be in the appropriate format or character encoding for an EAP-= Response/Identity. =3B
 =3B
 =3B =3B EAP peers need = to maintain state on the encoding of the user
 =3B =3B identifie= rs which are used in their locally configured EAP types.
 =3B = =3B When constructing an EAP-Response/Identity from that user identifier=2C=
 =3B =3B they MUST (re-)encode that user identifier as UTF-8 an= d use the
 =3B =3B resulting value for the EAP-Response/Identity= . =3B If the EAP type is
 =3B =3B configured for the use of = anonymous outer identities=2C the desired
 =3B =3B outer identit= y MUST also be (re-)encoded in UTF-8 encoding before
 =3B =3B be= ing put into the EAP-Response/Identity.
 =3B
Since RFC 3748 makes= it clear that the EAP-Response/Identity is not related to the method-speci= fic identity=2C constructing the EAP-Response/Identity from the method-spec= ific one is inadvisable. =3B =3B The re-encoding described above ma= y not be possible for a variety of reasons=2C including the fact that the m= ethod-specific identity need not be in NAI form at all. =3B

&nb= sp=3B
 =3B
 =3B

 =3B
 =3B
 =3B
&n= bsp=3B
 =3B
= --_bb9d0580-91aa-46f4-aef7-f0eec784de0e_-- From nobody Mon Jul 20 04:29:55 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A55201A219F for ; Mon, 20 Jul 2015 04:29:53 -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 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 1hKgnA8DHnqV for ; Mon, 20 Jul 2015 04:29:52 -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 1F0741A2119 for ; Mon, 20 Jul 2015 04:29:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B38B420752; Mon, 20 Jul 2015 07:29:31 -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 w3LAAFFk1jjQ; Mon, 20 Jul 2015 07:29:30 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (dhcp-8970.meeting.ietf.org [31.133.137.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 20 Jul 2015 07:29:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A2E8A82120; Mon, 20 Jul 2015 07:29:48 -0400 (EDT) From: Sam Hartman To: Bernard Aboba References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Mon, 20 Jul 2015 07:29:48 -0400 In-Reply-To: (Bernard Aboba's message of "Mon, 20 Jul 2015 04:12:40 -0700") 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] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 11:29:53 -0000 >>>>> "Bernard" == Bernard Aboba writes: Bernard> One of the fundamental assumptions of this document is Bernard> that the EAP-Response/Identity is somehow determined from Bernard> the method-specific identities. This is not correct, as Bernard> RFC 3748 Section 5.1 makes clear: Hi. I was very confused to read this paragraph, because we've discussed this issue several times and I think we're all in agreement that the method-specific identities are not directly related to the eap response/identity. I think that as the text you cite from RFC 3748 points out, the EAP response is often used for routing, so in many deployments there is some relation. I stopped reading your review after this first paragraph, because I think that this disconnect colors the entire review. I'd really appreciate it if you would explain why you think the document is assuming that the eap-response/identity is determined from method identities. I know that was not our intent. I do think it's true that implementations sometimes derive both the eap response/identity and the method-specific identities from a common principal. Other implementations request both identities from the user. However, I don't know anything that tries to map back from a method identity to an eap response. --Sam From nobody Mon Jul 20 04:54:03 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804151A3BA2; Mon, 20 Jul 2015 04:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUuyMJq8p03E; Mon, 20 Jul 2015 04:53:55 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1E71A6EFE; Mon, 20 Jul 2015 04:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1646; q=dns/txt; s=iport; t=1437393235; x=1438602835; h=from:to:cc:subject:date:message-id:mime-version; bh=JdnhmnvQuRjf2tmSXAiH0Idl/O12SYq1QWxZ5U7b7FM=; b=QnADT6i7TPNmDy5JUqJLwKyPgjP90LQJKHeW9Ii28r8rBYlUH/3lsNUU CMs6TDqLNDPHHazViM8dx7kqZaM28Sp5bwyj+lKr9UWCHqnYV+LD5kIHY 0RRqCFIWZzd57O4555SHfC4ZoTukA7HHBX+cv8QGwse9bQ6HBSosW+iN+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AzAwA34KxV/5RdJa1cgkZNVGkGu2QJgXWFd4EqOBQBAQEBAQEBgQqEGgwCAnkSAQsBdCcEAQ2IMw3FQwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEkE4EhDIFlFIBjCCBQ4QaiA+LGyZjgxlvAYFGgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,507,1432598400"; d="scan'208,217";a="170271974" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP; 20 Jul 2015 11:53:54 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6KBrson030352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jul 2015 11:53:54 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.42]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 06:53:54 -0500 From: "Douglas Gash (dcmgash)" To: "aaa-doctors@ietf.org" , "radext@ietf.org" Thread-Topic: TACACS+ RFC Presentation Thread-Index: AQHQwuLALKIr+80AlEiIFGtOVffheA== Date: Mon, 20 Jul 2015 11:53:53 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [10.61.66.205] Content-Type: multipart/alternative; boundary="_000_D1D2ADEE879E3dcmgashciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Benoit Claise \(bclaise\)" , "joelja@bogus.com" , Andrej Ota , Thorsten Dahm Subject: [radext] TACACS+ RFC Presentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 11:53:57 -0000 --_000_D1D2ADEE879E3dcmgashciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Please note that we are presenting a TACACS+ specification during the Ops A= rea open meeting today in Karin I (17:40 =96 18:40). The Ops AD suggested t= hat this may be of interest to RADIUS and AAA groups. Many thanks, Regards, Thorsten Dahm, Andrej Ota, Doug Gash. https://www.ietf.org/proceedings/93/slides/slides-93-opsarea-2.pdf --_000_D1D2ADEE879E3dcmgashciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7B1308BECF952B4DA152F59C2783D39D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi,

Please note that we are presenting a TACACS+ specification during = the Ops Area open meeting today in Karin I (17:40 =96 18:40). The Ops AD su= ggested that this may be of interest to RADIUS and AAA groups.

Many thanks,

Regards,

Thorsten Dahm, Andrej Ota, Doug Gash.

--_000_D1D2ADEE879E3dcmgashciscocom_-- From nobody Mon Jul 20 05:06:22 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68C51A21B3 for ; Mon, 20 Jul 2015 05:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LGQ9oQTviOJB for ; Mon, 20 Jul 2015 05:06:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA7F1A1AE1 for ; Mon, 20 Jul 2015 05:06:18 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id A07601B84DF; Mon, 20 Jul 2015 14:06:17 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 6E68DC804F; Mon, 20 Jul 2015 14:06:17 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 14:06:16 +0200 From: To: Sam Hartman , Bernard Aboba Thread-Topic: [radext] Review of draft-winter-radext-populating-eapidentity-01 Thread-Index: AQHQwt0De4YFAkaJm0y5udhwNnv9RZ3kORcBgAAI/9A= Date: Mon, 20 Jul 2015 12:06:15 +0000 Message-ID: <6155_1437393977_55ACE439_6155_10573_1_6B7134B31289DC4FAF731D844122B36E01CCA3D4@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.20.111516 Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 12:06:20 -0000 Hi Bernard, I tend to agree with Sam. I will review again the draft based on your comme= nt. However I understand that the point is WHEN "Identity Response be used = primarily for routing purposes ", there is some considerations to take into= account to use it as user-name identity in RADIUS and Diameter. Everything= else related to method-specific EAP identity (format, use, etc.) is out of= scope of this document. At least it is my current understanding. Lionel -----Message d'origine----- De=A0: radext [mailto:radext-bounces@ietf.org] De la part de Sam Hartman Envoy=E9=A0: lundi 20 juillet 2015 13:30 =C0=A0: Bernard Aboba Cc=A0: radext@ietf.org Objet=A0: Re: [radext] Review of draft-winter-radext-populating-eapidentity= -01 >>>>> "Bernard" =3D=3D Bernard Aboba writes: Bernard> One of the fundamental assumptions of this document is Bernard> that the EAP-Response/Identity is somehow determined from Bernard> the method-specific identities. This is not correct, as Bernard> RFC 3748 Section 5.1 makes clear: Hi. I was very confused to read this paragraph, because we've discussed th= is issue several times and I think we're all in agreement that the method-s= pecific identities are not directly related to the eap response/identity. = I think that as the text you cite from RFC 3748 points out, the EAP respons= e is often used for routing, so in many deployments there is some relation. I stopped reading your review after this first paragraph, because I think t= hat this disconnect colors the entire review. I'd really appreciate it if = you would explain why you think the document is assuming that the eap-respo= nse/identity is determined from method identities. I know that was not our intent. I do think it's true that implementations sometimes derive both the eap res= ponse/identity and the method-specific identities from a common principal. Other implementations request both identities from the user. However, I don't know anything that tries to map back from a method identit= y to an eap response. --Sam _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ 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 Mon Jul 20 05:09:58 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800A81A3BA1; Mon, 20 Jul 2015 05:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW0QYrFO4-QU; Mon, 20 Jul 2015 05:09:48 -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 268181A21BF; Mon, 20 Jul 2015 05:09:46 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 9C49C22C8E2; Mon, 20 Jul 2015 14:09:44 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 6C224238151; Mon, 20 Jul 2015 14:09:44 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 14:09:43 +0200 From: To: "Douglas Gash (dcmgash)" , "aaa-doctors@ietf.org" , "radext@ietf.org" Thread-Topic: TACACS+ RFC Presentation Thread-Index: AQHQwuLALKIr+80AlEiIFGtOVffheJ3kQ8Ug Date: Mon, 20 Jul 2015 12:09:43 +0000 Message-ID: <17768_1437394184_55ACE508_17768_3037_1_6B7134B31289DC4FAF731D844122B36E01CCA3E5@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: In-Reply-To: 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: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E01CCA3E5OPEXCLILM43corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.20.111516 Archived-At: Cc: "Benoit Claise \(bclaise\)" , "joelja@bogus.com" , Andrej Ota , "dime@ietf.org" , Thorsten Dahm Subject: Re: [radext] TACACS+ RFC Presentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 12:09:52 -0000 --_000_6B7134B31289DC4FAF731D844122B36E01CCA3E5OPEXCLILM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for the notification. Adding the dime mailing list in the loop for information. Lionel De : radext [mailto:radext-bounces@ietf.org] De la part de Douglas Gash (dc= mgash) Envoy=E9 : lundi 20 juillet 2015 13:54 =C0 : aaa-doctors@ietf.org; radext@ietf.org Cc : Benoit Claise (bclaise); joelja@bogus.com; Andrej Ota; Thorsten Dahm Objet : [radext] TACACS+ RFC Presentation Hi, Please note that we are presenting a TACACS+ specification during the Ops A= rea open meeting today in Karin I (17:40 - 18:40). The Ops AD suggested tha= t this may be of interest to RADIUS and AAA groups. Many thanks, Regards, Thorsten Dahm, Andrej Ota, Doug Gash. https://www.ietf.org/proceedings/93/slides/slides-93-opsarea-2.pdf ___________________________________________________________________________= ______________________________________________ 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. --_000_6B7134B31289DC4FAF731D844122B36E01CCA3E5OPEXCLILM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thank you = for the notification.

Adding the= dime mailing list in the loop for information.

Lionel

 = ;

De : rade= xt [mailto:radext-bounces@ietf.org] De la part de Douglas Gash (dcmgash)
Envoy=E9 : lundi 20 juillet 2015 13:54
=C0 : aaa-doctors@ietf.org; radext@ietf.org
Cc : Benoit Claise (bclaise); joelja@bogus.com; Andrej Ota; Tho= rsten Dahm
Objet : [radext] TACACS+ RFC Presentation=

 

Hi,

 

Please note that we are pre= senting a TACACS+ specification during the Ops Area open meeting today = in Karin I (17:40 – 18:40). The Ops AD suggested that this may be of interest to RADIUS and AAA groups.

 

Many thanks,

 

Regards,<= /p>

 

Thorsten Dahm, Andrej Ota, = Doug Gash.

 

______________________________________________________________________=
___________________________________________________

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.
--_000_6B7134B31289DC4FAF731D844122B36E01CCA3E5OPEXCLILM43corp_-- From nobody Mon Jul 20 05:20:41 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E8A1A1BBC; Mon, 20 Jul 2015 04:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLfDfG38lJ2A; Mon, 20 Jul 2015 04:05:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 627471A1BD9; Mon, 20 Jul 2015 04:05:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 52F1E18045A; Mon, 20 Jul 2015 04:01:12 -0700 (PDT) To: aland@freeradius.org, mchiba@cisco.com, gdommety@cisco.com, meklund@cisco.com, david@mitton.com, bernarda@microsoft.com X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20150720110112.52F1E18045A@rfc-editor.org> Date: Mon, 20 Jul 2015 04:01:12 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 20 Jul 2015 05:20:40 -0700 Cc: radext@ietf.org, Kathleen.Moriarty@emc.com, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] [Errata Verified] RFC5176 (4311) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 11:05:07 -0000 The following errata report has been verified for RFC5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=4311 -------------------------------------- Status: Verified Type: Technical Reported by: Alan DeKok Date Reported: 2015-03-23 Verified by: Kathleen Moriarty (IESG) Section: 2.3 Original Text ------------- Section 2.3 says: In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory. Corrected Text -------------- In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory to understand by the NAS, except Proxy-State attributes that MUST be treated as opaque data. See Section 3.1 for a discussion of how the NAS must handle Proxy-State. Notes ----- This was seen with vendor equipment. CoA proxying was done to the NAS, and the proxy was adding and forwarding Proxy-State as required by Section 3.1. However, the NAS was returning a CoA-NAK with Error-Cause = Unsupported-Attribute. The issue comes because Proxy-State is called out in Section 3.1 for special handling. However, that special handling isn't called out in Section 2.3. As a result, implementors can get confused. The RADEXT WG is rechartering with a document to address CoA proxying. We will also be addressing this issue in that document. There are additional attributes which a NAS should ignore, OR which should be filtered out by the proxy closest to the NAS. The text was slightly updated by the WG from the originally submitted text. -------------------------------------- RFC5176 (draft-ietf-radext-rfc3576bis-13) -------------------------------------- Title : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Publication Date : January 2008 Author(s) : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba Category : INFORMATIONAL Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Jul 20 05:20:42 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9ADB1A21B4 for ; Mon, 20 Jul 2015 05:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SItj5urhNj0M for ; Mon, 20 Jul 2015 05:20:37 -0700 (PDT) Received: from BLU004-OMC1S3.hotmail.com (blu004-omc1s3.hotmail.com [65.55.116.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E87781A21AE for ; Mon, 20 Jul 2015 05:20:36 -0700 (PDT) Received: from BLU406-EAS92 ([65.55.116.7]) by BLU004-OMC1S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 20 Jul 2015 05:20:35 -0700 X-TMN: [clXIBPCQF2UGPMO6x9iuK9s4/B7mpzLE] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Mon, 20 Jul 2015 14:16:31 +0200 References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <6155_1437393977_55ACE439_6155_10573_1_6B7134B31289DC4FAF731D844122B36E01CCA3D4@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" In-Reply-To: <6155_1437393977_55ACE439_6155_10573_1_6B7134B31289DC4FAF731D844122B36E01CCA3D4@OPEXCLILM43.corporate.adroot.infra.ftgroup> X-OriginalArrivalTime: 20 Jul 2015 12:20:35.0742 (UTC) FILETIME=[7B1BA3E0:01D0C2E6] Archived-At: Cc: Sam Hartman , "radext@ietf.org" Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 12:20:40 -0000 VGhlIHBvaW50IGlzIHRoYXQgdGhlIGRvY3VtZW50J3MgcmVjb21tZW5kYXRpb25zIGFyZSBiYXNl ZCBvbiB1c2luZyBtZXRob2Qgc3BlY2lmaWMgaWRlbnRpdGllcyB0byBkZXRlcm1pbmUgdGhlIEVB UC1SZXNwb25zZS9JZGVudGl0eS4gVGhpcyBpcyBmdW5kYW1lbnRhbGx5IGJyb2tlbiBiZWNhdXNl IHRob3NlIGlkZW50aXRpZXMgYXJlIHVucmVsYXRlZCBhbmQgdGhlIHR3byBpZGVudGl0aWVzICBu ZWVkIG5vdCB1c2UgdGhlIHNhbWUgZm9ybWF0cyBvciBlbmNvZGluZ3MgLSBhbmQgYXMgYSByZXN1 bHQgdGhlIGFkdmljZSBiYXNlZCBvbiB0aGlzIGluY29ycmVjdCBhc3N1bXB0aW9uIHdvdWxkIHJl c3VsdCBpbiBhdXRoZW50aWNhdGlvbiBmYWlsdXJlcywgdW5hY2NlcHRhYmxlIGRlbGF5cyBhbmQg d29yc2UuDQoNClRoZSBkb2N1bWVudCBpdHNlbGYgcG9pbnRzIHRoaXMgb3V0IC0gYnV0IGRvZXMg bm90IHJlY29nbml6ZSB0aGF0IHRoZSBwcm9ibGVtIGl0c2VsZiByZXN1bHRzIGZyb20gYSBmYWxz ZSBhc3N1bXB0aW9uLg0KDQoNCj4gT24gSnVsIDIwLCAyMDE1LCBhdCAxNDowNiwgbGlvbmVsLm1v cmFuZEBvcmFuZ2UuY29tIHdyb3RlOg0KPiANCj4gSGkgQmVybmFyZCwNCj4gDQo+IEkgdGVuZCB0 byBhZ3JlZSB3aXRoIFNhbS4gSSB3aWxsIHJldmlldyBhZ2FpbiB0aGUgZHJhZnQgYmFzZWQgb24g eW91ciBjb21tZW50LiBIb3dldmVyIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBwb2ludCBpcyBXSEVO ICJJZGVudGl0eSBSZXNwb25zZSBiZSB1c2VkIHByaW1hcmlseSBmb3Igcm91dGluZyBwdXJwb3Nl cyAiLCB0aGVyZSBpcyBzb21lIGNvbnNpZGVyYXRpb25zIHRvIHRha2UgaW50byBhY2NvdW50IHRv IHVzZSBpdCBhcyB1c2VyLW5hbWUgaWRlbnRpdHkgaW4gUkFESVVTIGFuZCBEaWFtZXRlci4gRXZl cnl0aGluZyBlbHNlIHJlbGF0ZWQgdG8gbWV0aG9kLXNwZWNpZmljIEVBUCBpZGVudGl0eSAoZm9y bWF0LCB1c2UsIGV0Yy4pIGlzIG91dCBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiBBdCBsZWFz dCBpdCBpcyBteSBjdXJyZW50IHVuZGVyc3RhbmRpbmcuDQo+IA0KPiBMaW9uZWwNCj4gDQo+IC0t LS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBEZSA6IHJhZGV4dCBbbWFpbHRvOnJhZGV4dC1i b3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFNhbSBIYXJ0bWFuDQo+IEVudm95w6kgOiBs dW5kaSAyMCBqdWlsbGV0IDIwMTUgMTM6MzANCj4gw4AgOiBCZXJuYXJkIEFib2JhDQo+IENjIDog cmFkZXh0QGlldGYub3JnDQo+IE9iamV0IDogUmU6IFtyYWRleHRdIFJldmlldyBvZiBkcmFmdC13 aW50ZXItcmFkZXh0LXBvcHVsYXRpbmctZWFwaWRlbnRpdHktMDENCj4gDQo+Pj4+Pj4gIkJlcm5h cmQiID09IEJlcm5hcmQgQWJvYmEgPGJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb20+IHdyaXRlczoN Cj4gDQo+ICAgIEJlcm5hcmQ+ICAgIE9uZSBvZiB0aGUgZnVuZGFtZW50YWwgYXNzdW1wdGlvbnMg b2YgdGhpcyBkb2N1bWVudCBpcw0KPiAgICBCZXJuYXJkPiB0aGF0IHRoZSBFQVAtUmVzcG9uc2Uv SWRlbnRpdHkgaXMgc29tZWhvdyBkZXRlcm1pbmVkIGZyb20NCj4gICAgQmVybmFyZD4gdGhlIG1l dGhvZC1zcGVjaWZpYyBpZGVudGl0aWVzLiAgVGhpcyBpcyBub3QgY29ycmVjdCwgYXMNCj4gICAg QmVybmFyZD4gUkZDIDM3NDggU2VjdGlvbiA1LjEgbWFrZXMgY2xlYXI6DQo+IA0KPiBIaS4gIEkg d2FzIHZlcnkgY29uZnVzZWQgdG8gcmVhZCB0aGlzIHBhcmFncmFwaCwgYmVjYXVzZSB3ZSd2ZSBk aXNjdXNzZWQgdGhpcyBpc3N1ZSBzZXZlcmFsIHRpbWVzIGFuZCBJIHRoaW5rIHdlJ3JlIGFsbCBp biBhZ3JlZW1lbnQgdGhhdCB0aGUgbWV0aG9kLXNwZWNpZmljIGlkZW50aXRpZXMgYXJlIG5vdCBk aXJlY3RseSByZWxhdGVkIHRvIHRoZSBlYXAgcmVzcG9uc2UvaWRlbnRpdHkuICBJIHRoaW5rIHRo YXQgYXMgdGhlIHRleHQgeW91IGNpdGUgZnJvbSBSRkMgMzc0OCBwb2ludHMgb3V0LCB0aGUgRUFQ IHJlc3BvbnNlIGlzIG9mdGVuIHVzZWQgZm9yIHJvdXRpbmcsIHNvIGluIG1hbnkgZGVwbG95bWVu dHMgdGhlcmUgaXMgc29tZSByZWxhdGlvbi4NCj4gDQo+IEkgc3RvcHBlZCByZWFkaW5nIHlvdXIg cmV2aWV3IGFmdGVyIHRoaXMgZmlyc3QgcGFyYWdyYXBoLCBiZWNhdXNlIEkgdGhpbmsgdGhhdCB0 aGlzIGRpc2Nvbm5lY3QgY29sb3JzIHRoZSBlbnRpcmUgcmV2aWV3LiAgSSdkIHJlYWxseSBhcHBy ZWNpYXRlIGl0IGlmIHlvdSB3b3VsZCBleHBsYWluIHdoeSB5b3UgdGhpbmsgdGhlIGRvY3VtZW50 IGlzIGFzc3VtaW5nIHRoYXQgdGhlIGVhcC1yZXNwb25zZS9pZGVudGl0eSBpcyBkZXRlcm1pbmVk IGZyb20gbWV0aG9kIGlkZW50aXRpZXMuDQo+IEkga25vdyB0aGF0IHdhcyBub3Qgb3VyIGludGVu dC4NCj4gDQo+IEkgZG8gdGhpbmsgaXQncyB0cnVlIHRoYXQgaW1wbGVtZW50YXRpb25zIHNvbWV0 aW1lcyBkZXJpdmUgYm90aCB0aGUgZWFwIHJlc3BvbnNlL2lkZW50aXR5IGFuZCB0aGUgbWV0aG9k LXNwZWNpZmljIGlkZW50aXRpZXMgZnJvbSBhIGNvbW1vbiBwcmluY2lwYWwuDQo+IE90aGVyIGlt cGxlbWVudGF0aW9ucyByZXF1ZXN0IGJvdGggaWRlbnRpdGllcyBmcm9tIHRoZSB1c2VyLg0KPiBI b3dldmVyLCBJIGRvbid0IGtub3cgYW55dGhpbmcgdGhhdCB0cmllcyB0byBtYXAgYmFjayBmcm9t IGEgbWV0aG9kIGlkZW50aXR5IHRvIGFuIGVhcCByZXNwb25zZS4NCj4gDQo+IC0tU2FtDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiByYWRl eHQgbWFpbGluZyBsaXN0DQo+IHJhZGV4dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JhZGV4dA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiANCj4gQ2UgbWVzc2Fn ZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQo+IHBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyDQo+IGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2Vz IGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBk J2FsdGVyYXRpb24sDQo+IE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4gDQo+ IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 DQo+IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91 dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+IA0K From nobody Mon Jul 20 05:23:36 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E57FA1A802D for ; Mon, 20 Jul 2015 05:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5u8-l_s10usq for ; Mon, 20 Jul 2015 05:23:25 -0700 (PDT) Received: from BLU004-OMC2S15.hotmail.com (blu004-omc2s15.hotmail.com [65.55.111.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5D9E1A802A for ; Mon, 20 Jul 2015 05:23:25 -0700 (PDT) Received: from BLU406-EAS37 ([65.55.111.71]) by BLU004-OMC2S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 20 Jul 2015 05:23:24 -0700 X-TMN: [K+cK2EhWWlg5x6hvF+ngunAMzDBL2zas] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Mon, 20 Jul 2015 14:23:21 +0200 References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: Sam Hartman In-Reply-To: X-OriginalArrivalTime: 20 Jul 2015 12:23:24.0745 (UTC) FILETIME=[DFD77390:01D0C2E6] Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 12:23:31 -0000 On Jul 20, 2015, at 13:29, Sam Hartman wrot= e: >>>>>> "Bernard" =3D=3D Bernard Aboba writes: >=20 > I stopped reading your review after this first paragraph, =20 [BA] If you had read further you would have learned the specific paragraphs i= n Section 4 that direct the EAP-Response/Identity to be determined from the m= ethod specific ones. Your loss.=20= From nobody Mon Jul 20 05:25:02 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793441A1B07 for ; Mon, 20 Jul 2015 05:25:01 -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 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 RgYdVtT5cUup for ; Mon, 20 Jul 2015 05:25:00 -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 7E0BD1A024E for ; Mon, 20 Jul 2015 05:25:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3796E20754; Mon, 20 Jul 2015 08:24:40 -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 B5R_jLg7mCZm; Mon, 20 Jul 2015 08:24:39 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (dhcp-8970.meeting.ietf.org [31.133.137.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 20 Jul 2015 08:24:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 436B988672; Mon, 20 Jul 2015 08:24:57 -0400 (EDT) From: Sam Hartman To: Bernard Aboba References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <6155_1437393977_55ACE439_6155_10573_1_6B7134B31289DC4FAF731D844122B36E01CCA3D4@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Mon, 20 Jul 2015 08:24:57 -0400 In-Reply-To: (Bernard Aboba's message of "Mon, 20 Jul 2015 14:16:31 +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" , "lionel.morand@orange.com" Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 12:25:01 -0000 >>>>> "Bernard" == Bernard Aboba writes: Bernard> The point is that the document's recommendations are based Bernard> on using method specific identities to determine the Bernard> EAP-Response/Identity. This is fundamentally broken because Bernard> those identities are unrelated and the two identities need Bernard> not use the same formats or encodings - and as a result the Bernard> advice based on this incorrect assumption would result in Bernard> authentication failures, unacceptable delays and worse. Bernard, at this point I'm getting somewhat frustrated, because you're repeating yourself. Asserting the same thing doesn't make it true. Your understanding of the document differs from mine. Repeating your understanding of the document will not convince me you are right. Instead, I'm asking you to quote the sections of the document you believe are based on this. --Sam From nobody Mon Jul 20 05:34:03 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80CC1A8701 for ; Mon, 20 Jul 2015 05:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4TtHi3uEQne for ; Mon, 20 Jul 2015 05:34:00 -0700 (PDT) Received: from BLU004-OMC2S36.hotmail.com (blu004-omc2s36.hotmail.com [65.55.111.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4700E1A86E4 for ; Mon, 20 Jul 2015 05:34:00 -0700 (PDT) Received: from BLU406-EAS122 ([65.55.111.72]) by BLU004-OMC2S36.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 20 Jul 2015 05:33:59 -0700 X-TMN: [SMAWpd1B+6ot/0pvGJHv2FYumTdTDYHl] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Mon, 20 Jul 2015 14:33:58 +0200 References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: In-Reply-To: X-OriginalArrivalTime: 20 Jul 2015 12:33:59.0036 (UTC) FILETIME=[59E893C0:01D0C2E8] Archived-At: Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 12:34:02 -0000 On Jul 20, 2015, at 13:29, Sam Hartman wrot= e: > Other implementations request both identities from the user. > However, I don't know anything that tries to map back from a method > identity to an eap response. [BA] Neither do I - it's a bad idea. That's why Section 4's advice seems so= strange: If an EAP authentication gets rejected, the EAP peer SHOULD re-try the a= uthentication using a different EAP-Response/Identity than before. The EAP peer SHOULD try all user identifiers from the entire set of configured EAP types before declaring final authentication failure. [BA] "all user identities" appears to imply using method-specific identities= to construct the EAP-Response/Identity. =20 EAP peers need to maintain state on the encoding of the user identifiers which are used in their locally configured EAP types. When constructing an EAP-Response/Identity from that user identifier, [BA] Again, this seems to imply using method-specific identities to construc= t the EAP-Response/Identity.= From nobody Mon Jul 20 05:39:06 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E961A8716 for ; Mon, 20 Jul 2015 05:39:05 -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 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 LzmG0Dv1Vo9U for ; Mon, 20 Jul 2015 05:39:02 -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 C70B61A872D for ; Mon, 20 Jul 2015 05:38:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 90C1320752; Mon, 20 Jul 2015 08:38:33 -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 AE_U2R94byGu; Mon, 20 Jul 2015 08:38:33 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (dhcp-8970.meeting.ietf.org [31.133.137.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 20 Jul 2015 08:38:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E3B2488672; Mon, 20 Jul 2015 08:38:50 -0400 (EDT) From: Sam Hartman To: Bernard Aboba References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> Date: Mon, 20 Jul 2015 08:38:50 -0400 In-Reply-To: (Bernard Aboba's message of "Mon, 20 Jul 2015 14:33:58 +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] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 12:39:05 -0000 >>>>> "Bernard" == Bernard Aboba writes: Bernard> On Jul 20, 2015, at 13:29, Sam Hartman wrote: >> Other implementations request both identities from the user. >> However, I don't know anything that tries to map back from a >> method identity to an eap response. Bernard> [BA] Neither do I - it's a bad idea. That's why Section Bernard> 4's advice seems so strange: Bernard> If an EAP authentication gets rejected, the EAP peer Bernard> SHOULD re-try the authentication using a different Bernard> EAP-Response/Identity than before. The EAP peer SHOULD try Bernard> all user identifiers from the entire set of configured EAP Bernard> types before declaring final authentication failure. Bernard> [BA] "all user identities" appears to imply using Bernard> method-specific identities to construct the Bernard> EAP-Response/Identity. Ah, that's not how I read it at all. I read that as saying that you try all the identities you have. If you're an implementation that stores outer identities separately from inner identities, then try all your outer identities. If you're an implementation that maps both from a common principal, do that for all your principals. Bernard> EAP peers need to maintain state on the encoding of the Bernard> user identifiers which are used in their locally configured Bernard> EAP types. When constructing an EAP-Response/Identity from Bernard> that user identifier, Bernard> [BA] Again, this seems to imply using method-specific Bernard> identities to construct the EAP-Response/Identity. I see what you're saying now. I think what the text is trying to talk about there is constructing both from some common principal/idea about an account. However it could be read as constructing one from another. And also, it doesn't deal as well with the case where they are separate. From nobody Mon Jul 20 05:39:16 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B621D1A8726 for ; Mon, 20 Jul 2015 05:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=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 7xJXy-Y7bx6R for ; Mon, 20 Jul 2015 05:39:12 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386591A870A for ; Mon, 20 Jul 2015 05:39:11 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id C9A27C0264; Mon, 20 Jul 2015 14:39:09 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.17]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id AB12518010B; Mon, 20 Jul 2015 14:39:09 +0200 (CEST) Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM24.corporate.adroot.infra.ftgroup ([fe80::a1e6:3e6a:1f68:5f7e%19]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 14:39:08 +0200 From: To: Bernard Aboba Thread-Topic: [radext] Review of draft-winter-radext-populating-eapidentity-01 Thread-Index: AQHQwt0De4YFAkaJm0y5udhwNnv9RZ3kORcBgAAI/9D//+J7gIAAJZtA Date: Mon, 20 Jul 2015 12:39:07 +0000 Message-ID: <23999_1437395949_55ACEBED_23999_2405_14_6B7134B31289DC4FAF731D844122B36E01CCA48F@OPEXCLILM43.corporate.adroot.infra.ftgroup> References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <6155_1437393977_55ACE439_6155_10573_1_6B7134B31289DC4FAF731D844122B36E01CCA3D4@OPEXCLILM43.corporate.adroot.infra.ftgroup> In-Reply-To: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.20.94516 Archived-At: Cc: Sam Hartman , "radext@ietf.org" Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 12:39:14 -0000 SGkgYmVybmFyZCwNCg0KYWZ0ZXIgYSBxdWljayByZXZpZXcsIEkgdGhpbmsgSSB1bmRlcnN0YW5k IHlvdXIgY29uY2VybnMuDQpJIHJlYWxseSB0aGluayB0aGF0IHRoZSBwb2ludCBpcyBub3QgdG8g bWFrZSBhbnkgYXNzdW1wdGlvbiBvbiB0aGUgbWV0aG9kLXNwZWNpZmljIElEIHRoYXQgY291bGQg YmUgdXNlZCBpbiBFQVAtUmVzcG9uc2UuDQpJIHRoaW5rIHdlIGNhbiB1cGRhdGUgdGhlIHRleHQg dG8gbWFrZSBpdCBjbGVhci4NCg0KVG8gc3VtLXVwLCBJIHdvdWxkIHNheSB0aGF0IHRoZSBpbnRl bnRpb24gb2YgdGhlIGRyYWZ0IGlzIHRvOg0KDQotIGNsYXJpZnkgdGhhdCB0aGUgRUFQLVJlc3Bv bnNlIGNhbiBiZSB1c2VkIGZvciByb3V0aW5nDQotIFdoZW4gaXQgaXMgdGhlIGNhc2UsIHR3byBj b25zZXF1ZW5jZXM6DQogICAgLSAgaXQgbWF5IGJlIG5lZWRlZCB0byB1c2UgZGlmZmVyZW50IGlk cyB0byByZWFjaCBkaWZmZXJlbnQgRUFwIHNlcnZlcnMsIHdoZW4gYSBzaW5nbGUgRUFQIHNlcnZl ciBjYW5ub3QgYmUgdXNlZCB0byBzdXBwb3J0IGFsbCB0aGUgbWV0aG9kcyBzdXBwb3J0ZWQgYnkg dGhlIHBlZXIuDQogICAgLSBhIHNwZWNpZmljIGVuY29kaW5nIG9mIHRoZSBpZCBlbmNhcHN1bGF0 ZWQgaW4gdGhlIEVBUC1SZXNwb25zZSBpcyByZXF1aXJlZCB0byBlbnN1cmUgYSBjb3JyZWN0IHVz ZSBvdmVyIFJBRElVUy9EaWFtZXRlcg0KDQpEbyB3ZSBhZ3JlZT8NCg0KTGlvbmVsDQoNCi0tLS0t TWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KRGXCoDogQmVybmFyZCBBYm9iYSBbbWFpbHRvOmJlcm5h cmRfYWJvYmFAaG90bWFpbC5jb21dIA0KRW52b3nDqcKgOiBsdW5kaSAyMCBqdWlsbGV0IDIwMTUg MTQ6MTcNCsOAwqA6IE1PUkFORCBMaW9uZWwgSU1UL09MTg0KQ2PCoDogU2FtIEhhcnRtYW47IHJh ZGV4dEBpZXRmLm9yZw0KT2JqZXTCoDogUmU6IFtyYWRleHRdIFJldmlldyBvZiBkcmFmdC13aW50 ZXItcmFkZXh0LXBvcHVsYXRpbmctZWFwaWRlbnRpdHktMDENCg0KVGhlIHBvaW50IGlzIHRoYXQg dGhlIGRvY3VtZW50J3MgcmVjb21tZW5kYXRpb25zIGFyZSBiYXNlZCBvbiB1c2luZyBtZXRob2Qg c3BlY2lmaWMgaWRlbnRpdGllcyB0byBkZXRlcm1pbmUgdGhlIEVBUC1SZXNwb25zZS9JZGVudGl0 eS4gVGhpcyBpcyBmdW5kYW1lbnRhbGx5IGJyb2tlbiBiZWNhdXNlIHRob3NlIGlkZW50aXRpZXMg YXJlIHVucmVsYXRlZCBhbmQgdGhlIHR3byBpZGVudGl0aWVzICBuZWVkIG5vdCB1c2UgdGhlIHNh bWUgZm9ybWF0cyBvciBlbmNvZGluZ3MgLSBhbmQgYXMgYSByZXN1bHQgdGhlIGFkdmljZSBiYXNl ZCBvbiB0aGlzIGluY29ycmVjdCBhc3N1bXB0aW9uIHdvdWxkIHJlc3VsdCBpbiBhdXRoZW50aWNh dGlvbiBmYWlsdXJlcywgdW5hY2NlcHRhYmxlIGRlbGF5cyBhbmQgd29yc2UuDQoNClRoZSBkb2N1 bWVudCBpdHNlbGYgcG9pbnRzIHRoaXMgb3V0IC0gYnV0IGRvZXMgbm90IHJlY29nbml6ZSB0aGF0 IHRoZSBwcm9ibGVtIGl0c2VsZiByZXN1bHRzIGZyb20gYSBmYWxzZSBhc3N1bXB0aW9uLg0KDQoN Cj4gT24gSnVsIDIwLCAyMDE1LCBhdCAxNDowNiwgbGlvbmVsLm1vcmFuZEBvcmFuZ2UuY29tIHdy b3RlOg0KPiANCj4gSGkgQmVybmFyZCwNCj4gDQo+IEkgdGVuZCB0byBhZ3JlZSB3aXRoIFNhbS4g SSB3aWxsIHJldmlldyBhZ2FpbiB0aGUgZHJhZnQgYmFzZWQgb24geW91ciBjb21tZW50LiBIb3dl dmVyIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBwb2ludCBpcyBXSEVOICJJZGVudGl0eSBSZXNwb25z ZSBiZSB1c2VkIHByaW1hcmlseSBmb3Igcm91dGluZyBwdXJwb3NlcyAiLCB0aGVyZSBpcyBzb21l IGNvbnNpZGVyYXRpb25zIHRvIHRha2UgaW50byBhY2NvdW50IHRvIHVzZSBpdCBhcyB1c2VyLW5h bWUgaWRlbnRpdHkgaW4gUkFESVVTIGFuZCBEaWFtZXRlci4gRXZlcnl0aGluZyBlbHNlIHJlbGF0 ZWQgdG8gbWV0aG9kLXNwZWNpZmljIEVBUCBpZGVudGl0eSAoZm9ybWF0LCB1c2UsIGV0Yy4pIGlz IG91dCBvZiBzY29wZSBvZiB0aGlzIGRvY3VtZW50LiBBdCBsZWFzdCBpdCBpcyBteSBjdXJyZW50 IHVuZGVyc3RhbmRpbmcuDQo+IA0KPiBMaW9uZWwNCj4gDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiBEZSA6IHJhZGV4dCBbbWFpbHRvOnJhZGV4dC1ib3VuY2VzQGlldGYub3JnXSBE ZSBsYSBwYXJ0IGRlIFNhbSBIYXJ0bWFuIA0KPiBFbnZvecOpIDogbHVuZGkgMjAganVpbGxldCAy MDE1IDEzOjMwIMOAIDogQmVybmFyZCBBYm9iYSBDYyA6IA0KPiByYWRleHRAaWV0Zi5vcmcgT2Jq ZXQgOiBSZTogW3JhZGV4dF0gUmV2aWV3IG9mIA0KPiBkcmFmdC13aW50ZXItcmFkZXh0LXBvcHVs YXRpbmctZWFwaWRlbnRpdHktMDENCj4gDQo+Pj4+Pj4gIkJlcm5hcmQiID09IEJlcm5hcmQgQWJv YmEgPGJlcm5hcmRfYWJvYmFAaG90bWFpbC5jb20+IHdyaXRlczoNCj4gDQo+ICAgIEJlcm5hcmQ+ ICAgIE9uZSBvZiB0aGUgZnVuZGFtZW50YWwgYXNzdW1wdGlvbnMgb2YgdGhpcyBkb2N1bWVudCBp cw0KPiAgICBCZXJuYXJkPiB0aGF0IHRoZSBFQVAtUmVzcG9uc2UvSWRlbnRpdHkgaXMgc29tZWhv dyBkZXRlcm1pbmVkIGZyb20NCj4gICAgQmVybmFyZD4gdGhlIG1ldGhvZC1zcGVjaWZpYyBpZGVu dGl0aWVzLiAgVGhpcyBpcyBub3QgY29ycmVjdCwgYXMNCj4gICAgQmVybmFyZD4gUkZDIDM3NDgg U2VjdGlvbiA1LjEgbWFrZXMgY2xlYXI6DQo+IA0KPiBIaS4gIEkgd2FzIHZlcnkgY29uZnVzZWQg dG8gcmVhZCB0aGlzIHBhcmFncmFwaCwgYmVjYXVzZSB3ZSd2ZSBkaXNjdXNzZWQgdGhpcyBpc3N1 ZSBzZXZlcmFsIHRpbWVzIGFuZCBJIHRoaW5rIHdlJ3JlIGFsbCBpbiBhZ3JlZW1lbnQgdGhhdCB0 aGUgbWV0aG9kLXNwZWNpZmljIGlkZW50aXRpZXMgYXJlIG5vdCBkaXJlY3RseSByZWxhdGVkIHRv IHRoZSBlYXAgcmVzcG9uc2UvaWRlbnRpdHkuICBJIHRoaW5rIHRoYXQgYXMgdGhlIHRleHQgeW91 IGNpdGUgZnJvbSBSRkMgMzc0OCBwb2ludHMgb3V0LCB0aGUgRUFQIHJlc3BvbnNlIGlzIG9mdGVu IHVzZWQgZm9yIHJvdXRpbmcsIHNvIGluIG1hbnkgZGVwbG95bWVudHMgdGhlcmUgaXMgc29tZSBy ZWxhdGlvbi4NCj4gDQo+IEkgc3RvcHBlZCByZWFkaW5nIHlvdXIgcmV2aWV3IGFmdGVyIHRoaXMg Zmlyc3QgcGFyYWdyYXBoLCBiZWNhdXNlIEkgdGhpbmsgdGhhdCB0aGlzIGRpc2Nvbm5lY3QgY29s b3JzIHRoZSBlbnRpcmUgcmV2aWV3LiAgSSdkIHJlYWxseSBhcHByZWNpYXRlIGl0IGlmIHlvdSB3 b3VsZCBleHBsYWluIHdoeSB5b3UgdGhpbmsgdGhlIGRvY3VtZW50IGlzIGFzc3VtaW5nIHRoYXQg dGhlIGVhcC1yZXNwb25zZS9pZGVudGl0eSBpcyBkZXRlcm1pbmVkIGZyb20gbWV0aG9kIGlkZW50 aXRpZXMuDQo+IEkga25vdyB0aGF0IHdhcyBub3Qgb3VyIGludGVudC4NCj4gDQo+IEkgZG8gdGhp bmsgaXQncyB0cnVlIHRoYXQgaW1wbGVtZW50YXRpb25zIHNvbWV0aW1lcyBkZXJpdmUgYm90aCB0 aGUgZWFwIHJlc3BvbnNlL2lkZW50aXR5IGFuZCB0aGUgbWV0aG9kLXNwZWNpZmljIGlkZW50aXRp ZXMgZnJvbSBhIGNvbW1vbiBwcmluY2lwYWwuDQo+IE90aGVyIGltcGxlbWVudGF0aW9ucyByZXF1 ZXN0IGJvdGggaWRlbnRpdGllcyBmcm9tIHRoZSB1c2VyLg0KPiBIb3dldmVyLCBJIGRvbid0IGtu b3cgYW55dGhpbmcgdGhhdCB0cmllcyB0byBtYXAgYmFjayBmcm9tIGEgbWV0aG9kIGlkZW50aXR5 IHRvIGFuIGVhcCByZXNwb25zZS4NCj4gDQo+IC0tU2FtDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiByYWRleHQgbWFpbGluZyBsaXN0DQo+ IHJhZGV4dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JhZGV4dA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gDQo+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNl cyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyANCj4gY29uZmlkZW50 aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVz ZXMsIA0KPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIA0KPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBh IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+IA0KPiBUaGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgDQo+IHBy aXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBz aG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlz YXRpb24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFz ZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLg0KPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuDQo+IFRoYW5rIHlvdS4NCj4gDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Mon Jul 20 05:59:43 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51081A8785 for ; Mon, 20 Jul 2015 05:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCk-6nzdmP9G for ; Mon, 20 Jul 2015 05:59:40 -0700 (PDT) Received: from BLU004-OMC2S33.hotmail.com (blu004-omc2s33.hotmail.com [65.55.111.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5301A8787 for ; Mon, 20 Jul 2015 05:59:38 -0700 (PDT) Received: from BLU406-EAS107 ([65.55.111.72]) by BLU004-OMC2S33.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 20 Jul 2015 05:59:37 -0700 X-TMN: [11plWKJYPDz/jLAfYUm1QMOI4dsHwEPE] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Mon, 20 Jul 2015 14:57:47 +0200 References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <6155_1437393977_55ACE439_6155_10573_1_6B7134B31289DC4FAF731D844122B36E01CCA3D4@OPEXCLILM43.corporate.adroot.infra.ftgroup> <23999_1437395949_55ACEBED_23999_2405_14_6B7134B31289DC4FAF731D844122B36E01CCA48F@OPEXCLILM43.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" In-Reply-To: <23999_1437395949_55ACEBED_23999_2405_14_6B7134B31289DC4FAF731D844122B36E01CCA48F@OPEXCLILM43.corporate.adroot.infra.ftgroup> X-OriginalArrivalTime: 20 Jul 2015 12:59:37.0973 (UTC) FILETIME=[EF2FBA50:01D0C2EB] Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 12:59:42 -0000 On Jul 20, 2015, at 14:39, lionel.morand@orange.com wrote: >=20 > Hi bernard, >=20 > after a quick review, I think I understand your concerns. [BA] Thanks.=20 > I really think that the point is not to make any assumption on the method-= specific ID that could be used in EAP-Response. [BA] Right. The method-specific identity might be in a different format that= is not convertible to an NAI (REDMOND\bernarda versus bernarda@microsoft.co= m). It might be in a different encoding (e.g. Not UTF-8). The method-specif= ic ID could identify the user while the EAP-Response/Identity might be anony= mous. So you can't assume the method-specific ID is a valid NAI suitable for= the EAP-Response/Identity or even can be transformed into one. > I think we can update the text to make it clear. >=20 > To sum-up, I would say that the intention of the draft is to: >=20 > - clarify that the EAP-Response can be used for routing > - When it is the case, two consequences: > - it may be needed to use different ids to reach different EAp servers= , when a single EAP server cannot be used to support all the methods support= ed by the peer. > - a specific encoding of the id encapsulated in the EAP-Response is req= uired to ensure a correct use over RADIUS/Diameter >=20 > Do we agree? [BA] Those things make sense. You can also point out the bad things that can= happen by using method-specific identities in the EAP-Response/Identity (if= that is something implementations have gotten into trouble with).=20 One other potential relevant point is how RADIUS servers are configured to d= eal with realms they aren't configured to natively handle. Most of the time t= hose realms are rejected but sometimes the RADIUS server can proxy.=20= From nobody Tue Jul 21 12:22:08 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD041B2A83 for ; Tue, 21 Jul 2015 12:22:07 -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 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 LKJvhJDUuslJ for ; Tue, 21 Jul 2015 12:22:05 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9AB81B2A7F for ; Tue, 21 Jul 2015 12:22:04 -0700 (PDT) Received: from viper.local (unknown [158.64.15.195]) by smtp.restena.lu (Postfix) with ESMTPSA id E4D23BB726; Tue, 21 Jul 2015 21:22:02 +0200 (CEST) To: Sam Hartman , Bernard Aboba References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <55AE9BD8.6040909@restena.lu> Date: Tue, 21 Jul 2015 21:22:00 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="E1dkJKJUlWkvObTvVmSbjRBX8gJIS9xE9" Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 19:22:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E1dkJKJUlWkvObTvVmSbjRBX8gJIS9xE9 Content-Type: multipart/mixed; boundary="------------010903090100030906010702" This is a multi-part message in MIME format. --------------010903090100030906010702 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, >>>>>> "Bernard" =3D=3D Bernard Aboba writes:= > Bernard> On Jul 20, 2015, at 13:29, Sam Hartman wrote: > >> Other implementations request both identities from the user. > >> However, I don't know anything that tries to map back from a > >> method identity to an eap response. > > Bernard> [BA] Neither do I - it's a bad idea. That's why Section > Bernard> 4's advice seems so strange: > > Bernard> If an EAP authentication gets rejected, the EAP peer > Bernard> SHOULD re-try the authentication using a different > Bernard> EAP-Response/Identity than before. The EAP peer SHOULD tr= y > Bernard> all user identifiers from the entire set of configured EAP= > Bernard> types before declaring final authentication failure. > > Bernard> [BA] "all user identities" appears to imply using > Bernard> method-specific identities to construct the > Bernard> EAP-Response/Identity. > > Ah, that's not how I read it at all. > I read that as saying that you try all the identities you have. > If you're an implementation that stores outer identities separately fro= m > inner identities, then try all your outer identities. > If you're an implementation that maps both from a common principal, do > that for all your principals. Thanks both for taking this thread so far - now I see the shortcomings in my formulation. FWIW, the intention of the wording was Sam's POV and I will re-phrase it to be clearer. > Bernard> EAP peers need to maintain state on the encoding of the= > Bernard> user identifiers which are used in their locally configure= d > Bernard> EAP types. When constructing an EAP-Response/Identity fro= m > Bernard> that user identifier, > > Bernard> [BA] Again, this seems to imply using method-specific > Bernard> identities to construct the EAP-Response/Identity. > > I see what you're saying now. > I think what the text is trying to talk about there is constructing bot= h > from some common principal/idea about an account. However it could be > read as constructing one from another. > And also, it doesn't deal as well with the case where they are separate= =2E I had a specific example in my head when thinking about this, it's a Redmond one :-) The Win 7 PEAP config allows to configure the method inner identity. There's also a separate place for the outer identity. However: you can't type a NAI realm in the outer ID box, only a non-NAI string. What happens when you type "anonymous" as outer ID, and "john@example.com" as the inner ID, is that the supplicant will send an EAP-Response/Identity of "anonymous@example.com". Just like Bernard says, yes, this is using (parts of) a method-specific (inner) identity to construct the EAP-Response/Identity. That is, the config options for inner vs. outer are different, yet related. The supplicant blends two different config items into one resulting string. Hopefully, both are in the same encoding, and hopefully, the encoding is UTF-8. If not, both parts of it need to be converted to a common encoding before concat'ing them, and the result be converted to UTF-8 before sending. Source: MSDN EAP Team Blog http://blogs.msdn.com/b/eapteam/archive/2009/01/16/peap-identity-privacy-= support-in-windows7.aspx The draft's intention is exactly to move implementations towards UTF-8 for the EAP-Response/Identity *no matter where they take the string from, be it from an inner identity, explicit configuration of an outer identity, or a blend of the two*. It is not the intention to spill inner identities to EAP-Response/Identity if an outer identity is configured. Greetings, Stefan Winter > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------010903090100030906010702 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.0.19 (Darwin) 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----- --------------010903090100030906010702-- --E1dkJKJUlWkvObTvVmSbjRBX8gJIS9xE9 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.0.19 (Darwin) iQIcBAEBCgAGBQJVrpvZAAoJEMDeajWKOdxm5cUQANM/kmmKAgFZ0YEW+J63nlr+ lFVCMeePhQ3a0xQ545S2/tKcu6FAQbwQao/Eo3YE1UiSUYePLp54nWsG7jvUJuZd 5i6odIYpKw+Ny8SbayQGmCEFqigSeJeZKkJeyKEFkmlQf8/qU2CuhCXxNk4Ph2Lb Ld9DCBfqQpdI6K4XSuN3Y+oIYtVjCThSfaVVFVACqYdrmK/G58tsqxmfeP8Ig45V acHpjLAK+tUbjhyPbpusD/2SCVFkKepOaCTLakmXSMA9DpX2P+/LOej7jYQDgiZ2 lT2+5sGH8w5JFvN6zSZltV6sWcxRMJY/rvXR01XutAY7ZyLurprCi3ntYmIHKK3v 2hx1goOyDQY19xKHM6dVV4ydohgTd3HZOv/bMweWDY2ToBvIivuAE8xzRc9JF1Hj nRoH9Zr+hUMIsSkRYsw6+DN1Ex9Pc8D+2jPp8LTJk/J4XgPDHew5xqWFSAPeI1m/ dCZCcuUhCJybYvmElq3cw2opTQkV7mtiYfCeizPV7dpvYgcOnW1HzSVtjkAvnH11 LT4ygryjv5ne6ZETq9+zEp/JseCKlQ3yGbRnKA5kZKDsJtVM7128Bl1/8NtYKDau 4vKnLf9sBGa4AEjmsVmbaUDHgQHaBgyEGhuMD4qq/hSkRvwHWtnWqAjm3Q0eJru/ Y5CClGDlfJLRMuqHSnnR =rham -----END PGP SIGNATURE----- --E1dkJKJUlWkvObTvVmSbjRBX8gJIS9xE9-- From nobody Tue Jul 21 12:35:01 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E271D1A883F for ; Tue, 21 Jul 2015 12:34:59 -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 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 5xdPwHuLHvAd for ; Tue, 21 Jul 2015 12:34:57 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65ADA1B2AA4 for ; Tue, 21 Jul 2015 12:34:57 -0700 (PDT) Received: from viper.local (unknown [158.64.15.195]) by smtp.restena.lu (Postfix) with ESMTPSA id 148DCBB73C for ; Tue, 21 Jul 2015 21:34:56 +0200 (CEST) To: radext@ietf.org References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 X-Enigmail-Draft-Status: N1111 Message-ID: <55AE9EDF.9000105@restena.lu> Date: Tue, 21 Jul 2015 21:34:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5UJPk1kxXi2ws3m7X3AMETRBfeGSq9nrg" Archived-At: Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 19:35:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5UJPk1kxXi2ws3m7X3AMETRBfeGSq9nrg Content-Type: multipart/mixed; boundary="------------070604050603080401010509" This is a multi-part message in MIME format. --------------070604050603080401010509 Content-Type: multipart/alternative; boundary="------------030204030904060000080201" --------------030204030904060000080201 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, croping to the remaining bits... > Also, the EAP-Response/Identity is frequently anonymous and is used > to prevent a snooping attacker from obtaining the method-specific > identities, which are typically encrypted. For this reason and others > described below, it is not advisable for EAP implementations to > determine the EAP-Response/Identity based on the method-specific > identities. And yet, this is what pretty much every supplicant I've seen does. Inner ID: john@example.com Outer ID: (not configured) EAP-Response/Identity: john@example.com (again, an example: this is what Windows 7 does if you do not configure Identity Privacy) That may be a bad idea (but what's the alternative? Bail out with "config error, need outer ID"?). The draft does not take any position on whether that's a good or bad thing to do. It merely states that if an implementation does that, it needs to be cautious to convert the inner ID to UTF-8 before sending at as outer ID. > Most EAP methods created subsequent to RFC 3748 have incorporated > their own Identity Exchanges, and those methods are therefore not > influenced by the EAP-Response/Identity. Since the > EAP-Response/Identity is distinct from the method-specific identity, > the recommendations of Section 4 will not have an effect on EAP > authentication, other than perhaps forcing the selection of a > different EAP server: =20 > =20 > If an EAP authentication gets rejected, the EAP peer SHOULD re-try > the authentication using a > different EAP-Response/Identity than before. The EAP peer SHOULD tr= y > all user identifiers from the entire set of configured EAP types > before declaring final authentication failure. > The advice has a number of major downsides. Since most > authentication failures will be due to mistyping the password, > responding to an authentication failure by retrying all conceivable > user identities will lead to major delays =2E.. in the order of magnitude of several hundred milliseconds ... > and very high levels of user annoyance. =2E.. or user joy and happiness, if going that extra mile turned a DoS into a successful authentication. > By responding to an authentication failure by trying method-specific > identities, implementations would divulge identity information that > was designed to be kept secret, compromising privacy. Also, an > implementation following this advice would utilize method-specific > identities that may not be in the appropriate format or character > encoding for an EAP-Response/Identity.=20 That's exactly why the draft states that a conversion to UTF-8 needs to be done before sending as EAP-Response/Identity. True, if the format is not what is needed on the routing level, the authentication still won't succeed. However, in the absence of an actual outer ID config, there's nothing an RFC can do to fix this; the user needs to fix his config then.= > Since RFC 3748 makes it clear that the EAP-Response/Identity is not > related to the method-specific identity, constructing the > EAP-Response/Identity from the method-specific one is inadvisable. =20 > The re-encoding described above may not be possible for a variety of > reasons, including the fact that the method-specific identity need not > be in NAI form at all.=20 Encoding (as in: to UTF-8) should always be possible (the EAP peer hopefully knows the original encoding). Again, if the resulting string is not a NAI but a NAI would be needed to route the authentication - time to give up. Greetings, Stefan Winter > > =20 > =20 > =20 > > =20 > =20 > =20 > =20 > =20 > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------030204030904060000080201 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi,

croping to the remaining bits...

Also, the EAP-Response/Identity is frequently anonymous and=A0is used to=A0prevent a snooping attacker from obtaining the method-specific identities, which are typically encrypted. =A0For this reason and others described below, it is not advisable for EAP implementations to determine the EAP-Response/Identity based on the method-specific identities.

And yet, this is what pretty much every supplicant I've seen does. Inner ID: john@example.com
Outer ID: (not configured)
EAP-Response/Identity: john@example.com

(again, an example: this is what Windows 7 does if you do not configure Identity Privacy)

That may be a bad idea (but what's the alternative? Bail out with "config error, need outer ID"?). The draft does not take any position on whether that's a good or bad thing to do. It merely states that if an implementation does that, it needs to be cautious to convert the inner ID to UTF-8 before sending at as outer ID.

Most EAP methods created subsequent to RFC 3748 have incorporated their own Identity Exchanges,=A0and those methods=A0are therefore not influenced by the EAP-Response/Identity.=A0=A0 Since the EAP-Response/Identity is distinct from the method-specific identity, the recommendations of Section 4 will not have an effect=A0on=A0EAP authentication, other than perhaps forcing the selection of a different EAP server:=A0=A0
=A0
=A0=A0 If an EAP authentication=A0gets rejected, the EAP peer SHO= ULD re-try the authentication using a
=A0=A0 different EAP-Response/Identity than before.=A0 The EAP pe= er SHOULD try
=A0=A0 all user identifiers from the entire set of configured EAP= types
=A0=A0 before declaring final authentication failure.

=A0The advice has a number of major downsides.=A0 = Since most authentication failures will be due to mistyping the password, responding to an authentication failure by retrying all conceivable user identities will lead to major delays

... in the order of magnitude of several hundred milliseconds ...
=
and very high levels of user annoyance.
... or user joy and happiness, if going that extra mile turned a DoS into a successful authentication.

By responding to an authentication failure by trying=A0method-specific identities, implementations would divulg= e identity information that was designed to be kept secret, compromising privacy. Also, an implementation following this advice would utilize method-specific identities that may not be in the appropriate format or character encoding for an EAP-Response/Identity.=A0

That's exactly why the draft states that a conversion to UTF-8 needs to be done before sending as EAP-Response/Identity. True, if the format is not what is needed on the routing level, the authentication still won't succeed. However, in the absence of an actual outer ID config, there's nothing an RFC can do to fix this; the user needs to fix his config then.

=A0Since RFC 3748 makes it clear that the EAP-Response/Identity is not related to the method-specific identity, constructing the EAP-Response/Identity from the method-specific one is inadvisable.=A0=A0 The re-encoding describ= ed above may not be possible for a variety of reasons, including the fact that the method-specific identity need not be in NAI form at all.=A0

Encoding (as in: to UTF-8) should always be possible (the EAP peer hopefully knows the original encoding). Again, if the resulting string is not a NAI but a NAI would be needed to route the authentication - time to give up.

Greetings,

Stefan Winter

=A0
=A0
=A0

=A0
=A0
=A0
=A0
=A0


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

--------------030204030904060000080201-- --------------070604050603080401010509 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.0.19 (Darwin) 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----- --------------070604050603080401010509-- --5UJPk1kxXi2ws3m7X3AMETRBfeGSq9nrg 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.0.19 (Darwin) iQIcBAEBCgAGBQJVrp7fAAoJEMDeajWKOdxmmTAQAJRRueUmE00QLkH0g6m9oHou Bfw+oqhPgXm18ncgYxa15pFP4kWpwGjUcaPcxN/ag2/AgI7/esakMm6YqadeMRoS fioiqQnk4jp7Evf0DohM4rP9bU5SVY1ZrDTmiBKBhqMqY/bcROH2D06Clw5O09eN MqZ6rgMa9GydK7EoMOz+eB+i/1R6l9sbPnFwA7obZQqHWhSvDNLxHdG9zJI9cyPz pPIdjszO22RiKXOcjTIoxASm4X1nBdg+6m7CC6bpJgV4F4C2Z67g40ifj+fnmkhg RCHo8SKxe9U5ulVWAq45yeQxi2JzlI/gMfChlpKFnC4yJdnMfv7LEVG5siCvL+Da CKEPvEkSrlPOg9QiFxvoW0AR6Vt7jNr/BIrc61kkef3f7g/qZjYTP88BfEOS/6hu RZknNC+0MxOe0nEXsACu1d5qBJBDfKElbMvkzTAHzA1rnyj0oU12aqoN33fCEkBC pnoXkXfuF7c/dTusluACUBrdJKWsP/MWLc8rxijo76KK5qlWgTKF+ZDyOJnKSIRx VzSFjK6jil5edEQzWRfxXJO/Xql7pYT9uuUSzSuNpO4h7P4zgcuTEq1mgh5V+mQ3 nmN2ZrWT2DDMfNYg4cPxH9GI2YAuhmtMV/VfIRdgtO8IsF9Y5feHI79wS7jQSCkT J+7mG+C2meQP49/qU+bk =hvMa -----END PGP SIGNATURE----- --5UJPk1kxXi2ws3m7X3AMETRBfeGSq9nrg-- From nobody Tue Jul 21 12:38:48 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6081B2B28 for ; Tue, 21 Jul 2015 12:38:46 -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 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 lt_ZdPdEUEBR for ; Tue, 21 Jul 2015 12:38:44 -0700 (PDT) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BB11A883F for ; Tue, 21 Jul 2015 12:38:44 -0700 (PDT) Received: from viper.local (unknown [158.64.15.195]) by smtp.restena.lu (Postfix) with ESMTPSA id 57F0BBB73F for ; Tue, 21 Jul 2015 21:38:43 +0200 (CEST) To: radext@ietf.org References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <6155_1437393977_55ACE439_6155_10573_1_6B7134B31289DC4FAF731D844122B36E01CCA3D4@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66 Message-ID: <55AE9FC2.7060807@restena.lu> Date: Tue, 21 Jul 2015 21:38:42 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="E8ivhjjnUmsnm4h1Ev7oW5PWS11pGLwwL" Archived-At: Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 19:38:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --E8ivhjjnUmsnm4h1Ev7oW5PWS11pGLwwL Content-Type: multipart/mixed; boundary="------------010002050401080501000809" This is a multi-part message in MIME format. --------------010002050401080501000809 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, > The point is that the document's recommendations are based on using met= hod specific identities to determine the EAP-Response/Identity. This is f= undamentally broken because those identities are unrelated and the two id= entities need not use the same formats or encodings - and as a result th= e advice based on this incorrect assumption would result in authenticatio= n failures, unacceptable delays and worse. > > The document itself points this out - but does not recognize that the p= roblem itself results from a false assumption. The "assumption" comes from observing the implemented reality of a vast multitude of supplicants, be those fundamentally broken or not. Since we're aiming at a BCP document, I think we should take reality into accou= nt. Greetings, Stefan Winter > > >> On Jul 20, 2015, at 14:06, lionel.morand@orange.com wrote: >> >> Hi Bernard, >> >> I tend to agree with Sam. I will review again the draft based on your = comment. However I understand that the point is WHEN "Identity Response b= e used primarily for routing purposes ", there is some considerations to = take into account to use it as user-name identity in RADIUS and Diameter.= Everything else related to method-specific EAP identity (format, use, et= c.) is out of scope of this document. At least it is my current understan= ding. >> >> Lionel >> >> -----Message d'origine----- >> De : radext [mailto:radext-bounces@ietf.org] De la part de Sam Hartman= >> Envoy=C3=A9 : lundi 20 juillet 2015 13:30 >> =C3=80 : Bernard Aboba >> Cc : radext@ietf.org >> Objet : Re: [radext] Review of draft-winter-radext-populating-eapident= ity-01 >> >>>>>>> "Bernard" =3D=3D Bernard Aboba writes= : >> Bernard> One of the fundamental assumptions of this document is >> Bernard> that the EAP-Response/Identity is somehow determined from >> Bernard> the method-specific identities. This is not correct, as >> Bernard> RFC 3748 Section 5.1 makes clear: >> >> Hi. I was very confused to read this paragraph, because we've discuss= ed this issue several times and I think we're all in agreement that the m= ethod-specific identities are not directly related to the eap response/id= entity. I think that as the text you cite from RFC 3748 points out, the = EAP response is often used for routing, so in many deployments there is s= ome relation. >> >> I stopped reading your review after this first paragraph, because I th= ink that this disconnect colors the entire review. I'd really appreciate= it if you would explain why you think the document is assuming that the = eap-response/identity is determined from method identities. >> I know that was not our intent. >> >> I do think it's true that implementations sometimes derive both the ea= p response/identity and the method-specific identities from a common prin= cipal. >> Other implementations request both identities from the user. >> However, I don't know anything that tries to map back from a method id= entity to an eap response. >> >> --Sam >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> >> ______________________________________________________________________= ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations con= fidentielles 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 messag= es electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deform= e ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privilege= d information 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= delete 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. >> > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------010002050401080501000809 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.0.19 (Darwin) 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----- --------------010002050401080501000809-- --E8ivhjjnUmsnm4h1Ev7oW5PWS11pGLwwL 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.0.19 (Darwin) iQIcBAEBCgAGBQJVrp/CAAoJEMDeajWKOdxmcUEQAMbh7JvbqrKsWkq65HUflDUE G/78q4+Zdrpiudh4t4XzDC5NsEEHWo3fgIJHyfLKMj2G6iT/QPcXsi1s8e0jCL0i p2lDdiDP3J3ZZGVqmmkz6Y00qum/DjHG1LxIVC6OKGsr2FSQZgYHd1LGuGYF89pM 4nq2xCXmEcvtrr1rMFeo/PdDStgfeifp9uUWfpcv8QoWIbTwmPT4L6/kjwFwXyvS SWrbvHgIc3ffyDheM/iaTS1QJeHBHXfGcNdFM591SfsQM00UKm/CeekL1vuVuyPe D7+AXJaKReFtNth4DC0sUOVD7sDWia1xGPUwI8p7TvMct6+uAZ1h99r0Ke1kfglo ZaVRhNaSyi1Lu0dx7abSnu31Dl8fTgk+TN7ucH5eH+5LumRwxMgj4v8VNMfoaGYs 2nP64AW0psxmxamewucI3psFt1AEkhY00pb4CSpljZUogAuw7c3ZX36y7dACSrRL vLKeEIpzPSYsV+JwGtzAtPVCyU6IZ56OBp9NZI0OgMhn+Jh3tdfYVInjGus+y360 kRM5TQflVsbtjgtJHR82SdPaic/zeAnR1CRlSjexkCiIYsrjDLTsBAouaMoWm0Nt ZBKzTjiiynkd3eVeLksY6XXgEBvL3BiDsQRTjaiNDeA3ce1jCJAJ4SS10XJK2HVy 6oA5kDQRzaaVCJDQU+4x =BSI7 -----END PGP SIGNATURE----- --E8ivhjjnUmsnm4h1Ev7oW5PWS11pGLwwL-- From nobody Tue Jul 21 15:55:57 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B201B321B for ; Tue, 21 Jul 2015 15:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfHw-pXi1LJg for ; Tue, 21 Jul 2015 15:55:54 -0700 (PDT) Received: from BLU004-OMC1S36.hotmail.com (blu004-omc1s36.hotmail.com [65.55.116.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63A451A877A for ; Tue, 21 Jul 2015 15:55:54 -0700 (PDT) Received: from BLU406-EAS411 ([65.55.116.9]) by BLU004-OMC1S36.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 21 Jul 2015 15:55:53 -0700 X-TMN: [r3OEb7iv1Hdfj5WVj2JG38ztoiMH7YlW] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Wed, 22 Jul 2015 00:54:59 +0200 References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55AE9BD8.6040909@restena.lu> To: Stefan Winter In-Reply-To: <55AE9BD8.6040909@restena.lu> X-OriginalArrivalTime: 21 Jul 2015 22:55:53.0638 (UTC) FILETIME=[658EBC60:01D0C408] Archived-At: Cc: Sam Hartman , "radext@ietf.org" Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 22:55:56 -0000 On Jul 21, 2015, at 21:22, Stefan Winter wrote: >=20 > The Win 7 PEAP config allows to configure the method inner identity. > There's also a separate place for the outer identity. > However: you can't type a NAI realm in the outer ID box, only a non-NAI > string. >=20 > What happens when you type "anonymous" as outer ID, and > "john@example.com" as the inner ID, is that the supplicant will send an > EAP-Response/Identity of "anonymous@example.com". [BA] That is bad behavior for sure in both cases.=20 > That is, the config options for inner vs. outer are different, yet > related. The supplicant blends two different config items into one > resulting string. Hopefully, both are in the same encoding, and > hopefully, the encoding is UTF-8. [BA] As they say, "hope is not a strategy".=20 > The draft's intention is exactly to move implementations towards UTF-8 > for the EAP-Response/Identity *no matter where they take the string > from, [BA] that is a fine goal, well supported by RFC 3748. > be it from an inner identity, explicit configuration of an outer > identity, or a blend of the two*. It is not the intention to spill inner > identities to EAP-Response/Identity if an outer identity is configured. [BA] Blending the two does not seem like a practice to be encouraged, nor do= I recall any one else doing something like that. So pointing at out the pot= ential ill effects as well as the right thing to do seems appropriate.= From nobody Tue Jul 21 16:11:50 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728BA1AC3FC for ; Tue, 21 Jul 2015 16:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MP-QSj_FxSF for ; Tue, 21 Jul 2015 16:11:46 -0700 (PDT) Received: from BLU004-OMC2S9.hotmail.com (blu004-omc2s9.hotmail.com [65.55.111.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8D71A872B for ; Tue, 21 Jul 2015 16:11:45 -0700 (PDT) Received: from BLU406-EAS34 ([65.55.111.72]) by BLU004-OMC2S9.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 21 Jul 2015 16:11:44 -0700 X-TMN: [t+bJKntEQ0IIUoaRDhGI2h3JgyWoXaIn] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/related; boundary="_191f66a6-0e5e-49aa-bca5-b5b3b5b100e2_" From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Wed, 22 Jul 2015 01:11:18 +0200 References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55AE9EDF.9000105@restena.lu> To: Stefan Winter In-Reply-To: <55AE9EDF.9000105@restena.lu> X-OriginalArrivalTime: 21 Jul 2015 23:11:44.0784 (UTC) FILETIME=[9C7C1900:01D0C40A] Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 23:11:48 -0000 --_191f66a6-0e5e-49aa-bca5-b5b3b5b100e2_ Content-Type: multipart/alternative; boundary="Apple-Mail-A1D884C9-9D63-45FF-9640-DFE54CC6BDCE" Content-Transfer-Encoding: 7bit --Apple-Mail-A1D884C9-9D63-45FF-9640-DFE54CC6BDCE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Jul 21, 2015, at 21:35, Stefan Winter wrote: >=20 > And yet, this is what pretty much every supplicant I've seen does. > Inner ID: john@example.com > Outer ID: (not configured) > EAP-Response/Identity: john@example.com >=20 > (again, an example: this is what Windows 7 does if you do not configure Id= entity Privacy) >=20 > That may be a bad idea (but what's the alternative? [BA] One thought might be to configure identity privacy by default both on c= lients and RADIUS servers. Now that we are more privacy aware, why not try t= o move things in this direction?=20 > True, if the format is not what is needed on the routing level, the authen= tication still won't succeed. However, in the absence of an actual outer ID c= onfig, there's nothing an RFC can do to fix this; the user needs to fix his c= onfig then. [BA] Having valid outer config would help too.=20 > Encoding (as in: to UTF-8) should always be possible (the EAP peer hopeful= ly knows the original encoding). Again, if the resulting string is not a NAI= but a NAI would be needed to route the authentication - time to give up. [BA] The EAP implementation needs to provide an NAI for the outer identity b= ecause the standard requires it. No need to sugar code it - not doing so is b= roken.= --Apple-Mail-A1D884C9-9D63-45FF-9640-DFE54CC6BDCE Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: 7bit
On Jul 21, 2015, at 21:35, Stefan Winter <stefan.winter@restena.lu> wrote:

And yet, this is what pretty much every supplicant I've seen does.
Inner ID: john@example.com
Outer ID: (not configured)
EAP-Response/Identity: john@example.com

(again, an example: this is what Windows 7 does if you do not configure Identity Privacy)

That may be a bad idea (but what's the alternative?

[BA] One thought might be to configure identity privacy by default both on clients and RADIUS servers. Now that we are more privacy aware, why not try to move things in this direction? 

True, if the format is not what is needed on the routing level, the authentication still won't succeed. However, in the absence of an actual outer ID config, there's nothing an RFC can do to fix this; the user needs to fix his config then.

[BA] Having valid outer config would help too. 


Encoding (as in: to UTF-8) should always be possible (the EAP peer hopefully knows the original encoding). Again, if the resulting string is not a NAI but a NAI would be needed to route the authentication - time to give up.

[BA] The EAP implementation needs to provide an NAI for the outer identity because the standard requires it. No need to sugar code it - not doing so is broken.
--Apple-Mail-A1D884C9-9D63-45FF-9640-DFE54CC6BDCE-- --_191f66a6-0e5e-49aa-bca5-b5b3b5b100e2_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --_191f66a6-0e5e-49aa-bca5-b5b3b5b100e2_-- From nobody Wed Jul 22 02:23:19 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6AD1AD182 for ; Wed, 22 Jul 2015 02:23:18 -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 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 J96yuOXkgBgK for ; Wed, 22 Jul 2015 02:23:12 -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 58F191ACE3A for ; Wed, 22 Jul 2015 02:21:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3265C2075B; Wed, 22 Jul 2015 05:20:44 -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 mgRtXtHcL3o3; Wed, 22 Jul 2015 05:20:43 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (dhcp-89db.meeting.ietf.org [31.133.137.219]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 22 Jul 2015 05:20:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7A2CA82120; Wed, 22 Jul 2015 05:21:06 -0400 (EDT) From: Sam Hartman To: Bernard Aboba References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55AE9EDF.9000105@restena.lu> Date: Wed, 22 Jul 2015 05:21:06 -0400 In-Reply-To: (Bernard Aboba's message of "Wed, 22 Jul 2015 01:11:18 +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: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 09:23:18 -0000 >>>>> "Bernard" == Bernard Aboba writes: Bernard> [BA] Having valid outer config would help too. Bernard> Encoding (as in: to UTF-8) should always be possible Bernard> (the EAP peer hopefully knows the original Bernard> encoding). Again, if the resulting string is not a NAI but Bernard> a NAI would be needed to route the authentication - time to Bernard> give up. Bernard> [BA] The EAP implementation needs to provide an NAI for Bernard> the outer identity because the standard requires it. No Bernard> need to sugar code it - not doing so is broken. Bernard> _______________________________________________ radext Bernard> mailing list radext@ietf.org Bernard> https://www.ietf.org/mailman/listinfo/radext I agree that the implementation MUST provide an outer identity. I do want to permit mapping from some common idea of an account. Especially for things like RFC 7055 where you're integrating EAP into something else, you may only have space in the involved APIs for a single concept of identity. There you almost certainly want to do a privacy-based outer ID, and you'll need to have specific knowledge of the methods you use, and there may be some configurations you don't work with. It's not fully general, but it is more intuitive than an iterface that prompts for a lot of identities. ONe thing to clarify in this document is which identities are we talking about. There are: * The outer identity carried in an EAP response in RADIUS/Diameter. I know we're talking about that one. That's the primary point of the document. * The Inner identity (if you have a tunnel method) often carried in an EAP response/identity in the tunnel. You could argue this one is either in or out of scope. You could argue this is an internal identifier of the tunnel method. * The method specific identifier of the EAP method within the tunnel. In case of password authentication in something like TEAP this identity may be carried and the classic inner identity may not. I think this identity is clearly out of scope for this document. --Sam From nobody Fri Jul 24 03:51:39 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A9A1A8AC0 for ; Fri, 24 Jul 2015 03:51:37 -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 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 hEUm2q0A2Ybl for ; Fri, 24 Jul 2015 03:51:35 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5866A1A8AB6 for ; Fri, 24 Jul 2015 03:51:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 3DB1422404A2; Fri, 24 Jul 2015 12:51:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJt1vqK7J-0a; Fri, 24 Jul 2015 12:51:03 +0200 (CEST) Received: from [192.168.2.14] (bas1-ottawa11-1176122299.dsl.bell.ca [70.26.51.187]) by power.freeradius.org (Postfix) with ESMTPSA id 92C842240203; Fri, 24 Jul 2015 12:51:02 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Fri, 24 Jul 2015 06:51:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55AE9EDF.9000105@restena.lu> To: Sam Hartman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Aboba Bernard , Winter Stefan , "radext@ietf.org" Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2015 10:51:38 -0000 Sam and I had extensive conversations about it this week. I think his = summary below is critical to get everyone talking about the same thing. We also need to discuss where these identities are derived from. For = example, wpa_supplicant allows you to configure the outer identity, and = the inner identity, though it gives them different names. I can't see = where the method-specific identify is configured. =46rom looking at the code, the method-specific identity is just a = copy of the inner identity. This process is different in windows. The inner and outer identities = can be configured via the 802.1X GUI. The method-specific identify = cannot be configured. And it is NOT the same as the inner identity. = Instead, some (essentially magic) process is used to transform one into = the other. In typical cases, the inner identity "user@example.com" gets = transformed to an EAP-MSCHAPv2 identity "EXAMPLE\user". I would suggest that such processes should be discouraged. It is = difficult enough to analyze the security of EAP without introducing 3 = potentially unrelated identities. What does it mean when the inner identity is "user@example.com", and = the method identity is "CORP/bob" ? Who is being authenticated here? I don't think anyone knows. In the case of Windows, it would be good for an EAP server to check = via an API that "user@example.com" gets transformed to "EXAMPLE\user". = The server can then verify that the method identity, while opaque, is = transformationally equivalent to the inner identity. This verification = would likely prevent some attacks. On Jul 22, 2015, at 5:21 AM, Sam Hartman = wrote: > ONe thing to clarify in this document is which identities are we = talking > about. There are: >=20 > * The outer identity carried in an EAP response in RADIUS/Diameter. I > know we're talking about that one. That's the primary point of the > document. >=20 > * The Inner identity (if you have a tunnel method) often carried in an > EAP response/identity in the tunnel. You could argue this one is > either in or out of scope. You could argue this is an internal > identifier of the tunnel method. >=20 > * The method specific identifier of the EAP method within the tunnel. > In case of password authentication in something like TEAP this > identity may be carried and the classic inner identity may not. I > think this identity is clearly out of scope for this document. >=20 > --Sam >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Fri Jul 24 04:20:58 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36A31A910E for ; Fri, 24 Jul 2015 04:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPHbOlbC7s0O for ; Fri, 24 Jul 2015 04:20:55 -0700 (PDT) Received: from BLU004-OMC1S36.hotmail.com (blu004-omc1s36.hotmail.com [65.55.116.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AD01A8BB3 for ; Fri, 24 Jul 2015 04:20:55 -0700 (PDT) Received: from BLU406-EAS149 ([65.55.116.9]) by BLU004-OMC1S36.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 24 Jul 2015 04:20:54 -0700 X-TMN: [GEmTS8/F93/opoa4CBdrhgpx81DOWVXi] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Bernard Aboba MIME-Version: 1.0 (1.0) Date: Fri, 24 Jul 2015 13:20:53 +0200 References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55AE9EDF.9000105@restena.lu> To: Alan DeKok In-Reply-To: X-OriginalArrivalTime: 24 Jul 2015 11:20:54.0068 (UTC) FILETIME=[CDEA8F40:01D0C602] Archived-At: Cc: Sam Hartman , "radext@ietf.org" , Winter Stefan Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2015 11:20:57 -0000 On Jul 24, 2015, at 12:51, Alan DeKok wrote: >=20 > What does it mean when the inner identity is "user@example.com", and the m= ethod identity is "CORP/bob" ? Who is being authenticated here? [BA] It means that the example.com RADIUS server is being asked to authentic= ate user bob in the CORP domain. In practice, this typically means that CORP= is within the example.com Forrest (e.g. Corp.example.com), otherwise the au= thentication would not succeed.=20= From nobody Fri Jul 24 04:26:13 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B0F1AC3B4 for ; Fri, 24 Jul 2015 04:26:11 -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 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 5pjNMyORqeHf for ; Fri, 24 Jul 2015 04:26:09 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1209F1A9147 for ; Fri, 24 Jul 2015 04:26:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 80A7822404A2; Fri, 24 Jul 2015 13:25:34 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8ixEBEL4Dhr; Fri, 24 Jul 2015 13:25:26 +0200 (CEST) Received: from [192.168.2.14] (bas1-ottawa11-1176122299.dsl.bell.ca [70.26.51.187]) by power.freeradius.org (Postfix) with ESMTPSA id 8E98A22401C5; Fri, 24 Jul 2015 13:25:25 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Fri, 24 Jul 2015 07:25:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <14078_1427880628_551BBAB4_14078_5155_1_6B7134B31289DC4FAF731D844122B36EF0B91F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <190D3355-0BB7-48D5-BEA2-55773E9BD785@deployingradius.com> <24001_1437383629_55ACBBCD_24001_3716_1_6B7134B31289DC4FAF731D844122B36E01CC9ED3@OPEXCLILM43.corporate.adroot.infra.ftgroup> <55AE9EDF.9000105@restena.lu> To: Aboba Bernard X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sam Hartman , Winter Stefan , "radext@ietf.org" Subject: Re: [radext] Review of draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2015 11:26:11 -0000 On Jul 24, 2015, at 7:20 AM, Bernard Aboba = wrote: > On Jul 24, 2015, at 12:51, Alan DeKok = wrote: >>=20 >> What does it mean when the inner identity is "user@example.com", and = the method identity is "CORP/bob" ? Who is being authenticated here? >=20 > [BA] It means that the example.com RADIUS server is being asked to = authenticate user bob in the CORP domain. In practice, this typically = means that CORP is within the example.com Forrest (e.g. = Corp.example.com), otherwise the authentication would not succeed.=20 I'm happy to make that assumption, but I'm not sure it's always true. On a similar note, what about: outer: user1@example.org inner: user2@example.com *and* where the example.org server is a proxy, and can proxy to = example.com. Should the .org server de-capsulate the outer session, and = send only the inner session to the .com site? These problems don't have clear solutions to me. The simplest = response is to forbid cross-domain identities. That may not be = practical, but we know it's safe. Alan DeKok.