Re: [radext] New Version Notification for draft-henry-radext-stable-mac-identifier-00.txt
"Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com> Thu, 18 November 2021 02:34 UTC
Return-Path: <ncamwing@cisco.com>
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 B778A3A07E3 for <radext@ietfa.amsl.com>; Wed, 17 Nov 2021 18:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.596
X-Spam-Level:
X-Spam-Status: No, score=-9.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 header.b=cwLzergG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Qfnaaq92
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 pjHtImSc3K2D for <radext@ietfa.amsl.com>; Wed, 17 Nov 2021 18:34:13 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2FB03A07E1 for <radext@ietf.org>; Wed, 17 Nov 2021 18:34:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16972; q=dns/txt; s=iport; t=1637202852; x=1638412452; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6ojjPLQNC4Ur2vNUWwRhQwYtp7rU0/j9exB4emjc4Ds=; b=cwLzergGsozaWQTzWm0vTh73JI0n3kwJjY3O49SKhAB61kJip6sOUmIt 623wZnVsO8DHPTEBR1vtT2zCFfnJgMEQ2Y1P+dHuJ5HB1spadqcwZ4V9f AUdX+Ec6kdW1+hv0153HR36Rl+1h2l8vws+6IZFjELYd+WlpWUa0VLGou o=;
IronPort-PHdr: A9a23:cFe50BZPmxZH6PdsJ93+uab/LTAphN3EVzX9orIriLNLJ6Kk+ZmqfEnS/u5kg1KBW4LHo+lFhOzbv+GFOyQA7J+NvWpEfMlKUBkI2skTlhYrVciCD0CzJfX2bis8ScJFUlIt/3yyPUVPXsjkYFiHqXyp5jlUERL6ZmJI
IronPort-Data: A9a23:pOC/7K8i+UZfppZUUD8ZDrUDsHyTJUtcMsCJ2f8bNWPcYEJGY0x3z2UeWmCOP/6KamD9L4h0YNy0/RsAu5XRyNU2SVQ9qXpEQiMRo6IpJzg2wmQcns+qw0aqoHtPt63yUfGdapBrJpPgjk31aOG49CAjjf3gqofUUYYoBAggHWeIdw954f5Ts7ZRbr9A2bBVMSvU0T/Bi5W31Gue5tJBGjl8B5RvB/9YlK+aVDsw5jTSbB3Q1bPUvyF94Jk3fcldI5ZkK7S4ENJWR86bpF241nnS8xFoAdS/n/OiKgsBQ6XZOk6FjX8+t6qK20cZ4HdtlPdgcqNANy+7iB3R9zx14NNGvJmvSAEmFqbNg+8aFRJfFkmSOIUXpuSWfCHn7pz7I0ruNiGEL+9VJFs/MYAI5s52DH1As/sCJ1glZxSKge6ezL+jTu59h8IsNsDnPZ4E/HpnyFnk4VwOKXzYa7/B6dkd1zAqi4UXRbDVZtESbnxkaxGoXvGGAX9PYLpWoQtiriCXn+VklW+o
IronPort-HdrOrdr: A9a23:ScxpnqtWfVpU1Kg61xTKIjJ87skCJoAji2hC6mlwRA09TyXGraGTdaUguyMc1gx/ZJh5o6H+BEGBKUmskqKceeEqTPeftXrdyRWVxeZZnMjfKlzbamzDH4tmtZuIHJIOc+EYYWIK6PoSpTPIb+rIo+P3spxA592utUuFJDsCA8oLgmsJaXf4LqQ1fng6OXNTLuv72iMznUvZRZ1hVLXDOpBqZZmmm/T70LbdJTIWDR8u7weDyRmy7qThLhSe1hACFxtS3LYL6wH+4knEz5Tml8v+5g7X1mfV4ZgTssDm0MF/CMuFjdVQAinwizyveJ9qV9S5zXQISaCUmREXeev30k4d1vdImivsl6aO0EDQMjzboXATArnZuAWlaDXY0JHErXkBert8bMpiA2vkAgwbzY1BOGYh5RPGi3KRZimwwxgVruK4JS2D3CCP0AkfuP9WgHpFXYQEbrhN6YQZ4UNOCZ8FWDn38YY9DYBVfY3hDdttABmnhkrizyRSKR2XLwIONwbDRlJHtt2e0jBQknw8x0wExNYHlnNF8J4mUZFL6+nNL6wtzdh1P4ErRLM4AP1ETdq8C2TLTx6JOGWOIU7/HKVCP37WsZb47Lg8+envcp0Vy5k5nojHTTpjxCEPUlOrDdfL0IxA8xjLTmn4VTPxyttG75w8obH4TKqDC1zJdLnvqbrpnxwyOLyuZx+DAuMePxa4FxqaJW9g5XyIZ6Vv
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D6AADHupVh/5JdJa1QAQkdAQEBAQkBEgEFBQFAgUcGAQsBgVEjBigHgVE3MYRHg0cDhTmFDoMCA4ETjxeKY4EugSUDVAsBAQENAQFBBAEBhQQCF4JQAiU2Bw4BAgQBAQESAQEFAQEBAgEGBIEJE4VoDYZDAQEBAxIREQwBASUQAgEPAgEIGAICGQ0CAgIwFRACBA4FIoJPglYDLwGhNQGBOgKKH3qBMYEBgggBAQYEBIJRgjkYgjUJgRAqAYMNhB6EV4ItCB8cgg2BFSccgWZKNz6CYwSBMQEUgzA3gi6PUTohEAY+JgQNBwcCEgNBAlkWBysKCAIDBQwSDAoCFwYIAwsCBieRORMbgz+nfoElCoM5jReRbAUtg2yLdJdNlhWBUJ8DAj8JAhaEUQIEAgQFAg4BAQaBaA4mgVlwFWUBgj5RGQ+OIAwWFW8BAoJJil50AjYCBgEKAQEDCZARLYE6XQEB
X-IronPort-AV: E=Sophos;i="5.87,243,1631577600"; d="scan'208";a="963951078"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Nov 2021 02:34:11 +0000
Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 1AI2YBKd031844 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 18 Nov 2021 02:34:11 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 17 Nov 2021 20:34:11 -0600
Received: from xfe-aln-002.cisco.com (173.37.135.122) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 17 Nov 2021 20:34:10 -0600
Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 17 Nov 2021 20:34:10 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G1QExSEXftj9PiaXJXM7HIR2+xwPMeMwQLog5WWDmC/qSQRB2aeqTRwWXRqcaHfsNawwVxgkqV3+JKt48oMNfmNBK2WirRnl+r0JYNMa5mEEV+If41wLO9CqkzI+wbF/bDo/CU454AwwfBiTv4VsGuhIgNZTSDJkPWm+Pe9ryPw2FwiL4weHi9IHPqHxGsRiarYyqa/Jp1EvZ45ikdNmLXRmwSgVjOZYN3+SpkciIehe9Gmzm7mL5VBrYC9yTr2kYVc8TW0GMjR4J32cOt77FAQYczbft3rpDkplfdeJCNF06TU7hJbnJujNK86oNaYWBajn79bVCcJG3OEa8vi2Jw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6ojjPLQNC4Ur2vNUWwRhQwYtp7rU0/j9exB4emjc4Ds=; b=VIZwkmH+gDmXLjBdGIFPTARU24Fv0DpmLXnsPRtPhkdAXmn+aI1T6GBMdIz7queCIs+peVGFx1+tfUGypUu8yqrYbnPgSMWfWY37nMpKJX78Pb63gznR2AJDFgQUTPHjV0qxZwRL41/Jl9nVQUw9D+Ldx+7dRfbbCI5dmfxVAYRGZiWrU+Nm4Eey2cqXi+imeNTIBU87RuHBzcPQ6QmNdkZ2RId+9wPXglnOYoEhux3UVoFEZaxq8KCuLGO96NgHx5HtnQxDWUvCYv0xv76vPn+3JPN0Yo9esn1hVWhHhWn57V0r4ykNG7MXmv8NqbhdI753qss8VEE2tlEnntdkvA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6ojjPLQNC4Ur2vNUWwRhQwYtp7rU0/j9exB4emjc4Ds=; b=Qfnaaq92DB3S0lYklOkY2gupYKwydtvVI/oIahYiz6rw3i12/P/3MRVHKuNPtvSUirD2GJIcZmQb3V17iRj+uWqF1qK+G7jfpmERID/AGa3GxAGzKO+Z3YMN85sg6Wj+yuwnY6plmBwXoOB0hLUO8DGs3rph8YWgLWs9OzIiRxc=
Received: from BYAPR11MB2919.namprd11.prod.outlook.com (2603:10b6:a03:8d::21) by BYAPR11MB3398.namprd11.prod.outlook.com (2603:10b6:a03:19::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4690.26; Thu, 18 Nov 2021 02:34:09 +0000
Received: from BYAPR11MB2919.namprd11.prod.outlook.com ([fe80::3044:28c7:86ef:464f]) by BYAPR11MB2919.namprd11.prod.outlook.com ([fe80::3044:28c7:86ef:464f%7]) with mapi id 15.20.4690.027; Thu, 18 Nov 2021 02:34:09 +0000
From: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
To: Alan DeKok <aland@deployingradius.com>
CC: "radext@ietf.org" <radext@ietf.org>, "Jerome Henry (jerhenry)" <jerhenry@cisco.com>
Thread-Topic: [radext] New Version Notification for draft-henry-radext-stable-mac-identifier-00.txt
Thread-Index: AQHXvtaeheiDKBqv10uFhsI6k1hHNKv4m6mAgAE6IICADm/zAA==
Date: Thu, 18 Nov 2021 02:34:09 +0000
Message-ID: <6D6D2B78-8E60-49D3-A55D-430A568F2EA2@cisco.com>
References: <163398069468.22139.9465987158189732084@ietfa.amsl.com> <A8D6D4E6-1511-43B7-AFC0-834BB3F5E9BB@cisco.com> <800563F0-0675-4B19-8286-E03589F2B64D@deployingradius.com>
In-Reply-To: <800563F0-0675-4B19-8286-E03589F2B64D@deployingradius.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.54.21101001
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 2fa22f5e-edef-4c16-2306-08d9aa3be650
x-ms-traffictypediagnostic: BYAPR11MB3398:
x-microsoft-antispam-prvs: <BYAPR11MB3398758F44AA0B4023F43C72D69B9@BYAPR11MB3398.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: j3d/5OqZSISLxuEaTJxflD/bvdO3kUMQTbYpNzWnzZtna3FjvAAGO5CXAoQ4DQcRdt9gZuF4NlvvTpm+mMmlhJyzDJQgrfAZj5N2Mi6n+6SG2aMxPtVSTuQvINHXRz7vohTzWecYUchlpjBAKAxHtmUOhxu1wvB+au+ghEQTsb4Q5oZeEyO2XJEUByO4YuxLzBQYPXS5bhMFr+qYlFvO/1XOxhVVSwmmcoXZm7Lzx+SyawodVkFO3I+6evdlrA+sWSdJ8LKviVYBUblFo/QX0cyQtYcVzVdh+GzTMF8M+2eQwVHmGlUaCDqkdjPvqb1NjSwWgbF8oyxfMUyegNVynNONsSDM8NJ6U7nmZhroKaVgR0Te/x7qtpM4u03RYyUaM+z3AiBGSlOmm9ib7oGsBE0DvCr+9fOyi4SmLXL2HWTFs+0Ub1d8LAg+eDhVQhRZ2AXsnpVXRmLd0RzXZkSnkeWh8ohJUU/GDLV6F1fF+FRx4DZaouJA4njZkpyokzK3/4t7Dq0nfLzhWXP1UjMydZ4fm1L1UWicUWqNvVyW/1rqRSSMXaQTYQQrTdgb+cAV4R3R6TKPge9KP9EdJG3PBr5FhpkDN00ZK5tm3pYL5gRdajU5f7vsPUQpGVzV4JfLRKbKtxjLruiUhApDmh6DfcUNfrOwOtmhdv86hQcs33IYYhRIPZF2XUv68Oeol0r8R2jBKXv/dD2KRVSX6d45CYH4ZIttweSsMr54Z/ISHq9efVTdu8mXtObfbvYaTYAF
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2919.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(186003)(38100700002)(316002)(30864003)(8936002)(122000001)(86362001)(107886003)(4326008)(54906003)(71200400001)(2616005)(508600001)(36756003)(66946007)(26005)(6486002)(8676002)(6506007)(6512007)(15650500001)(66476007)(66556008)(6916009)(5660300002)(64756008)(38070700005)(2906002)(33656002)(66446008)(53546011)(76116006)(83380400001)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: RW6XlD2UZ5UobFX4j4VmLr64PM3V7BRpn0tdKiN4ZyDZ0RHjcBgEgWsFkbfZn1HYxOX7US9tq9/ds+bTKmcW5YDgNqTc9Z5rSmgSct2NvZ8eCdZUIE30n/L4gpBSe/i+HtoYK4HmMvHl7NbWTXCv6/yj3hujsrwFY4drLanqcqgoQfXfedwD+MQHQP0Wukjkj80nwIRVURsvxmJ4TFnKc9lb7AuTu7mi76NK9+qhhC9/tI0w4zwKqxIYj+8rwkFNzJBUEUWu40FzMajXXHIPksTd4JY7eMQW9yfcXm3V7H3YLUjuIcpK/NCaFhNTRniBsPzzcfiX14YlKa0fun6DZfwkpD81yHA15FHxt4uG0ssnq2PDafntRXbB+RgvnXOWut2KJUA77IBTJlOH7kO9Ho7PZxiaB0nYyQMzFvYT3ilVvdTPypbbHiGgd2oMYUErcgAOvd3JRtOgkRlISiFF001Gt3mDf0prLuJt74KoMMJ0dIjfQaZBymRGeNDryZNWLI+UEyqlCOxPvNfvgfPUy5No76HLD5NhRb4gw5r4bFQzyUDDbqn4YnDSOWqENdMFrPmA3rcQTc9VBCJnzmw0hDoXJu5MxkPh1yT0dbN5fTF/Rrcv9Z+JoHImtds6PVRWbmTbBQ5diunn6GExSYc+MSTAPh/ZsyJUqi2AsTyRWW/B7lS93Rvf+EgBfbU7UmkdptWuKWE3FsjlaiajGb0SGt7UcA+5JmRRYjAE4xWm32/WKVpOZ3IxK8Kj3A4t61T16xnnOhhzdwDLaNu0DfrbahERM+gquvP+yOr9/wutA5T8GqOWWQQGqfqFrU2Z1ibpJeXT5I9EitDZPJvR7dLLWARNzX9+swWq+j5hPl1eBiGuo+ogxpltdFMGhdtJFjk3ePT+2lc2TW2DfkeB/dD1bgoaMKx7U7+KV0RdQWM7xh4rOA36OQBji6cbPbM3iHTw9QD9BXbavZ6jYHvsE8Cq8Tx339lyVqdfwCy9Kyun65yQbKHmkdg6lEdKa2bIAhRMbnS1pRjtUeKNFM9jNiocBx276PraCwd41BPk7zWv+a0Ab53TFSRqmAEDavOm3U6wbQ7AGntTR7l1JIASCWhk7yrPJLl/pGawsqQOh6uwlFIgYVPKGh5iXSJCcI4ZesmdyPecbjnKftYi4UeSJHSi8ztWNZrPf0hO3fDuYghFfDrFLy6PPKwb+giIOyIVg25cwvG2iGoi42Q4LjvtFF9sX6uBfPNZYYmf5abe8i9SJ5MNp/amo8sdE/x5Hq9lIJx/+bvw49YDfxLZzGT83Hyq69l4EuIoYWp3F/6mKt01mnLEoyci4puC9/ZDtv8D6IiYDwcURcIrxbWLSDnOiqbPANEMhUjFsZHRsWvqXEmREvXCir4i92yYQB2XyK+pNZS2tC3d1XXdC2KBKk+2TrdBWc2sAizHwQttGtoULXHa6Cl1ukgluPlPsmPJucS4I/x1bfSijMw0JCNwPA0G/FyEua4ZOfjnAsZz1M5Uxxfh/bUsb1i1mlUkIMu0tkYilvd8Dux2uxCyb0ro7+KRopfXTS+jhN/KkJRaPHkAlpS5cNe5NGdSfZeim8eUptNe6dCBAa1ubTkJS85TANCcd7TquOYvNPYB5oyl/lXPUFaRSa0bHrytgJOvVcCINNnsYese
Content-Type: text/plain; charset="utf-8"
Content-ID: <3DDA5FF77CA4B74192C18F98D1BDC43E@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2919.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2fa22f5e-edef-4c16-2306-08d9aa3be650
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2021 02:34:09.1810 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: mk3PVt80+jWS8tTJXtX4A9O1Kfeq9BVFpOmSQ+sqOpywMXbtd/nOLweS/bHqpL0bnSUPAMuS4JJ8KpDYmy2hHQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3398
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com
X-Outbound-Node: rcdn-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/KpkNkh8u3wGVOX8p3i3l57jUmmI>
Subject: Re: [radext] New Version Notification for draft-henry-radext-stable-mac-identifier-00.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Nov 2021 02:34:18 -0000
Hi Alan, Many thanks for the thorough review and the extended thread on the draft....rather than going thru each of your feedback I can summarize by stating that we'll work to address them in a new revision. I do need to refer back to the 802.11 updates that are putting RCM to practice as I think one of the proposals I saw was to have the client signal the SMI but I can't recall whether it went inside an encrypted channel by which the AP would be able to see, if that is the case, that is something we need to improve upon in that forum too. Best, Nancy On 11/8/21, 6:08 AM, "Alan DeKok" <aland@deployingradius.com> wrote: On Nov 7, 2021, at 10:21 PM, Nancy Cam-Winget (ncamwing) <ncamwing=40cisco.com@dmarc.ietf.org> wrote: > > Hi all, > We have submitted a draft that relays a stable MAC identifier to the RADIUS server. The identifier is being defined by 802.11 as they implement MAC address rotation. > Your reviews and feedback are being solicited as we would like to see this work move forward here as well. As RADEXT is essentially dead, I think the way forward is to submit the draft to OPSAWG. I'll support it there. I have some comments on initially reading the document. Mostly clarifications, and asking for more details. Over all, I think this work should go forward with some rework. Section 2: The attributes in this document are intended to be applicable across a wide variety of network access scenarios in which RADIUS is involved: * In some cases, ... It appears that the "*" was intended to be a separate bullet item? The client may then have not provided a stable machine identifier (SMI) to the RADIUS server, for example because the 802.1X/EAP process authenticated the user. I'm not sure how 802.1X/EAP authentication causes the identifiers to be unstable. The two things would seem to be completely independent. * There are cases where the client may express a machine identity to the RADIUS server during the authentication phase, and that the RADIUS server interprets as stable, but may not express a stable machine identifier to the NAS. The client's interaction with the RADIUS server is mediated by the NAS. So there's not many ways that a client can "express" an identity to the RADIUS server without the NAS also seeing that information. Hopefully this is explained later in the document. And nit: "express" doesn't seem correct here, despite being used throughout the document. Perhaps "inform" would be a better choice. The client doesn't express an opinion, for example. It informs the RADIUS server of something. Section 2.1: In this scenario, the client initially joins the network in a constrained state and proceeds through the 802.1X/EAP authentication phase. Nit: If the client hasn't authenticated, then it hasn't "joined" the network. And the use of "constrained state" here does follow typical terminology. ... This characteristic is visible to the NAS (in the client source address) a Nit "characteristic" here seems unnecessarily complex. Perhaps just "information" again. ... The RADIUS validates the user identity (but not a stable machine identity). Perhaps: The RADIUS validates the user identity, but cannot validate the machine identity, as no stable identifier is available at this point. 2.1.1. General Use Cases ... It would be worth noting that the RCM MAC address MUST NOT change when the device uses session resumption for EAP. If the MAC changes, then it looks like the resumption data has been sent to a different device, which would be a security breach. In addition, if the RCM MAC address does change, then the device MUST re-authenticate from scratch, and not use any cached session resumption information. ... If the wireless infrastructure (NAS) receives a stable machine identifier information from the client, after authentication with the client first MAC address, then the NAS SHOULD share this identifier with the RADIUS server. Nit: perhaps add "via the following process" Thus, after the NAS has received a stable identifier representation from the client machine, the NAS SHOULD send a new access-request message to the RADIUS server. Containing... what? There's clearly more than just a SMI attribute in the packet. The Calling-Station-ID is the current RCM MAC address. If the STA is requesting the SMI, the SMI payload SHOULD set to Null. There is no concept of "Null" in RADIUS. RFC 2865 says that zero-length attribute MUST NOT be sent. Perhaps instead say "the 48-bit value of all zeros is special, and indicates that the client is requesting a SMI. And remove all references to "Null" in the document. The RADIUS server supporting the SMI attribute considers the authentication as already validated and SHOULD returns an Access- Accept message. Again: how? What's in the Access-Request packet? If the NAS request had the SMI AVP set to Null and the RADIUS server did not uniquely identify the client machine, then the RADIUS server SHOULD return an Access-Accept message with the SMI AVP set to the Null value. The NAS then generates a local SMI for the client, and sends it to the client machine over a protected frame on one hand, and to the RADIUS server as above on the other hand. Lots of questions here... how does the RADIUS server uniquely identify the client machine? How does the NAS send the SMI to the RADIUS server? The rest of this section gives a very high level overview of what happens. I have similar comments as above: the requirements are high level, and vague. 2.1.2. Special scenarios ... In cases 2 and 3, when the client changes its MAC address and the infrastructure immediately recognizes the new MAC address as representing the same machine as before, no client MAC address change occurs from the perspective of the other infrastructure systems. Except that the MAC address is seen in the RADIUS accounting packets? ... It is only when a new stable machine identifier is expressed between the NAS the other infrastructure elements that a new SMI exchange is needed between the NAS and the RADIUS server. It's not clear why the Stable Machine Identifier would change? If it's changing, why is it "stable"? If it's stable, why is it changing? I have similar comments about the RADIUS exchanges as above. 2.1.3. Failure Handling ... The RADIUS server not supporting the SMI is unable to process the request and SHOULD respond with an Access-Reject, a NACK, or SHOULD NOT respond. Which one is it? And it's very bad to suggest that the RADIUS server should not respond to a packet. Very, very, very, bad. Additionally, the RADIUS server may detect an anomaly in the SMI (format error, duplication, suspicion of impersonation or other malicious detection). How is this done? Especially because the SMI can change. So is the change allowed, or is it impersonation? The RADIUS server may then return to the NAS a warning in the form of a VSA, thus causing the NAS to reject or contain the offender. Details, please. This suggestion seems very much outside of the traditional way of doing things. 2.2. Stable RADIUS machine identifier Some methods use RADIUS to authenticate the client machine itself, irrespective of the user authentication. Some methods of... what? RADIUS just carries authentication information. It has no concept of machines versus users. So the description here needs more explanation to describe precisely what is being discussed. In that case, the RADIUS server receives a stable identifier for the machine, even when the MAC address and the associated Calling Station-Id are changing. A stable identifier in the form of... what? Details, please. 3. Stable-Machine-Identifier ... Nit: suggest a minimum length, and a maximum length. 48 bits is likely too small. 256 bits is enough to uniquely identify every atom on the planet. 5. Security & Privacy Considerations It is strongly recommended that the SMI format used is such that neither the machine globally unique MAC address nor the machine user identity are revealed. Are there suggestions for how this is to be done? ... Furthermore, where a reference is used to the machine globally unique MAC address or to the machine user identity, it is recommended that the binding lifetime of that reference be kept as short as possible. I'm unclear on what that means. What is a "reference" to a MAC address? The rest of the document doesn't mention references to MAC addresses. Attempting theft of service, a man-in-the-middle may try to insert, modify, or remove the SMI in the Access-Accept packets and Accounting packets. However, RADIUS Access-Accept and Accounting packets already provide integrity protection. This is true of all RADIUS packets, no matter their content. It's not clear why this needs to be called out specifically for SMI. If the NAS includes SMI in an Access-Request packet, a man-in-the- middle may remove it. This will cause the issues that the SMI was designed to solve. To prevent such an attack, the NAS SHOULD include a Message-Authenticator(80) attribute within Access-Request packets containing a SMI attribute. RFC 5080 Section 2.2.2 already says: Client implementations SHOULD include a Message-Authenticator attribute in every Access-Request to further help mitigate this issue. It would be worth referring to previous standards, and re-iterating their security requirements. There isn't much need to repeat a lot of previous text about how bad RADIUS security is. The Security Considerations section here should also discuss security issues with the SMI, how it's used etc. See comment below for some discussion on this topic. Summary: The document discusses high level concepts, and is vague on details. We need SMI, but the current text isn't clear enough for me to implement anything. I don't think the SMI negotiation belongs in an Access-Request exchange. I'm not sure how that would work. The details are very high level. It's not clear how this would work with proxies. There are many open questions. It would be simple to just do the following: * if the device doesn't have an SMI, it creates one. Perhaps a 128-bit random identifier would be sufficient to avoid collisions * the device then informs the NAS as to what the SMI is. * the NAS puts the SMI into RADIUS Accounting-Request packets for a particular session * the RADIUS server sees the SMI, and correlates it with the RCM MAC * if the SMI is available during the original authentication, the client device informs the NAS, and the NAS places the SMI into the Access-Request packets. There's little need to involve the RADIUS server in the SMI allocation / assignment. If the RADIUS server can't already identify the device, then there's no reason for the RADIUS server to assign an SMI. The client device might as well do that. In addition, it would be useful for the device to have a different SMI for each realm it is authenticating to. i.e. when authenticating as "user@example.com", it would send SMI 1234. When authenticating as "bob@example.org", it would send SMI 5678. This process would ensure that organizations could not cooperate to remove device identity. And it means that leaks of user/device databases would not permit attackers use the SMI for correlating users across multiple organizations.
- [radext] FW: New Version Notification for draft-h… Nancy Cam-Winget (ncamwing)
- Re: [radext] New Version Notification for draft-h… Alan DeKok
- Re: [radext] New Version Notification for draft-h… Bernard Aboba
- Re: [radext] New Version Notification for draft-h… Alan DeKok
- Re: [radext] FW: New Version Notification for dra… Benjamin Kaduk
- Re: [radext] New Version Notification for draft-h… lionel.morand
- Re: [radext] FW: New Version Notification for dra… Jerome Henry (jerhenry)
- Re: [radext] New Version Notification for draft-h… Jerome Henry (jerhenry)
- Re: [radext] New Version Notification for draft-h… Alan DeKok
- Re: [radext] FW: New Version Notification for dra… Nancy Cam-Winget (ncamwing)
- Re: [radext] New Version Notification for draft-h… Nancy Cam-Winget (ncamwing)
- Re: [radext] New Version Notification for draft-h… Nancy Cam-Winget (ncamwing)
- Re: [radext] FW: New Version Notification for dra… Bernard Aboba