Hi,
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...
Hannes wrote that the draft-ietf-emu-eap-tls13 does not work with Mbed because
it introduces a new message and requires unencrypted data. One of Hannes
suggestions for change was that:
"Use the Commitment Message as an application layer payload (encrypted as it
should be)."
This suggestion is exactly my understanding of how draft-ietf-emu-eap-tls13-10
works. At least it is exactly what I intended when I wrote the sections in
question. I don't see why anybody would get the impressions that the
application data would be unencrypted, all application data in TLS 1.3 is
encrypted.
To summarize, I don't see that there is a real motivation for late technical
change. That Hannes misunderstood the draft seems like a reason to add some
clarification text.
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.
Cheers,
John
-----Original Message-----
From: Emu <emu-boun...@ietf.org> on behalf of John Mattsson
<john.mattsson=40ericsson....@dmarc.ietf.org>
Date: Tuesday, 1 September 2020 at 10:10
To: Mohit Sethi M <mohit.m.sethi=40ericsson....@dmarc.ietf.org>, 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
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
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
