RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 4 records.

Status: Verified (2)

RFC 8110, "Opportunistic Wireless Encryption", March 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5427
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Alexandru Lupascu
Date Reported: 2018-07-17
Verifier Name: Benjamin Kaduk
Date Verified: 2018-08-23

Section 3 says:

To add an opportunistic encryption mode of access to [IEEE802.11], it
   is necessary to perform a Diffie-Hellman key exchange during 802.11
   authentication and use the resulting pairwise secret with the 4-way
   handshake.

It should say:

To add an opportunistic encryption mode of access to [IEEE802.11], it
   is necessary to perform a Diffie-Hellman key exchange during 802.11
   association and use the resulting pairwise secret with the 4-way
   handshake.

Notes:

As stated in Section 4.4, the Diffie-Hellman key exchange is completed in the 802.11 association step and NOT in the 802.11 authentication step: "Once the client and AP have finished 802.11 association, they then complete the Diffie-Hellman key exchange ...".

Errata ID: 5951
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: David Goodall
Date Reported: 2019-12-30
Verifier Name: Barry Leiba
Date Verified: 2020-01-02

Section 4.4 Table 2 says:

HMAC-SHA-521

It should say:

HMAC-SHA-512

Status: Reported (1)

RFC 8110, "Opportunistic Wireless Encryption", March 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 6182
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Jouni Malinen
Date Reported: 2020-05-19

Section 4.2 says:

   +----------+--------+-------------------+-------------+-------------+
   |   OUI    | Suite  |   Authentication  |     Key     |     Key     |
   |          |  Type  |        Type       |  Management |  derivation |
   |          |        |                   |     Type    |     type    |
   +----------+--------+-------------------+-------------+-------------+
   | 00-0F-AC |   18   |   Opportunistic   |     This    |  [RFC5869]  |
   |          |        |      Wireless     |   document  |             |
   |          |        |     Encryption    |             |             |
   +----------+--------+-------------------+-------------+-------------+

                             Table 1: OWE AKM

It should say:

   +----------+-------+------------------+-------------+---------------+
   |   OUI    | Suite |  Authentication  |     Key     |      Key      |
   |          |  Type |       Type       |  Management |   derivation  |
   |          |       |                  |     Type    |      type     |
   +----------+-------+------------------+-------------+---------------+
   | 00-0F-AC |   18  |  Opportunistic   |     This    | [IEEE802.11], |
   |          |       |     Wireless     |   document  | 12.7.1.7.2    |
   |          |       |    Encryption    |             |               |
   +----------+-------+------------------+-------------+---------------+

                             Table 1: OWE AKM

Notes:

The combination of IEEE Std 802.11-2016 and IETF RFC 8110 leaves it
somewhat vague how the PTK is to be derived from the PMK when using OWE.

IEEE 802.11 performs PTK derivation as part of the 4-way handshake using
a KDF with following parameters: KDF-Hash-Length(K, Label, Context).

RFC 5869 defines HKDF with HKDF-Extract(salt, IKM) -> PRK,
HKDF-Expand(PRK, info, L) -> OKM. It is not clear what would be "salt"
and "info" for these functions without mapping from the IEEE 802.11
terms (e.g., those "Label" and "Context"). Such mapping is missing from
RFC 8110.

Either the additional needed details for PTK derivation would need to be
provided for the OWE AKM or the IEEE 802.11 KDF would need to be used
instead of HKDF for the PTK derivation part (while other key derivations
for OWE could continue to use HKDF since they are fully defined in the
RFC).

Since there are already deployed OWE implementations that use the IEEE
802.11 KDF for this, this errata entry is suggesting a change to address
the alternative that matches such implementations.

Status: Rejected (1)

RFC 8110, "Opportunistic Wireless Encryption", March 2017

Source of RFC: IETF - NON WORKING GROUP

Errata ID: 5980
Status: Rejected
Type: Technical
Publication Format(s) : TEXT

Reported By: Alexander Martin
Date Reported: 2020-02-12
Rejected by: John Scudder
Date Rejected: 2024-02-11

Section 4.3 says:

   This failure should be logged, and if the client abandons association
   due to the (repeated) receipt of invalid elements, notification of
   this fact should be provided to the user.

It should say:

   This failure SHOULD be logged, and if the client abandons association
   due to the (repeated) receipt of invalid elements, notification of
   this fact SHOULD be provided to the user.

Notes:

Uncapitalized "should" used instead of RFC 2119 "SHOULD".
--VERIFIER NOTES--
Use of RFC 2119 keywords is optional. The text is sufficiently clear with the lower-case “should”.

Report New Errata



Advanced Search