Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread Jorge Vergara
>>DISCUSS: We have interoperable implementations of -13.  Does this mean that 
>>the EAP state machines *implicitly* work with the TLS state machines?  There 
>>is no *explicit* requirement in the draft about ordering, and no discussion 
>>thereof.  I suspect that this means the implementations work in part by 
>>accident, instead of by design.  So updates to TLS libraries *may* break 
>>EAP-TLS.  It would be best to make any assumptions explicit.  And / or to 
>>recommend to implementors that they be flexible with respect to changing 
>>order of the 0x00 octet vs session tickets.
>[Joe] Yes we should be clear about this.
[Jorge] My only recommendation would be to wordsmith this part of draft-13 
found in section 2.5. I am not a good wordsmith but I see potential confusion 
here:
>After sending the Commitment Message, the EAP-TLS
>   server may only send an EAP-Success, an EAP-Failure, or an EAP-
>   Request with a TLS Alert Message.

[Jorge] The diagrams in the draft mostly imply that the commitment message 
being the last thing sent, after any NewSessionTicket. As stated, this is 
problematic since the TLS stack may re-order these, and the NewSessionTicket 
may have to come in another EAP-TLS fragment entirely if the combined message 
ends up crossing a fragment boundary.

In my mind, it is obvious that the rest of the EAP-TLS packet should be 
processed so that the EAP-TLS client can correctly receive the NewSessionTicket 
and any other handshake data that may have been in this final message. However, 
once that complete EAP-TLS packet is processed, the next message from the 
server should indeed be an EAP-Success, EAP-Failure, or EAP-Request with a TLS 
Alert Message as draft-13 indicates.

This is currently how the Windows client implementation operates, but it is 
mostly by chance. If we made the full processing of the EAP-TLS packet 
explicit, then I think this would resolve the concerns around ordering here.

Jorge Vergara

From: Emu  On Behalf Of Joseph Salowey
Sent: Friday, January 29, 2021 2:00 PM
To: Alan DeKok 
Cc: EMU WG ; Benjamin Kaduk ; Martin Thomson 
;  
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

HI Alan,

THanks for this message, comments inline below:

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
  This is a new message to summarize history, requirements, etc. for EAP-TLS 
and TLS 1.3.  The focus here is the requirements for EAP-TLS, and how the 0x00 
commitment message versus CloseNotify meets those.  I'll ignore the exporter 
changes here, as those are less controversial.

  The original proposal in the EAP-TLS draft was to send a zero-length 
application data message in order to signal that no more post-handshake 
messages were needed.  From the -05 version:

   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.

  However, the OpenSSL APIs (among others) do not allow for sending zero octets 
of application data.  The proposal was then changed to send a 0x00 octet.

 There was discussion that CloseNotify could achieve the same goals.  But 
CloseNotify requires an additional round trip.  There are strong opinions that 
additional round trips are bad.

  In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal 
Alert:  
https://www.mail-archive.com/emu@ietf.org/msg03092.html

  i.e. there would be no TLS layer signalling for the following situations:

   bad_certificate,  unsupported_certificate,  certificate_revoked,
certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca,
access_denied, etc

  This limitation would be an unmitigated disaster for EAP-TLS.  Those messages 
are required by people deploying EAP-TLS.  Without those messages, it will be 
near impossible to debug configuration issues.

  As a result, we cannot use CloseNotify to signal "no more handshake messages" 
from the server.

  There is a related issue, in that TLS 1.3 separates Session Tickets from TLS 
handshakes.  So it's still possible for the EAP state machine to send a 0x00 
octet, and then the TLS state machines sends that *before* a Session 

[Emu] EAP-TLS 1.3 Hackathon at IETF 110

2021-01-29 Thread Bernard Aboba
In order to better validate existing implementations of EAP-TLS 1.3, we
will be organizing an EAP-TLS 1.3 Hackathon at IETF 110.

The goal of the hackathon is to test operating system client
implementations (Android, iOS, Mac OS X, Windows) with server
implementations over the Internet.

If you are interested in participating in the Hackathon, please contact
Alan and myself.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread Joseph Salowey
HI Alan,

THanks for this message, comments inline below:

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok 
wrote:

>   This is a new message to summarize history, requirements, etc. for
> EAP-TLS and TLS 1.3.  The focus here is the requirements for EAP-TLS, and
> how the 0x00 commitment message versus CloseNotify meets those.  I'll
> ignore the exporter changes here, as those are less controversial.
>
>   The original proposal in the EAP-TLS draft was to send a zero-length
> application data message in order to signal that no more post-handshake
> messages were needed.  From the -05 version:
>
>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.
>
>   However, the OpenSSL APIs (among others) do not allow for sending zero
> octets of application data.  The proposal was then changed to send a 0x00
> octet.
>
>  There was discussion that CloseNotify could achieve the same goals.  But
> CloseNotify requires an additional round trip.  There are strong opinions
> that additional round trips are bad.
>
>   In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal
> Alert:  https://www.mail-archive.com/emu@ietf.org/msg03092.html
>
>   i.e. there would be no TLS layer signalling for the following situations:
>
>bad_certificate,  unsupported_certificate,  certificate_revoked,
> certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca,
> access_denied, etc
>
>   This limitation would be an unmitigated disaster for EAP-TLS.  Those
> messages are required by people deploying EAP-TLS.  Without those messages,
> it will be near impossible to debug configuration issues.
>
>   As a result, we cannot use CloseNotify to signal "no more handshake
> messages" from the server.
>
>   There is a related issue, in that TLS 1.3 separates Session Tickets from
> TLS handshakes.  So it's still possible for the EAP state machine to send a
> 0x00 octet, and then the TLS state machines sends that *before* a Session
> Ticket.
>
>   In addition, RFC 8446 Figure 1 shows that application data can be sent
> by the server to the client, *before* the client certificate is sent to the
> server.  So sending this octet in EAP-TLS does not prove that the client
> certificate has been validated.
>
> DISCUSS: the EAP-TLS draft should explain that the 0x00 byte is NOT a
> positive signal of either "finished TLS", or "successful authentication".
>
> [Joe] It would be good to be clear about the purpose of the message.


> DISCUSS: the EAP-TLS draft should also explain that session tickets may be
> sent either before or after the 0x00 octet.  Does the packet flow look any
> different for the two cases?  If so, what does that mean?
>
> [Joe] I believe the flow of the message flights would be the same, but the
on-the-wire format of those flights could be reversed.  I don't think this
will necessarily cause a problem since the application data is consumed by
the EAP TLS and the NewSessionTicket is consumed by TLS,  However I think
the draft should be clear that this can happen.


> DISCUSS: We have interoperable implementations of -13.  Does this mean
> that the EAP state machines *implicitly* work with the TLS state machines?
> There is no *explicit* requirement in the draft about ordering, and no
> discussion thereof.  I suspect that this means the implementations work in
> part by accident, instead of by design.  So updates to TLS libraries *may*
> break EAP-TLS.  It would be best to make any assumptions explicit.  And /
> or to recommend to implementors that they be flexible with respect to
> changing order of the 0x00 octet vs session tickets.
>
> [Joe] Yes we should be clear about this.


>
>   In situations where resumption is not needed, figure 1 of
> https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13 is correct.
> There are 3.5 rounds, which is about as low as possible.  Adding resumption
> here would *increase* there number of rounds to 4.5, which is worse!
>
> DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that
> this examples does not include Session Tickets.  Section 2.1.2 should be
> updated to note that there are more rounds than for the previous section.
>
>
[Joe] Yes.  It might be helpful to say that the commitment message may be
sent before or after the client authentication is verified, but in the case
that resumption is used it will always be after.


>
>   In situations where the certificate chain is longer, the initial
> authentication will be >=4.5 round trips, and session tickets are perhaps
> more useful.
>
> DISCUSS: the EAP-TLS draft 

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread Joseph Salowey
On Fri, Jan 29, 2021 at 11:34 AM Mohit Sethi M  wrote:

> Hi Ben,
> On 1/29/21 8:32 PM, Benjamin Kaduk wrote:
>
> Hi Alan,
>
> I see that the thread is continuing and that perhaps my reply will even
> become stale as I write it, but I'm replying to your note instead of the
> tip of the thread because it has good context for making some broader
> points that I would like to make.
>
> On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:
>
>   We're approaching 2 weeks since the last discussion of this topic.  This 
> document has been in development for 3 years.  We desperately need to finish 
> it.  IMHO waiting another 6 months is not an option.  Even 3 would be 
> worrying.
>
> My understanding of the discussions involving the TLS WG are that we forked
> off into two sub-threads: one about the use of TLS Exporters for key
> derivation (the one this is a reply to), that largely concluded with
> agreement on a simple change to make, and the other sub-thread about the
> protocol element known in -13 as the "commitment message".
>
> With respect to the exporter usage, I do see you had asked about using the
> type-code as the exporter context value that Martin didn't see much value
> in, but I am willing to accept that as a boon for safety of portability to
> other TLS-using EAP mechanisms.  (I do note that the current editor's copy
> shows calls to TLS-Exporter() with only two arguments, but three are
> required; the construction there also seems to include a propspect for
> violation of the requirement that "one label is not a prefix of any other
> label" when both regular one-byte and extended type codes are used, but if
> the type code is meant to be the context argument I believe that risk goes
> away.)
>
> RFC 5705 says:
>
>If no context is provided, it then computes:
>
>PRF(SecurityParameters.master_secret, label,
>SecurityParameters.client_random +
>SecurityParameters.server_random
>)[length]
>
>If context is provided, it computes:
>
>PRF(SecurityParameters.master_secret, label,
>SecurityParameters.client_random +
>SecurityParameters.server_random +
>context_value_length + context_value
>)[length]
>
> We use only two arguments and say "No context data is used in the TLS
> exporter interface.". We could show the context argument as empty in the
> calls to make things clearer. By the way, this is what is done by TEAP
> also. RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters
> defined in [RFC5705] to derive the session_key_seed.  The label used in the
> derivation is "EXPORTER: teap session key seed".  The length of the session
> key seed material is 40 octets.  *No context data is used in the export
> process.*"
>
> The change of moving the type-code from the context to the label was made
> based on your review (comments from Martin) and the fact that some
> libraries such as wolfssl don't support passing a context (so far). See:
> https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996
>
[Joe] If this implements the derivation RFC 5216.  It's not clear that
function will give you the right output with TLS 1.3 since we are now using
exporters.  Perhaps they provide an exporter interface which should be used
instead.

Personally, I think including the method byte in the context is a bit less
error prone and straight forward then including it in the label.


>
> With respect to the "commitment message", I thought we had a discussion
> that revealed that the mechanism in the -13 could not fulfil its stated
> purpose, and that also called into question whether that stated purpose was
> actually the right thing that the protocol needed.  My understanding,
> therefore, was that the TLS WG could not contribute further insight until
> there was a revised proposal from people who understand the needs of the
> EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
> actually be achievable.
>
>
>   We have multiple inter-operable implementations which have implemented 
> draft-13.  That work over the last few months have resulted in implementors 
> making plans to do beta testing in the next few weeks.  Those plans have been 
> put on indefinite hold, due to the recent request for changes.
>
>   I understand getting feedback from the TLS WG is useful.  But I would 
> prefer to have consensus on a *solution*. Right now, we just have a series of 
> proposed changes, with little to no discussion.
>
> I think this is becaues the TLS WG members (in aggregate) do not have a
> clear picture of what property or properties EAP-TLS will require from TLS
> that led to the need for an additional message when using TLS 1.3 as
> opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
> "authenticated signal from TLS to EAP-TLS that the authentication completed
> successfully" was mentioned, but I did not have the sense that there 

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread Alan DeKok
  This is a new message to summarize history, requirements, etc. for EAP-TLS 
and TLS 1.3.  The focus here is the requirements for EAP-TLS, and how the 0x00 
commitment message versus CloseNotify meets those.  I'll ignore the exporter 
changes here, as those are less controversial.

  The original proposal in the EAP-TLS draft was to send a zero-length 
application data message in order to signal that no more post-handshake 
messages were needed.  From the -05 version:

   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.

  However, the OpenSSL APIs (among others) do not allow for sending zero octets 
of application data.  The proposal was then changed to send a 0x00 octet.

 There was discussion that CloseNotify could achieve the same goals.  But 
CloseNotify requires an additional round trip.  There are strong opinions that 
additional round trips are bad.

  In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal 
Alert:  https://www.mail-archive.com/emu@ietf.org/msg03092.html

  i.e. there would be no TLS layer signalling for the following situations:

   bad_certificate,  unsupported_certificate,  certificate_revoked,  
certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca, 
access_denied, etc

  This limitation would be an unmitigated disaster for EAP-TLS.  Those messages 
are required by people deploying EAP-TLS.  Without those messages, it will be 
near impossible to debug configuration issues.

  As a result, we cannot use CloseNotify to signal "no more handshake messages" 
from the server.

  There is a related issue, in that TLS 1.3 separates Session Tickets from TLS 
handshakes.  So it's still possible for the EAP state machine to send a 0x00 
octet, and then the TLS state machines sends that *before* a Session Ticket.

  In addition, RFC 8446 Figure 1 shows that application data can be sent by the 
server to the client, *before* the client certificate is sent to the server.  
So sending this octet in EAP-TLS does not prove that the client certificate has 
been validated.

DISCUSS: the EAP-TLS draft should explain that the 0x00 byte is NOT a positive 
signal of either "finished TLS", or "successful authentication".

DISCUSS: the EAP-TLS draft should also explain that session tickets may be sent 
either before or after the 0x00 octet.  Does the packet flow look any different 
for the two cases?  If so, what does that mean?

DISCUSS: We have interoperable implementations of -13.  Does this mean that the 
EAP state machines *implicitly* work with the TLS state machines?  There is no 
*explicit* requirement in the draft about ordering, and no discussion thereof.  
I suspect that this means the implementations work in part by accident, instead 
of by design.  So updates to TLS libraries *may* break EAP-TLS.  It would be 
best to make any assumptions explicit.  And / or to recommend to implementors 
that they be flexible with respect to changing order of the 0x00 octet vs 
session tickets.


  In situations where resumption is not needed, figure 1 of 
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13 is correct.  There are 
3.5 rounds, which is about as low as possible.  Adding resumption here would 
*increase* there number of rounds to 4.5, which is worse!

DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that this 
examples does not include Session Tickets.  Section 2.1.2 should be updated to 
note that there are more rounds than for the previous section.


  In situations where the certificate chain is longer, the initial 
authentication will be >=4.5 round trips, and session tickets are perhaps more 
useful.

DISCUSS: the EAP-TLS draft should be updated to better explain the costs / 
benefits of using resumption


  I hope that this summary clarifies the issues and requirements.  The 0x00 
octet is intended as a promise that no more handshake messages are sent.  I 
leave it to others to discuss whether or not that promise is useful.

  As for what to do, my $0.02 is that the behaviour described in -13 is fine.  
The 0x00 octet is useful.  The key exporters are perhaps odd, but not 
problematic.  We have multiple inter-operable implementations.

  The remaining question is this:

DISCUSS: other than word-smithing the above points, are there serious 
objections to the behaviour documented in -13?  i.e. does the IETF want to 
recommend that EAP-TLS alpha testing begins *now*, or should it wait until 2022?

  The only advice I offer here is that we *cannot* rev EAP-TLS, as there is no 
"version" flag in the EAP-TLS 

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread Mohit Sethi M
Hi Ben,

On 1/29/21 8:32 PM, Benjamin Kaduk wrote:

Hi Alan,

I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.

On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:


  We're approaching 2 weeks since the last discussion of this topic.  This 
document has been in development for 3 years.  We desperately need to finish 
it.  IMHO waiting another 6 months is not an option.  Even 3 would be worrying.



My understanding of the discussions involving the TLS WG are that we forked
off into two sub-threads: one about the use of TLS Exporters for key
derivation (the one this is a reply to), that largely concluded with
agreement on a simple change to make, and the other sub-thread about the
protocol element known in -13 as the "commitment message".

With respect to the exporter usage, I do see you had asked about using the
type-code as the exporter context value that Martin didn't see much value
in, but I am willing to accept that as a boon for safety of portability to
other TLS-using EAP mechanisms.  (I do note that the current editor's copy
shows calls to TLS-Exporter() with only two arguments, but three are
required; the construction there also seems to include a propspect for
violation of the requirement that "one label is not a prefix of any other
label" when both regular one-byte and extended type codes are used, but if
the type code is meant to be the context argument I believe that risk goes
away.)

RFC 5705 says:

   If no context is provided, it then computes:

   PRF(SecurityParameters.master_secret, label,
   SecurityParameters.client_random +
   SecurityParameters.server_random
   )[length]

   If context is provided, it computes:

   PRF(SecurityParameters.master_secret, label,
   SecurityParameters.client_random +
   SecurityParameters.server_random +
   context_value_length + context_value
   )[length]


We use only two arguments and say "No context data is used in the TLS exporter 
interface.". We could show the context argument as empty in the calls to make 
things clearer. By the way, this is what is done by TEAP also. RFC 7170 says 
"TEAPv1 makes use of the TLS Keying Material Exporters defined in [RFC5705] to 
derive the session_key_seed.  The label used in the derivation is "EXPORTER: 
teap session key seed".  The length of the session key seed material is 40 
octets.  No context data is used in the export process."

The change of moving the type-code from the context to the label was made based 
on your review (comments from Martin) and the fact that some libraries such as 
wolfssl don't support passing a context (so far). See: 
https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996



With respect to the "commitment message", I thought we had a discussion
that revealed that the mechanism in the -13 could not fulfil its stated
purpose, and that also called into question whether that stated purpose was
actually the right thing that the protocol needed.  My understanding,
therefore, was that the TLS WG could not contribute further insight until
there was a revised proposal from people who understand the needs of the
EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
actually be achievable.



  We have multiple inter-operable implementations which have implemented 
draft-13.  That work over the last few months have resulted in implementors 
making plans to do beta testing in the next few weeks.  Those plans have been 
put on indefinite hold, due to the recent request for changes.

  I understand getting feedback from the TLS WG is useful.  But I would prefer 
to have consensus on a *solution*. Right now, we just have a series of proposed 
changes, with little to no discussion.



I think this is becaues the TLS WG members (in aggregate) do not have a
clear picture of what property or properties EAP-TLS will require from TLS
that led to the need for an additional message when using TLS 1.3 as
opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
"authenticated signal from TLS to EAP-TLS that the authentication completed
successfully" was mentioned, but I did not have the sense that there was
universal agreement of that as the sole relevant property.

I think there was a misunderstanding that an authenticated signal of 
authentication completed was needed. Only a signal of no more post handshake 
messages was needed. I think Alan's summary might also explain the situation 
better.

--Mohit





  We're getting to the point where we have to ship code as promised to 
customers soon (weeks, not months).  We therefore need consensus, as soon as 
possible.

  My preference is to implement draft-13.  We know the code works.  People are 
ready to ship it.  Any 

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread Alan DeKok
On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk  wrote:
> With respect to the exporter usage, I do see you had asked about using the
> type-code as the exporter context value that Martin didn't see much value
> in, but I am willing to accept that as a boon for safety of portability to
> other TLS-using EAP mechanisms.

  OK. 

>  (I do note that the current editor's copy
> shows calls to TLS-Exporter() with only two arguments, but three are
> required; the construction there also seems to include a propspect for
> violation of the requirement that "one label is not a prefix of any other
> label" when both regular one-byte and extended type codes are used, but if
> the type code is meant to be the context argument I believe that risk goes
> away.)

  The EAP type codes are one octet: 0x00 through 0xfd.  The "expanded" type 
codes begin with 0xfe.  So there is no prefix issue, even if the type codes 
form part of the label.

  That being said, using them as the context is preferred, I think.

> With respect to the "commitment message", I thought we had a discussion
> that revealed that the mechanism in the -13 could not fulfil its stated
> purpose, and that also called into question whether that stated purpose was
> actually the right thing that the protocol needed.

  I'm less sure.  There was a lot of discussion around a lot of things.  Part 
of the issue seems to be that bits of the TLS state machine are underspecified 
so far as the EAP needs go.

  i.e. when Z happens, is A guaranteed to have happened before that?  RFC 8446 
is not clear.

> I think this is becaues the TLS WG members (in aggregate) do not have a
> clear picture of what property or properties EAP-TLS will require from TLS
> that led to the need for an additional message when using TLS 1.3 as
> opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
> "authenticated signal from TLS to EAP-TLS that the authentication completed
> successfully" was mentioned, but I did not have the sense that there was
> universal agreement of that as the sole relevant property.

  The issue is in part due to API limitations in OpenSSL.  I will send a 
separate message summarizing the issues.

> Well, the text of the -13 contains a protocol mechanism that cannot deliver
> its stated purpose, so I will continue to hold a Discuss position if that
> remains.  One Discuss ballot does not have to block the work indefinitely
> (the shepherding AD can request a different IESG balloting procedure be
> used), and I leave it between the WG and Roman whether to attempt that
> route.  It is perhaps possible that (as John noted downthread) the text
> about the commitment message was badly written, and that just changing the
> surrounding description could work, but that gets back to the question I
> mentioned above of what properties EAP-TLS actually requires from TLS.

  I've had some further discussions and will send a separate message 
summarizing the issues.

  Alan DeKok.

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


Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread Benjamin Kaduk
Hi Alan,

I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.

On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:
>   We're approaching 2 weeks since the last discussion of this topic.  This 
> document has been in development for 3 years.  We desperately need to finish 
> it.  IMHO waiting another 6 months is not an option.  Even 3 would be 
> worrying.

My understanding of the discussions involving the TLS WG are that we forked
off into two sub-threads: one about the use of TLS Exporters for key
derivation (the one this is a reply to), that largely concluded with
agreement on a simple change to make, and the other sub-thread about the
protocol element known in -13 as the "commitment message".

With respect to the exporter usage, I do see you had asked about using the
type-code as the exporter context value that Martin didn't see much value
in, but I am willing to accept that as a boon for safety of portability to
other TLS-using EAP mechanisms.  (I do note that the current editor's copy
shows calls to TLS-Exporter() with only two arguments, but three are
required; the construction there also seems to include a propspect for
violation of the requirement that "one label is not a prefix of any other
label" when both regular one-byte and extended type codes are used, but if
the type code is meant to be the context argument I believe that risk goes
away.)

With respect to the "commitment message", I thought we had a discussion
that revealed that the mechanism in the -13 could not fulfil its stated
purpose, and that also called into question whether that stated purpose was
actually the right thing that the protocol needed.  My understanding,
therefore, was that the TLS WG could not contribute further insight until
there was a revised proposal from people who understand the needs of the
EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
actually be achievable.

>   We have multiple inter-operable implementations which have implemented 
> draft-13.  That work over the last few months have resulted in implementors 
> making plans to do beta testing in the next few weeks.  Those plans have been 
> put on indefinite hold, due to the recent request for changes.
> 
>   I understand getting feedback from the TLS WG is useful.  But I would 
> prefer to have consensus on a *solution*. Right now, we just have a series of 
> proposed changes, with little to no discussion.

I think this is becaues the TLS WG members (in aggregate) do not have a
clear picture of what property or properties EAP-TLS will require from TLS
that led to the need for an additional message when using TLS 1.3 as
opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
"authenticated signal from TLS to EAP-TLS that the authentication completed
successfully" was mentioned, but I did not have the sense that there was
universal agreement of that as the sole relevant property.

>   We're getting to the point where we have to ship code as promised to 
> customers soon (weeks, not months).  We therefore need consensus, as soon as 
> possible.
> 
>   My preference is to implement draft-13.  We know the code works.  People 
> are ready to ship it.  Any changes will add not just more months of standard 
> discussion, but more months of interoperability testing.
> 
>   If there is no progress in EMU, we're looking at September for first betas. 
>  With no guarantee that there won't be further changes made after that.
> 
>   So the question is:
> 
> * are the draft-13 0x00 byte and exporter *terrible* enough to delay the 
> standard another 6 months?

Well, the text of the -13 contains a protocol mechanism that cannot deliver
its stated purpose, so I will continue to hold a Discuss position if that
remains.  One Discuss ballot does not have to block the work indefinitely
(the shepherding AD can request a different IESG balloting procedure be
used), and I leave it between the WG and Roman whether to attempt that
route.  It is perhaps possible that (as John noted downthread) the text
about the commitment message was badly written, and that just changing the
surrounding description could work, but that gets back to the question I
mentioned above of what properties EAP-TLS actually requires from TLS.

-Ben

> * if the answer is "no", then we can ship now.
> 
> * if the answer is 'yes", then the next question is "when can we get this 
> finalized?"  "March" would be late.  "July" is a major problem.
> 
> > On Jan 12, 2021, at 10:22 AM, Alan DeKok  wrote:
> > 
> > On Jan 11, 2021, at 7:08 PM, Martin Thomson  wrote:
> >> I was not exactly.  I was thinking that EAP-TLS uses the unadorned string 
> >> and other usages (that need a different MSK) define their own string as 
> >> needed.
> > 
> >  Which is largely what was done for <= TLS 1.2.

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread Jorge Vergara
> We need to get agreement on how to proceed here asap. I would like 
> implementors and security AD to agree on the way forward before submitting 
> -14. Four ways forward:
> 
> A. Add (1) and (2)
> B. Only add (1)
> C. Only add (2)
> D. Do not add (1) or (2)

My preference is D.

> Do we need to have a telephone meeting to discuss these things? We cannot 
> have a formal interim meeting as that formally takes weeks to setup. This can 
> also not wait until the next IETF. As soon as we agree on a way forward we 
> can update and submit a new version within 24 h.

Totally open to this.

Jorge Vergara

-Original Message-
From: Alan DeKok  
Sent: Friday, January 29, 2021 5:10 AM
To: John Mattsson 
Cc: Jorge Vergara ; Martin Thomson 
; Benjamin Kaduk ; Roman Danyliw 
;  ; EMU WG 
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Jan 29, 2021, at 5:31 AM, John Mattsson  wrote:
> 
> I can live with any version, the important thing is that interoperable 
> implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 
> 1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.

  Then our choices are:

a) draft-13 in February.  There are multiple interoperable implementations, 
including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.

b) ??? in 2021.

> The close_notity changes are not only positive as it sometimes introduce an 
> additional roundtrip. The Commitment message can according to specification 
> be sent with the server Finish even if some/most/all implementation does not 
> seem to allow this. If the commitment message cannot be send with Finished in 
> practice there is no difference in latency. Still a bit sad how poorly TLS 
> 1.3 and EAP interacts.

  The TLS implementations largely assume that TLS is being used (a) over TCP, 
and (b) to exchange application data.  These assumptions *severely* limit the 
choices available for implementors of EAP-TLS.

  We can verify these assumptions by simply noting that many TLS 
implementations include native support for TLS over TCP.  While there have been 
assertions that TLS libraries also implement EAP, those assertions seem to be 
firmly outside of the bounds of reality.

> We need to get agreement on how to proceed here asap. I would like 
> implementors and security AD to agree on the way forward before submitting 
> -14. Four ways forward:
> 
> A. Add (1) and (2)
> B. Only add (1)
> C. Only add (2)
> D. Do not add (1) or (2)

  My strong preference is (D).

> I assume implementors (Alan, Jorge) are fine with all other changes since -13.

  Yes,

> Do we need to have a telephone meeting to discuss these things? We cannot 
> have a formal interim meeting as that formally takes weeks to setup. This can 
> also not wait until the next IETF. As soon as we agree on a way forward we 
> can update and submit a new version within 24 h.

  TBH, implementors have already had multiple informal discussions and calls.  
One more wouldn't make much difference.

  Alan DeKok

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


Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread Alan DeKok
On Jan 29, 2021, at 8:10 AM, Alan DeKok  wrote:
>  Then our choices are:
> 
> a) draft-13 in February.  There are multiple interoperable implementations, 
> including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.
> 
> b) ??? in 2021.

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


Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread Alan DeKok
On Jan 29, 2021, at 5:31 AM, John Mattsson  wrote:
> 
> I can live with any version, the important thing is that interoperable 
> implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 
> 1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.

  Then our choices are:

a) draft-13 in February.  There are multiple interoperable implementations, 
including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.

b) ??? in 2021.

> The close_notity changes are not only positive as it sometimes introduce an 
> additional roundtrip. The Commitment message can according to specification 
> be sent with the server Finish even if some/most/all implementation does not 
> seem to allow this. If the commitment message cannot be send with Finished in 
> practice there is no difference in latency. Still a bit sad how poorly TLS 
> 1.3 and EAP interacts.

  The TLS implementations largely assume that TLS is being used (a) over TCP, 
and (b) to exchange application data.  These assumptions *severely* limit the 
choices available for implementors of EAP-TLS.

  We can verify these assumptions by simply noting that many TLS 
implementations include native support for TLS over TCP.  While there have been 
assertions that TLS libraries also implement EAP, those assertions seem to be 
firmly outside of the bounds of reality.

> We need to get agreement on how to proceed here asap. I would like 
> implementors and security AD to agree on the way forward before submitting 
> -14. Four ways forward:
> 
> A. Add (1) and (2)
> B. Only add (1)
> C. Only add (2)
> D. Do not add (1) or (2)

  My strong preference is (D).

> I assume implementors (Alan, Jorge) are fine with all other changes since -13.

  Yes,

> Do we need to have a telephone meeting to discuss these things? We cannot 
> have a formal interim meeting as that formally takes weeks to setup. This can 
> also not wait until the next IETF. As soon as we agree on a way forward we 
> can update and submit a new version within 24 h.

  TBH, implementors have already had multiple informal discussions and calls.  
One more wouldn't make much difference.

  Alan DeKok

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


Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread John Mattsson
Hi,

I can live with any version, the important thing is that interoperable 
implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 
1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.

We (the authors) have addressed all the comments from IESG/TLS WG in GitHub.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/tree/master

Text format:

https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

The diff can be found here:

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 would be ready for submission but I think the Implementors, WGs, Chairs, 
Shepard, ADs need to agree on the direction before we do that. The two 
important technical changes from -13 are

(1) Changing key derivation
(2) Changing Commitment message to close_notify

The key derivation changes are good and more modern. I personally like the 
change but the change but I don't think it is essential and was not done for 
security reasons.

The close_notity changes are not only positive as it sometimes introduce an 
additional roundtrip. The Commitment message can according to specification be 
sent with the server Finish even if some/most/all implementation does not seem 
to allow this. If the commitment message cannot be send with Finished in 
practice there is no difference in latency. Still a bit sad how poorly TLS 1.3 
and EAP interacts. I am not sure I fully agree with the layer violation 
argument, my interpretation was that this was information for the EAP state 
machine which is the application using TLS. Maybe the text regarding the 
commitment message was badly written and should have talked about the EAP state 
machine more instead of TLS

We need to get agreement on how to proceed here asap. I would like implementors 
and security AD to agree on the way forward before submitting -14. Four ways 
forward:

A. Add (1) and (2)
B. Only add (1)
C. Only add (2)
D. Do not add (1) or (2)

I assume implementors (Alan, Jorge) are fine with all other changes since -13.

Do we need to have a telephone meeting to discuss these things? We cannot have 
a formal interim meeting as that formally takes weeks to setup. This can also 
not wait until the next IETF. As soon as we agree on a way forward we can 
update and submit a new version within 24 h.

Cheers,
John

-Original Message-
From: TLS  on behalf of Jorge Vergara 

Date: Friday, 29 January 2021 at 00:57
To: Alan DeKok , Martin Thomson 
Cc: "t...@ietf.org" , EMU WG 
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

I am in favor of sticking to draft-13. There was some discussion about whether 
draft-13 contained a TLS layering violation, but I believe that discussion 
concluded that it does not. As noted, discussion has mostly stalled since then 
with a few additional ideas surfacing that have added round trips. Other 
threads are now popping up expressing dissatisfaction with the extra round trip.

Alan mentions that betas may be months out for his product line - for Microsoft 
and Windows, the situation is much tighter. If we cannot reach consensus 
quickly we will need to push this out of our 2021 release cycle. Seeing as 
we're sitting on draft-13 with multiple implementations available, I would 
really prefer to reach consensus to finalize draft-13 and get this into the 
hands of customers this calendar year.

Jorge Vergara

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Saturday, January 23, 2021 2:28 PM
To: Martin Thomson 
Cc:  ; EMU WG 
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

  We're approaching 2 weeks since the last discussion of this topic.  This 
document has been in development for 3 years.  We desperately need to finish 
it.  IMHO waiting another 6 months is not an option.  Even 3 would be worrying.

  We have multiple inter-operable implementations which have implemented 
draft-13.  That work over the last few months have resulted in implementors 
making plans to do beta testing in the next few weeks.  Those plans have been 
put on indefinite hold, due to the recent request for changes.

  I understand getting feedback from the TLS WG is useful.  But I would prefer 
to have consensus on a *solution*. Right now, we just have a series of proposed 
changes, with little to no discussion.

  We're getting to the point where we have to ship code as promised to 
customers soon (weeks, not months).  We therefore need consensus, as soon as 
possible.

  My preference is to implement draft-13.  We know the code works.  People are 
ready to ship it.  Any changes will add not just more months of standard 
discussion, but more months of interoperability testing.

  If there is no progress in EMU, we're looking at September for first