RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Reported (2)

RFC 9190, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3", February 2022

Source of RFC: emu (sec)

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

Reported By: Alan DeKok
Date Reported: 2023-07-29

Section 2.5 says:

   When an EAP-TLS server has successfully processed the TLS client
   Finished and sent its last handshake message (Finished or a post-
   handshake message), it sends an encrypted TLS record with application
   data 0x00.  The encrypted TLS record with application data 0x00 is a
   protected success result indication, as defined in [RFC3748] ...

It should say:

(append)

If the EAP-TLS peer does not see the protected success indication, it
MUST behave as if it had received an EAP Failure instead.

Notes:

This is largely a nit, but it's reasonable to say this.

The existing text discussed what the server must do, But it does not say what the
peer does if the server fails to behave this way,

Errata ID: 8094
Status: Reported
Type: Technical
Publication Format(s) : TEXT, PDF, HTML

Reported By: Eliot Lear
Date Reported: 2024-09-04

Section 2.1.1 says:

Certificates can be of any type supported by TLS including raw
public keys.

It should say:

Certificates can be of any type supported by TLS. Raw public keys may
also be used.

Notes:

A raw public key specifically is **not** a certificate.

Report New Errata



Advanced Search