The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3
interacts with the EAP state machine as specified in RFC 4137. It appears
to me that this under-specification is at the root of the questions about
the commitment message.
Historically, under-specification of the EAP-TLS
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.
Title : Using EAP-TLS with TLS 1.3
Authors : John Preuß Mattsson
Mohit Sethi
On Feb 2, 2021, at 11:31 AM, John Mattsson
wrote:
> Our understanding is that draft-ietf-emu-eap-tls13-13 currently has no
> possibility to progress to the RFC editor’s que. To secure a place in the RFC
> editors’ que we have submitted version -14 that addresses all the comments in
> the IESG
Hi,
Our understanding is that draft-ietf-emu-eap-tls13-13 currently has no
possibility to progress to the RFC editor’s que. To secure a place in the RFC
editors’ que we have submitted version -14 that addresses all the comments in
the IESG Discuss. -14 uses close_notify instead of a
One note on a new issue in -14:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-14#section-2.1.2
The diagram suggests that it's possible for the EAP-TLS server to separate
the "TLS Finished" messages from the "NewSessionTicket" message. There is no
guidance as to how this is done.
Joe Salowey said:
"[Joe] Based on RFC 5216 the server could fail the finished message or as
section 2.1.3 shows it could send the finish and then it can send an
Alert and result in EAP-Failure. In this case it would be possible
for an attacker to remove the Alert and send a success. Whether
Alan DeKok said:
"The way forward is to resolve open issues. Publishing the current draft
would be premature.
IMHO we are still nowhere near agreement. There are many open questions
which have not been resolved."
[BA] Agreed. The recently published draft does not resolve the open issues
or
Alan DeKok wrote:
>The diagram suggests that it's possible for the EAP-TLS server to separate the
>"TLS Finished" >messages from the "NewSessionTicket" message. There is no
>guidance as to how this is done. >After spending some time going through RFC
>8446 and OpenSSL docs / code, it's not
Hi,
Bernard Aboba wrote:
> The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3
> interacts with the EAP state machine as specified in RFC 4137
> The issue in the EAP-TLS 1.3 specification is that the interlock with these
> variables is not defined
It is definitely true
On Feb 2, 2021, at 4:42 PM, John Mattsson
wrote:
> 4. was something I thought was clear. The -13 version states that “The
> EAP-TLS server commits to not send any more handshake messages”. This was
> according to my memory exactly what was requested from the implementors.
The text is in
On Feb 2, 2021, at 4:16 PM, John Mattsson
wrote:
>
> Alan DeKok wrote:
>
>> The diagram suggests that it's possible for the EAP-TLS server to separate
>> the "TLS Finished" >messages from the "NewSessionTicket" message. There is
>> no guidance as to how this is done. >After spending some
On Tue, Feb 2, 2021 at 11:41 AM Bernard Aboba
wrote:
> Joe Salowey said:
>
> "[Joe] Based on RFC 5216 the server could fail the finished message or as
>
> section 2.1.3 shows it could send the finish and then it can send an Alert
> and result in EAP-Failure. In this case it would be possible
Alan wrote:
> wrote:
>> 4. was something I thought was clear. The -13 version states that “The
>> EAP->TLS server commits to not send any more handshake messages”. This was
>> >according to my memory exactly what was requested from the implementors.
>
> The text is in
On Tue, Feb 2, 2021 at 2:10 PM Alan DeKok wrote:
> On Feb 2, 2021, at 4:42 PM, John Mattsson 40ericsson@dmarc.ietf.org> wrote:
> > 4. was something I thought was clear. The -13 version states that “The
> EAP-TLS server commits to not send any more handshake messages”. This was
> according
The discussion largely happened in 802.11 since that was where the
vulnerability vulnerability was discovered (by Bill Arbaugh at UMD).
Documentation of the required signals was in RFC 4137, tests on the fixed
implementations were done by UMD and subsequent analysis and security
proofs were done
15 matches
Mail list logo
