From nobody Mon Sep 4 23:19:46 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6E0513236D for ; Mon, 4 Sep 2017 23:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOBitkgbDtVC for ; Mon, 4 Sep 2017 23:19:43 -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 58690120727 for ; Mon, 4 Sep 2017 23:19:43 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id A6F8E43AFC for ; Tue, 5 Sep 2017 08:19:41 +0200 (CEST) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: Date: Tue, 5 Sep 2017 08:19:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="n9897nD5Hhl4UVvwXdUhCvemm0CT2uGk2" Archived-At: Subject: [radext] working group next steps X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 06:19:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --n9897nD5Hhl4UVvwXdUhCvemm0CT2uGk2 Content-Type: multipart/mixed; boundary="EagqQnIuo0nnbf6DufBsJ7lshLvoPRM03"; protected-headers="v1" From: Stefan Winter To: "radext@ietf.org" Message-ID: Subject: working group next steps --EagqQnIuo0nnbf6DufBsJ7lshLvoPRM03 Content-Type: multipart/mixed; boundary="------------945098AB9AEE0F9F203402DC" Content-Language: lb-LU This is a multi-part message in MIME format. --------------945098AB9AEE0F9F203402DC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello! During IETF99 in Prague we discussed the future of this working group. Given the very low amount of discussion on the list, almost nobody being available for document review, and almost empty sessions at physical meetings, the outcome was that the radext working group has no real futur= e. The plan for the immediate future is to * finish the ongoing work * close the WG * keep the list open New proposed work on RADIUS will subsequently be discussed on the mailing list and can take the AD sponsoring or opsawg route. There was consensus in the meeting (which wasn't all that difficult considering that the meeting room was almost empty). As usual, we are asking to confirm this on the mailing list; any objections should be voiced within two weeks, i.e. until 22 Sept. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------945098AB9AEE0F9F203402DC 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----- --------------945098AB9AEE0F9F203402DC-- --EagqQnIuo0nnbf6DufBsJ7lshLvoPRM03-- --n9897nD5Hhl4UVvwXdUhCvemm0CT2uGk2 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 iQIcBAEBCgAGBQJZrkH9AAoJEMDeajWKOdxmJ6kQAKBDiG9I3x2tzpCuaTvuDwNO 4Os0YPfUqCAjBkDRGfFvWYgnX5VnnjYnS4yE5TU19Gq6FqqX49EGP1CWL4RGMlXG /ybjZmBphvVlD6CecbcMxUpHf25eoFXzfMMyzg41R5ncI1DbSm6ELg8kJsrMHAaj J5MqIPs2uNgmAfQJ50rCawDlVx1pu4uU4bJG3dDzsMBgZvFMgXGlsRyXSJUhq99m SXLGWoFBOGG/5JbGg3mHMQS6fEhBZN3bx9XesYaHWwb5M4+ypsxXll8mj2f+3sob WJKkX0RVwOO072CjWxNh8nTIP8pNaGULylzi/Dap3Tv3Rny8Yfuz4ae42dA4QUUC VSsSkTRqcPpF7KznhntBqvZ7hFGf1wxBIKODZu2rXU1tV4yE8geLCjY54l42ctzX SpLT4rTFYhpyXYBtekwO6Eti1nJY6BsUUAsyeb1i8CCFVnO1XZvSvHu9UvMhVUYQ fot7VQJQFcJYIc2OMs7iWWx2UEz5ROlOpQu2/6wzmzL0npfwkb3I4KKkfKfG0VK1 oBLA/oedoyWIqJ30SOk2Wts8uzEec/IGU5pGTyMifZNY2wWVHgJLR8jaqry16oCu OO+WrCQcCvI+kq5CIvHFm+32xxw+uJ+08QZ+qOIGgNpk7Rfz7X4pr/XjiliRL/ZY dxPCHzApO6igEVi3dNeP =RwFX -----END PGP SIGNATURE----- --n9897nD5Hhl4UVvwXdUhCvemm0CT2uGk2-- From nobody Mon Sep 4 23:29:25 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ACE132376 for ; Mon, 4 Sep 2017 23:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLfLz-lLEhbk for ; Mon, 4 Sep 2017 23:29:16 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B90120727 for ; Mon, 4 Sep 2017 23:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1556; q=dns/txt; s=iport; t=1504592955; x=1505802555; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=kl6QwEYSF6/MICpV7x4iujb27e84ky5pvsM6eTTrKq8=; b=hn5ca6K4TdFOXjwDYCQD2xXtUxBUusMQmE/fNYYEGx9UWSJVl/A+iFpW I2S+onrKqhCt3D+XQdrlLX+XpN01opylXbk3nTHUaM2qSIQ5MEXDdl35D Yf6tgiU5y3JnyWyjNiXEYsYtESjURYaZQcKJIOFXWbBqVC8Zhbf/rRGrO M=; X-IronPort-AV: E=Sophos;i="5.41,478,1498521600"; d="scan'208";a="291324732" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Sep 2017 06:29:15 +0000 Received: from [10.24.17.69] ([10.24.17.69]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v856TE2X000546; Tue, 5 Sep 2017 06:29:15 GMT To: Stefan Winter References: Cc: "radext@ietf.org" , Enke Chen , Naiming Shen From: Enke Chen Message-ID: <2fe1f171-50a7-1058-83e2-d381263f1d3c@cisco.com> Date: Mon, 4 Sep 2017 23:29:14 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] working group next steps X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 06:29:24 -0000 Hi, Stefan: In the WG meeting minutes of IETF99, it says that: It is proposed to push forward the draft-chen-radext-identifier-attr. This will be discussed on the mailing list. It has been decided to finish the ongoing work, including the non-WG document on Extended ID and then close the WG. Can we request WG adoption of draft-chen-radext-identifier-attr as an ongoing work item? Thanks. -- Enke On 9/4/17 11:19 PM, Stefan Winter wrote: > Hello! > > > During IETF99 in Prague we discussed the future of this working group. > > > Given the very low amount of discussion on the list, almost nobody being > available for document review, and almost empty sessions at physical > meetings, the outcome was that the radext working group has no real future. > > > The plan for the immediate future is to > > * finish the ongoing work > > * close the WG > > * keep the list open > > > New proposed work on RADIUS will subsequently be discussed on the > mailing list and can take the AD sponsoring or opsawg route. > > > There was consensus in the meeting (which wasn't all that difficult > considering that the meeting room was almost empty). As usual, we are > asking to confirm this on the mailing list; any objections should be > voiced within two weeks, i.e. until 22 Sept. > > > Greetings, > > > Stefan Winter > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > From nobody Tue Sep 5 12:30:19 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92BFF132E10 for ; Tue, 5 Sep 2017 12:30:18 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGgAQMYmsCPX for ; Tue, 5 Sep 2017 12:30:16 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id BDD9F132397 for ; Tue, 5 Sep 2017 12:30:16 -0700 (PDT) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 364A6566; Tue, 5 Sep 2017 19:30:15 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <2fe1f171-50a7-1058-83e2-d381263f1d3c@cisco.com> Date: Tue, 5 Sep 2017 15:30:13 -0400 Cc: Winter Stefan , "radext@ietf.org" , Naiming Shen Content-Transfer-Encoding: quoted-printable Message-Id: <4A0D9825-181E-4687-AAE4-A27868A86C20@deployingradius.com> References: <2fe1f171-50a7-1058-83e2-d381263f1d3c@cisco.com> To: Enke Chen X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] working group next steps X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 19:30:19 -0000 On Sep 5, 2017, at 2:29 AM, Enke Chen wrote: > In the WG meeting minutes of IETF99, it says that: >=20 > It is proposed to push forward the = draft-chen-radext-identifier-attr. This will > be discussed on the mailing list. >=20 > It has been decided to finish the ongoing work, including the non-WG = document on > Extended ID and then close the WG. >=20 > Can we request WG adoption of draft-chen-radext-identifier-attr as an = ongoing > work item? I still prefer my draft. But I would like to see *some* discussion of = the subject. some comments: - the identifier should just be a 32-bit number. There's no need to = reserve 2 bits for the "status" field. - the draft offers little guidance to implementors, and has minimal = discussion of the compatibility of this proposal with "standard" RADIUS. If the WG does decide to use extended-attars, I would suggest merging = that document with the additional text from my proposal. Only minor = edits should be necessary.= From nobody Tue Sep 5 13:01:56 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2161243F6 for ; Tue, 5 Sep 2017 13:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=f5.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHG-WRNhXz8F for ; Tue, 5 Sep 2017 13:01:53 -0700 (PDT) Received: from mail15.f5.com (mail15.f5.com [104.219.106.14]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB1C13202D for ; Tue, 5 Sep 2017 13:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=f5; t=1504641714; x=1536177714; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=iZkx/42JrLdLkPlTwlHS8TlOfre8JO6RlQFynM9NNXw=; b=bI7FcZ1u2Ttz6C2wLceqnPiMdeyOO8E+0unEuCsbqfym4WWw8mNYivm/ 119r7DPgwMCcEz2HAorukuCzGdCcWPuFXdCl/9XhPxf8E4CmXwdSxYFKd xzWsKHhdYGlUAom+MERc/Q2j0z40Y+9bh+s5chJ87z6ej+gSAzYRRuVUR cpvkhTLvI08K+50pfXtCDv2UVnqeYDElLkfI1q4wJTsEvNIb3K7a+mQDx O4ujBh8ufrJCoL7Ebm4wBOscRlh7SzloS+To5XyhFTkGrM1yGNwKJ5itZ prLkqzexkX6s0MQB3w704ZWKVvMLCnr6PGt/a+svF3vcgDYwItJQaJAdh A==; X-IronPort-AV: E=McAfee;i="5900,7806,8645"; a="19580540" X-IronPort-AV: E=Sophos;i="5.41,481,1498546800"; d="scan'208";a="19580540" Received: from seadev21.olympus.f5net.com ([192.168.24.21]) by mail.f5net.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Sep 2017 13:01:53 -0700 Received: from seadev21.olympus.f5net.com (localhost [127.0.0.1]) by seadev21.olympus.f5net.com (8.14.4/8.12.11) with ESMTP id v85K1qjI045394; Tue, 5 Sep 2017 13:01:52 -0700 Received: (from aesmith@localhost) by seadev21.olympus.f5net.com (8.14.4/8.14.4/Submit) id v85K1pqN045316; Tue, 5 Sep 2017 13:01:51 -0700 X-Authentication-Warning: seadev21.olympus.f5net.com: aesmith set sender to AE.Smith@f5.com using -f Date: Tue, 5 Sep 2017 13:01:51 -0700 From: Astrid Smith To: Alan DeKok Cc: Enke Chen , Winter Stefan , Naiming Shen , "radext@ietf.org" Message-ID: <20170905200151.GH42884@seadev21.f5.com> References: <2fe1f171-50a7-1058-83e2-d381263f1d3c@cisco.com> <4A0D9825-181E-4687-AAE4-A27868A86C20@deployingradius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A0D9825-181E-4687-AAE4-A27868A86C20@deployingradius.com> User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [radext] working group next steps X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:01:55 -0000 On Tue, Sep 05, 2017 at 03:30:13PM -0400, Alan DeKok wrote: > On Sep 5, 2017, at 2:29 AM, Enke Chen wrote: > > In the WG meeting minutes of IETF99, it says that: > > > > > It is proposed to push forward the > > > draft-chen-radext-identifier-attr. This will be discussed on the > > > mailing list. > > > > > It has been decided to finish the ongoing work, including the > > > non-WG document on Extended ID and then close the WG. > > > > Can we request WG adoption of draft-chen-radext-identifier-attr as > > an ongoing work item? > > I still prefer my draft. But I would like to see *some* discussion > of the subject. > > some comments: > > - the identifier should just be a 32-bit number. There's no need to > reserve 2 bits for the "status" field. > > - the draft offers little guidance to implementors, and has minimal > discussion of the compatibility of this proposal with "standard" > RADIUS. > > If the WG does decide to use extended-attars, I would suggest > merging that document with the additional text from my proposal. > Only minor edits should be necessary. Hi, new to the list here - I work at F5, maintaining support for RADIUS (and other protocols) in BIG-IP. Neither of these proposals seem to clash with the RADIUS proxy which I maintain, because we don't try to correlate request/response messages. I like the DeKok draft a lot, particularly because it doesn't add any overhead to most packets. However, if we were to add a request/response pairing feature, an explicit ID as in Chen's draft would be easier for me to implement cleanly. I suspect that I'm not alone in this. -- astrid smith ------------------- --<[ c y b e r | s o f t w a r e | e n g i n e e r ]>-- ------------ ------------------ From nobody Tue Sep 5 13:24:41 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00100132709 for ; Tue, 5 Sep 2017 13:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wrOyzf-zJSC for ; Tue, 5 Sep 2017 13:24:32 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774A2128D0D for ; Tue, 5 Sep 2017 13:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2054; q=dns/txt; s=iport; t=1504643072; x=1505852672; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=aej4WVjF/tnwA9btGhDSirGrMNfldiCT01pT8sgJCiQ=; b=DG+ge1ey+uuNlIS7fHdGWzjJq9fE7DiyXYkC98ZGza6lZl3O5MvVX2zI TRMm+igsiSmykC1kR/Y91zwmWz5j9w6BArpfKCmcQYv6kuYmtZuRhVbHT ZAlcy2zJiiKy+QZOlDKV1QlEhYHQ+0UIqaMhXmOHCu7KLtHeep/yuDuJV k=; X-IronPort-AV: E=Sophos;i="5.41,481,1498521600"; d="scan'208";a="479919646" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Sep 2017 20:24:32 +0000 Received: from [10.24.50.19] ([10.24.50.19]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v85KOVpB030235; Tue, 5 Sep 2017 20:24:31 GMT To: Alan DeKok References: <2fe1f171-50a7-1058-83e2-d381263f1d3c@cisco.com> <4A0D9825-181E-4687-AAE4-A27868A86C20@deployingradius.com> Cc: Winter Stefan , "radext@ietf.org" , Naiming Shen , Enke Chen From: Enke Chen Message-ID: <0031d4a4-df00-eb69-ca4e-244cfd334d1b@cisco.com> Date: Tue, 5 Sep 2017 13:24:30 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <4A0D9825-181E-4687-AAE4-A27868A86C20@deployingradius.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [radext] working group next steps X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 20:24:34 -0000 Hi, Alan: On 9/5/17 12:30 PM, Alan DeKok wrote: > On Sep 5, 2017, at 2:29 AM, Enke Chen wrote: >> In the WG meeting minutes of IETF99, it says that: >> >> It is proposed to push forward the draft-chen-radext-identifier-attr. This will >> be discussed on the mailing list. >> >> It has been decided to finish the ongoing work, including the non-WG document on >> Extended ID and then close the WG. >> >> Can we request WG adoption of draft-chen-radext-identifier-attr as an ongoing >> work item? > > I still prefer my draft. But I would like to see *some* discussion of the subject. > > some comments: > > - the identifier should just be a 32-bit number. There's no need to reserve 2 bits for the "status" field. Are you saying that the "status" field is not needed, or it should be a separate field? If the former, as stated in the draft: ... where the 2-bit Status field is to be used in a Status-Server message to discover the support for the Extended Identifier feature. : If the latter, I think that is just personal preference in encoding. In this case we need 2 bits, and there are enough bits in the 4-byte field. > > - the draft offers little guidance to implementors, and has minimal discussion of > the compatibility of this proposal with "standard" RADIUS. Could be be more specific about which part of the draft is not clear for implementation? On backward compatibility, the proposal is completely compatible as it follows the well-established practice of using the "Status-Server" message for discovery. If it is desired, sure we can add minimal discussion. > > If the WG does decide to use extended-attars, I would suggest merging that document > with the additional text from my proposal. Only minor edits should be necessary. > Sure, we can work together on these minor edits. Actually I proposed to collaborate several months ago, and never received a reply from you. Shall we work together offline? Thanks. -- Enke From nobody Tue Sep 5 14:14:17 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65129132E1E for ; Tue, 5 Sep 2017 14:14:15 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1h_Qs98DX3Sr for ; Tue, 5 Sep 2017 14:14:13 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 62BA5126B6E for ; Tue, 5 Sep 2017 14:14:13 -0700 (PDT) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 22B83194; Tue, 5 Sep 2017 21:14:12 +0000 (UTC) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <0031d4a4-df00-eb69-ca4e-244cfd334d1b@cisco.com> Date: Tue, 5 Sep 2017 17:14:10 -0400 Cc: Winter Stefan , "radext@ietf.org" , Naiming Shen Content-Transfer-Encoding: quoted-printable Message-Id: <176C204A-FFE2-4B45-8345-FE5B4EC147F4@deployingradius.com> References: <2fe1f171-50a7-1058-83e2-d381263f1d3c@cisco.com> <4A0D9825-181E-4687-AAE4-A27868A86C20@deployingradius.com> <0031d4a4-df00-eb69-ca4e-244cfd334d1b@cisco.com> To: Enke Chen X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] working group next steps X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 21:14:15 -0000 On Sep 5, 2017, at 4:24 PM, Enke Chen wrote: > Are you saying that the "status" field is not needed, or it should be = a separate field?=20 I'm saying the field isn't needed. > If the former, as stated in the draft: >=20 > ... where the 2-bit Status field is to be used in a Status-Server = message > to discover the support for the Extended Identifier feature. : If the extended-identifier attribute exists in a Status-Server = message, it's an indication that the client supports the attribute. If = the attribute exists in a reply to Status-Server, it indicates that the = server supports the attribute. > If the latter, I think that is just personal preference in encoding. > In this case we need 2 bits, and there are enough bits in the 4-byte = field. I'm saying simply the fact that it exists at all is good enough. And = RFC 6929 suggests that non-standard data fields are a bad thing. >> - the draft offers little guidance to implementors, and has minimal = discussion of >> the compatibility of this proposal with "standard" RADIUS. >=20 > Could be be more specific about which part of the draft is not clear = for implementation? Compare my draft to yours. There's a huge difference. Your draft basically says "use an extended ID". Mine goes into = details of what that means to a client, what it means to a server, how = each of them manages the data, how the change affects RADIUS proxying. i.e. it explains in detail *all* of the side effects of changing = RADIUS. > On backward compatibility, the proposal is completely compatible as it = follows > the well-established practice of using the "Status-Server" message for = discovery. > If it is desired, sure we can add minimal discussion.=20 Sure... and what happens when things go wrong? When a client sends Status-Server with extended ID, does it have to = wait for a response before sending other packets? Or can it just send = lots of packets, and add in Extended-Id later? If so, how does this all = work? One major purpose of RFCs is to guide implementors in the corner = cases. Everyone knows how to add an attribute to a packet. That's the = easy part. The hard part is ensuring that all of the corner cases are = explained. Just compare the two documents to see what's missing from your draft. = I'm not saying your draft is wrong. I'm saying that there are many = cases where an implementor will read it, implement part of it, and then = get to a point where he just doesn't know what to do... so he picks = something, and hopes for the best. Having implementation-defined behaviour is a bad idea. >> If the WG does decide to use extended-attars, I would suggest = merging that document >> with the additional text from my proposal. Only minor edits should = be necessary. >>=20 >=20 > Sure, we can work together on these minor edits. Actually I proposed = to collaborate > several months ago, and never received a reply from you. Shall we work = together offline? I did reply... I suggest waiting for the rest of the WG to make = comments before changing either draft. Alan DeKok. From nobody Tue Sep 5 14:16:54 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D77132E1E for ; Tue, 5 Sep 2017 14:16:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODavMVUdUF1H for ; Tue, 5 Sep 2017 14:16:51 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 1C9B41323B5 for ; Tue, 5 Sep 2017 14:16:51 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id s15so10698769uag.1 for ; Tue, 05 Sep 2017 14:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZCcUmDJDLWcMrdoyv8NQIiNoqxUVLHf9Qvc37G1Y6bU=; b=u9azbDpcn/phVfqBwFR+rM3FlVX2AIdve/xDg0H95pDyxjpDgnZRpzCwJPCU08c2yO C0fypagC8dSIXd0HVeR/Lr7wBFCmnS+BftsMOG2yAN6HcclieY3aSE5UVacBa55B+TVs T0se38YUN1OrlZUmN0bvwni4/KBpUvf447pPqnSAHXW81foeSLdJQpoq/f3Tkjiv/Ygr rjemruqWWQJAUZiRNYG4/xgENDl2pW/7eqRmualFtMyppTnwtcvoPPpRq+c5QJNkZ4+j RLIVr1/ufGOoi8/diS5eB9SsjoierOanIMwl7qox/4dB0REwkHAtfVOwdudmRrSaKTfB TAjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZCcUmDJDLWcMrdoyv8NQIiNoqxUVLHf9Qvc37G1Y6bU=; b=sWnFM3Lfzg0tGCd0Brv4qxaFIbE1uLPIeMcOl8x7xwtuFNtX78SiXsNmumHV1VfkeC rowGB27Y7r6a6Mqy7ye39sOcfiP5te2uyPov4zZZAbl1dh08BZ/Q2c0hMltPYKhYY6Di XzlhQ5IDTYzmp6B2jJlYuB0TgFBDiH4sCrbA6y4dyqlzhYSHkpWlPmAawIrUFyhYpd2q exKU6Em1oq8DGmU7bm8FxcYRzNypOp4HYxfvPyvat/L0618hlMJnx6KZuTiIDlSJyvA0 2DiQYvBZB6kpD+gWXWbcQ3OtKdSUyYe3kqXi1xxW9s7c6IxN6hSZ1nzgJ+FHmtxusTLU AZDw== X-Gm-Message-State: AHPjjUjw9ueFHIAGOGs3fYGey/invskeuLNsTYCsFopUmUXWSYpsoySx R6JIsAdTbiQrLA== X-Google-Smtp-Source: ADKCNb4FFoSYoDqsWM/D+anYdlKObMCAytrnBMwvsA62Ew0GPw1qHdwCjHcc2wtAxVtza/dMC5Xetw== X-Received: by 10.176.1.180 with SMTP id 49mr272360ual.159.1504646209929; Tue, 05 Sep 2017 14:16:49 -0700 (PDT) Received: from [172.22.28.28] ([74.174.236.75]) by smtp.gmail.com with ESMTPSA id j48sm374506uaa.30.2017.09.05.14.16.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Sep 2017 14:16:49 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Bernard Aboba X-Mailer: iPhone Mail (14G60) In-Reply-To: <4A0D9825-181E-4687-AAE4-A27868A86C20@deployingradius.com> Date: Tue, 5 Sep 2017 17:16:48 -0400 Cc: Enke Chen , Winter Stefan , Naiming Shen , "radext@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <2fe1f171-50a7-1058-83e2-d381263f1d3c@cisco.com> <4A0D9825-181E-4687-AAE4-A27868A86C20@deployingradius.com> To: Alan DeKok Archived-At: Subject: Re: [radext] working group next steps X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 21:16:53 -0000 I strongly prefer Alan's draft.=20 > On Sep 5, 2017, at 3:30 PM, Alan DeKok wrote: >=20 >=20 > I still prefer my draft. But I would like to see *some* discussion of th= e subject. >=20 > some comments: >=20 > - the identifier should just be a 32-bit number. There's no need to reser= ve 2 bits for the "status" field. >=20 > - the draft offers little guidance to implementors, and has minimal discus= sion of the compatibility of this proposal with "standard" RADIUS. >=20 > If the WG does decide to use extended-attars, I would suggest merging tha= t document with the additional text from my proposal. Only minor edits shou= ld be necessary. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Sep 5 14:17:21 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D6A132E31 for ; Tue, 5 Sep 2017 14:17:20 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgzMP94x2Hb7 for ; Tue, 5 Sep 2017 14:17:19 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id 114651323B5 for ; Tue, 5 Sep 2017 14:17:19 -0700 (PDT) Received: from [192.168.120.42] (23-233-24-114.cpe.pppoe.ca [23.233.24.114]) by mail.networkradius.com (Postfix) with ESMTPSA id 1B05B6B2; Tue, 5 Sep 2017 21:17:17 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: <20170905200151.GH42884@seadev21.f5.com> Date: Tue, 5 Sep 2017 17:17:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9D9D8441-40B5-4241-B2C3-43E9DAE69779@deployingradius.com> References: <2fe1f171-50a7-1058-83e2-d381263f1d3c@cisco.com> <4A0D9825-181E-4687-AAE4-A27868A86C20@deployingradius.com> <20170905200151.GH42884@seadev21.f5.com> To: Astrid Smith , radext@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [radext] working group next steps X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 21:17:20 -0000 On Sep 5, 2017, at 4:01 PM, Astrid Smith wrote: > I like the DeKok draft a lot, particularly because it doesn't add any > overhead to most packets. And a large overhead to reply packets. :( Oh well. On major benefit is that it is explicitly an hop-by-hop identifier. = And there is no way to accidentally make the identifier "leak" across = proxies. One minor drawback is that it's easy for people to read PCAP traces = and see an "extended identifier" attribute in request / reply. It's = harder for them to look at PCAP traces and somehow figure out that only = the *reply* contains an extended identifier. > However, if we were to add a request/response pairing feature, an > explicit ID as in Chen's draft would be easier for me to implement > cleanly. I suspect that I'm not alone in this. I've done both in FreeRADIUS (v4). The code difference isn't that = large. Both are about ~300 line patches. Alan DeKok. From nobody Wed Sep 6 07:14:25 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADA1132A84 for ; Wed, 6 Sep 2017 07:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdN7-W83F5UO for ; Wed, 6 Sep 2017 07:14:21 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id E2EC2132A0D for ; Wed, 6 Sep 2017 07:14:20 -0700 (PDT) Received: from [192.168.20.65] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id 9A63576E for ; Wed, 6 Sep 2017 14:14:19 +0000 (UTC) From: Alan DeKok Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 6 Sep 2017 10:14:16 -0400 To: radext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [radext] Review of draft-chen-radext-identifier-attr-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Sep 2017 14:14:24 -0000 This message reviews the document, and explains my thoughts on what = more should be in the document. In this document we propose extensions to the RADIUS protocol to address this fundamental limitation and thus allowing for more efficient and more scalable implementations. More specifically, a new attribute ("Extended Identifier Attribute")=20 nit-pick: I would just call it "Extended-Identifier", and use that name = consistently throughout the document. Once the support is confirmed, the attribute can then be used to carry the extended identifier parameter nit-pick: Same here: just call it Extended-Identifier, not "extended = identifier parameter" For brevity the extensions specified in this document are referred to as "the Extended Identifier feature" hereafter. nitpick: I would just say "supports Extended-Identifier". 2.1. The Extended Identifier Attribute Again, use the name which will be in the IANA 3. IANA Considerations A new attribute ("Extended Identifier Attribute") is defined for the RADIUS protocol. The type value [RFC3575] needs to be assigned using the assignment rules in section 10.3 of [RFC6929] IANA needs explicit instructions. "Assign a new attribute in the = "RADIUS Attribute Types" with the following information: Value TBD (assigned by IANA) Description Extended-Identifier Data Type integer Reference TBD (this specification) ... The value of the attribute has 4 octets, and consists of the following fields: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Sta| Extended Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ My $0.02 is to just make it an "integer" attribute. If it exists in = Status-Server, it is an indication that the client wants to use extended = identifiers. If it exists in a reply to a status-server, it indicates = that the server agrees to use this feature. To simplify packet processing and for consistency, the "Extended Identifier Attribute" MUST be encoded as the very first attribute in the attribute list of a RADIUS packet. If the attribute does not appear as the first one in the attribute list of a RADIUS packet, the RADIUS packet MUST be treated as invalid and the packet be discarded according to [RFC2865]. I would recommend deleting that text. The Extended-Identifier should = be an attribute like any other. Otherwise it's really extending the = RADIUS header, which can have compatibility issues. I would suggest replacing it with text saying that it's just a normal = attribute, and that implementations MUST NOT rely on it being the first = attribute in the packet. One simple reason is that implementations must walk the packet to see = if it's valid, before they do any additional processing. They can look = for Extended-Identifier at the same time as they walk the packet, so = there's really no cost in allowing it to be anywhere. Due to the hop-by-hop nature of RADIUS packet transmission between RADIUS devices, a PROXY server MUST strip the "Extended Identifier Attribute" (and reconstruct if appropriate) before sending the packet over a different session. That's my biggest worry about this proposal. If proxies don't do = that... the attribute "leaks" across proxies, and Bad Things happen. 2.2. Status-Server Considerations ... Prior to sending a RADIUS packet (other than the Status-Server request) with the "Extended Identifier Attribute", a client implementing this specification SHOULD first send a Status-Server request with the "Extended Identifier Attribute" to indicate its support for the Extended Identifier feature. That's good, but does the client have to wait for the response before = sending any other packet? I would suggest allowing it. i.e. clients can send Status-Server with = Extended-Identifier, and *immediately* also send normal RADIUS packets = without Extended-Identifier. The server can reply to normal packets the normal way. And if the = server receives Extended-Identifier (and supports it), it echoes the = attribute back in replies. This dual capability can make implementations more complex. But, it = means that they can immediately start sending packets without waiting = for negotiation to finish. 2.3. Use of the Extended Identifier Field ... The Extended Identifier is to be used together with the Identifier to identify requests and replies. The assignment of these parameters is left to implementation. I would suggest some guidelines here: - the Extended-Identifier "ID space" is per connection. i.e. tracking = and comparison of Extended-Identifiers is done *in addition to* all = existing RADIUS tracking of request / reply ID / IP / port information. = It does not *replace* any of that. - the Extended-Identifier ID is publicly visible, and therefore has no = cryptographic purpose. Implementations should likely just use a simple = incrementing counter per connection. That way minimal tracking has to = be done on the client. - How is the Extended-Identifier use in UDP, where RADIUS clients may be = behind a NAT (not really supported officially in RADIUS, but a = wide-spread use-case) (See Section 7.1 of my draft) - and what happens for TCP and dynamic discovery? (See section 7.2 / 7.3 = of my draft) - Does a client re-negotiate Extended-Identifier every time it opens a = new source port? (See section 7.4 of my draft) - who should use Extended-Identifier? Should low-load systems use it? = What are the costs for using it? =20 - what does a server do if it receives a packet with a duplicate = Extended-Identifier? (See Section 2.3 of my draft) - can client and servers be administratively configured to support = Extended-Identifier? If so, they likely don't need to do negotiation. = But what happens if the configurations don't agree? can the client send = Extended-Identifier, fail to see it in the response...and fall back to = normal RADIUS? Or should it just always do negotiation? - add Extended-Identifier as an allowed attribute in Access-Request, = Access-Reject, Accounting-Response, etc. (See Section 6 of my draft) - if the client successfully negotiates Extended-Identifier, is there a = recommendation to NOT open multiple source ports? I would suggest so... - how does this capability affect proxies? i.e. if they support = Extended-Identifier inbound, but not outbound... what happens? See RFC = 6613 Section 2.5 for issues. - a more detailed Security Considerations section would be good. My draft goes through many of these points in detail. My draft also = has a lot of text which likely shouldn't be in any published RFC, but = serves to explain to the reader why these choices were made. Once = everyone agrees on the best approach forward, those explanations can be = removed. Alan DeKok. From nobody Fri Sep 8 00:18:14 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65822133134 for ; Fri, 8 Sep 2017 00:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1xg0eqgKGdT for ; Fri, 8 Sep 2017 00:18:12 -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 329F913219A for ; Fri, 8 Sep 2017 00:18:12 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 843E343A98 for ; Fri, 8 Sep 2017 09:18:10 +0200 (CEST) To: "radext@ietf.org" From: Stefan Winter Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Message-ID: Date: Fri, 8 Sep 2017 09:18:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vJO1sjVg4vFhOdflQqTQgOll4X351kMjJ" Archived-At: Subject: [radext] Extended IDs X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 07:18:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vJO1sjVg4vFhOdflQqTQgOll4X351kMjJ Content-Type: multipart/mixed; boundary="HvkCcuA2LN5FkG4TfUuLpV6JDdfhpLAEu"; protected-headers="v1" From: Stefan Winter To: "radext@ietf.org" Message-ID: Subject: Extended IDs --HvkCcuA2LN5FkG4TfUuLpV6JDdfhpLAEu Content-Type: multipart/mixed; boundary="------------A386CABBF7CE9C7AD3603200" Content-Language: lb-LU This is a multi-part message in MIME format. --------------A386CABBF7CE9C7AD3603200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, thanks all for raising the awareness of these two drafts. I think it would be good if all remaining readers of this list who care enough now take some time to read both drafts and make up their mind on what the preferred approach is. In approx. two weeks' time I will start a call for adoption on both drafts, and hopefully there are enough responses to make the exercise meaningful. If so, the one with more votes wins. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 2, avenue de l'Universit=C3=A9 L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipie= nt's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 =09 --------------A386CABBF7CE9C7AD3603200 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----- --------------A386CABBF7CE9C7AD3603200-- --HvkCcuA2LN5FkG4TfUuLpV6JDdfhpLAEu-- --vJO1sjVg4vFhOdflQqTQgOll4X351kMjJ 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 iQIcBAEBCgAGBQJZskQyAAoJEMDeajWKOdxmZ/kP/089iL/asf7nZaoECwcpM7IV 9ktIQCPX7z/UK7EUUUOl2N9sLaMlWfjRr6kRP55nhqrIZbbFa73XF+Zk83zC+RYS TMOnbdo99MFiJQr3WmWgHgi4gBYoLPSJMOzG6MGbtyJHm7C7SXOe+DA9Uc+Mpp55 1u4qYk1ShdcdzRC0TARMzsj0++n+11nBReqXwKhhEkV5S882+qddpW+ZpyJsNjpT s0qKeKpV0zCihXdvO3SlO6CXCYCYOm3sBm/Ba3IgenMlb/l6pG06oPNX/3w0gD9t 5Fb8V7xu1xuMxfQF6W1C8IUoC9lhyq8kZucz06GG3GYRmJIwAwjdJtmoGeumuQ4g BYGDveAkYjxYd/t9P+t7w6Ci0LDpvbTbJxUmeWIS9L7KYVl0JjKOXzsf9C9dfbag WAkZAXkf9Dl4weqz4B/iWgVnOdGV8W4X1Bihwa43O68M3uyyWVjLuVs50Z4bpQwr rgewDgUU3JLsFEnUVgNfwv4DqJtI6ZYuiljuWtAtUKT96s1/kbrvXJdTNBPXNN8p NMMZjLO7aSedMAqwPfHn+Y6eRzFnlux6RVoof2v1JdxB46YPBvCEk8ryFFDLa5N0 ZXWoQAXKTfoEq7UtZTw6SSxg+lc2q3Qdvvyb099EmIVELDTM8edgAddKZro2XH+l YDw19p4L131L/dCiyRs1 =8o35 -----END PGP SIGNATURE----- --vJO1sjVg4vFhOdflQqTQgOll4X351kMjJ-- From nobody Thu Sep 14 23:16:41 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77376132D97 for ; Thu, 14 Sep 2017 13:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p4P32iWb7Ykh for ; Thu, 14 Sep 2017 13:07:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14665132C2A for ; Thu, 14 Sep 2017 13:07:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 335AEB80D6B; Thu, 14 Sep 2017 13:07:40 -0700 (PDT) To: baruch@kayote.com, dscreat@dscreat.com, david@kayote.com, dwilli@cisco.com, beckw@t-systems.com, bclaise@cisco.com, warren@kumari.net, lionel.morand@orange.com, stefan.winter@restena.lu X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: denis@ovsienko.info, radext@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170914200740.335AEB80D6B@rfc-editor.org> Date: Thu, 14 Sep 2017 13:07:40 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 14 Sep 2017 23:16:39 -0700 Subject: [radext] [Technical Errata Reported] RFC5090 (5115) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 14 Sep 2017 20:07:56 -0000 The following errata report has been submitted for RFC5090, "RADIUS Extension for Digest Authentication". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5115 -------------------------------------- Type: Technical Reported by: Denis Ovsienko Section: 3 Original Text ------------- 3.17. Digest-Domain Attribute [...] Length 3 [...] 3.18. Digest-Stale Attribute [...] Length 3 Corrected Text -------------- 3.17. Digest-Domain Attribute [...] Length >= 3 [...] 3.18. Digest-Stale Attribute [...] Length >= 3 Notes ----- Those two attributes contain string values. All other such attributes in Section 3 uniformly define Length >= 3. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5090 (draft-ietf-radext-rfc4590bis-02) -------------------------------------- Title : RADIUS Extension for Digest Authentication Publication Date : February 2008 Author(s) : B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck Category : PROPOSED STANDARD Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Fri Sep 15 06:51:38 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8209A1321DC for ; Fri, 15 Sep 2017 06:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUoYvJDWqZ1I for ; Fri, 15 Sep 2017 06:45:23 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 3E01912421A for ; Fri, 15 Sep 2017 06:45:23 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id 189so2938678wmh.1 for ; Fri, 15 Sep 2017 06:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc; bh=03VP1sXxAI8AJfOe4fx5xC745rWKe+fnRq8sNFN0QoI=; b=IfL8bDXRf62Ls0vEXVDgu9+MciMLC2dVsnxc6WWVUdewhrQNLDfS8+Pv+xuSdjvLjw x+tRt+Zkk+np/4VIqBe40qeLg41sfdeb3vRR3PBRawQDO36YdBsvBVJYI+mfjCVpvdbK L75kKXjdrO6bJQYb/74MUfPlnQOtpagDI22TM82COA3zAunyhkBGDzhNnx+XJ7FScOwR V3K83NYWpByQgelticEndWxLcp/j+PTAk2Nuc6QFcWQ903JZl47fZj96Uef9Z1+9SViK NeXBPgnIQM/aQ35o0kR6bPCJxHCoKJM8nXW9A55DSoY1n9VayMsF7uZouFQB/pvfa7PI 02gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:cc; bh=03VP1sXxAI8AJfOe4fx5xC745rWKe+fnRq8sNFN0QoI=; b=FYjvtYh4bkjmhDI/DOn7hGf3fAmWFr9dOASPdDwBUZFw9G8EyOiI43bDU24oKn/D20 PNe0AXogkDyoFcPpLYCWt3FEu2NxL0jQmyHZQUx/wiozThyvOYzxRHMRlb2S3bzwnqNG dvcVsSKSypCh2+QmQvyfZNt7tl0bHU840P2mWnek3X0zuILSDsSXBB0rwcZjJzi/KSzC xq0otHWMgGoD0VgDWuH+eFjgYDZ/QwoUmv7N0E711gsUpEykLUN0R/l/itPp1xh3lhMv FOhgqWqURcngWeEEAp3JJLkSEEbF3xXGFF0XUNDCSWn+xV5gFGvXgiEw0f1/iA4H9AWx zXcw== X-Gm-Message-State: AHPjjUgle57OAH+P9RpaI7XDH339BRfze5CBdbLA6mjrcsc061xTg2eT dZe/bjs44I0fgLbDhdYvt+e9P5oK7y50FXXJi09VEw== X-Received: by 10.28.210.204 with SMTP id j195mt3215930wmg.124.1505483121515; Fri, 15 Sep 2017 06:45:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.164.141 with HTTP; Fri, 15 Sep 2017 06:44:40 -0700 (PDT) In-Reply-To: <20170914200740.335AEB80D6B@rfc-editor.org> References: <20170914200740.335AEB80D6B@rfc-editor.org> From: Warren Kumari Date: Fri, 15 Sep 2017 09:44:40 -0400 Message-ID: Cc: baruch@kayote.com, dscreat@dscreat.com, david@kayote.com, dwilli@cisco.com, beckw@t-systems.com, Benoit Claise , lionel.morand@orange.com, Stefan Winter , denis@ovsienko.info, radext@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: X-Mailman-Approved-At: Fri, 15 Sep 2017 06:51:37 -0700 Subject: Re: [radext] [Technical Errata Reported] RFC5090 (5115) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 15 Sep 2017 13:45:29 -0000 [ - RFC Errata System (for clutter) ] Hi all, I'm not a RADIUS person, and I'd like some advice / feedback here - from my brief reading of RFC5090 (and RFC4590) and a twisty maze of references, which seemed to end at RFC 7616 is does look like Digest-Domain is indeed a (unbounded) string, and so I think that the errata is correct for at least that part. It also seems that Digest-Stale is a string, but should only be 'true' or 'false' and so should likely be >=6 (4 chars for 'true' + type + length), but I'd assume that >=3 is likely better, because otherwise someone is likely to trip over pointy parser edges (e.g if someone decided to return 'x' instead of 'true' I think that this should be a failure somewhere other than in the parser). Thoughts? W On Thu, Sep 14, 2017 at 4:07 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC5090, > "RADIUS Extension for Digest Authentication". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5115 > > -------------------------------------- > Type: Technical > Reported by: Denis Ovsienko > > Section: 3 > > Original Text > ------------- > 3.17. Digest-Domain Attribute > [...] > Length > 3 > [...] > > 3.18. Digest-Stale Attribute > [...] > Length > 3 > > > Corrected Text > -------------- > 3.17. Digest-Domain Attribute > [...] > Length > >= 3 > [...] > > 3.18. Digest-Stale Attribute > [...] > Length > >= 3 > > > Notes > ----- > Those two attributes contain string values. All other such attributes in Section 3 uniformly define Length >= 3. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5090 (draft-ietf-radext-rfc4590bis-02) > -------------------------------------- > Title : RADIUS Extension for Digest Authentication > Publication Date : February 2008 > Author(s) : B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck > Category : PROPOSED STANDARD > Source : RADIUS EXTensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sun Sep 17 22:14:36 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCFE133343 for ; Fri, 15 Sep 2017 07:52:32 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVFioJv4f2dQ for ; Fri, 15 Sep 2017 07:52:31 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id E90441331C2 for ; Fri, 15 Sep 2017 07:52:30 -0700 (PDT) Received: from [192.168.10.50] (CPEf4cc55220745-CM64777ddff610.cpe.net.cable.rogers.com [99.248.225.186]) by mail.networkradius.com (Postfix) with ESMTPSA id 86144DA; Fri, 15 Sep 2017 14:52:28 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Fri, 15 Sep 2017 10:52:26 -0400 Cc: radext@ietf.org, "lionel.morand@orange.com" , Winter Stefan , dscreat@dscreat.com, dwilli@cisco.com, baruch@kayote.com, denis@ovsienko.info, beckw@t-systems.com, Benoit Claise , david@kayote.com Content-Transfer-Encoding: quoted-printable Message-Id: <0ADDAA9A-1DFB-49E0-9F45-01668CF5F531@deployingradius.com> References: <20170914200740.335AEB80D6B@rfc-editor.org> To: Warren Kumari X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Sun, 17 Sep 2017 22:14:34 -0700 Subject: Re: [radext] [Technical Errata Reported] RFC5090 (5115) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 15 Sep 2017 14:52:32 -0000 On Sep 15, 2017, at 9:44 AM, Warren Kumari wrote: >=20 > I'm not a RADIUS person, and I'd like some advice / feedback here - > from my brief reading of RFC5090 (and RFC4590) and a twisty maze of > references, which seemed to end at RFC 7616 is does look like > Digest-Domain is indeed a (unbounded) string, and so I think that the > errata is correct for at least that part. Yes. > It also seems that Digest-Stale is a string, but should only be 'true' > or 'false' and so should likely be >=3D6 (4 chars for 'true' + type + > length), but I'd assume that >=3D3 is likely better, because otherwise > someone is likely to trip over pointy parser edges (e.g if someone > decided to return 'x' instead of 'true' I think that this should be a > failure somewhere other than in the parser). I agree. The RADIUS specs are usually fairly vague. But using "=3D=3D 3" in a = place where it everything else uses ">=3D 3" is definitely wrong. Alan DeKok. From nobody Sun Sep 17 22:14:40 2017 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204E11341DB; Fri, 15 Sep 2017 12:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5loO1p_HBKj; Fri, 15 Sep 2017 12:34:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FC1132D41; Fri, 15 Sep 2017 12:34:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D77C8B80A51; Fri, 15 Sep 2017 12:34:27 -0700 (PDT) To: denis@ovsienko.info, baruch@kayote.com, dscreat@dscreat.com, david@kayote.com, dwilli@cisco.com, beckw@t-systems.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: bclaise@cisco.com, iesg@ietf.org, radext@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170915193427.D77C8B80A51@rfc-editor.org> Date: Fri, 15 Sep 2017 12:34:27 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Sun, 17 Sep 2017 22:14:34 -0700 Subject: [radext] [Errata Verified] RFC5090 (5115) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.22 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, 15 Sep 2017 19:34:44 -0000 The following errata report has been verified for RFC5090, "RADIUS Extension for Digest Authentication". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5115 -------------------------------------- Status: Verified Type: Technical Reported by: Denis Ovsienko Date Reported: 2017-09-14 Verified by: Benoit Claise (IESG) Section: 3 Original Text ------------- 3.17. Digest-Domain Attribute [...] Length 3 [...] 3.18. Digest-Stale Attribute [...] Length 3 Corrected Text -------------- 3.17. Digest-Domain Attribute [...] Length >= 3 [...] 3.18. Digest-Stale Attribute [...] Length >= 3 Notes ----- Those two attributes contain string values. All other such attributes in Section 3 uniformly define Length >= 3. -------------------------------------- RFC5090 (draft-ietf-radext-rfc4590bis-02) -------------------------------------- Title : RADIUS Extension for Digest Authentication Publication Date : February 2008 Author(s) : B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck Category : PROPOSED STANDARD Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG