Hello Tirumaleswar and Aritra, thanks for posting the drafts. Here are my notes I mentioned earlier on the list.
I'd be fine keeping the two drafts separate. This allows avoiding repeated text that clarifies which functionality, hybrid or non-hybrid, is currently described. In other words, they can concentrate on the subject easier. However, they should be aware of each other and make it clear from the beginning the only one or the two is allowed within in one EAP-AKA' dialogue. If both are attempted at the same time, this should be processed as an unrecoverable error and EAP-AKA' should fail. In both drafts the new attributes attempt to change the existing attribute format by updating the length field to two octets and changing its location. Even though the attributes are defined as skippable for implementations that don't implement them, a peer or server cannot successfully parse the attribute list anymore if the attribute length field is changed. I suggest finding a way to split the long values into multiple attriubtes. For example, using two attributes, such as AT_PUB_KEM_HEAD and AT_PUB_KEM_TAIL. I'd avoid prefxies like _1 and _2 because they are easier to mix up in code and logs. One thing I'd avoid is concatenating multiple attributes. Using suitably named attributes, or some other method to ensure the are used in the correct order, would match existing EAP-AKA' behaviour: the attributes can be in any order as recommended by the RFC: https://datatracker.ietf.org/doc/html/rfc4187#section-8.2 Unless otherwise specified, the order of the attributes in an EAP-AKA message is insignificant, and an EAP-AKA implementation should not assume a certain order will be used. I would also avoid using duplicate attributes. As far as I know, there's only one attribute in IANA's attribute register which is AT_KDF_FS in RFC 9678. The EAP-AKA RFC sort of hints that duplicates are not expected. For example peer and server error cases both mention duplicate attributes: https://datatracker.ietf.org/doc/html/rfc4187#section-6.3.1 https://datatracker.ietf.org/doc/html/rfc4187#section-6.3.2 o Wrong attribute types or duplicate attributes have been included in the EAP request. ... o The server encounters a malformed attribute, a non-recognized non-skippable attribute, or a duplicate attribute. The length of the new attributes may be a problem. EAP-AKA RFC says the following: https://datatracker.ietf.org/doc/html/rfc4187#section-8.2 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. To summarise the above: attribute naming, free position in attribute list, not using duplicates and separate documents would ease implementation. These should be easy to update too. The length of new attributes may be a bigger problem. This would be a good point to raise in tomorrow's meeting? Thanks, Heikki -- Heikki Vatiainen [email protected]
_______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
