Hi,
I personally fine with writing MUST send an Error alert if the WG wants that.
This would maybe help with using close_notify as an alternate success
indication.
The most pressing question regarding alerts is if EAP-TLS can force the TLS
implementation to not use close_notify in any situation except for success.
RFC 8446 allow an TLS implementation to send close_notify after receiving
client finished. The server might send it because of an error in the client
Finished or because it wants to close the connection for any reason.
EAP-TLS Peer EAP-TLS Server
EAP-Request/
<-------- Identity
EAP-Response/
Identity (Privacy-Friendly) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
(TLS ClientHello) -------->
EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
TLS EncryptedExtensions,
TLS CertificateRequest,
TLS Certificate,
TLS CertificateVerify,
<-------- TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
Server
decides to close connection.
EAP-Request/
EAP-Type=EAP-TLS
<-------- (TLS close_notify)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Failure
I don't if this would be common or expected behavior from the server, but if
EAP-TLS cannot enforce that this to not happen, then we cannot use close_notify
as an alternate success indication, because an alternate success indication
cannot be followed by EAP-Failure.
John
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
