Hi,
It seems not accurate enough, one of PQCs which has built-in DH algorithm has
been cracked.
The sentence "the security and availability of PFS need to be further evaluated
when PQC is used" should be more accurate.
Best,
Meiling
From: Karl Norrman
Date: 2023-03-15 17:18
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!
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
Date: 2023-03-13 15:16
To: karl.norrman; jari.arkko; vesa.torvinen; John Mattsson
CC: emu
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
Date: 2023-02-27 19:23
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!
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>
Sent: Monday, 27 February 2023 04:02
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,
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
Date: 2023-02-13 17:21
To: chenmeil...@chinamobile.com; Jari Arkko; Vesa Torvinen; John Mattsson
Subject: RE: RE: [Emu] I-D Action: draft-ietf-emu-aka-pfs-10.txt
Hi!
Please see inline.
From: Meiling Chen <chenmeil...@chinamobile.com>
Sent: Monday, 13 February 2023 02:31
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>
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
Date: 2023-02-09 17:02
To: chenmeil...@chinamobile.com; Jari Arkko; Vesa Torvinen; John Mattsson
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.
I have replied to some of your questions there as well.
Please see inline.
From: Meiling Chen <chenmeil...@chinamobile.com>
Sent: Wednesday, 8 February 2023 10:51
To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org>; Jari Arkko
<jari.ar...@ericsson.com>; Karl Norrman <karl.norr...@ericsson.com>; Vesa
Torvinen <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)).
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)). 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
Date: 2023-01-30 18:21
To: John Mattsson; emu
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
Date: 2023-01-26 22:36
To: 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> on behalf of internet-dra...@ietf.org
<internet-dra...@ietf.org>
Date: Thursday, 26 January 2023 at 15:31
To: i-d-annou...@ietf.org <i-d-annou...@ietf.org>
Cc: emu@ietf.org <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
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
