Found 3 records.

Status: Verified (3)

RFC 3580, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", September 2003

Note: This RFC has been updated by RFC 7268

Errata ID: 1503
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Avi Lior
Date Reported: 2008-09-12
Verifier Name: Nevil Brownlee
Date Verified: 2010-04-03

Section 3.21 says:

For IEEE 802.1X Authenticators, this attribute is used to store the
   Supplicant MAC address in ASCII format (upper case only), with octet
   values separated by a "-".  Example: "00-10-A4-23-19-C0".

It should say:

For IEEE Std 802.1X-2001 authenticators, this attribute is used to store
the Supplicant MAC address, represented as an ASCII character string in
Canonical format (see IEEE Std 802). For example, "00-10-A4-23-19-C0".

Notes:

The IETF Informational RFC needed to specify that the representation of the MAC address is in Canonical Format.

This is the case in the IEEE document 802_1x-2001 which is the corrected text provided.

I would be okay if the authors wanted to use Supplicant MAC address instead of "bridge or Access Point" in the proposed corrected text.

Errata ID: 4484
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Lowe
Date Reported: 2015-09-27
Verifier Name: Nevil Brownlee
Date Verified: 2016-03-17

Section 2.2 says:

   The purpose of this attribute is to make it possible to link together
   multiple related sessions.  While [IEEE8021X] does not act on
   aggregated ports, it is possible for a Supplicant roaming between
   Access Points to cause multiple RADIUS accounting packets to be sent
   by different Access Points.

It should say:

   The purpose of this attribute is to make it possible to link together
   multiple related sessions.  While [IEEE8021X] does not act on
   aggregated ports, it is possible for a Supplicant roaming between
   Basic Service Sets to cause multiple RADIUS accounting packets to be
   sent by the same or different Access Points.

Notes:

This was written in the context of an Access Point only offering a single Basic Service Set, predating Access Points containing multiple radios or supporting Virtual Access Points. It is not accurate today.

Errata ID: 4491
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Nick Lowe
Date Reported: 2015-10-04
Verifier Name: Nevil Brownlee
Date Verified: 2016-03-17

Section 3.20 says:

Called-Station-Id

   For IEEE 802.1X Authenticators, this attribute is used to store the
   bridge or Access Point MAC address in ASCII format (upper case only),
   with octet values separated by a "-".  Example: "00-10-A4-23-19-C0".
   In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
   Access Point MAC address, separated from the MAC address with a ":".
   Example "00-10-A4-23-19-C0:AP1".

It should say:

Called-Station-Id

   For IEEE 802.1X Authenticators, this attribute is used to store the
   bridge MAC address or IEEE 802.11 BSSID (upper case only), with octet
   values separated by a "-".  Example: "00-10-A4-23-19-C0".
   In IEEE 802.11, where the SSID is known, it SHOULD be appended to the
   BSSID, separated from the BSSID with a ":".
   Example "00-10-A4-23-19-C0:AP1".

   The Called-Station-Id MUST be UTF-8 encoded.

Notes:

The RFC was written in the context of an Access Point only offering a
single Basic Service Set, predating and not anticipating Access Points
containing multiple radios or supporting Virtual Access Points. It is
not accurate today and the RFC should originally have stated a Basic
Service Set. It was an error to not state this.

This errata, however, emphatically does not change the original
meaning or intention of the RFC. Basic Service Set was always meant.

Since 802.11 SSIDs may be UTF-8 encoded, the Called-Station-Id MUST always be treated as being UTF-8 encoded in the context of 802.1X to accommodate 802.11 where the SSID has been appended. (This inherently encodes the bridge MAC address or IEEE 802.11 BSSID as ASCII would.)

Report New Errata