[Emu] Review: draft-ietf-emu-pqc-eapaka-01 and draft-ietf-emu-hybrid-pqc-eapaka-01

[Heikki Vatiainen <[e-mail]>]

Hello Aritra, Hello Tirumaleswar,

please find below my review of your two drafts from an implementation point
of view. This includes considering how the protocol updates affect existing
EAP-AKA implementation and how they co-exist with the existing SIM based
EAP methods.

First, as a reminder to the list members and to make it easier myself to
refer to what already exists, here's a short overview of the current
SIM-based EAP methods, their updates and relationships.

1. EAP-SIM and EAP-AKA - the first SIM based EAP methods
- RFC 4186 defines EAP-SIM
- RFC 4187 defines EAP-AKA

EAP-SIM and EAP-AKA are similar, up to a point. They share the same IANA
registry:
https://www.iana.org/assignments/eapsimaka-numbers/eapsimaka-numbers.xhtml
EAP-SIM has not received updates since the first publication.

2. EAP-AKA' - also know as EAP-AKA Prime
- RFC 5448 defines EAP-AKA'
- Has a separate EAP type from EAP-AKA
- Updated, but not obsoleted, by RFC 9048

Quoting RFC 5448: "[EAP-AKA'] is a small revision of the EAP-AKA'".
EAP-AKA' also uses the aforementioned IANA registry
Quoting RFC 9048: 'This document does not obsolete RFC 5448; however, this
document is the most recent and fully backwards-compatible specification'

3. EAP-AKA' FS - where FS is for Forward Secrecy
- RFC 9678 updates, but does not obsolete, RFCs 9048 and 5448
- Does not have its own EAP type

Quoting RFC 9678: 'This document updates RFC 9048, [cut], and its
predecessor RFC 5448 with an optional extension providing ephemeral key
exchange'

4. The current EMU drafts to make EAP-AKA' safe against
cryptographically-relevant quantum computers:
- draft-ietf-emu-pqc-eapaka
- draft-ietf-emu-hybrid-pqc-eapaka

First, I think it's better to have the two drafts separate. They can then
focus to their own thing and simply say that they are mutually exclusive.
>From what I've seen from other documents, this can avoid the text that does
always need to say something along 'if you do A they don't B and if you do
B they don't do A'. This construct then repeats over and over making it
harder to follow the main topic.


Second, the both drafts define new attributes that is needed with post
quantum safe algorithms. These attributes are from the skippable range
making the functionality in the drafts compatible with the existing
implementations.


Third, because the new attributes need to exchange large amounts of data
between the EAP peer and server, the both drafts purpose to use a different
encoding with their new attributes. The main change is that length field
would now be 2 octets instead of one octet.

This change would break any existing EAP-AKA' implementation that is not
aware of the different encoding. Even the use of skippable range doesn't
help, because the implementation still needs to know how many octets to
skip.

In addition to this, EAP-AKA RFC 4187 has the following restrictions:
https://datatracker.ietf.org/doc/html/rfc4187#section-8
Section 'Protocol Extensibility', second paragraph states:

   When specifying new attributes, it should be noted that EAP-AKA does
   not support message fragmentation.  Hence, the sizes of the new
   extensions MUST be limited so that the maximum transfer unit (MTU) of
   the underlying lower layer is not exceeded.  According to [RFC3748],
   lower layers must provide an EAP MTU of 1020 bytes or greater, so any
   extensions to EAP-AKA SHOULD NOT exceed the EAP MTU of 1020 bytes.

One option to handle this could be to use two rounds
of EAP-Request/AKA'-Challenge - EAP-Response/AKA'-Challenge pairs. The long
values could be split to two, not necessarily equal length, values and sent
with separate AKA'-Challenge messages.

RFC 9678 provides a precedent for this.
https://www.rfc-editor.org/rfc/rfc9678.html#section-6.2-12
Quote: '... the Server re-sends the EAP-Response/AKA'-Challenge message,
...'

Adding a one more EAP round trip still keeps the maximum number of EAP
messages well below what some very common EAP methods already use. For
example, PEAP and EAP-TLS often do well over ten(s) of round trip because
of certificates and CA chains they use.

Most likely the extra round trip, or even more round trips, is better for
compatibility, than causing fragmentation and using MTU exceeding EAP
messages. Existing EAP authenticators and other nodes that are part of the
authentication dialogue, may not handle long messages gracefully.

-- 
Heikki Vatiainen
[e-mail]