Stefan said: "That's true. As I went through your comments below, I realised that large parts of the texts you quoted should be moved to the dynamic-discovery draft altogether as they are are very specific to that draft. I'm thinking of taking out all the snippets you mentioned below, transfer them to dynamic-discovery and leaving nothing but a small "pointer" paragraph in the RADIUS/TLS document."
[BA] That's a great idea. Stefan said: "Indeed. I'll update the text to that end. Note though that adding Error-Cause is a MAY only in 5176, so it may very well be that an implementation which doesn't support dynauth would still send only a "naked" NAK, ignoring the MAY." [BA] It's a MAY in RFC 5176 because existing implementations didn't support Error-Cause at all. However, in this particular case, since you're requiring that RADIUS/TLS implementations support NAK in the first place, you can also say that they SHOULD send an Error-Cause attribute. So I'd suggest that the MAY be stronger, so as to remove a potential ambiguity about the meaning of the NAK. It is sufficient that upon receiving such a packet, an unconditional NAK is sent back to indicate that the action is not supported. [BA] The problem is that a NAK does NOT mean that the action is unsupported according to RFC 5176, unless there is an Error-Cause attribute present that indicates that. Stefan said: "I'm slightly confused here. To my best knowledge, Error-cause is only specified in the context of DynAuth (RFC5176). That attribute is listed as only allowed in a NAK as per the attribute occurrence table in 5176." [BA] While RFC 5176 only mentions use of Error-Cause in dynamic authorization it can also be used in other contexts. For example, Error-Cause is referenced in the following other RFCs: RFC 3579: Error-Cause use in Access-Challenge and Access-Reject (see Section 3.3) RFC 5080: Error-Cause in Access-Reject (See Section 2.6.1) Stefan said: "I would be hesitant to use Error-Cause in RADIUS Accounting packets - unless the corresponding RFCs get updated to specify that this attribute is now also to be used in Accounting semantics." [BA] Apparently, Error-Cause is being sent in Accounting-Request packets, see: http://lists.cistron.nl/pipermail/freeradius-users/2011-January/msg00255.html With respect to Accounting-Response, RFC 2866 does prohibit inclusion of attributes relating to a service, but not attributes like Proxy-State or Vendor-Specific. So I'd argue that Error-Cause fits within the category of attributes that would be permissible -- an Informational attribute that can be ignored without damage. Stefan said: "The non-ability to indicate "No accounting please" has been discussed in a radext wg meeting. The conclusion was that auth and acct are two separate, unrelated items. RADIUS Accounting needs to be configured differently and explicitly; so there is little risk that accounting packets are sent "by chance" anyway. If they are sent to the wrong place, that is an administrative error: misconfigured on the sender-side." [BA] If a RADIUS over UDP packet is sent to the wrong place, an ICMP message will result that the RADIUS Accounting client can act on, such as by logging the error. In this case, you are mandating that the RADIUS over TLS server ignore the request, resulting in continuing connection attempts and retransmissions by the RADIUS over TLS client, who doesn't receive evidence of the misconfiguration. So I'd argue that RADIUS over TLS is creating a new problem.
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
