Hi,
Note that close_notify (no more data) is not an exact replacement for the
Commitment Message (no more handshake data). A change from 0x00 to close_notify
invalidates Figure 6: EAP-TLS unsuccessful client authentication in the
document.
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-Request/
EAP-Type=EAP-TLS
<-------- (TLS Fatal Alert)
EAP-Response/
EAP-Type=EAP-TLS -------->
<-------- EAP-Failure
Figure 6: EAP-TLS unsuccessful client authentication
If the Commitment Message is changed to close_notify, the TLS Fatal Alert would
have to be changed to an EAP-Failure instead. The difference is that The TLS
Fatal Alert can contain information such as
bad_certificate, unsupported_certificate, certificate_revoked,
certificate_expired, certificate_unknown, illegal_parameter, unknown_ca,
access_denied, etc. while EAP-Failure must not contain any additional data.
I don't have any strong preferences but if we change to close_notify, then
Figure 6 needs to be updated.
Cheers,
John
-----Original Message-----
From: Emu <emu-boun...@ietf.org> on behalf of Mohit Sethi M
<mohit.m.sethi=40ericsson....@dmarc.ietf.org>
Date: Wednesday, 5 August 2020 at 11:31
To: Alan DeKok <al...@deployingradius.com>, Jorge Vergara
<jover...@microsoft.com>
Cc: 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
I seem to agree with the consensus around the usage of close_notify
instead of a byte of 0x00. In fact, I can't even remember the reason for
that choice anymore.
The draft is now updated in github to specify the usage of close_notify:
https://protect2.fireeye.com/v1/url?k=6a599c40-34f9328d-6a59dcdb-866132fe445e-b8526f21b1021465&q=1&e=bf6ddc28-bb64-4bb0-bea7-defe210b15fd&u=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-ietf-emu-eap-tls13
Here is the diff for your convenience:
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt&url2=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt
This edit probably still requires some sanity checking. I will wait
until we have confirmation from the different implementations before
cleaning up and publishing a new version.
--Mohit
On 8/4/20 8:15 PM, Alan DeKok wrote:
> On Aug 3, 2020, at 2:23 PM, Jorge Vergara <jover...@microsoft.com> wrote:
>> ACK that EAP-TLS does not need to keep the connection open.
> I agree. I'm happy to change the implementations to send "close
notify".
>
>> Question: should some consideration be given to consistency with other
EAP methods that do need to keep the connection open? i.e. PEAP/EAP-TTLS/TEAP
> When those methods send application data, they don't need to do
anything else.
>
> When those methods use fast reconnect, they don't send application
data. So the other EAP methods should also send "close notify" in that case.
>
> Alan DeKok.
>
> _______________________________________________
> 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
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
