As part of ongoing (new) implementation effort, my colleague realised that there are couple of oddities in the RFC 4187 attribute table (Section 10.1).
First, for AT_CHECKCODE, the table indicates “0” for EAP-Response/AKA-Identity, yet Section 10.13 says “ The AT_CHECKCODE attribute MAY be used to protect the EAP/AKA-Identity messages.” This seems like an oversight in the table. The entry should be “0-1” instead. Second, again for EAP-Response/AKA-Identity, AT_IDENTITY is marked as “0-1” but the corresponding text in Section 4.1.5 says "the peer MUST respond with EAP-Response/AKA-Identity and include the permanent identity in AT_IDENTITY.” Again, we think the text is correct and the table should read “1” in this case. Note that the peer can send a client error message if for instance it does not have a suitable identity. Are we reading these correctly, or are we missing something? (I’d fix these in RFC 5448bis but they aren’t included in 5448 to begin with… so maybe an errata should be filed. The current errata do not seem to include these issues, see https://www.rfc-editor.org/errata_search.php?rfc=4187 <https://www.rfc-editor.org/errata_search.php?rfc=4187>) Jari
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
