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 [email protected]
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
