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
