Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[John Mattsson]

Then draft-dekok-emu-tls-eap-types will have to describe how TLS-based EAP 
types do or not do the commit with application data.

As far as I understand, 0x00 will work for these other EAP types as well, so 
not need to change any thing in draft-ietf-emu-eap-tls13.

Cheers,
John

-Original Message-
From: Alan DeKok 
Date: Monday, 29 July 2019 at 00:51
To: Jim Schaad 
Cc: Jouni Malinen , John Mattsson , EMU 
WG 
Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

On Jul 28, 2019, at 5:09 PM, Jim Schaad  wrote:
> 
> I cannot speak to PEAP, but it would seem that TEAP might need this 
feature
> as, at least on resumption, it is totally optional for both sides to use 
any
> TLVs an thus the same issue might be present.  TTLS seems to always 
require
> that the client send a AVP, but I am not sure that it is required for the
> server based on a really fast read.

  For initial authentication, TTLS requires TLVs inside of the TLS tunnel.  
For resumption, the inner tunnel isn't used.

  So it looks like the other TLS-based EAP methods will have the same 
issue, when resumption is used.

  Alan DeKok.



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[Alan DeKok]

On Jul 28, 2019, at 5:09 PM, Jim Schaad  wrote:
> 
> I cannot speak to PEAP, but it would seem that TEAP might need this feature
> as, at least on resumption, it is totally optional for both sides to use any
> TLVs an thus the same issue might be present.  TTLS seems to always require
> that the client send a AVP, but I am not sure that it is required for the
> server based on a really fast read.

  For initial authentication, TTLS requires TLVs inside of the TLS tunnel.  For 
resumption, the inner tunnel isn't used.

  So it looks like the other TLS-based EAP methods will have the same issue, 
when resumption is used.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[Jim Schaad]

I cannot speak to PEAP, but it would seem that TEAP might need this feature
as, at least on resumption, it is totally optional for both sides to use any
TLVs an thus the same issue might be present.  TTLS seems to always require
that the client send a AVP, but I am not sure that it is required for the
server based on a really fast read.

Jim


-Original Message-
From: Jouni Malinen  
Sent: Sunday, July 28, 2019 12:58 PM
To: John Mattsson 
Cc: Alan DeKok ; Jim Schaad
; EMU WG 
Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

On Thu, Jul 25, 2019 at 10:49:40AM +, John Mattsson wrote:
> Question: How will the use of Application data with TLSPlaintext.fragment
= 0x00 work with EAP-TTLS, PEAP, and TEAP when they start using TLS 1.3? I
assume they will need to send the same 0x00 to commit to not sending any
more handshake messages as well as using application data for other
purposes. I do not know exactly how the TLSPlaintext fragments look like in
EAP-TTLS, PEAP, and TEAP. The TLSPlaintext fragment for commit need to be
chosen so that the string does not collide with any other strings used.

I don't see why TTLS, PEAP, or TEAP would need to use this specific 0x00
indication for this since they end up using the tunnel for Phase 2 (or at
least protected result indication if Phase 2 authentication is
skipped) and that can be implicitly used for the same purpose.

EAP-TLS needs this workaround because without it, the NewSessionTicket
message changes in TLS 1.3 are quite inconvenient for EAP. With TTLS and
PEAP, it would seem fine to send out the NewSessionTicket before concluding
Phase 2. With TEAP, there is some more discussion about use of the
NewSessionTicket option for provisioning the new PAC (which seem a bit
inconvenient for some use cases IMHO, but nevertheless, I don't see this
needing any additional mechanism for indicating when the NewSessionTicket is
not going to be showing up).

-- 
Jouni MalinenPGP id EFC895FA

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[Jouni Malinen]

On Thu, Jul 25, 2019 at 10:49:40AM +, John Mattsson wrote:
> Question: How will the use of Application data with TLSPlaintext.fragment = 
> 0x00 work with EAP-TTLS, PEAP, and TEAP when they start using TLS 1.3? I 
> assume they will need to send the same 0x00 to commit to not sending any more 
> handshake messages as well as using application data for other purposes. I do 
> not know exactly how the TLSPlaintext fragments look like in EAP-TTLS, PEAP, 
> and TEAP. The TLSPlaintext fragment for commit need to be chosen so that the 
> string does not collide with any other strings used.

I don't see why TTLS, PEAP, or TEAP would need to use this specific 0x00
indication for this since they end up using the tunnel for Phase 2 (or
at least protected result indication if Phase 2 authentication is
skipped) and that can be implicitly used for the same purpose.

EAP-TLS needs this workaround because without it, the NewSessionTicket
message changes in TLS 1.3 are quite inconvenient for EAP. With TTLS and
PEAP, it would seem fine to send out the NewSessionTicket before
concluding Phase 2. With TEAP, there is some more discussion about use
of the NewSessionTicket option for provisioning the new PAC (which seem
a bit inconvenient for some use cases IMHO, but nevertheless, I don't
see this needing any additional mechanism for indicating when the
NewSessionTicket is not going to be showing up).

-- 
Jouni MalinenPGP id EFC895FA

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[John Mattsson]

I made a few smaller changes, added a figure, and committed to GitHub. 

A diff can be found here:

http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13-05.txt=https://raw.githubusercontent.com/emu-wg/draft-ietf-emu-eap-tls13/master/draft-ietf-emu-eap-tls13.txt

The GitHub commit can be found here:

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/b6529d49b129a0796715ab320df18003ceb4a964#diff-f0254f10e4339e650834528e3c398a26

Question: How will the use of Application data with TLSPlaintext.fragment = 
0x00 work with EAP-TTLS, PEAP, and TEAP when they start using TLS 1.3? I assume 
they will need to send the same 0x00 to commit to not sending any more 
handshake messages as well as using application data for other purposes. I do 
not know exactly how the TLSPlaintext fragments look like in EAP-TTLS, PEAP, 
and TEAP. The TLSPlaintext fragment for commit need to be chosen so that the 
string does not collide with any other strings used.

Cheers,
John

-Original Message-
From: John Mattsson 
Date: Wednesday, 24 July 2019 at 20:49
To: Alan DeKok , Jouni Malinen , Jim 
Schaad 
Cc: EMU WG 
Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

Hi,

Based on the discussion on the list and at the meeting today I suggest the 
following changes to Section 2.1, 2.5, and figures. When we agree I will make a 
commit to GitHub and submit a new version of the draft.

With the solution suggested by Jim, there should be no need to force 
NewSessionTicket. Do we need a figure to illustrate the "or in a separate 
EAP-Request" part of " The TLS record with application data may be sent in the 
same EAP-Request as the last handshake record or in a separate EAP-Request."

Cheers,
John

Section 2.1:
---

OLD
   The EAP server commits to not send any more handshake messages by
   sending an empty TLS record, see Section 2.5.


NEW
   The EAP server commits to not send any more handshake messages by
   sending a TLS record with the application data 0x00, see Section 2.5.


Section 2.5 EAP State Machines
---

OLD
   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 appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type = application_data and
   TLSPlaintext.length = 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

NEW
   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 TLS record with application data 0x00 (i.e. a
   TLS record with TLSPlaintext.type = application_data,
   TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00).  EAP
   server implementations MUST set TLSPlaintext.fragment to 0x00, but
   EAP peer implementations MUST accept any application data as a commit
   from the EAP server to not send any more handshake messages.  The TLS
   record with application data may be sent in the same EAP-Request as
   the last handshake record or in a separate EAP-Request.  After
   sending the application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

Figures:
---

OLD
 <  TLS empty record)

NEW
 <  TLS Application Data)
 



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[John Mattsson]

Hi,

Based on the discussion on the list and at the meeting today I suggest the 
following changes to Section 2.1, 2.5, and figures. When we agree I will make a 
commit to GitHub and submit a new version of the draft.

With the solution suggested by Jim, there should be no need to force 
NewSessionTicket. Do we need a figure to illustrate the "or in a separate 
EAP-Request" part of " The TLS record with application data may be sent in the 
same EAP-Request as the last handshake record or in a separate EAP-Request."

Cheers,
John

Section 2.1:
---

OLD
   The EAP server commits to not send any more handshake messages by
   sending an empty TLS record, see Section 2.5.


NEW
   The EAP server commits to not send any more handshake messages by
   sending a TLS record with the application data 0x00, see Section 2.5.


Section 2.5 EAP State Machines
---

OLD
   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 appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type = application_data and
   TLSPlaintext.length = 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

NEW
   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 TLS record with application data 0x00 (i.e. a
   TLS record with TLSPlaintext.type = application_data,
   TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00).  EAP
   server implementations MUST set TLSPlaintext.fragment to 0x00, but
   EAP peer implementations MUST accept any application data as a commit
   from the EAP server to not send any more handshake messages.  The TLS
   record with application data may be sent in the same EAP-Request as
   the last handshake record or in a separate EAP-Request.  After
   sending the application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

Figures:
---

OLD
 <  TLS empty record)

NEW
 <  TLS Application Data)
 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[Alan DeKok]

On Jul 13, 2019, at 4:21 PM, Jouni Malinen  wrote:
> I'm not sure how I'd feel about EAP-TLS extension that uses actual
> application data when we have EAP-TEAP available for cases that need
> additional data to be exchanged in the tunnel.

  Sure.

> Anyway, this combination
> of server sending one octet (0x00) and peer decrypting the application
> data but ignoring its length and contents is what I ended up
> implementing now. This seems to work fine for the case where
> NewSessionTicket message(s) are used.

  That makes sense.

> I did see some issues when OpenSSL 1.1.1 when disabling sending of
> session tickets, though. The current draft indicates that the empty
> Application Data payload would be send out in the same EAP packet with
> the server's Finished message, i.e., before the server having
> authenticated the peer. And this would be done without the peer having
> used TLS early data (which is explicitly disallowed in the draft). That
> combination did not work with my experiments since OpenSSL was rejecting
> the SSL_write() operation after the server having written own Finished
> message, but before having received the Finished message from the peer.
> The OpenSSL documentation seemed to imply that SSL_write_early_data()
> could be used by the server _if_ the client first sent early data.. At
> least in my tests, OpenSSL rejected that call without early data from
> the client.

  Yes, that's what I've seen, too.

> I may have missed some other part of the OpenSSL API where the server
> could have sent out the Application Data message to the unauthenticated
> peer (if someone knows how to do that, please do let me know), but
> regardless, this design of the EAP-TLS v1.3 server depending on a
> mechanism that need actual application data (even if empty or known one
> octet value) to be sent before having completed authentication of the
> TLS client feels like something that can result in implementation
> complexities with various TLS libraries. Forcing a new session ticket to
> be sent out is a way to work around this, but I'm not sure I'd call this
> ideal.

  I think that's the only practical solution.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[Jouni Malinen]

On Sat, Jul 13, 2019 at 08:59:04AM +0200, Alan DeKok wrote:
> On Jul 12, 2019, at 11:08 PM, Jouni Malinen  wrote:
> > It would seem to make sense to me to allow the EAP-TLS 1.3 server to
> > send out either an empty plaintext or a one octet plaintext to avoid
> > this issue in a straightforward manner.
> 
>   We may also want to later perform additional signalling at that phase of 
> the authentication.  As such, it may be good to say:
> 
> * a one octet plaintext of 0x00 should be sent
> * on reception, any data received should be ignored
>   * non-zero octets, or more than one octet MAY indicate future extensions

I'm not sure how I'd feel about EAP-TLS extension that uses actual
application data when we have EAP-TEAP available for cases that need
additional data to be exchanged in the tunnel. Anyway, this combination
of server sending one octet (0x00) and peer decrypting the application
data but ignoring its length and contents is what I ended up
implementing now. This seems to work fine for the case where
NewSessionTicket message(s) are used.

I did see some issues when OpenSSL 1.1.1 when disabling sending of
session tickets, though. The current draft indicates that the empty
Application Data payload would be send out in the same EAP packet with
the server's Finished message, i.e., before the server having
authenticated the peer. And this would be done without the peer having
used TLS early data (which is explicitly disallowed in the draft). That
combination did not work with my experiments since OpenSSL was rejecting
the SSL_write() operation after the server having written own Finished
message, but before having received the Finished message from the peer.
The OpenSSL documentation seemed to imply that SSL_write_early_data()
could be used by the server _if_ the client first sent early data.. At
least in my tests, OpenSSL rejected that call without early data from
the client.

I may have missed some other part of the OpenSSL API where the server
could have sent out the Application Data message to the unauthenticated
peer (if someone knows how to do that, please do let me know), but
regardless, this design of the EAP-TLS v1.3 server depending on a
mechanism that need actual application data (even if empty or known one
octet value) to be sent before having completed authentication of the
TLS client feels like something that can result in implementation
complexities with various TLS libraries. Forcing a new session ticket to
be sent out is a way to work around this, but I'm not sure I'd call this
ideal.

-- 
Jouni MalinenPGP id EFC895FA

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[Alan DeKok]

On Jul 12, 2019, at 11:08 PM, Jouni Malinen  wrote:
> In other words, there does not seem to be any convenient way of
> implementing this with the current version of one of the most commonly
> used TLS libraries. I can make this work by sending out a one-octet
> (0x00) TLSPlaintext as a workaround, but it does not look like I could
> make the implementation comply with the draft without changing the TLS
> library which is close to a complete showstopper for quick deployment.

  I agree.

> It would seem to make sense to me to allow the EAP-TLS 1.3 server to
> send out either an empty plaintext or a one octet plaintext to avoid
> this issue in a straightforward manner.

  We may also want to later perform additional signalling at that phase of the 
authentication.  As such, it may be good to say:

* a one octet plaintext of 0x00 should be sent
* on reception, any data received should be ignored
  * non-zero octets, or more than one octet MAY indicate future extensions

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[Jouni Malinen]

On Wed, Jun 26, 2019 at 09:16:19PM -0700, Joseph Salowey wrote:
> The Working Group last call has completed with no comments for
> draft-ietf-emu-eap-tls13-05.  I would like to confirm that some working
> group members have reviewed the draft.  If you have reviewed the draft
> please respond to this thread.

While the current design may work in theory, the use of an "empty TLS
record" looks problematic from implementation and deployment view point.
That terms itself is quite a bit confusing term since this is not really
talking about an empty TLS record in the EAP-TLS message, but about a
zero length TLSPlaintext structure that gets encrypted into a _non_-zero
length TLSCiphertext structure that gets encoded in the TLS record that
goes over EAP-TLS (and that is not empty since all ciphers add something
to the payload length in practice).

The main problem here is that at least OpenSSL is not willing to send
such an empty TLSPlaintext structure. SSL_write() has following to say
about this:
https://www.openssl.org/docs/man1.1.1/man3/SSL_write.html
"You should not call SSL_write() with num=0, it will return an error.
SSL_write_ex() can be called with num=0, but will not send application
data to the peer."

In other words, there does not seem to be any convenient way of
implementing this with the current version of one of the most commonly
used TLS libraries. I can make this work by sending out a one-octet
(0x00) TLSPlaintext as a workaround, but it does not look like I could
make the implementation comply with the draft without changing the TLS
library which is close to a complete showstopper for quick deployment.

It would seem to make sense to me to allow the EAP-TLS 1.3 server to
send out either an empty plaintext or a one octet plaintext to avoid
this issue in a straightforward manner.

This is referring to the following areas in the draft (-05):

2.1.1.

   In the case where EAP-TLS with mutual authentication is successful,
   the conversation will appear as shown in Figure 1.  The EAP server
   commits to not send any more handshake messages by sending an empty
   TLS record, see Section 2.5.

(that confusing use of "empty TLS record" and "TLS empty record" in the
message exchange figures)


2.5.
   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 appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type = application_data and
   TLSPlaintext.length = 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

(this is where that TLSPlaintext.length = 0 should also allow 1 to make
this easier to implement and deploy)

-- 
Jouni MalinenPGP id EFC895FA

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

[Mohit Sethi M]

There have been several reviews of different aspects of this draft in the past:

Jim provided a complete review here: 
https://mailarchive.ietf.org/arch/msg/emu/ZDwpgyOL5eBPgyOGwXqxj1VhX-4

A discussion about the L-bit and fragmentation here: 
https://mailarchive.ietf.org/arch/msg/emu/ZexFr7GROnvNOjN6gGESoO9H0dk

Fairly long discussion on session resumption here: 
https://mailarchive.ietf.org/arch/msg/emu/LgGAtWVLZsiog13OZRVIFbOZqv4

Implementation report here: 
https://mailarchive.ietf.org/arch/msg/emu/fTnE46aKnAxhfx38Od-7carTKjI

It would still help the chairs and the document shepherd if folks on the list 
can be a little more proactive and provide comments/feedback on working group 
documents. If you have previously read the document and feel that it is ready, 
then confirming that on the list helps. Having wider community review/input and 
consensus building is core to the work we do at the IETF. It would be sad to 
ship documents to the IESG with limited or no review/feedback from the working 
group!

--Mohit

On 6/27/19 7:16 AM, Joseph Salowey wrote:
The Working Group last call has completed with no comments for 
draft-ietf-emu-eap-tls13-05.  I would like to confirm that some working group 
members have reviewed the draft.  If you have reviewed the draft please respond 
to this thread.

THanks,

Joe



___
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] WGLC completed for for draft-ietf-emu-eap-tls13-05

[Joseph Salowey]

The Working Group last call has completed with no comments for
draft-ietf-emu-eap-tls13-05.  I would like to confirm that some working
group members have reviewed the draft.  If you have reviewed the draft
please respond to this thread.

THanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu