See inline for additional comments on some of the drafts. From: Alan DeKok <[email protected]> Date: Tuesday, 18 January 2022 at 14:01 To: John Mattsson <[email protected]> Cc: EMU WG <[email protected]> Subject: Re: [Emu] EMU Meetings On Jan 15, 2022, at 6:12 AM, John Mattsson <[email protected]> wrote: > - 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.
Agreed. > - ACE WG seems to be done with draft-ietf-ace-wg-coap-eap. Would be good if > more people from EMU WG reviewed this before it goes to IESG. I don't understand that one. Reading the document doesn't clear up a lot for me. > - There is a large amount of suggested work that might or not fit in the > current charter. At some point we should discuss if and how to recharter. > > draft-arkko-emu-rfc3748bis I heard significant opposition to that at the last EMU meeting. I don't see a compelling reason to rev 3748. John: I think we should get back to this topic for more discussion on if and how. Bernard expressed opposition to obsolete as he said that would require recertification of products. But there was also a suggestion that we should instead do Internet Standard instead. EAP does definitly deserve to be an Internet Standard. Another suggestion was to make an update instead of obsolete which would not trigger recertification. The following has been brought up as reasons for doing some kind of update: - EAP is essential for network acces authentication and should be an Internet Standard - "Master" should be changed to "Main" tofollow inclusive language recommendations (TLS is already doing this). - Several of the methods defines in RFC 3748 like MD5-Challenge would benefit from security consideration and references to more recommended methods such as EAP-TLS. - There are errata. - The consideration and recommendations for identity protection is not up to data with current best practice. - RFC 3748 does not even mention forward secrecy is more and more becoming a requirement to acceptable security. - Mention new access technologies such as 5G where EAP is an essential part. - Mention of recommend use of documents such as [RFC4137] [RFC5113] [RFC5247] [RFC6677] [RFC7029]. IETF is at least nowadays very often making updates such as this (RFC7296, RFC8446bis, RFC7616, RFC8489, RFC8656, RFC8445, etc.) My personal view would be that the security considerations considering MD5, identity protection, and forward secrecy would be worthwhile doing in some way. It would also be good to mention essential updates such as RFC 4137. > draft-dekok-emu-eap-usability That's had little discussion. Recent updates to Passpoint (XML config file, pretty much as proposed by Stefan Winter) make it less relevant. But it could still be useful. > draft-lear-eap-teap-brski I have no comments here. > draft-mattsson-emu-eap-tls-psk This needs a bit of fleshing out. If we do PSK / password checking in the TLS layer, then the users identity must be public, which compromises privacy. I'm not sure how this is preferable to TTLS + PAP. John: I am also very sceptical to the security properties and scope of this draft, which is a reason that is has not been updated. As you say, most use of PSKs compromise privacy. The only exception would be when the PSK identity is only used once. In some deployments it does not make sense that the background authentication server (which might be owned by a different entity than the authenitcator) has access to the key used to encrypt communication betweed the peer and the authenticator. After the first EAP session, the peer and the authenticator should in such deployments do ECDHE authenticated with the MSK. Not sure if this MSK+ECDHE would be EAP or if it is already solved by any existing methods. There is also a stange and mostly wrong conception that PSKs are needed for IoT, that is not correct unless you go to ridicolously constrained devices. PSK is never needed for constrained radio as PSK and public key authentication and key exchange can be done in the same message sizes (using implicit authentication or NIKE). The added processing latency is negligible for bootstrapping use cases. Public key authentication require slightly more code, but that is required for forward secrecy anyway and well worth it. Public keys makes key distribution much easier. I think mandatory forward secrecy and identity protection should be requirents in new EAP methods (but if PFS is done between the peer and the authenticator, it might be skipped between the peer and the backend authentication server). - I think it could maybe make sense to have a good PSK+ECDHE EAP method for use cases where the PSK identity is used once, but that should not focus on IoT. Might be that TTLS + PAP is preferable. - I also think Russ' use cases of using Certificates and PSK made sense, but that use case will likely be replaced by PQC algorithms quite soon. - For constrained IoT radio, TLS 1.3 handshake messages are huge. If IoT is the focus I think EAP-EDHOC and/or EAP-cTLS would make a lot more sense. > draft-ingles-eap-edhoc That seems useful for limited situations (i.e. IoT). It also has issues with publicizing identities. John: I think the only thing that is missing is to mandate use of ananymous NAIs. > draft-chen-emu-eap-tls-ibs I have the same comments as above. Alan DeKok.
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
