"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.