[Emu] Re: Fragmentation in draft-ietf-emu-pqc-eapaka-02

[Tao Wan <[e-mail]>]

Hi Heikki,

Thank you for bringing the attention to my post on the 3GPP LS to EMU and the AT_IDENTITY fragmentation draft. Here is some background information on the LS and draft.

At 3GPP SA3 May meeting, it was concluded that both standalone and hybrid PQC schemes for SUCI will be supported. However, the proposal to start normative specification of PQC profiles for SUCI was not agreed, partly due to concerns that EAP-AKA’ cannot currently support PQC protected SUCI of large size. So 3GPP SA3 sent the LS, asking IETF EMU to update EAP-AKA’ to support large identities.  Based on the request from 3GPP, I proposed the AT_IDENTITY fragmentation draft.

It would be great if both the LS and the draft could be discussed at the Friday meeting. Although I cannot attend to present, I hope both are straightforward to discuss without me. I am happy to provide comments by email.

Thanks,
Tao

From: Heikki Vatiainen <[e-mail]>
Date: Wednesday, July 22, 2026 at 12:29 PM
To: Wang Guilin <[e-mail]>; EMU WG <[e-mail]>
Cc: Jari Arkko <[e-mail]>
Subject: [Emu] Re: Fragmentation in draft-ietf-emu-pqc-eapaka-02

Hello Guilin,

after reviewing recent postings for the Friday meeting, I noticed I had missed a draft and messages related to AT_IDENTITY fragmentation and where to need for it comes from.

Tao Wan posted on the list on June 2nd two related links:
- a link to AT_IDENTITY fragmentation draft: https://datatracker.ietf.org/doc/draft-wan-emu-aka-prime-identity-fragmentation/
- a link to a liaison statement from 3GPP: https://datatracker.ietf.org/liaison/2162/ titled: LS on supporting transmission of large identity in EAP-AKA’

The liaison statement then points to a 3GPP Technical Report with more about SUCI calculation when Post-Quantum Cryptography algorithms are used.

The liaison statement is not linked on the EMU WG page even if it directly requests for EAP-AKA' updates.

Thanks,
Heikki


On Tue, 21 Jul 2026 at 20:29, Wang Guilin <[e-mail]<mailto:[e-mail]>> wrote:
Thanks, John.

I see. I once thought SUCI is just a symmetric encryption of SUPI, using a key dervived from EAP-AKA or EAP-AKA'. In this case, the length of SUCI will be mainly decided by that of SUPI.

Using asymmetric KEM-DEM encryption or HPKE will be a different story.

> SUCI is specified in an appendix to 3GPP TS 33.501 since Rel-15.

Great!

Guilin

发件人：John Mattsson <[e-mail]<mailto:[e-mail]>>
收件人：Wang Guilin <[e-mail]<mailto:[e-mail]>>;Heikki Vatiainen <[e-mail]<mailto:[e-mail]>>
抄 送：EMU WG <[e-mail]<mailto:[e-mail]>>;Jari Arkko <[e-mail]<mailto:[e-mail]>>;Wang Guilin <[e-mail]<mailto:[e-mail]>>
时 间：2026-07-21 19:13:14
主 题：Re: [Emu] Re: Fragmentation in draft-ietf-emu-pqc-eapaka-02

SUCI is an asymmetric KEM-DEM encryption of SUPI (similar to the later HPKE which might be familiar to IETF people). The MTI profiles today use ECC, but already now people are free to use PQC. 3GPP is expected to soon specify PQC profiles for SUCI. And if any government want to use FrodoKEM, 3000 bytes would not be enough :)

SUCI is specified in an appendix to 3GPP TS 33.501 since Rel-15.

Cheers,
John

From: Wang Guilin <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, 21 July 2026 at 18:52
To: Heikki Vatiainen <[e-mail]<mailto:[e-mail]>>; John Mattsson <[e-mail]<mailto:[e-mail]>>
Cc: EMU WG <[e-mail]<mailto:[e-mail]>>; Jari Arkko <[e-mail]<mailto:[e-mail]>>; Wang Guilin <[e-mail]<mailto:[e-mail]>>
Subject: [Emu] Re: Fragmentation in draft-ietf-emu-pqc-eapaka-02

Is SUCI a symmetric encryption of SUPI?

Any particular coming reasons may lead SUCI much longer?

Guilin

发件人：Heikki Vatiainen <[e-mail]<mailto:[e-mail]>>
收件人：John Mattsson <[e-mail]<mailto:[e-mail]>>
抄 送：EMU WG <[e-mail]<mailto:[e-mail]>>;Jari Arkko <[e-mail]<mailto:[e-mail]>>
时 间：2026-07-21 18:20:07
主 题：[Emu] Re: Fragmentation in draft-ietf-emu-pqc-eapaka-02

On Tue, 21 Jul 2026 at 08:38, John Mattsson <[e-mail]<mailto:[e-mail]>> wrote:
Heikki Vatiainen wrote:
>Second, section '7.5 Applicability' notes that AT_IDENTITY may need fragmentation with large SUCI values. SUCI is 3GPP's Subscription Concealed Identifier which is encrypted permanent user identifier.
>
>If AT_IDENTITY requires fragmentation, then EAP-Request/AKA'-Identity and EAP-ResponseAKA'-Identity exchange, that runs before the first EAP-Request/AKA'-Challenge, needs to be fragmentation aware too. AT_IDENTITY is used only with EAP-Response/AKA-Identity as defined by RFC 4187.
>
>3GPP TS 33.501 says about maximum size 'total of 3000 octets plus size of input' where input can be a NAI (username@realm). With these maximum sizes even the initial, non-EAP-AKA'  EAP-Response/Identity comes problematic too, because of the EAP Identity type definition:
>
>    https://www.rfc-editor.org/rfc/rfc3748.html#section-5.1
>    By default, an EAP implementation SHOULD NOT assume that an Identity >    Request or Response can be larger than 1020 octets.

This seems like an RFC 9048 problem. EAP-AKA' with PQC SUCIs can be used without ephemeral PQC key exchange giving FS and PCS.

With 1020 bytes you would not be able to fit a ML-KEM-768 ciphertext (1088 bytes) or ML-KEM-1024 (1568 bytes) . ML-KEM-512 (768 bytes) would work.


Since long SUCIs are going to happen in the future, should the fragmentation work be done as an update to RFC 9048? As you wrote, long SUCIs and the draft discussed in this thread cause fragmentation for different reasons. The fragmentation support could then be part of updated base EAP-AKA'.

EAP-SIM and EAP-AKA seem not to be affected because there's no use of SUCI planned for them? As an example, I took a look at the 3GPP AAA Server interfaces document, 3GPP TS 29.273, and while it uses EAP-AKA for a number of cases, it seems to use SUCI with EAP-AKA' only. In other words, it seems need for fragmentation could be limited to RFC 9048.

One of the ways to get around long SUCI values might be to use a short enough value with EAP-Response/Identity and let EAP-Request/AKA'-Identity exchange to handle identities that are over the 1020 octet threshold. This would match what the EAP-AKA RFC originally suggests too:
https://datatracker.ietf.org/doc/html/rfc4187#section-4.1.2.2 (named Relying on EAP-Response/Identity Discouraged):

   For this reason, it is RECOMMENDED that the EAP peer and server use
   the method-specific identity attributes in EAP-AKA, and the server is
   strongly discouraged from relying upon the EAP-Response/Identity.

--
Heikki Vatiainen
[e-mail]<mailto:[e-mail]>


--
Heikki Vatiainen
[e-mail]<mailto:[e-mail]>