On Sep 1, 2020, at 8:24 AM, John Mattsson <john.matts...@ericsson.com> wrote: > Reading up on the mail discussion more (I have been on parental leave), I > don't see any real motivation for this late technical change suggestion...
My $0.02 is that it's philosophical. EAP-TLS does authentication using TLS. Adding an extra zero byte seems weird. It's a hack to get around limitations of protocol and/or implementations. > If we change the specification to use close_notify: > > - we need to also update Figure 6 > > - do we still want to have the flexibilty that "The close_notify alert may be > sent in the same EAP-Request as the last handshake record or in a separate > EAP-Request."? The flexibility was added to be compatible with OpenSSL that > where not compatible with RFC8446. But keeping the flexibility with > close_notify allows the server to chose between an extra round-trip and the > ability to send a TLS Fatal Alert as a result of unsuccessful client > authentication. In my experience, the TLS Fatal Alert is incredibly useful. It would be very, very, bad to remove that from the spec. Doing so would mean that failed authentications get an error of "failed", instead of something descriptive. And IMHO there's a special place for people who use content-free error messages. So my priorities are: * EAP failure MUST (where possible) get an informative TLS Fatal Alert back to the peer * it would be nice to remove the "send 1 byte of 0x00" hack, as it's philosophically weird I think it would be acceptable to send 1 byte of 0x00 when an EAP failure occurred. We know that the user won't be authenticated, so we don't care about extra data stuffed into the TLS session. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
