Hi,
If the ability to send a descriptive TLS Fatal Alert back to the peer is a
requirement, changing to close_notify seems like a bad idea. My understanding
is that is would add an extra roundtrip without any clear benefits compared to
sending an encrypted 0x00 application data.
EAP Peer EAP 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,
<-------- Commitment Message)
EAP-Response/
EAP-Type=EAP-TLS
(TLS Certificate,
TLS CertificateVerify,
TLS Finished) -------->
<-------- EAP-Success
Figure 1: EAP-TLS mutual authentication
vs.
EAP Peer EAP 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) -------->
EAP-Request/
EAP-Type=EAP-TLS
<-------- TLS close_notify)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Success
Figure 1: EAP-TLS mutual authentication
Cheers,
John
-----Original Message-----
From: Alan DeKok <al...@deployingradius.com>
Date: Tuesday, 1 September 2020 at 14:51
To: John Mattsson <john.matts...@ericsson.com>
Cc: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>, Mohit Sethi M
<mohit.m.sethi=40ericsson....@dmarc.ietf.org>, Jorge Vergara
<jover...@microsoft.com>, Mohit Sethi M <mohit.m.se...@ericsson.com>, Benjamin
Kaduk <ka...@mit.edu>, EMU WG <emu@ietf.org>
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3
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
