Re: [Emu] Commitment Message handling in EAP-TLS 1.3

2020-08-01 Thread Jim Schaad


-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

2020-08-01 Thread Alan DeKok
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