[Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
I am just finally getting caught up on mail for the EMU WG and am getting this done. It should probably be clarified that Figure 1has the additional restriction that the server is not sending any resumption tickets as well.It would also be better to label the TLS Application Data as the commitment message as no other TLS Application data is being sent. I think that it might be reasonable to put in a note for Figure 2 that if a client does receive a fatal from the hello message, then changing the offered key share algorithm is one thing that might be successful in the future - That is put in a note to match what the request retry message does. Okay - I found the use of the retry down below but it is not referenced from here but it is still labeled as a server rejects the client hello. In section 2.1.5 - You are mandating support for resumption. Is this really what you are planning to do? If this is true then lots of the previous text seems to be off because this is not part of that discussion. In section 2.1.6 - Should there be a recommendation (or not) that when a resumption ticket is used, then a new ticket (or set of tickets) ought to be provided to the client. In section 2.5 - I don't know that I have the ability to control what the TLS block looks like to the extent that this seems to be wanting to do. In section 5.7 - I am not sure why one could not re-check for revocation when doing a resumption, I would expect that this is only server side that would do it but the current paragraph two outlaws it. I am a little surprised that the padding feature of TLS 1.3 received absolutely no mention in this document. Jim ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-00.txt
Hi, I read the whole document again. I think it is in a good shape. Some quick high level comments. I will do a more detailed review(s) later - I think this should formally update rfc5448bis - "This specification is an optional extension to the EAP-AKA'" While the extension is not mandatory, I think the draft should somewhere say that use of the extension is strongly recommended instead of just stating that it is optional. - "This specification is an optional extension to the EAP-AKA' authentication method which was defined in RFC 5448 (to be superseded by draft-ietf-emu-rfc5448bis)." With RFC5448bis almost done, I think this could be changed to - "This specification is an optional extension to the EAP-AKA' authentication method defined in draft-ietf-emu-rfc5448bis." - "from being able to decrypt all past communications." True, but this could be more specificly described as "from being able to decrypt any past communications." - " 3rd generation AKA " I don't think it is third gen AKA, rather 3G aka in the sense of AKA for 3G - "When AKA (and AKA')" AKA' is not explained anywhere - "Perfect Forward Secrecy" vs. "Perfect Forward Security" Draft uses both. PFS is stated to stand for the Security version. I suggest only using one of them. - Whould be good to say something small about active vs. passive attacks early. Just a few sentences that active attacks are much more resource demanding and can be detected. - "This method is referred to as ECDHE" Could say "This method is referred to as ECDHE or ECDH-EE" TLS calls it ECDHE while some other IETF protocols call it ECDH-EE - "i.e., using temporary keys" I suggest "using only temporary keys" to differentiate from ECDH-ES that use one static key pair and one ephemeral key pair. - "Curve25519 group specified in [RFC8031]." I think the group is specified in RFC 7748 - The draft should probably mention 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 detecting active attackers. - "I-D.mattsson-eap-tls13" -> "I-D.ietf-emu-eap-tls13" - "John Mattson" -> "John Mattsson" - "SIM" vs. "USIM" vs. "(U)SIM" The document uses all three. Could maybe cut down to one or two. Cheers, John ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-06.txt
The did not get any feedback on the suggested changes I send out on Thu, 25 July 2019 so I submitted that version as -06 that addresses all the comments made during the WGLC. Cheers, John -Original Message- From: Emu on behalf of "internet-dra...@ietf.org" Reply to: "emu@ietf.org" Date: Saturday, 3 August 2019 at 10:25 To: "i-d-annou...@ietf.org" Cc: "emu@ietf.org" Subject: [Emu] I-D Action: draft-ietf-emu-eap-tls13-06.txt 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 : Using EAP-TLS with TLS 1.3 Authors : John Mattsson Mohit Sethi Filename: draft-ietf-emu-eap-tls13-06.txt Pages : 28 Date: 2019-08-03 Abstract: This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP- TLS. TLS 1.3 provides significantly improved security, privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 further improves security and privacy by mandating use of privacy and revocation checking. This document updates RFC 5216. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-06 https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-06 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 ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05
Then draft-dekok-emu-tls-eap-types will have to describe how TLS-based EAP types do or not do the commit with application data. As far as I understand, 0x00 will work for these other EAP types as well, so not need to change any thing in draft-ietf-emu-eap-tls13. Cheers, John -Original Message- From: Alan DeKok Date: Monday, 29 July 2019 at 00:51 To: Jim Schaad Cc: Jouni Malinen , John Mattsson , EMU WG Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05 On Jul 28, 2019, at 5:09 PM, Jim Schaad wrote: > > I cannot speak to PEAP, but it would seem that TEAP might need this feature > as, at least on resumption, it is totally optional for both sides to use any > TLVs an thus the same issue might be present. TTLS seems to always require > that the client send a AVP, but I am not sure that it is required for the > server based on a really fast read. For initial authentication, TTLS requires TLVs inside of the TLS tunnel. For resumption, the inner tunnel isn't used. So it looks like the other TLS-based EAP methods will have the same issue, when resumption is used. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] I-D Action: draft-ietf-emu-eap-tls13-06.txt
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 : Using EAP-TLS with TLS 1.3 Authors : John Mattsson Mohit Sethi Filename: draft-ietf-emu-eap-tls13-06.txt Pages : 28 Date: 2019-08-03 Abstract: This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP- TLS. TLS 1.3 provides significantly improved security, privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 further improves security and privacy by mandating use of privacy and revocation checking. This document updates RFC 5216. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-06 https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-06 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
