Re: [Emu] [Reap] EAP - TLS 1.3

2017-12-01 Thread John Mattsson
Thanks for your comments Alan. Very helpful. See answers and comments below: On Nov 16, 2017, Alan DeKok wrote: >That's good. But as Bernard points out, there's no need to change >EAP-TLS. You can just use TLS 1.3. I don’t agree with that, see concrete details below. >How so? 5216 says

Re: [Emu] [Reap] EAP - TLS 1.3

2017-12-01 Thread John Mattsson
Hi Bernard, On Thu, Nov 19, 2017, Bernard Aboba wrote: >The big question is "Why not create a new EAP method"?  >The overall intent seems to be to create an pre-shared key EAP method >optimized for 5G, >based on EAP-TLS v1.3.   I don’t know why you have gotten the idea that the intent is

Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-00.txt

2018-05-31 Thread John Mattsson
A diff from the last version can be found here: https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-mattsson-eap-tls13-02.txt=https://www.ietf.org/id/draft-ietf-emu-eap-tls13-00.txt Except editorials, the main change is that the Exporter labels has been changes to conform with

Re: [Emu] I-D Action: draft-ietf-emu-rfc5448bis-00.txt

2018-06-26 Thread John Mattsson
Hi, This looks very good, I looked through the document quickly and have some mostly editorial comments. - I think the document still need to have the first-page header "Updates: 4187". My understanding of Obsoletes is that it replaces the older document and that the new document can be used

Re: [Emu] Fwd: New Version Notification for draft-arkko-eap-aka-pfs-01.txt

2018-06-26 Thread John Mattsson
Now that draft-ietf-emu-eap-tls13 and draft-ietf-emu-rfc5448bis has been adopted, I think it is time to start discussing the remaining things that the working group has been charted to do. I think Perfect Forward Secrecy (PFS) and privacy are very important targets for the group. RFC 7258

Re: [Emu] EAP-TLS with large certificates

2018-01-25 Thread John Mattsson
TLS 1.3 also changes which of the certificates that can be omitted. TLS 1.2 (and earlier) only allows omitting the self-signed root certificate while TLS 1.3 allows omitting any trust anchor certificate. This would be useful in cases where the possessed trust anchors are known. TLS 1.2: "the

Re: [Emu] Potential re-establishment of the EMU working group

2017-12-22 Thread John Mattsson
On Dec 21, 2017, Alan DeKok wrote: >The question I have is whether we can do anything to EAP-TLS to address the >issue. Answering that question >requires a deeper dive into TLS. In TLS 1.3, ECC is mandatory to support. This drastically reduces the sizes of certificates and signatures (public

Re: [Emu] I-D Action: draft-ietf-emu-rfc5448bis-01.txt

2018-07-17 Thread John Mattsson
Hi, I reviewed the new -01 version. Looks very good. Some additional comments: -- Section 1 - Section 5 and 6 is missing from the document structure description. Is this intentional? - OLD "updates to RFC 5448 AKA' and" NEW "updates to RFC 5448 EAP-AKA' and" -- Section 3 - Some of the

[Emu] FW: New Version Notification for draft-mattsson-eap-tls13-02.txt

2018-03-06 Thread John Mattsson
a...@ietf.org> wrote: A new version of I-D, draft-mattsson-eap-tls13-02.txt has been successfully submitted by John Mattsson and posted to the IETF repository. Name: draft-mattsson-eap-tls13 Revision: 02 Title: Using EAP-TLS with TLS

Re: [Emu] Call for agenda items

2018-03-05 Thread John Mattsson
Hi Joe, I’d like us to discuss the use of EAP-TLS with TLS 1.3 as well as strategies on how to avoid fragmentation due to large certificates and certificate chains in all versions of EAP-TLS. I plan to submit a new version of draft-mattsson-eap-tls13. Cheers, John

Re: [Emu] Agenda Items for IETF 102

2018-06-28 Thread John Mattsson
Hi Joe, I would like to request time to discuss draft-ietf-emu-eap-tls13. The discussion topics would be the issues highlighted by Jouni Malinen. - EAP state machine and EAP TLS with 1.3 - Sending additional information in the Flags byte - Send payload in EAP-Success - Derivation of

Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-00.txt

2018-06-28 Thread John Mattsson
John: Thanks Jouni, very good comments. Great to get feedback from implementation. I think there is a slight mismatch between the assumptions in TLS and EAP, 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

[Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-02.txt

2018-10-16 Thread John Mattsson
al Message- From: "internet-dra...@ietf.org" Date: Tuesday, 16 October 2018 at 22:30 To: Mohit Sethi , John Mattsson Subject: New Version Notification for draft-ietf-emu-eap-tls13-02.txt A new version of I-D, draft-ietf-emu-eap-tls13-02.txt has been successfully submitted by John M

[Emu] FW: New Version Notification for draft-ms-emu-eaptlscert-01.txt

2018-10-22 Thread John Mattsson
as well as reviews of the whole document are very welcome. Cheers, John -Original Message- From: "internet-dra...@ietf.org" Date: Monday, 22 October 2018 at 12:26 To: Mohit Sethi , John Mattsson Subject: New Version Notification for draft-ms-emu-eaptlscert-01.txt A new ve

[Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt

2018-11-14 Thread John Mattsson
veral editorials. Cheers, John -Original Message- From: "internet-dra...@ietf.org" Date: Wednesday, 14 November 2018 at 13:20 To: Mohit Sethi , John Mattsson Subject: New Version Notification for draft-ietf-emu-eap-tls13-03.txt A new version of I-D, draft-ietf-emu-eap-tls13-03.txt

[Emu] NIST to Withdraw SP 800-120 “Recommendation for EAP Methods Used in Wireless Network Access Authentication”

2018-10-04 Thread John Mattsson
FYI,   NIST has decided to withdraw SP 800-120 “Recommendation for EAP Methods Used in Wireless Network Access Authentication” on October 19, 2018. The document SP 800-120 is out of date and NIST is instead referring to relevant IETF standards.

[Emu] EAP-TLS 1.3 TLS-Exporter context_value

2019-01-11 Thread John Mattsson
Hi, RFC 8446 defines the TLS-Exporter interface as: TLS-Exporter(label, context_value, key_length) draft-ietf-emu-eap-tls13 is using the exporter interface without context: Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128) IV =

[Emu] TLS attacks relevant for EAP-TLS

2019-01-11 Thread John Mattsson
Hi, The draft "Using EAP-TLS with TLS 1.3" (draft-ietf-emu-eap-tls13-03) specifies the use of EAP-TLS with TLS 1.3: https://tools.ietf.org/html/draft-ietf-emu-eap-tls13 https://github.com/emu-wg/draft-ietf-emu-eap-tls13 In Bangkok the EMU WG decided to analyse if some of the known attacks on

Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-01.txt

2018-09-19 Thread John Mattsson
-emu-eap-tls13-01.txt has been successfully submitted by John Mattsson and posted to the IETF repository. Name: draft-ietf-emu-eap-tls13 Revision: 01 Title: Using EAP-TLS with TLS 1.3 Document date: 2018-09-18 Group: emu Pages: 19 URL: https://

Re: [Emu] Implementation report for EAP-TLS 1.3: OK, with nits

2019-01-28 Thread John Mattsson
Hi Alan, Great news that you have done interoperability testing of EAP-TLS 1.3 and that you have not found any major issues. I think it is very good to inform implementors about the use of the length values to ensure combability. I have added your suggested text to the GitHub.

Re: [Emu] Implementation report for EAP-TLS 1.3: OK, with nits

2019-01-28 Thread John Mattsson
Hi Alan, The intention with "All other parameters such as MSK and EMSK are derived as specified in EAP-TLS [RFC5216], Section 2.3." was to only mention changes compared to RFC 5216. Avoiding potential confusion is a very important goal to avoid incompatible implementations. I think we should

Re: [Emu] TLS 1.3 and other EAP methods

2019-01-28 Thread John Mattsson
>Sure. The question then becomes one of encoding. For types < 256, 1 octet is >>enough. For others, it should be a 32-bit number in network byte order. Maybe we can state that it is the EAP Method Type value in network byte order with any leading bytes of value zero removed? Then 13 is

Re: [Emu] Implementation report for EAP-TLS 1.3: OK, with nits

2019-01-28 Thread John Mattsson
Hi Alan, >> Should all of the following be added to draft-ietf-emu-eap-tls13? >> >> MSK = Key_Material(0, 63) >> EMSK = Key_Material(64, 127) >> Enc-RECV-Key = MSK(0, 31) >> Enc-SEND-Key = MSK(32, 63) >> RECV-IV = IV(0, 31) >> SEND-IV = IV(32, 63) > I

[Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

2019-04-03 Thread John Mattsson
Michael Richardson wrote: >I implemented server side EAP-SIM and EAP-AKA back 16 some years ago. >Based upon the many emails I got asking for help configuring EAP-SIM, and >the zero I got for EAP-AKA, I have never been sure to what extend AKA >really go out there. Is the nano-SIM in my phone

Re: [Emu] Review of draft-ietf-emu-eap-tls13-04

2019-03-21 Thread John Mattsson
Thanks for the thorough review Jim! -Original Message- From: Jim Schaad Date: Wednesday, 20 March 2019 at 11:03 To: "draft-ietf-emu-eap-tl...@ietf.org" Cc: 'EMU WG' Subject: Review of draft-ietf-emu-eap-tls13-04 Resent-From: Resent-To: John Mattsson , Resent-Date: Wed

[Emu] EAP-TLS 1.3 - Session-Id and extended EAP types

2019-03-24 Thread John Mattsson
Noticed the following: draft-ietf-emu-eap-tls13-04 defines the key hierarchy as Type-Code= 0x0D Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", Type-Code, 128) IV = TLS-Exporter("EXPORTER_EAP_TLS_IV",

Re: [Emu] Review of draft-ietf-emu-eap-tls13-04

2019-03-24 Thread John Mattsson
Jim Schaad wrote: >> I suggest writing: >> >> TLS 1.3 introduced early application data which is not used in EAP-TLS. A >> server which receives an "early_data" extension MUST ignore the extension >> or respond with a HelloRetryRequest as described in Section 4.2.10 of RFC >> 8446. > > That is

[Emu] TLS Resumption across Server Name Indications for TLS 1.3

2019-03-25 Thread John Mattsson
https://tools.ietf.org/html/draft-sy-tls-resumption-group This document will be discussed today in the TLS WG 11.20 - 12.20. Might be interesting for the discussion on cross method resumption for TLS-based EAP methods. Cheers, John ___ Emu mailing

Re: [Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

2019-04-06 Thread John Mattsson
I think it is of utter importance that PFS for AKA gets published and deployed. The great SIM heist was a disaster for cellular security. The extension of the heist is not known, and the report from Gemalto was a joke trying to sweep thing under the rug. Potentially billions of secret keys

[Emu] FW: [TLS] Comment on draft-thomson-tls-sic-00

2019-03-29 Thread John Mattsson
it does. Use of this draft requires pre-distributing all intermediary certificates. John -Original Message- From: TLS on behalf of John Mattsson Date: Friday, 29 March 2019 at 10:30 To: "t...@ietf.org" Subject: [TLS] Comment on draft-thomson-tls-sic-00 Hi, I a

[Emu] FW: Comment on draft-thomson-tls-sic-00

2019-03-29 Thread John Mattsson
time on TLS 1.2. Cheers, John -Original Message- From: John Mattsson Date: Friday, 29 March 2019 at 11:34 To: "t...@ietf.org" Subject: Re: Comment on draft-thomson-tls-sic-00 Some more comments after reading the draft in detail. - The abstract and introduction

Re: [Emu] Notes on session resumption with TLS-based EAP methods

2019-02-20 Thread John Mattsson
Alan DeKok ; wrote: >The issue with session resumption is much larger than just the EAP method. >This subject should ideally be discussed in the "Security Considerations" >section of the new EAP-TLS draft. I agree >i.e. We should define precisely what a "session" is. > >Right now, the draft

Re: [Emu] Notes on session resumption with TLS-based EAP methods

2019-03-06 Thread John Mattsson
Thanks for the suggested security consideration Alan! This helps a lot! I'll will work with updating the draft during the next days. Your suggested text look very good at a first readthrough. Cheers, John ___ Emu mailing list Emu@ietf.org

Re: [Emu] Notes on session resumption with TLS-based EAP methods

2019-02-21 Thread John Mattsson
Alan DeKok ;; wrote: >This security bug was completely missed in RFC 5216. This new draft should >rectify that error. > >i.e. using an NAI of "example.org" in the first session, and "example.com" in >the second session. > >Not only is this entirely permitted by the current spec, it's not

Re: [Emu] EAP and Fragmentation

2019-03-15 Thread John Mattsson
Alan wrote: >I've done a quick check. On reception, FreeRADIUS accepts the L bit for any >type of message. It doesn't care >about fragments, just that the length is >correct. > >For sending packets, FreeRADIUS sets the L bit only if it is sending >fragments. That is probably the correct

[Emu] FW: New Version Notification for draft-ietf-emu-eap-tls13-04.txt

2019-03-13 Thread John Mattsson
Monday, 11 March 2019 at 22:06 To: Mohit Sethi , John Mattsson Subject: New Version Notification for draft-ietf-emu-eap-tls13-04.txt A new version of I-D, draft-ietf-emu-eap-tls13-04.txt has been successfully submitted by John Mattsson and posted to the IETF repository. Name: draft-ietf-em

[Emu] FW: New Version Notification for draft-ms-emu-eaptlscert-02.txt

2019-03-13 Thread John Mattsson
2019 at 21:06 To: Mohit Sethi , John Mattsson , Sean Turner Subject: New Version Notification for draft-ms-emu-eaptlscert-02.txt A new version of I-D, draft-ms-emu-eaptlscert-02.txt has been successfully submitted by John Mattsson and posted to the IETF repository. Name: draft-ms-emu-

Re: [Emu] Notes on session resumption with TLS-based EAP methods

2019-03-11 Thread John Mattsson
Hi, There seems to be agreement on the list to add security considerations on authorization and resumption. With the text from Alan as a basis (thanks again Alan!), I have added the sections below to draft-ietf-emu-eap-tls13. Some high level changes from Alas text: - Some considerations also

Re: [Emu] Question about draft-ietf-emu-eap-tls13-03 && application data

2019-03-10 Thread John Mattsson
Hi, As there was no objections, I made the following changes to the GitHub version that will appear in draft-ietf-emu-eap-tls13-04 Section 2.1.1 OLD: As stated in [RFC5216], the TLS cipher suite shall not be used to protect application data. This applies also for early application

Re: [Emu] EAP and Fragmentation

2019-03-10 Thread John Mattsson
Welcome and thanks for your comments Oleg! slon v sobstvennom palto ; wrote: >Per my experience the existing fragmentation method described in EAP-TLS >RFC 5216 serves good for all fragmentation needs. The method is reused by >PEAP, EAP-FAST, TEAP and EAP-TTLS. There's an ambiguity in EAP-TLS

Re: [Emu] Notes on session resumption with TLS-based EAP methods

2019-02-08 Thread John Mattsson
Re: [Emu] Notes on session resumption with TLS-based EAP methods Mohit Sethi M ; wrote: > >For me, an EAP-TLS server should not only refuse resumption if a client >was not authenticated, it should also refuse resumption if the client >was authenticated with other methods than certificates

Re: [Emu] WGLC for RFC5448bis

2019-02-14 Thread John Mattsson
Hi, I have reviewed this draft multiple times, I think this draft is very well-written and ready to be published. A few minor comments: - "3rd Generation Authentication and Key Agreement" I see that this exact term was used in RFC 5448, but I find it quite strange. I think the terminology is

Re: [Emu] Notes on session resumption with TLS-based EAP methods

2019-02-06 Thread John Mattsson
I think this is a very good discussion to have. Any problems with peer authentication would (at least in theory) affect pure EAP-TLS as well. RFC 5216 states that: RFC 5216: "While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances in which

Re: [Emu] Question about draft-ietf-emu-eap-tls13-03 && application data

2019-02-01 Thread John Mattsson
Hi Alan > Alan DeKok ; wrote: > >> The mentioned requirement comes from Section 2.4 of RFC 5216, which states >> that: >> >> "Since the ciphersuite negotiated within EAP-TLS applies only to the EAP >> conversation, TLS ciphersuite negotiation MUST NOT be used to negotiate the >>

Re: [Emu] Notes on session resumption with TLS-based EAP methods

2019-02-02 Thread John Mattsson
Hi Alan, Very good that this is discussed and highlighted. My understanding is that TLS itself clearly allows a resumed connection to be used for a completely different purpose. The ALPN specification (RFC 7301) says that: "When session resumption or session tickets [RFC5077] are used, the

Re: [Emu] Notes on session resumption with TLS-based EAP methods

2019-02-02 Thread John Mattsson
Alan DeKok ; wrote: >I would suggest then referencing or duplicating the above text, and saying >something like: > >--- >Implementations SHOULD be capable of session resumption across different >TLS-based EAP types. This recommendation is made for a few reasons. It is >recommended by

Re: [Emu] TLS 1.3 and other EAP methods

2019-02-03 Thread John Mattsson
Based on this discussion I suggest changing the title and the scope of draft-ms-emu-eaptlscert OLD: "Handling Large Certificates and Long Certificate Chains in EAP-TLS" NEW: "Handling Large Certificates and Long Certificate Chains in TLS-based EAP Methods" The problem description, discussion,

Re: [Emu] Session identifiers for fast re-authentication

2019-02-03 Thread John Mattsson
Looks good! I only have editorial comments - "defintion" - "implemementations" - " Session-Id = 0x19 || client.random || server.random). This definition is already in wide-spread use in multiple PEAP" Should remove ")." and add a blank line. - I noticed that this draft and

Re: [Emu] TLS 1.3 and other EAP methods

2019-01-31 Thread John Mattsson
Hi Alan, David, I also strongly agree that all TLS-based EAP methods in use should be capable of working with TLS 1.3. You make a very strong case that this need to happen as soon as possible and that the most practical approach is to add the information to draft-ietf-emu-eap-tls13. Just like

Re: [Emu] Question about draft-ietf-emu-eap-tls13-03 && application data

2019-01-31 Thread John Mattsson
Hi Alan, The mentioned requirement comes from Section 2.4 of RFC 5216, which states that: "Since the ciphersuite negotiated within EAP-TLS applies only to the EAP conversation, TLS ciphersuite negotiation MUST NOT be used to negotiate the ciphersuites used to secure data." However, I do not

Re: [Emu] TLS 1.3 and other EAP methods

2019-01-31 Thread John Mattsson
> Alan DeKok ; wrote: > > Hmm... if the changes are too complex, it may be better to have a new > document. I have a first draft written, and will be publishing it soon. It's > only about 12 pages, but it goes through a lot of detail that is likely not > relevant for the EAP-TLS document. >

Re: [Emu] EAP and Fragmentation

2019-03-15 Thread John Mattsson
Hi Oleg, >I remember that some EAP-TLS/PEAP clients rejected not fragmented messages >without L bit set, probably due to their wrong interpretation of EAP-TLS >RFC. Would it worth to say something like "Implementation SHOULD accept >unfragmented messages with and without L bit set" in addition

[Emu] FW: I-D Action: draft-ietf-emu-eap-tls13-05.txt

2019-05-26 Thread John Mattsson
raft 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 : Using EAP-TLS with TLS 1.3 Authors : John Mattsson Mohit Sethi Filename

[Emu] FW: New Version Notification for draft-ms-emu-eaptlscert-03.txt

2019-05-26 Thread John Mattsson
eers, John -Original Message- From: "internet-dra...@ietf.org" Date: Sunday, 26 May 2019 at 12:01 To: Mohit Sethi , John Mattsson , Sean Turner Subject: New Version Notification for draft-ms-emu-eaptlscert-03.txt A new version of I-D, draft-ms-emu-eaptlscert-03.txt h

Re: [Emu] Can we get a WG last call for draft-dekok-emu-eap-session-id-00 ?

2019-06-11 Thread John Mattsson
I think this should be moved forward quickly. If Alan submits the -01 version that was promised in February :) (including changes addressing Mohit's comments) I think the chairs should do adoption and WGLC quickly after each other. Cheers, John -Original Message- From: Emu on

Re: [Emu] The EMU WG has placed draft-dekok-emu-eap-session-id in state "Call For Adoption By WG Issued"

2019-07-03 Thread John Mattsson
I support adoption. I do not have any more comments at the moment, but I will review the next version. Good that this draft is moving forward. Now that RFC5448bis and EAP-TLS 1.3 are past WGLC it would be good if we could have some more discussion regarding the other two drafts concerning

Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-00.txt

2019-08-03 Thread John Mattsson
ention X25519 which is the name of the Diffie-Hellman function defined in RFC 7748. Curve25519 is the group. - "as specified in Section 2 of [RFC8031] and Section 6.1 of [RFC7748]." Why refering to two different RFCs? - The security considerations could say a little about dete

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-06.txt

2019-08-03 Thread John Mattsson
a work item of the EAP Method Update WG of the IETF. Title : Using EAP-TLS with TLS 1.3 Authors : John Mattsson Mohit Sethi Filename: draft-ietf-emu-eap-tls13-06.txt Pages : 28 Date

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

2019-08-03 Thread John Mattsson
Message- From: Alan DeKok Date: Monday, 29 July 2019 at 00:51 To: Jim Schaad Cc: Jouni Malinen , John Mattsson , EMU WG Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05 On Jul 28, 2019, at 5:09 PM, Jim Schaad wrote: > > I cannot speak to PEAP, but it

Re: [Emu] Re-charter text

2019-08-21 Thread John Mattsson
Dear chairs, Looks good to me. Some mostly editorial comments: - "EAP method" vs. "EAP type" Just noticed that different documents in EMU WG use these two different terms. I any of them preferred? - "TLS and SIM cards" "SIM cards" is just one side of AKA. There are several network nodes

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-09-12 Thread John Mattsson
See comments inline -Original Message- From: Alan DeKok Date: Thursday, 12 September 2019 at 15:56 To: Aura Tuomas Cc: EMU WG , "draft-ietf-emu-eap-tl...@ietf.org" Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Resent from: Resent to: John Mattsson , R

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-09-18 Thread John Mattsson
verifies the Finished message. I don't see why this would be more of a problem in EAP-TLS with TLS 1.3 that in any other application of EAP-TLS. /John -Original Message- From: Alan DeKok Date: Wednesday, 18 September 2019 at 15:07 To: "Owen Friel (ofriel)" Cc: John Mattsson

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-09-19 Thread John Mattsson
chaad , 'Alan DeKok' Cc: "draft-ietf-emu-eap-tl...@ietf.org" , 'EMU WG' Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Resent from: Resent to: John Mattsson , Resent date: Thursday, 19 September 2019 at 11:17 > -Original Message- > Fro

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

2019-07-24 Thread John Mattsson
Hi, Based on the discussion on the list and at the meeting today I suggest the following changes to Section 2.1, 2.5, and figures. When we agree I will make a commit to GitHub and submit a new version of the draft. With the solution suggested by Jim, there should be no need to force

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

2019-07-25 Thread John Mattsson
for commit need to be chosen so that the string does not collide with any other strings used. Cheers, John -Original Message- From: John Mattsson Date: Wednesday, 24 July 2019 at 20:49 To: Alan DeKok , Jouni Malinen , Jim Schaad Cc: EMU WG Subject: Re: [Emu] WGLC completed for for draft

Re: [Emu] I-D Action: draft-dekok-emu-eap-session-id-01.txt

2019-07-25 Thread John Mattsson
Hi, Minor comments on the 01 version. Otherwise I think the document is ready for WGLC. - I agree with Mohit that the title should be changed to something like "EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP" - Abstracts in RFCs cannot have references. [RFC5247] and [AKAP] need to be

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-07.txt

2019-09-21 Thread John Mattsson
The changes from -06 to -07 are based on the comments from Jim and Alan - Mention record padding where it makes sense (introduction, state machine, and privacy considerations) - Mention that fig 1 contains neither HelloRetryRequest nor Post-Handshake messages - Use the term Commitment Message

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-07 Thread John Mattsson
Joseph Salowey wrote: > Is the current published version up to date with the rest of the comments? Yes, to my knowledge, the current draft handles all the other comments. If we decide to leave EAP-TLS PSK discussions for another draft, I think draft-ietf-emu-eap-tls13-07 is ready to move

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-10 Thread John Mattsson
rnal-psk-importer fills a gap in the TLS 1.3 protocol, but is not a game changer in any way. John From: Mohit Sethi M Date: Thursday, 10 October 2019 at 10:03 To: Eliot Lear , John Mattsson Cc: "draft-ietf-emu-eap-tl...@ietf.org" , John Mattsson , EMU WG Subject: Re: [Emu] POST WGLC Comm

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-10 Thread John Mattsson
the main specification. From: Mohit Sethi M Date: Thursday, 10 October 2019 at 09:55 To: John Mattsson , Eliot Lear , Joseph Salowey Cc: John Mattsson , "draft-ietf-emu-eap-tl...@ietf.org" , EMU WG Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Hi, Speaking pure

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-10 Thread John Mattsson
Mohit Sethi M mailto:mohit.m.se...@ericsson.com wrote: > Can you give an example of an existing TLS 1.3 deployment that offers both > resumption PSKs and external PSKs? Don’t know if it is deployed anywhere, but OpenSSL supports resumption of PSK sessions. There was a bug that stopped it from

Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

2020-03-11 Thread John Mattsson
a transport for TLS and that the decisions of which authentication methods to support should be taken by the TLS WG. Cheers, John -Original Message- From: Russ Housley Date: Tuesday, 10 March 2020 at 18:48 To: Mohit Sethi M Cc: John Mattsson , EMU WG Subject: Re: [Emu] Late WGLC Comm

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-09.txt

2020-03-10 Thread John Mattsson
Hi, - The new version should address all the received comments from Alan and Russ regarding EAP, TLS, and Certificate identities. - New section on identities early in the document discussing identities and pointing to other sections discussing identities. - More information given on why

Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

2020-03-11 Thread John Mattsson
nt to avoid EAP-TLS (cert), EAP-TLS (psk), EAP-TLS (pwd), etc John -Original Message- From: Alan DeKok Date: Wednesday, 11 March 2020 at 12:26 To: John Mattsson Cc: Russ Housley , Mohit Sethi M , EMU WG Subject: Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13 On Mar

Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

2020-03-09 Thread John Mattsson
forward would be specify the use of [ID-ietf-tls-tls13-cert-with-extern-psk] in the same new draft as EAP-TLS with PSK authentication. Does that sound like an acceptable way forward? Cheers, John -Original Message- From: Russ Housley Date: Monday, 13 January 2020 at 18:29 To: John Mattsson

[Emu] 3GPP mandates Rel-16 EAP-TLS implementations to support TLS 1.3

2020-03-09 Thread John Mattsson
Hi, I am happy to report that 3GPP just took the decision that nodes supporting EAP-TLS shall support EAP-TLS with TLS 1.3. The changes apply to all 3GPP Rel-16 nodes. [1] The 3GPP profiling for TLS in EAP-TLS now follows the general 3GPP TLS profiling, which mandates support of TLS 1.3,

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-08.txt

2020-03-09 Thread John Mattsson
Hi Alan, Thanks for you many good suggestions. I tried to address all your comments and include all your suggestions in a recent commit to github. - I did not include an identity section as I did not see how it would fit with the structure of RFC 5216 that the draft reuses. Instead I expanded

[Emu] Status of draft-dekok-emu-tls-eap-types?

2020-03-11 Thread John Mattsson
Chairs, Alan, WG What is the status and plans for draft-dekok-emu-tls-eap-types? Several people have expressed that they would like to see this kind of draft published shortly after draft-ietf-emu-eap-tls13. But draft-dekok-emu-tls-eap-types appears rather dead, it is still an individual draft

Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

2020-09-02 Thread John Mattsson
ode, 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: [Emu] I-D Action: draft-ietf-emu-t

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

2020-09-01 Thread John Mattsson
Hi, Note that close_notify (no more data) is not an exact replacement for the Commitment Message (no more handshake data). A change from 0x00 to close_notify invalidates Figure 6: EAP-TLS unsuccessful client authentication in the document. EAP Peer

Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

2020-09-01 Thread John Mattsson
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

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

2020-09-01 Thread John Mattsson
ation. 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 Hi, No

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

2020-09-01 Thread John Mattsson
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

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

2020-09-22 Thread John Mattsson
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

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-26 Thread John Mattsson
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

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-26 Thread John Mattsson
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

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

2020-11-19 Thread John Mattsson
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

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

2020-11-20 Thread John Mattsson
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:

[Emu] NewSessionTicket, Resumption, close_notify, and number of round-trips

2021-01-27 Thread John Mattsson
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

[Emu] Encourage people to make issues on GitHub for EAP-TLS 1.3

2021-02-03 Thread John Mattsson
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

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

2021-02-04 Thread John Mattsson
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

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-04 Thread John Mattsson
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,

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-04 Thread John Mattsson
, 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 B

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

2021-02-04 Thread John Mattsson
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 AM Eri

[Emu] EAP-TLS 1.3 and KeyUpdate

2021-01-26 Thread John Mattsson
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

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

Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-14.txt

2021-02-02 Thread John Mattsson
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

Re: [Emu] EAP-TLS protected result indications

2021-02-03 Thread John Mattsson
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

Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-14.txt

2021-02-03 Thread John Mattsson
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

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-03 Thread John Mattsson
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

  1   2   >