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

[Heikki Vatiainen <[e-mail]>]

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]> 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]>
> *收件人：*Wang Guilin <[e-mail]>;Heikki Vatiainen <
> [e-mail]>
> *抄 送：*EMU WG <[e-mail]>;Jari Arkko <[e-mail]>;Wang
> Guilin <[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]>
> *Date: *Tuesday, 21 July 2026 at 18:52
> *To: *Heikki Vatiainen <[e-mail]>; John Mattsson <
> [e-mail]>
> *Cc: *EMU WG <[e-mail]>; Jari Arkko <[e-mail]>; Wang
> Guilin <[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]>
> *收件人：*John Mattsson <[e-mail]>
> *抄 送：*EMU WG <[e-mail]>;Jari Arkko <[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]>
> 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]
>


-- 
Heikki Vatiainen
[e-mail]