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
