Re: [Emu] Commitment Message handling in EAP-TLS 1.3
On Sep 22, 2020, at 10:35 AM, John Mattsson wrote: > > If we are going back to an encrypted application message with 0x00, how do we > update the draft to make it clear that the commitment message is encrypted? > Several people understood that 0x00 was supposed to not be encrypted. Is > something incorrect in draft-ietf-emu-eap-tls13-10, or it there just a need > to add a note like: > > "Note that in TLS 1.3, all application data including the Commitment Message > is protected through authenticated encryption."? That seems fine to me. Section 2.5 already states that 0x00 is the plaintext, and that plaintext length != encrypted length. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
If we are going back to an encrypted application message with 0x00, how do we update the draft to make it clear that the commitment message is encrypted? Several people understood that 0x00 was supposed to not be encrypted. Is something incorrect in draft-ietf-emu-eap-tls13-10, or it there just a need to add a note like: "Note that in TLS 1.3, all application data including the Commitment Message is protected through authenticated encryption."? John -Original Message- From: Alan DeKok Date: Tuesday, 22 September 2020 at 15:17 To: Jorge Vergara Cc: John Mattsson , Mohit Sethi M , Benjamin Kaduk , EMU WG Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 On Sep 17, 2020, at 12:44 PM, Jorge Vergara wrote: > > Does anyone else have any other thoughts on this? I'm not a TLS expert but > similarly value the TLS Fatal Alerts over using close_notify. If we will be > losing alerts then I would favor switching back to 0x00. In the absence of further discussion, I would suggest staying with 0x00. I'll go poke some code. :) Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
On Sep 17, 2020, at 12:44 PM, Jorge Vergara wrote: > > Does anyone else have any other thoughts on this? I'm not a TLS expert but > similarly value the TLS Fatal Alerts over using close_notify. If we will be > losing alerts then I would favor switching back to 0x00. In the absence of further discussion, I would suggest staying with 0x00. I'll go poke some code. :) Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
Does anyone else have any other thoughts on this? I'm not a TLS expert but similarly value the TLS Fatal Alerts over using close_notify. If we will be losing alerts then I would favor switching back to 0x00. Jorge Vergara -Original Message- From: Alan DeKok Sent: Wednesday, September 2, 2020 10:33 AM To: John Mattsson Cc: John Mattsson ; Mohit Sethi M ; Jorge Vergara ; Mohit Sethi M ; Benjamin Kaduk ; EMU WG Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 On Sep 1, 2020, at 10:23 AM, John Mattsson wrote: > > 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. It's fine for EAP Success. But having two different code paths is a little surprising. > My understanding is that is would add an extra roundtrip without any clear > benefits compared to sending an encrypted 0x00 application data. That's a reason to stick with sending 0x00, then. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
On Sep 1, 2020, at 10:23 AM, John Mattsson wrote: > > 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. It's fine for EAP Success. But having two different code paths is a little surprising. > My understanding is that is would add an extra roundtrip without any clear > benefits compared to sending an encrypted 0x00 application data. That's a reason to stick with sending 0x00, then. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
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 Date: Tuesday, 1 September 2020 at 14:51 To: John Mattsson Cc: John Mattsson , Mohit Sethi M , Jorge Vergara , Mohit Sethi M , Benjamin Kaduk , EMU WG Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 On Sep 1, 2020, at 8:24 AM, John Mattsson 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 t
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
On Sep 1, 2020, at 8:24 AM, John Mattsson 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
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
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 on behalf of John Mattsson
Date: Tuesday, 1 September 2020 at 10:10
To: Mohit Sethi M , Alan DeKok
, Jorge Vergara
Cc: Mohit Sethi M , Benjamin Kaduk ,
EMU WG
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 on behalf of Mohit Sethi M
Date: Wednesday, 5 August 2020 at 11:31
To: Alan DeKok , Jorge Vergara
Cc: Mohit Sethi M , Benjamin Kaduk
, EMU WG
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 sp
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 on behalf of Mohit Sethi M Date: Wednesday, 5 August 2020 at 11:31 To: Alan DeKok , Jorge Vergara Cc: Mohit Sethi M , Benjamin Kaduk , EMU WG 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=1=bf6ddc28-bb64-4bb0-bea7-defe210b15fd=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=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 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
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://github.com/emu-wg/draft-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=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 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
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
Hi Mohit, Sorry for the slow response. On Fri, Jul 31, 2020 at 02:08:44PM +, Mohit Sethi M wrote: > Dear all, > > Thanks all for the discussion on the commitment message. > > draft-ietf-emu-eap-tls13-10 > (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows > the ticket establishment and commitment message: [snip] > > and the relevant text on commitment message: > > When an EAP server has sent its last handshake message (Finished or a >Post-Handshake), it commits to not sending any more handshake >messages by sending a Commitment Message. The Commitment Message is [reordering] > > I couldn't parse the comments about the "KeyUpdate" message. Perhaps having > the discussion over email will help me understand the issue. > I was referring to the specific promise to not send any more *handshake* messages here -- the only currently defined handshake messages that the EAP server could be sending are NewSessionTicket and KeyUpdate. (Okay, or EKTKey from draft-ietf-per-srtp-ekt-diet, but EAP is not using that at all.) I was not sure if the need was to avoid sending KeyUpdate vs. NewSessionTicket, and why the application layer needed to be concerned with it at all -- to some extent both can be handled internally by the TLS implementation. The application probably wants to get involved if it wants to resume using a session ticket, but it's permitted to just drop the tickets on the floor and never use them. >a TLS record with application data 0x00 (i.e. a TLS record with >TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and >TLSPlaintext.fragment = 0x00). Note that the length of the plaintext >is greater than the corresponding TLSPlaintext.length due to the >inclusion of TLSInnerPlaintext.type and any padding supplied by the >sender. EAP server implementations MUST set TLSPlaintext.fragment to >0x00, but EAP peer implementations MUST accept any application data >as a Commitment Message from the EAP server to not send any more >handshake messages. The Commitment Message may be sent in the same >EAP-Request as the last handshake record or in a separate EAP- >Request. Sending the Commitment Message in a separate EAP-Request >adds an additional round-trip, but may be necessary in TLS >implementations that only implement a subset of TLS 1.3. This construction feels weird to me because it's using application data to try to make a promise about the TLS layer, which is a fragile construction and could break if there are changes to the TLS implementation without corresponding changes to the application code. In general, the application will not even know when/whether the TLS implementation is going to send more messages (though it would be fairly surprising for the TLS implementation to spontaneously send stuff in the absence of other application messages). Using close_notify as we seem to be agreeing upon feels better since it's the TLS-layer mechanism for doing so and the TLS implementation is expected to do the right thing in terms of not sending more messages, once it's sent or received. -Ben ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
I think it might be a good idea to specify that the close_notify is always sent when the TLS channel is closed. I was thinking that if we really wanted a content on the EAP Response, then it be reasonable to have the client respond with a close_notify as well. -Original Message- From: Alan DeKok Sent: Tuesday, August 4, 2020 10:16 AM To: Jorge Vergara Cc: Jim Schaad ; Mohit Sethi M ; EMU WG ; Benjamin Kaduk Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 On Aug 3, 2020, at 2:23 PM, Jorge Vergara 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
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
On Aug 3, 2020, at 2:23 PM, Jorge Vergara 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
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
ACK that EAP-TLS does not need to keep the connection open. 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 Jorge -Original Message- From: Emu On Behalf Of Jim Schaad Sent: Saturday, August 1, 2020 8:23 AM To: 'Alan DeKok' Cc: 'Mohit Sethi M' ; 'EMU WG' ; 'Benjamin Kaduk' Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 -Original Message- From: Alan DeKok Sent: Saturday, August 1, 2020 6:53 AM To: Jim Schaad Cc: Mohit Sethi M ; EMU WG ; Benjamin Kaduk Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 On Jul 31, 2020, at 12:30 PM, Jim Schaad wrote: > > Ok – so this issue was raised at IETF 102. (presentation > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F102%2Fslides%2Fslides-102-emu-eap-tls-with-tls-13-00data=02%7C01%7Cjovergar%40microsoft.com%7C79f98e3e6f7f49971c4608d8362ed351%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318922028443984sdata=nExLYi6p0JNNeZ8TZsfXkRIm53%2BHuUidEhU2GrrioA4%3Dreserved=0) > > Just reading the slides is not telling me what was the problem. I think I am > going to need to hear the audio of the presentation. I have an extremely > vague memory that there was an OpenSSL problem involved here but I would not > swear to that. You might be a better description either from John Mattsson > or Jouni. IIRC it's that OpenSSL doesn't have an API to send a zero bytes of application data. I think other TLS implementations have similar limitations. Regardless of what solution is implemented, the requirement is to have a positive acknowledgement that TLS setup is finished. This step seems to be missing by default in TLS 1.3. I suspect that most uses of TLS will *always* send application data. Which makes EAP-TLS an outlier. Hence the need for hacks like "send application data as one octet of zero". [JLS] Cobwebs are slowly being shaken out of my brain. * I made an incorrect statement yesterday because I got EAP-TEAP and EAP-TLS confused. Not surprising because I only ever spent any time on EAP-TEAP . In EAP-TLS, once the handshake has been completed the tunnel does not need to be kept open. This is the opposite of the case for EAP-TEAP where the tunnel is used for application EAP data. * Based on that I agree with EKR that the close notification could be used instead of sending the one byte of application data. Sending the close notification means that the server will no longer be sending any data and thus would not send any new session tickets. 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 <(close_notify) EAP-Response/ EAP-Type=EAP-TLS > < EAP-Success Jim Alan DeKok. ___ Emu mailing list Emu@ietf.org https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7C79f98e3e6f7f49971c4608d8362ed351%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318922028448974sdata=c40nE5bUpT69CYY9qDNx7dRyVWzFRqgoKcUvgV0p9yE%3Dreserved=0 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
-Original Message- From: Alan DeKok Sent: Saturday, August 1, 2020 6:53 AM To: Jim Schaad Cc: Mohit Sethi M ; EMU WG ; Benjamin Kaduk Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3 On Jul 31, 2020, at 12:30 PM, Jim Schaad wrote: > > Ok – so this issue was raised at IETF 102. (presentation > https://www.ietf.org/proceedings/102/slides/slides-102-emu-eap-tls-with-tls-13-00) > > Just reading the slides is not telling me what was the problem. I think I am > going to need to hear the audio of the presentation. I have an extremely > vague memory that there was an OpenSSL problem involved here but I would not > swear to that. You might be a better description either from John Mattsson > or Jouni. IIRC it's that OpenSSL doesn't have an API to send a zero bytes of application data. I think other TLS implementations have similar limitations. Regardless of what solution is implemented, the requirement is to have a positive acknowledgement that TLS setup is finished. This step seems to be missing by default in TLS 1.3. I suspect that most uses of TLS will *always* send application data. Which makes EAP-TLS an outlier. Hence the need for hacks like "send application data as one octet of zero". [JLS] Cobwebs are slowly being shaken out of my brain. * I made an incorrect statement yesterday because I got EAP-TEAP and EAP-TLS confused. Not surprising because I only ever spent any time on EAP-TEAP . In EAP-TLS, once the handshake has been completed the tunnel does not need to be kept open. This is the opposite of the case for EAP-TEAP where the tunnel is used for application EAP data. * Based on that I agree with EKR that the close notification could be used instead of sending the one byte of application data. Sending the close notification means that the server will no longer be sending any data and thus would not send any new session tickets. 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 <(close_notify) EAP-Response/ EAP-Type=EAP-TLS > < EAP-Success Jim Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
On Jul 31, 2020, at 12:30 PM, Jim Schaad wrote: > > Ok – so this issue was raised at IETF 102. (presentation > https://www.ietf.org/proceedings/102/slides/slides-102-emu-eap-tls-with-tls-13-00) > > Just reading the slides is not telling me what was the problem. I think I am > going to need to hear the audio of the presentation. I have an extremely > vague memory that there was an OpenSSL problem involved here but I would not > swear to that. You might be a better description either from John Mattsson > or Jouni. IIRC it's that OpenSSL doesn't have an API to send a zero bytes of application data. I think other TLS implementations have similar limitations. Regardless of what solution is implemented, the requirement is to have a positive acknowledgement that TLS setup is finished. This step seems to be missing by default in TLS 1.3. I suspect that most uses of TLS will *always* send application data. Which makes EAP-TLS an outlier. Hence the need for hacks like "send application data as one octet of zero". Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Commitment Message handling in EAP-TLS 1.3
Ok – so this issue was raised at IETF 102. (presentation https://www.ietf.org/proceedings/102/slides/slides-102-emu-eap-tls-with-tls-13-00) Just reading the slides is not telling me what was the problem. I think I am going to need to hear the audio of the presentation. I have an extremely vague memory that there was an OpenSSL problem involved here but I would not swear to that. You might be a better description either from John Mattsson or Jouni. From: Mohit Sethi M Sent: Friday, July 31, 2020 7:09 AM To: emu@ietf.org Cc: Benjamin Kaduk ; Jim Schaad ; Eric Rescorla Subject: Commitment Message handling in EAP-TLS 1.3 Dear all, Thanks all for the discussion on the commitment message. draft-ietf-emu-eap-tls13-10 (https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows the ticket establishment and commitment message: 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 NewSessionTicket,< EAP-Success and the relevant text on commitment message: When an EAP server has sent its last handshake message (Finished or a Post-Handshake), it commits to not sending any more handshake messages by sending a Commitment Message. The Commitment Message is a TLS record with application data 0x00 (i.e. a TLS record with TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00). Note that the length of the plaintext is greater than the corresponding TLSPlaintext.length due to the inclusion of TLSInnerPlaintext.type and any padding supplied by the sender. EAP server implementations MUST set TLSPlaintext.fragment to 0x00, but EAP peer implementations MUST accept any application data as a Commitment Message from the EAP server to not send any more handshake messages. The Commitment Message may be sent in the same EAP-Request as the last handshake record or in a separate EAP- Request. Sending the Commitment Message in a separate EAP-Request adds an additional round-trip, but may be necessary in TLS implementations that only implement a subset of TLS 1.3. I couldn't parse the comments about the "KeyUpdate" message. Perhaps having the discussion over email will help me understand the issue. --Mohit ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
