Continuing from the previous message... It says:
In channel binding data, the code is set to 0 (channel binding data) As above, I suggest leaving the value "0" as unused, and starting assignments from "1". If we want to get cute, we can re-use the values from EAP: 5.3.1. Channel Binding Codes 2 data from client 3 success 4 failure 5.3.2. Namespace Identifiers Again, I suggest using "1" for RADIUS. A related question is should we allocate a code for Diameter? :) 5.3.3. Radius Namespace I suggest leaving out all re-definition of RADIUS AVPs. Instead, refer to RFC 2865 Section 5. Say that the NS-Specific data is RADIUS attributes, in the RADIUS attribute format. But the RADIUS packet header (code, length, authenticator) is not included. It also says: RADIUS AVPs are encoded with a one-octet attribute type followed by a one-octet length followed by the value of the RADIUS attribute being encoded. The length includes the type and length octets; the minimum legal length is 2 for an attribute with no value. This last bit is not true. RFC 2865 forbids attributes with "Length" of two. Instead, the entire attribute is suppressed, and never placed into a packet. The same should apply here. It says: Some RADIUS container specifications forbid sending attributes with no value. No, the base RADIUS protocol forbids sending attributes with no value. It is not clear what they mean, or how it is better to send them than to send nothing at all. This prohibition not withstanding, these attributes SHOULD be sent with no value in channel binding responses. I am not clear why the document makes that suggestion. If it's a SHOULD, there should be explanation as to why it's a good idea. Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu