Sam Hartman wrote: > I'm happy to make changes regarding your comments; a couple of them were > not directly actionable but I can make best guesses. Most of them were > directly actionable and I agree the changes improve the text. > I'd appreciate comments from the groups on whether we start codes at 2 > or 1.
It's just a suggestion... there's no serious reason to switch. > Alan> 5.3.3. Radius Namespace > > Alan> I suggest leaving out all re-definition of RADIUS AVPs. > Alan> Instead, refer to RFC 2865 Section 5. Say that the > Alan> NS-Specific data is RADIUS attributes, in the RADIUS attribute > Alan> format. But the RADIUS packet header (code, length, > Alan> authenticator) is not included. > > I'd prefer to keep the definition in. Why? The specifications for RADIUS are publicly available. I don't see the purpose in duplicating that text. > Unfortunately, as discussed in the text, we need to be able to send > empty attributes in channel binding response. It's not clear: Some RADIUS container specifications forbid sending attributes with no value. This prohibition not withstanding, these attributes SHOULD be sent with no value in channel binding responses. Sentence (1) is wrong. RFC 2865 specifically forbids sending attributes with no value. > I understand RADIUS has no meaning for empty attributes, but I think we > have a justified meaning for expressing that. The document contains no justification for empty responses. Looking for the word "response", I can't even find text which explains what the EAP peer does with the empty response. > I think the text is correct as is. The text should be clarified that zero-length attributes are specifically forbidden by RADIUS. > It's a SHOULD because we may specify cases where you include value or > where you don't fully understand the container format. > The definition of channel binding responses indicates that by default > you SHOULD send the attribute without a value and explains why. (You > don't want to echo back all that data.) There's a lot to discuss here. The amount of "all that data" is probably small, so it might not matter to echo it. And I'm still not sure why it's being echoed. Does it serve as an ACK, that the attribute was checked by the EAP server? From the document: The EAP server receives the channel binding data and performs the validation. The EAP method provides a way to return a response; the channel binding response uses the same basic format as the channel binding data. OK.... so what does the response *mean*? For me, echoing a copy of an attribute (value and all) means that the server validated the attribute. Echoing nothing means that the server doesn't know what to do with the attribute. Echoing an attribute with an empty value means... what? Alan DeKok. _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
