[Emu] emu - New Meeting Session Request for IETF 108

[IETF Meeting Session Request Tool]

A new meeting session request has just been submitted by Liz Flynn, on behalf 
of the emu working group.


-
Working Group Name: EAP Method Update
Area Name: Security Area
Session Requester: Liz Flynn


Number of Sessions: 1
Length of Session(s):  50 Minutes
Number of Attendees: 50
Conflicts to Avoid: 
 Chair Conflict: saag tls cfrg lwig
 Technology Overlap: curdle uta secdispatch oauth mls t2trg pearg lake
 Key Participant Conflict: sacm quic kitten bier acme 6lo





People who must be present:
  Jari Arkko
  Joseph A. Salowey
  Roman Danyliw
  Alan DeKok
  John Mattsson
  Mohit Sethi

Resources Requested:

Special Requests:
  
-


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

Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

[Hannes Tschofenig]

Hi Mohit,

Thanks for the super-detailed response.

Give me till tomorrow to parse your response. Glad to hear that you talked 
about this topic already.

Ciao
Hannes

From: Mohit Sethi M 
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13


Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken to 
avoid changes to the underlying TLS implementation while also avoiding changes 
to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP-TLS 
is non-trivial. See his email here: 
https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. 
Essentially, TLS 1.3 allows a server to send a Post-Handshake message with a 
NewSessionTicket at any time. However, in EAP-TLS this is not possible. The TLS 
tunnel is torn down after authentication. John notes in his response to Jouni 
(https://mailarchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in 
TLS the connection is assumed to stay open for a long time after the client 
sends Finished, in EAP the connection is assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra round trip 
and left the peer uncertain about the next message 
(https://tools.ietf..org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni 
highlighted this uncertainty for a peer: " the peer has no idea whether the 
NewSessionTicket is delivered after ClientFinished. In other words, the next 
message in the sequence could be either continuation of EAP-TLS method or 
EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that 
purpose?". See RFC 3748 (https://tools.ietf.org/html/rfc3748) which says the 
following:

   Implementation Note: Because the Success and Failure packets are not

   acknowledged, they are not retransmitted by the authenticator, and

   may be potentially lost.  A peer MUST allow for this circumstance as

   described in this note.
and

 On the peer, after success result indications have been exchanged by

   both sides, a Failure packet MUST be silently discarded.  The peer

   MAY, in the event that an EAP Success is not received, conclude that

   the EAP Success packet was lost and that authentication concluded

   successfully.

Thus, EAP-Success cannot be used as a reliable notification mechanism. Till 
version 05 of the document, we used an empty application data record as a 
notification of the last handshake message. The text said:

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, Jouni in a later response 
(https://mailarchive.ietf.org/arch/msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted 
that such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL 
is not willing to send such an empty TLSPlaintext structure. SSL_write() has 
following to say : '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.'"

Therefore, the text was later updated to:

 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.


There is still a challenge in scenarios where a server chooses not to issue any 
NewSessionTicket. In this email: 
https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ Jouni 
notes this problem:

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 

Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

[Mohit Sethi M]

Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken to 
avoid changes to the underlying TLS implementation while also avoiding changes 
to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP-TLS 
is non-trivial. See his email here: 
https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. 
Essentially, TLS 1.3 allows a server to send a Post-Handshake message with a 
NewSessionTicket at any time. However, in EAP-TLS this is not possible. The TLS 
tunnel is torn down after authentication. John notes in his response to Jouni 
(https://mailarchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in 
TLS the connection is assumed to stay open for a long time after the client 
sends Finished, in EAP the connection is assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra round trip 
and left the peer uncertain about the next message 
(https://tools.ietf..org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni 
highlighted this uncertainty for a peer: " the peer has no idea whether the 
NewSessionTicket is delivered after ClientFinished. In other words, the next 
message in the sequence could be either continuation of EAP-TLS method or 
EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that 
purpose?". See RFC 3748 (https://tools.ietf.org/html/rfc3748) which says the 
following:

   Implementation Note: Because the Success and Failure packets are not
   acknowledged, they are not retransmitted by the authenticator, and
   may be potentially lost.  A peer MUST allow for this circumstance as
   described in this note.

and

 On the peer, after success result indications have been exchanged by
   both sides, a Failure packet MUST be silently discarded.  The peer
   MAY, in the event that an EAP Success is not received, conclude that
   the EAP Success packet was lost and that authentication concluded
   successfully.

Thus, EAP-Success cannot be used as a reliable notification mechanism. Till 
version 05 of the document, we used an empty application data record as a 
notification of the last handshake message. The text said:

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, Jouni in a later response 
(https://mailarchive.ietf.org/arch/msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted 
that such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL 
is not willing to send such an empty TLSPlaintext structure. SSL_write() has 
following to say : '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.'"

Therefore, the text was later updated to:

 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.


There is still a challenge in scenarios where a server chooses not to issue any 
NewSessionTicket. In this email: 
https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ Jouni 
notes this problem:

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 

Re: [Emu] draft-ietf-emu-eap-tls13-09

[Mohit Sethi M]

Hi Hannes,

On 6/12/20 11:29 AM, Hannes Tschofenig wrote:

A short follow-up on my own review:

I wrote:



"
Pre-Shared Key (PSK) authentication SHALL NOT be used except
   for resumption.
"
What you want to say that that EAP-TLS MUST NOT use external PSKs. I wonder why 
you want to rule that use case out? It is a perfectly fine use case for TLS 1.3 
and there is even the possibility to use PSK with ECDHE. What is the motivation?



I noticed now that the working group had a discussion about this already and 
that there is a new document being published specifically focused on 
EAP-TLS-PSK-based authentication. Hence, ignore the second part of my comment.

Indeed. There has been lots of discussion on this topic. To summarize:

RFC 5216 explicitly required certificate based TLS authentication with the 
following text:

   If the EAP server is not resuming a previously established session,
   then it MUST include a TLS server_certificate handshake message, and
   a server_hello_done handshake message MUST be the last handshake
   message encapsulated in this EAP-Request packet.

   The certificate message contains a public key certificate chain for
   either a key exchange public key (such as an RSA or Diffie-Hellman
   key exchange public key) or a signature public key (such as an RSA or
   Digital Signature Standard (DSS) signature public key).

Bernard Aboba opined that external PSK based authentication shouldn't be added 
to EAP-TLS in this update. Instead a separate document (with a separate EAP 
method type) should do that. Hence, we now have: 
https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00. For reference, 
here are some email conversations containing discussion on this topic:

- https://mailarchive.ietf.org/arch/msg/emu/FtxRJHTjzSY0yVdVr8Vjyk9D-vk/
- https://mailarchive.ietf.org/arch/msg/emu/CRh3VXLDnpJFFIbHWJAjiOgfzAg/
- https://mailarchive.ietf.org/arch/msg/emu/nYrIA4PKqk2mrUoNvAtFh7S-Xb8/
- https://mailarchive.ietf.org/arch/msg/emu/hVG357HXqvy0EjZ2yrOLdspH53o/

--Mohit



Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

___
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] draft-ietf-emu-eaptlscert-04

[Mohit Sethi M]

Hi Hannes,

Thanks for the follow up. I have submitted a new version which should 
address your concerns. Here is a diff for your convenience:

https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-05

Please see in-line for details.

I believe that the draft is now ready for publication.

--Mohit

On 6/10/20 12:02 PM, Hannes Tschofenig wrote:

Thanks for the update.

A few more minor comments on -04:

Section 4.1:

"TLS 1.3 [https://tools.ietf.org/html/rfc8446] requires implementations to support 
ECC."

This is only true absent an application profile defining something else.
The UTA group has just adopted a WG item that defines such a profile.

Hence, I suggest to add the remark about the profile. Something like

"In the absence of an application profile standard specifying
otherwise, a TLS 1.3-compliant application must support ECC."

Done!


4.2.  Updating TLS and EAP-TLS Code

Why are you calling the section "updating code"? The suggestion in 4.2.1 does 
not require code update and whether something requires a code update depends what you 
have in the code already. Maybe you just need to enable the feature.  Updating the code 
is also a negative aspect because you are likely going to update the code on a regular 
basis anyway to fix bugs and to support new algorithms. Luckily TLS has the extension 
negotiation built-in and hence you can detect and negotiate new features on the fly.
I agree that all code indeed should be updated to fix bugs and 
vulnerabilities. However, updating applications and certificates is 
certainly different from updating the underlying TLS library and EAP 
implementation. Administrators in enterprise environments (where EAP-TLS 
is widely used) have great control over when and how the server and 
client updates are rolled out. The categorization in section 4 should 
help administrators to decide how to avoid the fragmentation problem. 
Whether it is issuing new certificates, updating the access points, or 
updating the TLS and EAP-TLS implementation. Nonetheless, I have added 
the following text: "This section discusses how the fragmentation 
problem can be avoided by updating the underlying TLS or EAP-TLS 
implementation. Note that in many cases the new feature may already be 
implemented in the underlying library and simply needs to be taken into 
use."


4.2.4.  Caching Certificates

"The extension however necessitates a successful full handshake before any 
caching."

This is not true. The spec defines a way to populate the cache by running a 
full handshake.
However, you could also populate the cache by out-of-band means, for example by 
pre-distributing certs.

The mechanism to re-run the handshake to populate the cache is, however, a safe 
fallback in case configuration changes and the pre-distributed certs become 
invalid. It is better to have a fallback.

I thought I made that comment before.


You had raised this issue before and I had responded to you before. Here 
is the response again:


Where does RFC 7924 (https://tools.ietf.org/html/rfc7924) talk about 
populating the cache with an out-of-band mechanism? The text in Section 
1 of RFC 7924 clearly states that:  "This specification defines a TLS 
extension that allows a client and a server to exclude transmission 
information cached in an earlier TLS handshake.". Notice the "earlier 
TLS handshake" part. I certainly refuse to add or describe new 
functionality which isn't discussed in the original RFC.




4.2.3.  Compact TLS 1.3

You are still stating "This naturally means that cTLS is not interoperable with 
previous versions of the TLS protocol."

cTLS is a compression of TLS, which means that you can fall-back to TLS, if the 
other peer does not support cTLS. As mentioned in my previous email, I don't 
understand why you are mentioning this aspect at all given that this document 
is about certificate size reduction.
I understand your desire of making cTLS look good. I am not sure how 
hiding the information that cTLS doesn't interoperate with older 
versions of TLS helps. Anyhow, I have removed that sentence since 
progressing the draft at this is stage is more important than arguing 
over one sentence.


Raw Public Keys

I wonder whether you should mention the possibility to use RPKs 
(https://tools.ietf.org/html/rfc7250) in Section 4.1.2 because those would be a 
fairly obvious choice in EAP-TLS given that we are talking about a nailed up 
connection between the EAP peer and the EAP server. This would obviously reduce 
the overhead associated with certificates considerably.


Added a new sub-section.

With this, I believe that all issues are resolved and the document is 
ready for publication.




Ciao
Hannes


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the 

[Emu] I-D Action: draft-ietf-emu-eaptlscert-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

Title   : Handling Large Certificates and Long Certificate 
Chains in TLS-based EAP Methods
Authors : Mohit Sethi
  John Mattsson
  Sean Turner
Filename: draft-ietf-emu-eaptlscert-05.txt
Pages   : 14
Date: 2020-06-15

Abstract:
   EAP-TLS and other TLS-based EAP methods are widely deployed and used
   for network access authentication.  Large certificates and long
   certificate chains combined with authenticators that drop an EAP
   session after only 40 - 50 round-trips is a major deployment problem.
   This document looks at the this problem in detail and describes the
   potential solutions available.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eaptlscert/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eaptlscert-05
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eaptlscert-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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