September 2024 at 19:36
To: Eliot Lear
Cc: Mohit Sethi , RFC Errata System ,
John Mattsson , debcool...@gmail.com
, j...@salowey.net , pe...@akayla.com
, emu@ietf.org
Subject: Re: [Technical Errata Reported] RFC9190 (8094)
On Wed, Sep 4, 2024 at 1:26 PM Eliot Lear mailto:l...@lear.ch>>
le not making larger changes that would invalidate the
security proofs.
Cheers,
John
From: Alexander Clouter
Date: Tuesday, 7 November 2023 at 18:04
To: John Mattsson
Cc: EMU WG
Subject: Re: [Emu] FW: New Version Notification for
draft-ingles-eap-edhoc-05.txt
Hello,
On Thu, 28 Sep 2023, at
test vector documents from LAKE WG have now
been approved by the IESG for publication. I think this would be a good time to
have the adoption call on the list.
Cheers,
John
From: internet-dra...@ietf.org
Date: Tuesday, 12 September 2023 at 10:14
To: Göran Selander , John Mattsson
, Dan Garcia
Hi Sean,
Thanks for your detailed review and thanks for making a GitHub PR!
I have now merged you PR with the small changes we agreed on. We will soon
submit a -11 version. We still have a few more changes that needs to be done.
Cheers,
John
From: Sean Turner via Datatracker
Date: Tuesday, 14
To: chenmeil...@chinamobile.com , Jari Arkko
, Vesa Torvinen , John
Mattsson
Cc: emu@ietf.org
Subject: RE: RE: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt
Hi!
If I understand correctly, you mean that current PQ-secure key establishment
schemes are either broken or do not provide PFS.
Because of
Hi,
Let’s have some discussion based on the presentation at the interim. My view is
that the thing that would make sense to do in LAKE is to have a new method 4
that can be used for both the initial handshake and for resumption, similar to
the PSK authentication in TLS 1.3.
+-
uch longer)
Cheers,
John
From: Tero Kivinen
Date: Sunday, 29 January 2023 at 16:32
To: Rafa Marín López
Cc: John Mattsson , l...@ietf.org ,
EMU WG
Subject: Re: [Lake] EDHOC rekey
Rafa Marín López writes:
> Hi John:
> - 2) Use PSK with ECDHE (similar to psk_dhe_ke in TLS)
>
> Let m
Hi,
The -10 version fixes various nits found by Peter Yee.
Cheers,
John
From: Emu on behalf of internet-dra...@ietf.org
Date: Thursday, 26 January 2023 at 15:31
To: i-d-annou...@ietf.org
Cc: emu@ietf.org
Subject: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt
A New Internet-Draft is avail
Hi Rafa,
Thanks for bringing up this question. I think this is a very good discussion to
have at this point.
First discussion is probably why resumption is needed. I think there are three
things that can be more optimized in a resumption.
- A) Message sizes in the protocol.
- B) Less asymetric
That sounds good. Would be good to have text stating that passwords of length
255 characters (the current max) shall be allowed. Requiring a minimum length
of 8 or a least 6 characters would be good.
Cheers,
John
From: Emu on behalf of Alan DeKok
Date: Wednesday, 25 January 2023 at 02:15
To:
Hi,
We submitted -09 addressing the comments during the second WGLC. We also made
some smaller editorial changes:
- Scalable Vector Graphics (SVG) versions for all figures have been added so
the draft looks nice in HTML. The figures have been slightly modified to render
nicely with aasvg (as s
tps://htmlpreview.github.io/?https://github.com/emu-wg/eap-aka-pfs/blob/master/draft-ietf-emu-aka-pfs-latest.html>
Cheers,
John
On 2022-12-18, 15:47, "Michael Richardson" wrote:
John Mattsson mailto:john.matts...@ericsson.com>>
wrote:
> Thanks for the suggestion,
Hi,
>This document replaces RFC 7170.
Use the IETF term obsoletes and add that to the header.
- Use the new RFC 8174 text.
- I think we are past the time when it is acceptable to publish standards track
based on the obsolete TLS 1.2. NIST is requiring TLS 1.3 support everywhere by
January 2024
Hi Oleg,
My understanding is that a TLS server and client can skip sending a
CertificateStatus even if it has negotiated support of OSCP stapling. I assume
that the reason is that the server might not get a response from the OSCP
server in time and might then decide to continue the handshake wi
I generated SVG with aasvg manually and added to the xml file in GitHub. You
will get nice looking SVG in -09.
Cheers,
John
From: Emu on behalf of John Mattsson
Date: Saturday, 17 December 2022 at 15:16
To: Michael Richardson , Peter Yee ,
'EMU WG'
Subject: Re: [Emu] Second WG
Thanks Heikki,
- Looking at the Android page below (I did not want to register at WBA) it
seems like EAP-AKA' FS will be treated the same as EAP-AKA'. They use the same
EAP-Method prefix.
https://source.android.com/docs/core/connect/carrier-wifi
- draft-ietf-emu-aka-pfs-08 only mentions SUCI on
Thanks for the suggestion, Michael. Currently we are unfortunately using xml.
The aasvg version seems nice. I make an issue on GitHub and see what we can do.
Cheers,
John
From: Emu on behalf of Michael Richardson
Date: Friday, 16 December 2022 at 18:17
To: Peter Yee , 'EMU WG'
Subject: Re: [E
Alan DeKok wrote:
> It may be worth adding a one-sentence comment on the order of:
>
> Note that this derivation depends on SHA-1, which may be formally deprecated
> in the
> near future.
Yes, please do.
Cheers,
John
From: Alan DeKok
Date: Saturday, 29 October 2022 at 13:07
To
I think this is important (and unexpected)
information to readers of the document and users of the EAP method. My
understanding is that TEAP 1.3 is not using SHA-1.
Cheers,
John
From: Emu on behalf of Alan DeKok
Date: Friday, 28 October 2022 at 17:36
To: John Mattsson
Cc: emu@ietf.org
Subject: Re:
Hi,
Good that publication is requested.
A small nit:
OLD and tje
NEW and the
PEAP and SHA-1:
Looks like Microsoft is planning to stick with SHA-1 for PEAP 1.3 [PEAP-PRF]. I
think that is the wrong choice. NIST recently stated that they plan to
deprecate and eventually disallow _all_ uses of SH
hive/id/draft-ietf-emu-aka-pfs-07.txt&url2=https://raw.githubusercontent.com/emu-wg/eap-aka-pfs/master/draft-ietf-emu-aka-pfs-latest.txt>
Cheers,
John
From: John Mattsson
Date: Saturday, 6 August 2022 at 10:12
To: emu@ietf.org
Subject: Author review of draft-ietf-emu-aka-pfs-07
Hi,
I did a
Hi,
I did a thorough very trough read of draft-ietf-emu-aka-pfs-07. I found several
minor things that I think should be fixed:
- Fixed all names with non-ascii characters including my own. -07 dispays
non-ascii characters in some of the references wrongly.
- I fixed all the idnits (to long rows
Hi,
I read through the high level parts of the draft and have following comments:
- "compromising smart cards"
Not sure the attacks actually attacked the smart cards. I suggest
reformulating this as
"compromising the smart card supply chain".
- I think the draft should mention zero-trust.
Hi,
I have reviewed the document. I think it is ready. There is interest to use
these methods in 5G. TLS 1.3 is a must going forward.
Comments:
- The MAC function in section 2.2 is not defined. I assume it should be HMAC.
Suggestion:
OLD
For TLS 1.3, the hash function used is the same
Agree that we should work on progressing the draft and get it published soon.
NIST requires support of TLS 1.3 everywhere by January 2024 without exceptions.
Issuing a WGLC is a good way to get reviews. The worst thing that can happen is
that we need a second WGLC. Alternatively the chairs shoul
Hi,
I think it would be very good if IETF/EMU could agree on simpler, more
automatic, and secure deployment and configuration of TLS-based EAP methods.
This is severely needed. Both complexity and security are very real problems.
https://threatpost.com/misconfiguration-university-wifi-login-cre
See inline for additional comments on some of the drafts.
From: Alan DeKok
Date: Tuesday, 18 January 2022 at 14:01
To: John Mattsson
Cc: EMU WG
Subject: Re: [Emu] EMU Meetings
On Jan 15, 2022, at 6:12 AM, John Mattsson
wrote:
> - The adopted draft-ietf-emu-tls-eap-types and draft-ietf-
Any updates on this?
I think there is a quite a lot to discuss. I think an interim make a lot of
sense.
- The adopted draft-ietf-emu-tls-eap-types and draft-ietf-emu-aka-pfs seems to
be more or less done, very important, and need to progess.
- ACE WG seems to be done with draft-ietf-ace-wg-coa
On Oct 18, 2021, Alan DeKok wrote:
>Implementors are doing final interoperability testing on client && server
>implementations. We hope to have updates within a few weeks,
Any updates on this? I think this is a very important draft. TLS 1.2 is
obsolete and NIST requires use of TLS 1.3 everywher
Hi,
Seems to be consensus in the security area to recommend not using the term
Perfect Forward Secrecy (PFS).
https://mailarchive.ietf.org/arch/msg/saag/6ImeENhteXGdLsnaJHRoN6LW1zk/
Following this the draft should be updated to talk about "forward secrecy" and
maybe have considerations regardi
Thanks,
I think this is a very useful mechanism and a well written draft. Some quick
comments.
- "ciphersuite"
Note that both TLS and EDHOC spells this with space "cipher suite"
- Section 2. I don't understand what "SM" in Figure 1 is an abbrevation for.
- Section 2. "UDP/TCP/Websockets" Why i
,
John
From: John Mattsson
Date: Wednesday, 23 June 2021 at 10:39
To: Alan DeKok , EMU WG
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-03.txt
I agree that the document is ready for WG last call.
John
From: Emu on behalf of Alan DeKok
Date: Tuesday, 22 June 2021 at 15:10
To: EMU
I agree that the document is ready for WG last call.
John
From: Emu on behalf of Alan DeKok
Date: Tuesday, 22 June 2021 at 15:10
To: EMU WG
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-03.txt
This is to address John's review, and to do some minor cleanups and textual
fixes.
Your suggestion looks good to me. I added a commit to RR #83
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83
From: Bernard Aboba
Date: Saturday, 19 June 2021 at 16:47
To: John Mattsson
Cc: Joseph Salowey , EMU WG
Subject: Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216
I
Hi Alan,
I reviewed draft-ietf-emu-tls-eap-types-02. Some minor comments:
- “The Type-Code is defined to be 1 octet for values smaller than 255.”
I think this should be “smaller than 254” as 0xFE = 254
- “Some implementations use the TLS "Finished" state as a signal that
application data
Hi Bernard,
Thanks for your comments on backward compatibility. I think PR #83 addresses
your comments. I did not write anything about TLS 1.0 and TLS 1.1 as RFC 8996
(which updates RFC 5216) formally forbids support and negotiation of these weak
versions.
https://github.com/emu-wg/draft-ietf-
hn: I made a commit based on Joes suggestion above.
Cheers,
John
From: Joseph Salowey
Date: Friday, 18 June 2021 at 22:30
To: Alan DeKok
Cc: John Mattsson , Bernard Aboba
, Mohit Sethi M , EMU WG
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-16.txt
On Thu, Jun 17, 2021 at 9:55 AM Alan DeKok
mai
Hi,
Thanks Joe for making such very clear and concrete issues on GitHub!
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues
I have made a single PR addressing all the currently listed issues in the way
suggested by Joe.
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files
-
Hi,
I think it would be good to first make sure that we have GitHub issues or pull
requests for the remaining EAP-TLS issues.
https://github.com/emu-wg/draft-ietf-emu-eap-tls13
The more I work with GitHub in IETF, the more I like it, both as an author or
commenting on documents. It forces comm
Hi,
I implemented the suggestions below in the following PR. Some of the editorial
changes was merged directly to master.
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/78
I have also implemented all the thing in issue #58 (Alans review) in a PR
https://github.com/emu-wg/draft-ietf-emu-
Hi Oleg,
"If server name matching is not used, then peers may end up trusting
servers for EAP authentication that are not intended to be EAP
servers for the network. If name matching is not used with a public
CA bundle, then effectively any server can obtain a certificate which
will be trusted for
Hi Meiling,
I just looked through this draft quickly.
- draft-ietf-tls-dtls13 specifies DTLS 1.3 which is not used in EAP-TLS. You
likely want to reference RFC8446 or RFC8446bis.
- I don't really understand why a new EAP method is needed here, this just
seems like ordinary EAP-TLS to me...
-
Hi Meiling,
In version 15 the group decided to go back more or less to how things worked in
version 13 where protected TLS application Data 0x00 is send instead of
close_notify. This is changed in a lot of places in the draft.
A big change from -13 is that where protected TLS application Data
I don’t see any strong reasons to keep the -15 key derivation. I started to
prepare a PR for the likely change back to -13.
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/68
- Version 15 has the following wrong text that need to change. Key_Material can
now be kept, but IV should be re
Appology accepted.
John
-Original Message-
From: Alan DeKok
Date: Monday, 22 February 2021 at 14:41
To: John Mattsson
Cc: EMU WG
Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3
I'd like to apologize to John for mis-stating what he said. That attempt at
paraphrasin
both before and after it was put in the document.
>i.e.: Instead of fighting with standards bodies, implementors have gone >and
>done their own thing, because the specifications are lacking. Worse, >the
>processes used by standards bodies are lacking.
-Original Message-
F
My mistake, I read zero-bytes instead of zero-byte. The text is fine. Sorry for
the spam.
---
Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer>
On 19 February 2021 at 07:49:15 CET, John Mattsson
wrote:
But if I missed something and implementors are fine with “Zero-by
es
are issues by a CA that is exclusively used for EAP-TLS in a specific network
and ignore the identities.
/John
-Original Message-
From: Alan DeKok
Date: Thursday, 18 February 2021 at 22:39
To: John Mattsson
Cc: EMU WG , Martin Thomson , Benjamin Kaduk
Subject: Re: [Emu] Key Derivation fo
But if I missed something and implementors are fine with “Zero-byte”, I do not
object. Zero-bytes is allowed by the TLS 1.3 specification and theoreticallty
better as it is not send normally.
From: Emu on behalf of John Mattsson
Date: Friday, 19 February 2021 at 07:09
To: Joseph Salowey
Small nit: Zero-byte application record was removed in -06 as many TLS
implementations did not support sending a Zero-byte application record.
Zero-byte was then changes to send 0x00 but accept any application data. Other
EAP-TLS based method might require longer specific stings like “EAP-Succes
Hi,
I don't think any additional information in the key derivation is needed.
I do think that the requirements for server identity verification in RFC 5216
is a bit vague.
HTTPS (RFC 2818) for example has much more stricter requirement regarding this:
"If the hostname is available, the clie
nding application data in an EAP-Request the EAP-TLS server MUST send
only EAP-Success."
would not work for TTLS, PEAP, FAST, TEAP. To make it work the application data
would have to be something specific like "EAP-SUCCESS".
John
-Original Message-
From: John Mattsson
Hi Mohit,
A P-256 ECDH public key does not _require_ 33 bytes. EDHOC uses 32 bytes
compact representation [RFC 6090] and there are a lot of people arguing that
HPKE should do the same.
3GPP 5G already uses the 33 bytes compressed format from SECG in SUCI (I wrote
part of that specification
Hi Vadim,
Extending EAP-Failure/EAP-Success has been discussed in the past. People have
expressed that it would be good to protect EAP-Failure/EAP-Success and to be
able to send data with them. Changing EAP-Failure/EAP-Success is however not
seen as possible and was not discussed in any recent
ay, 9 February 2021 at 15:22
To: John Mattsson
Cc: EMU WG
Subject: Re: [Emu] Protected Result Indicators in EAP-TLS
On Feb 9, 2021, at 5:00 AM, John Mattsson
wrote:
>
> Below is my summary of the situation:
>
> - It seems like there will be consensus to have protected result indicat
Below is my summary of the situation:
- It seems like there will be consensus to have protected result indicators in
EAP-TLS 1.3.
- No one has objected to mandate Error alert on fatal error condition.
- Optional protected result indicators are different from mandatory result
indicators,
recent
would make EAP-Success a dummy message. It has to be sent according
to EAP, but would not really be used
John
-Original Message-----
From: John Mattsson
Date: Sunday, 7 February 2021 at 11:14
To: EMU WG
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3
Hi,
Thanks,
Good to know that RFC 5448 (EAP-AKA’) and aka-pfs have protected result
indicators. I missed that RFC 5448 gets this from RFC 4187.
John
-Original Message-
From: "jari.ar...@piuha.net"
Date: Monday, 8 February 2021 at 18:07
To: John Mattsson
Cc: EMU WG
Subject
>This consensus call has two parts:
>
>1. Please respond to the list if you support adding explicit result
>indications of success and failure from the EAP Server to the EAP Peer in
>EAP-TLS 1.3. If you object please respond to the list indicating why.
I support this based on that implementors su
Hi,
Martin Thompson wrote:
>What I was concerned about was the information that is exchanged in EAP
>*before* the TLS handshake
>begins that might affect the choice of certificate to offer. As this is not
>authenticated at all,
>there are trivial attacks if a client uses that information to gu
: Mohit Sethi M
Date: Monday, 8 February 2021 at 06:33
To: John Mattsson , Bernard Aboba
, "emu@ietf.org" , "t...@ietf.org"
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine
Hi all,
I have now read both the papers. I am not sure the attacks in [2] are anymo
Alan DeKok wrote:
>> I personally fine with writing MUST send an Error alert if the WG wants
>> that.
>
> This is what all implementations have done for ~15 years. The TLS Alert
> satisfies the "altReject"
> requirements of RFC 4137. Which means it's a very good iea.
Jorge said offline th
Alan DeKok wrote:
>The document should explain this in detail, and suggest which message flows
>are preferred, and which >ones MUST be supported. It should explain what
>happens when resumption is negotiated, and 20
>tickets are received by the peer. What does that mean? What does the peer do
Hi,
I think it is important to point out that the discussion has been about
_protected_ result indications. RFC 3748 discussed protected and non-protected
result indications. Also worth noting that it is not possible with protected
failure indication when the server does not accept the ClientHe
Hi,
Bernard brought up compability with RFC 4137 and the need for protected
alternate indication of success in the context of EAP-TLS 1.3
https://mailarchive.ietf.org/arch/msg/emu/F-LcEX3UbAEX20Amk0xBBqfPQNQ/
I think we need to discuss this in a general EAP setting as this in not EAP-TLS
speci
Hi,
I personally fine with writing MUST send an Error alert if the WG wants that.
This would maybe help with using close_notify as an alternate success
indication.
The most pressing question regarding alerts is if EAP-TLS can force the TLS
implementation to not use close_notify in any situatio
Hi,
I made several updates to the text based on your comments.
My earlier comments on the early ticket was wrong, it is not a bug. The ticket
in OpenSSL is still valid but the server does cannot calculate the PSK before
it has received the client Finished.
All message flows are correct. There
should ask the TLS WG.
John
-Original Message-
From: John Mattsson
Date: Friday, 5 February 2021 at 20:36
To: EMU WG
Subject: [Emu] EAP-TLS and TLS alerts
Hi,
Alerts are definitly not mandatory in TLS 1.3. Adding a note stating that
alerts are not mandatory seems like a good idea. But
Hi,
Alerts are definitly not mandatory in TLS 1.3. Adding a note stating that
alerts are not mandatory seems like a good idea. But "suggests" seems like the
wrong word and optional != SHOULD.
I would like more feedback from other people before adding new requirements on
TLS. Can an application
Not sure that OpenSSL current default behavior is interesting for the draft.
None of the Tickets in the draft are invalid.
The tickets in Figure 2 are different messages.
Sending a ticket with Finished after asking for client auth seems like a
implementaion bug.
As far as I understand, a ser
Some quick comments below:
Alan DeKok wrote:
>So it's possible for a malicious client to get the ticket, and close the
>connection without >sending a client cert. Then, if the EAP server doesn't
>destroy the ticket, the client can >reconnect.
The resumption_master_secret includes the client f
Hi,
I re-read all the mails written on the EMU list the last month to see if any
comments and suggestions had been forgotten. Based on that, the following
smaller changes were added to the GitHub version and are planned for the next
version:
- Added references to ietf-emu-tls-eap-types as sugg
Hi Joe,
Good initiative.
1. To have an alternate success indication is new. The requirement needs to be
the possibility to have an _protected_ success indication. This is requires in
at least IEEE 802. It seems to be a weakness in the IEEE 802 spec, but EAP-TLS
simply has to align with this. I
described when the "keying material becomes available" which
is the words used by RFC 4137 for eapKeyData and aaaEapKeyData.
Open question if Section 2.5 should say something about TLS 1.2.
Cheers,
John
From: John Mattsson
Date: Thursday, 4 February 2021 at 15:22
To: Bernard Ab
From: Eric Rescorla
Date: Thursday, 4 February 2021 at 15:32
To: John Mattsson
Cc: EMU WG , Benjamin Kaduk , "t...@ietf.org"
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
On Thu, Feb 4, 2021 at 6:29 A
S 1.3, I do not think any future additions to TLS 1.3 would be needed for
EAP-TLS 1.3.
From: John Mattsson
Date: Thursday, 4 February 2021 at 13:18
To: Bernard Aboba , "emu@ietf.org" ,
"t...@ietf.org"
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine
Hi
Hi Bernard,
I (re-)read the papers you send.
- "Extensible Authentication Protocol Vulnerabilities and Improvements
Improvements"
This paper talks attacks on availability by spoofing messages. It looks into
a small amount of ways where spoofed messages causes the TLS connection to
fail, esp
Hi,
I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS interact
better is a very promising idea. This would probably take some time to get
specified and implemented so it is probably a future
optimization/simplification rather that something EAP-TLS 1.3 should wait for.
An ext
Hi,
I would strongly encourage people to make concrete and well-defined issues on
GitHub for any major issues that you think need to be addresses before -13, -14
or -xx progress.
Mailing issues to the list is of course also accepted but tend to get dragged
into long conversations and are not a
Alan DeKok wrote:
>Does that mean all open issues have been addressed and resolved?
>
>The current suggestion from Eric is to *not* use application data, but to use
>>CloseNotify instead. Does this mean the earlier discussion was wrong, or is
>the >current suggestion wrong? Are we allowed to
ilure for any reason
Cheers,
John
-Original Message-
From: John Mattsson
Date: Wednesday, 3 February 2021 at 00:48
To: "emu@ietf.org"
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine
Alan wrote:
> wrote:
>> 4. was something I thought was clear. T
Hi,
There was several recent comments on close_notify and the ability to send alert
messages. My understanding is that the message flow in -14 allows the important
alert messages to be sent. The server can always send an alert explaining why
client authentication failed. This should be a hard r
Hi,
Thanks, that is good information. Note that RFC 4137 is informative examples of
how EAP can be implemented and not even mentioned in RFC 5216. Given this
discussion it feels like RFC 5216 also needs to follow RFC 4137 or do something
similar to be secure. RFC 5216 do not say anything about
Alan wrote:
> wrote:
>> 4. was something I thought was clear. The -13 version states that “The
>> EAP->TLS server commits to not send any more handshake messages”. This was
>> >according to my memory exactly what was requested from the implementors.
>
> The text is in draft-mattsson-eap-tls13-0
Hi,
Bernard Aboba wrote:
> The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3
> interacts with the EAP state machine as specified in RFC 4137
> The issue in the EAP-TLS 1.3 specification is that the interlock with these
> variables is not defined
It is definitely true tha
Alan DeKok wrote:
>The diagram suggests that it's possible for the EAP-TLS server to separate the
>"TLS Finished" >messages from the "NewSessionTicket" message. There is no
>guidance as to how this is done. >After spending some time going through RFC
>8446 and OpenSSL docs / code, it's not cl
rg"
Date: Tuesday, 2 February 2021 at 17:28
To: John Mattsson , John Mattsson
, Mohit Sethi
Subject: New Version Notification for draft-ietf-emu-eap-tls13-14.txt
A new version of I-D, draft-ietf-emu-eap-tls13-14.txt
has been successfully submitted by Mohit Sethi and posted to the
IETF rep
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
Hi,
I am not very happy with adding an additional dummy roundtrip to the 5G
certificate authentication. Fragmentation and slow databases can be optimized
away (short chains, small certs, 4K or 9K frames) but a mandatory extra
roundtrip stays forever.
Without fragmentation, EAP-TLS 1.3 is now w
Hi,
Looking at the GitHub version after the latest changes. I don't think the
tradeoffs make sense anymore.
- Full handshake is now 4.5 round-trips
- Resumption is now 4.5 round-trips.
This does not seem like a good tradeoff or optimization at all. If we instead
skipped Resumption, the full h
Hi,
TLS 1.3 (RFC 8446) Section 4.6.3 allows both client and server to send a
KeyUpdate Post-Handshake message. Doing so directly after the handshake and
without any application data being sent does not make that much sense, but is
allowed.
Should the draft say something about the KeyUpdate mes
Hi Mohit,
Great! I agree.
John
-Original Message-
From: Mohit Sethi M
Date: Friday, 20 November 2020 at 09:11
To: John Mattsson , "emu@ietf.org"
Subject: Re: [Emu] I-D Action: draft-ietf-emu-eaptlscert-07.txt
Hi John,
On 11/20/20 7:33 AM, John Mattsson wrote:
> L
Looking at the references in the document:
"Suppressing Intermediate Certificates in TLS" has not been updated since March
2019. It looks like the TLS working group is not working on this extension. We
should maybe ask Martin, if he is planning to drive this in the future, or if
it has been rep
to
be real-time you need to make an online OCSP request-response to the OCSP
responder.
John
-Original Message-
From: Eliot Lear
Date: Monday, 26 October 2020 at 13:16
To: John Mattsson
Cc: "emu@ietf.org"
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
Hi
Hi,
When this was discussed in the group, it was decided to not only mandate
revocation checking, but to also mandate OCSP stapling as is it often the only
viable solution to let an offline peer check the revocation status of the
server. We had a discussion on must-staple, and the decision was
a need to
add a note like:
"Note that in TLS 1.3, all application data including the Commitment Message is
protected through authenticated encryption."?
John
-Original Message-
From: Alan DeKok
Date: Tuesday, 22 September 2020 at 15:17
To: Jorge Vergara
Cc: John Mattss
ssary to update any TEAP TLS 1.2
code, but it definitely feels like a worthwhile thing to do when the
implementation is anyway updated for TLS 1.3.
-Original Message-
From: Emu On Behalf Of Alan DeKok
Sent: Tuesday, September 1, 2020 1:59 PM
To: John Mattsson
Cc: emu@ietf.org
Subject: Re:
Hi,
I have reviewed draft-ietf-emu-tls-eap-types-01. Looks good. Two crypto related
comments below:
- "MAC is the MAC function negotiated in TLS 1.3."
There is no MAC function negotiated in TLS 1.3. Also, a modern TLS
implementation would not negotiate any MAC funtion in TLS 1.2 as they would
EAP-Response/
EAP-Type=EAP-TLS >
< EAP-Success
Figure 1: EAP-TLS mutual authentication
Cheers,
John
-Original Message-
From: Alan DeKok
Date: Tuesday, 1 September 2020 at 14:51
To: John Mattsson
Cc: John Mattsson , Mohit Sethi M
, Jor
ient
authentication.
Cheers,
John
-Original Message-
From: Emu on behalf of John Mattsson
Date: Tuesday, 1 September 2020 at 10:10
To: Mohit Sethi M , Alan DeKok
, Jorge Vergara
Cc: Mohit Sethi M , Benjamin Kaduk ,
EMU WG
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3
1 - 100 of 185 matches
Mail list logo
