RFC 9427 section 4 says: The EAP peer MUST in turn check for the existence of the protected success result indication (one octet of 0x00) and cause authentication to fail if that octet is not received.
This is largely a nit, I think. But it's good to be explicit. This was found by going through the TEAP document / 9190 / 9427 , and comparing the text on resumption and protected success indication. > On Jul 29, 2023, at 7:07 PM, RFC Errata System <rfc-edi...@rfc-editor.org> > wrote: > > 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 _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
