The following errata report has been submitted for RFC9190, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7577 -------------------------------------- Type: Technical Reported by: Alan DeKok <al...@freeradius.org> Section: 2.5 Original Text ------------- 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] ... Corrected Text -------------- (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, 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. -------------------------------------- RFC9190 (draft-ietf-emu-eap-tls13-21) -------------------------------------- Title : EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3 Publication Date : February 2022 Author(s) : J. Preuß Mattsson, M. Sethi Category : PROPOSED STANDARD Source : EAP Method Update Area : Security Stream : IETF Verifying Party : IESG _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
