Hi!
Section 7.5 currently states: “… introduction of a powerful enough quantum computer would disable this protocol extension's ability to provide the forward security capability. This would make it necessary to update the current ECC algorithms in this specification to PQC algorithms. This specification does not add such algorithms, but a future update can do that.” Would adding a sentence “Such algorithms must be evaluated based on performance, bandwidth consumption and security before being added.” cover your concern? BR Karl From: Meiling Chen <chenmeil...@chinamobile.com> Sent: Wednesday, 15 March 2023 08:18 To: Karl Norrman <karl.norr...@ericsson.com>; Jari Arkko <jari.ar...@ericsson.com>; Vesa Torvinen <vesa.torvi...@ericsson.com>; John Mattsson <john.matts...@ericsson.com> Cc: emu <emu@ietf.org> Subject: Re: Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt Hi, Since the differences are in PQC problem. I suggest adding a description in Section 7.5: the security and availability of PFS need to be further evaluated when PQC is used. Best, Meiling From: Meiling Chen<mailto:chenmeil...@chinamobile.com> Date: 2023-03-13 15:16 To: karl.norrman<mailto:karl.norr...@ericsson.com>; jari.arkko<mailto:jari.ar...@ericsson.com>; vesa.torvinen<mailto:vesa.torvi...@ericsson.com>; John Mattsson<mailto:john.matts...@ericsson.com> CC: emu<mailto:emu@ietf.org> Subject: Re: RE: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt Hi, There are some concerns about the use of PFS in CT network, although PFS adds some security in theory, it may not be appropriate for actual deployment. Since this is closely related to 3GPP, what are their comments? Best, Meiling From: Karl Norrman<mailto:karl.norr...@ericsson.com> Date: 2023-02-27 19:23 To: chenmeil...@chinamobile.com<mailto:chenmeil...@chinamobile.com>; Jari Arkko<mailto:jari.ar...@ericsson.com>; Vesa Torvinen<mailto:vesa.torvi...@ericsson.com>; John Mattsson<mailto:john.matts...@ericsson.com> CC: emu@ietf.org<mailto:emu@ietf.org> Subject: RE: RE: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt Hi! I understand your main concern to be that you prefer to see a solution adding PFS that is also secure against a PQ attacker and that does not increase the bandwidth consumption too much doing it. I believe there are benefits of adding a mechanism for PFS for EAP-AKA’ even if a potential future PQ attacker may break the PFS part. As discussed in section 7.5, the PFS property is added on top of EAP-AKA’. An independent DH-exchange is mixed-in with the symmetric-key AKA key establishment, so intuitively, the result is no less secure than the current protocols (even against a PQ attacker). Let’s consider the risks. - If we do nothing, we will surely not get PFS. - If we add PFS based on a DH-exchange, we won’t get PFS against attackers with PQ capabilities (which may or may not materialize, and which may or may not be very costly to obtain). - If we wait with introducing PFS until we have mechanism that has small bandwidth consumption and resists PQ attackers a lot of data will be without PFS protection against non-PQ attackers. Introducing a DH-based PFS mechanism now will not mitigate all those risks, that is true, but it allows parties to make trade-offs that suite their risk appetite. For example: - An operator who does not have the bandwidth to spare can opt to use EAP-AKA’ or native AKA. - An operator may choose to deploy EAP-AKA’ or native AKA for some devices, and EAP-AKA’-FS for others, depending on device or subscription type. The operator would have to assess the risk of PQ attackers to become a concern, and weigh that against the risk of other attacks on the long-term key as well as the consumed bandwidth. My point is that at least there would be a choice until we come up with a more bandwidth-efficient and PQ-attacker resistant mechanism. BR Karl From: Meiling Chen <chenmeil...@chinamobile.com<mailto:chenmeil...@chinamobile.com>> Sent: Monday, 27 February 2023 04:02 To: Karl Norrman <karl.norr...@ericsson.com<mailto:karl.norr...@ericsson.com>>; Jari Arkko <jari.ar...@ericsson.com<mailto:jari.ar...@ericsson.com>>; Vesa Torvinen <vesa.torvi...@ericsson.com<mailto:vesa.torvi...@ericsson.com>>; John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> Cc: emu <emu@ietf.org<mailto:emu@ietf.org>> Subject: Re: RE: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt Hi, I don't agree with you mix SUCI and D-H here, It has to be clear that SUCI is only done at the initial stage, However, authentication happens frequently, the network has the authority to initiate authentication, that means D-H Much Higher frequency. The most important issues to be discussed and solved in PFS are also our most important concerns, How to solve PQC problems that we have to take into consideration from 5G , Increase of at least 1000 bytes, How to solve this problem. Best, Meiling From: Karl Norrman<mailto:karl.norr...@ericsson.com> Date: 2023-02-13 17:21 To: chenmeil...@chinamobile.com<mailto:chenmeil...@chinamobile.com>; Jari Arkko<mailto:jari.ar...@ericsson.com>; Vesa Torvinen<mailto:vesa.torvi...@ericsson.com>; John Mattsson<mailto:john.matts...@ericsson.com> Subject: RE: RE: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt Hi! Please see inline. From: Meiling Chen <chenmeil...@chinamobile.com<mailto:chenmeil...@chinamobile.com>> Sent: Monday, 13 February 2023 02:31 To: Karl Norrman <karl.norr...@ericsson.com<mailto:karl.norr...@ericsson.com>>; Jari Arkko <jari.ar...@ericsson.com<mailto:jari.ar...@ericsson.com>>; Vesa Torvinen <vesa.torvi...@ericsson.com<mailto:vesa.torvi...@ericsson.com>>; John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> Subject: Re: RE: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt Hi all, Thanks John open an issue, but I'm Meiling Chen not Meiling Cheng. for Karl's reply please see inline. From: Karl Norrman<mailto:karl.norr...@ericsson.com> Date: 2023-02-09 17:02 To: chenmeil...@chinamobile.com<mailto:chenmeil...@chinamobile.com>; Jari Arkko<mailto:jari.ar...@ericsson.com>; Vesa Torvinen<mailto:vesa.torvi...@ericsson.com>; John Mattsson<mailto:john.matts...@ericsson.com> Subject: RE: Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt Hi! First, John opened an issue with your comments to the EMU mailing list: Comments by Meiling Cheng · Issue #43 · emu-wg/eap-aka-pfs · GitHub<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-ae0508f79ec1f0e0&q=1&e=818bdd26-f413-411e-80ae-b13b3f6d4c4c&u=https%3A%2F%2Fgithub.com%2Femu-wg%2Feap-aka-pfs%2Fissues%2F43>. I have replied to some of your questions there as well. Please see inline. From: Meiling Chen <chenmeil...@chinamobile.com<mailto:chenmeil...@chinamobile.com>> Sent: Wednesday, 8 February 2023 10:51 To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:john.mattsson=40ericsson....@dmarc.ietf.org>>; Jari Arkko <jari.ar...@ericsson.com<mailto:jari.ar...@ericsson.com>>; Karl Norrman <karl.norr...@ericsson.com<mailto:karl.norr...@ericsson.com>>; Vesa Torvinen <vesa.torvi...@ericsson.com<mailto:vesa.torvi...@ericsson.com>> Subject: Re: Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt Hi authors, For this is the Second WG Last Call, I have some comments: 1. EAP-AKA' PFS requirements are not clear and obvious, For this feature, at least 32 bytes will be added to the existing AKA process at the New Radio, which greatly affects the cost. [Karl]: Yes, to increase security, there is a need to increase bandwidth usage. It is a trade-off. I do not believe adding 32 bytes will greatly affect costs for 5G. For 4G it may have been a tougher trade-off, but in 5G we already have a “large” SUCI in the NAS signaling, and there is even discussions around padding that. So in general 5G NAS procedures are already using relatively large messages compared to earlier generations. Further, re-authentication is not a frequently run procedure, making the increased message size less of an issue. [Meiling]: 32Bytes growth for Iot device is fatal, and Resource-constrained equipment can not support D-H, bandwidth and CPU consumption is huge. [Karl]: My point was that a device that is capable of using SUCI would also be capable of running a DH. Similarly, If the bandwidth consumption with SUCI was not seen as a problem, I don’t see that a DH-exchange would be considerably worse. Also note that neither SUCI not authentication are frequent events. When it comes to constrained IoT devices, I am sure there are super-constrained use cases where the device and bandwidth cannot allow for SUCI nor DH. For those use cases, one would have to make a risk-analysis, and if it turns out that the risk is acceptable, one can use EAP-AKA’ or perhaps even plain AKA. At the same time, I note that IETF is standardizing a DH-based key exchange targeted at constrained devices, so sufficiently many use cases involving IoT devices seems capable of running DH (draft-ietf-lake-edhoc-19 - Ephemeral Diffie-Hellman Over COSE (EDHOC)<https://datatracker.ietf.org/doc/draft-ietf-lake-edhoc/>). 2. AKA based on symmetric key is currently very secure, the PFS of communication network is different from that of PC server, For the communication network, UDM has a very high protection intensity, and it is almost impossible for the long-term shared secrets to be leaked. At present, there is no case that the SIM root key is broken by hackers in the process of use. [Karl]: I completely agree with you that AKA is a strong and well-analyzed AKE. That is why EAP-AKA’ FS is reusing it as a building block and extends the protocol with PFS. I also agree that the UDM can be assumed to be well protected. We do, however, need to consider that the long-term keys are not only at risk when stored in the UDM. The keys are also present in the USIM, and the distribution of the keys is another attack vector. In fact, the distribution was what was attacked in the SIM Heist attack in 2015 (The Great SIM Heist: How Spies Stole the Keys to the Encryption Castle (theintercept.com)<https://theintercept.com/2015/02/19/great-sim-heist/>). It could be argued that PFS does not help against attacks when the adversary knows the key even before it is provided to the customer. This is true, but it does help if such batches of keys are obtained by an adversary at a later stage. [Meiling]: FOR SIM Heist attack in 2015, The main culprit is the manufacturing process of SIM card manufacturers, this is a low probability event. There is no absolute security in this world. [Karl]: That is true, but I would like to reiterate what I say below regarding multi-level security: this days, 3GPP and other organizations do apply several layers of security. Again, for SBA, one could argue that an inside attacker in the mobile core network is also a low probability event (in comparison to, e.g., air-interface attacks). Still, SA3 chose to add TLS e2e between NFs as a second layer of protection. 3.The necessity of AKA PFS is not strong, AKA is used to protect the security of the signaling for the communication network, PFS considers more at the application layer which TLS has been done. [Karl]: I think we are at a stage where we need to have multi-level security. For example, in SBA in the 5G core network, we do use TLS point-to-point between NFs even though both endpoints reside in an NDS secure domain. A well protected UDM is good first line of defense, but I would not like that to be the only defense. I do believe PFS is important for the access network as well, even if TLS is applied over the top. For example, for userplane traffic, IP addresses and other metadata is still visible even when TLS is applied over the top. This information is also sensitive and requires strong protection. [Meiling]: PFS can not solve the problem of IP addresses and other metadata protection. [Karl]: Sorry for being unclear. What I meant was: The air-interface transports metadata that TLS does not protect. An example of that is IP addresses. The air-interface protects this data with encryption and the keys for that encryption are derived from AKA. Even if TLS has PFS and protects the rest of the data, the air-interface encryption does not have PFS today. That means that someone can collect encrypted air-interface data, later obtain the long-term key and then decrypt the IP addresses. By applying an AKA enhanced with PFS would strengthen the protection that the existing encryption provides. 4.Whether the PFS ideas proposed in this draft are sustainable? How to deal with Post-Quantum Cryptography in the future, the introduction of PQC will increase the consumption of hundreds of bytes? [Karl]: The question of PQC is very important for 3GPP radio access security. Today the security is as you know not using public key crypto for anything else than SUCI. The DH exchange introduced by EAP-AKA’ FS would indeed be a new dependence on asymmetric-key technology. Note though that the session key resulting from EAP-AKA’ FS still includes the symmetric key from the underlying AKA run in addition to the secret g^{xy} resulting from the DH exchange. This means that an adversary would need to break that symmetric key as well, even if they have access to a quantum computer that breaks the DH exchange. [Meiling]: In addition to the sustainability of PQC, Another scenario is how to use AKA PFS in satellite network in the future, Satellite communication is very concerned about byte consumption. [Karl]: I cannot predict whether future 3GPP satellite communication will be so bandwidth constrained that running a DH-exchange is prohibitively expensive. But I would handle that the same way as super-constrained IoT use cases: make a risk-assessment whether the intended satellite use cases can be sufficiently secured without it. BR Karl BR Karl Best, Meiling From: Meiling Chen<mailto:chenmeil...@chinamobile.com> Date: 2023-01-30 18:21 To: John Mattsson<mailto:john.mattsson=40ericsson....@dmarc.ietf.org>; emu<mailto:emu@ietf.org> Subject: Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt Hi, I have reviewed the draft, it seems that asymmetric negotiation is used to achieve PFS, But I didn't understand how it was realized. MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity) K_encr = MK[0..127] K_aut = MK[128..383] K_re = MK_ECDHE[0..255] MSK = MK_ECDHE[256..767] EMSK = MK_ECDHE[768..1279] 1. ECDHE's private key is not reflected in the K_encr, MSK used SHARED_SECRET(I understand it is the private key in a pair of keys), Ensure PFS by mixing private key? The names of SHARED SECRET and long-term shared secrets on the SIM card should be distinguished. 2.TLS1.3 support secp256r1, secp384r1, secp521r1，x25519， x448, why the draft only x25519? Best, Meiling From: John Mattsson<mailto:john.mattsson=40ericsson....@dmarc.ietf.org> Date: 2023-01-26 22:36 To: emu@ietf.org<mailto:emu@ietf.org> Subject: Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt Hi, The -10 version fixes various nits found by Peter Yee. Cheers, John From: Emu <emu-boun...@ietf.org<mailto:emu-boun...@ietf.org>> on behalf of internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> <internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>> Date: Thursday, 26 January 2023 at 15:31 To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> <i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org>> Cc: emu@ietf.org<mailto:emu@ietf.org> <emu@ietf.org<mailto:emu@ietf.org>> Subject: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.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 : Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS) Authors : Jari Arkko Karl Norrman Vesa Torvinen John Preuß Mattsson Filename : draft-ietf-emu-aka-pfs-10.txt Pages : 32 Date : 2023-01-26 Abstract: Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising the smart card supply chain, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. Always assuming breach such as key compromise and minimizing the impact of breach are essential zero-trust principles. This specification updates RFC 9048, the improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA'), with an optional extension. Similarly, this specification also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension, when negotiated, provides Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term pre-shared secret in a Subscriber Identity Module (SIM) card from being able to decrypt any past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-10 A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-aka-pfs-10 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts _______________________________________________ Emu mailing list Emu@ietf.org<mailto:Emu@ietf.org> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
