Subject: [radext] Review of draft-ietf-radext-radsec

From: Bernard Aboba <[email-masked]>
Date: Wed, 18 Jan 2012 19:17:26 -0800

This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radsec. 

Overall, this draft was a pleasant to read, and it is clear that a lot of thought as well as implementation experience has gone into it. 

Kudos to the authors. 

General Issues

There is a considerable amount of text relating to dynamic discovery in this document, yet
there is only an informational reference to it. 

Since inserting a normative reference to dynamic discovery could delay the publication of
this document unnecessarily, my recommendation is to consolidate some of the dynamic
discovery material into a single section in which you can discuss the implications, while
clearly indicating the status of the dynamic discovery work (e.g. still under development, optional to
implement along with RADSEC, etc.). 

For example, you might consider consolidating the following text from Sections 3.1 and 6 
and placing it prior to the current Section 3.1:

Section 3.X:  Implications of Dynamic Peer Discovery

   One mechanism to discover RADIUS over TLS peers dynamically via DNS 

   is specified in [I-D.ietf-radext-dynamic-discovery].  While this mechanism

   is still under development and therefore is not a normative dependency of

   RADIUS/TLS, the use of dynamic discovery has potential future implications that are

   important to understand. 

   If dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery] is used, peer authentication
   alone is not sufficient; the peer must also be authorised to perform
   user authentications.  In these cases, the trust fabric cannot depend
   on peer authentication methods like DNSSEC to identify RADIUS/TLS
   nodes.  The nodes also need to be properly authorised.  Typically,
   this can be achieved by adding appropriate authorisation fields into
   a X.509 certificate.  Such fields include SRV authority [RFC4985],
   subjectAltNames, or a defined list of certificate fingerprints.
   Operators of a RADIUS/TLS infrastructure should define their own
   authorisation trust model and apply this model to the certificates.
   The checks enumerated in Section 2.3 provide sufficient flexibility
   for the implementation of authorisation trust models.

[BA] I think you need to be more prescriptive here.  Are there specific
fields that a RADSEC TLS certificate should contain?  Having individual
implementations/deployments defining their own authorization schemes seems
like a bad idea.  

   In the case of dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
   able to accept connections from a large, not previously known, group
   of hosts, possibly the whole internet.  In this case, the server's
   RADIUS/TLS port can not be protected from unauthorised connection
   attempts with measures on the network layer, i.e. access lists and
   firewalls.  This opens more attack vectors for Distributed Denial of
   Service attacks, just like any other service that is supposed to
   serve arbitrary clients (like for example web servers).

   In the case of dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only
   proof of authorisation for a connecting RADIUS/TLS nodes.  Special
   care needs to be taken that certificates get verified properly
   according to the chosen trust model (particularly: consulting CRLs,
   checking critical extensions, checking subjectAltNames etc.) to
   prevent unauthorised connections.

Other comments

Section 1

   One mechanism to discover RADIUS over TLS peers with DNS is specified in
   [I-D.ietf-radext-dynamic-discovery].

[BA] Recommend moving this to a section devoted to dynamic discovery. 

Section 2.1

   See
   section Section 3.3 (4) and (5) for considerations regarding
   separation of authentication, accounting and dynauth traffic.

[BA] Recommend changing to:

   "See Section 3.3 for considerations regarding separation of
    authentication, accounting and dynamic authorisation traffic."

Section 2.3

   4.  start exchanging RADIUS datagrams.  Note Section 3.3 (1) ).  The
       shared secret to compute the (obsolete) MD5 integrity checks and
       attribute encryption MUST be "radsec" (see Section 3.3 (2) ).

Section 3.1

   (3) If dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery] is used, peer authentication
   alone is not sufficient; the peer must also be authorised to perform
   user authentications.  In these cases, the trust fabric cannot depend
   on peer authentication methods like DNSSEC to identify RADIUS/TLS
   nodes.  The nodes also need to be properly authorised.  Typically,
   this can be achieved by adding appropriate authorisation fields into
   a X.509 certificate.  Such fields include SRV authority [RFC4985],
   subjectAltNames, or a defined list of certificate fingerprints.
   Operators of a RADIUS/TLS infrastructure should define their own
   authorisation trust model and apply this model to the certificates.
   The checks enumerated in Section 2.3 provide sufficient flexibility
   for the implementation of authorisation trust models.

As noted above, I'd suggest removing this material from Section 3.1 and 
consolidating it with other dynamic-discovery material.  

Section 3.3

   Note well: it is not required for an implementation
   to actually process these packet types.  It is sufficient that upon
   receiving such a packet, an unconditional NAK is sent back to
   indicate that the action is not supported.

[BA] What Error-Cause attribute value should be included within the NAK to make it
clear that the action is not supported?  Error 406 "Unsupported Extension"?
That is what RFC 5176 Section 3.5 seems to indicate. 

   There
   is no RADIUS datagram to signal an Accounting NAK.  Clients may be
   misconfigured to send Accounting packets to a RADIUS/TLS server which
   does not wish to process their Accounting packet.  The server will
   need to silently drop the packet.  The client will need to deduce
   from the absence of replies that it is misconfigured; no negative
   ICMP response will reveal this.

[BA] This seems like a bad idea.  How about requiring implementations not
supporting Accounting to respond with an Accounting-Response containing
Error-Cause attribute value 406?  Implementations receiving an Accounting-Response
with this Error-Cause can be required to treat this like an ICMP response. 

Section 4

   As a consequence, the selection of transports to communicate from a
   client to a server is a manual administrative action.  An automatic
   fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
   bidding attacks on the peer communication.

[BA] If a fixed shared secret "radsec" is used alongside fallback to RADIUS/UDP,
that seems more like a MUST NOT!!

Section 6

   In the case of dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
   able to accept connections from a large, not previously known, group
   of hosts, possibly the whole internet.  In this case, the server's
   RADIUS/TLS port can not be protected from unauthorised connection
   attempts with measures on the network layer, i.e. access lists and
   firewalls.  This opens more attack vectors for Distributed Denial of
   Service attacks, just like any other service that is supposed to
   serve arbitrary clients (like for example web servers).

   In the case of dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only
   proof of authorisation for a connecting RADIUS/TLS nodes.  Special
   care needs to be taken that certificates get verified properly
   according to the chosen trust model (particularly: consulting CRLs,
   checking critical extensions, checking subjectAltNames etc.) to
   prevent unauthorised connections.

[BA] I'd recommend collecting this and other dynamic-discovery related material
into a separate section prior to 3.1. 

Appendix C. Assessment of Crypto-Agility Requirements

   The RADIUS Crypto-Agility Requirements (link to RFC once issued here)
   defines numerous classification criteria for protocols that strive to
   enhance the security of RADIUS.  It contains mandatory (M) and
   recommended (R) criteria which crypto-agile protocols have to
   fulfill.  The authors believe that the following assessment about the
   crypto-agility properties of RADIUS/TLS are true.

[BA] The Crypto-Agility RFC is now published so you should reference that.

---

From: Stefan Winter <[email-masked]>
Date: Thu, 26 Jan 2012 09:08:24 +0100

Hi,

comments inline.

> Overall, this draft was a pleasant to read, and it is clear that a lot
> of thought as well as implementation experience has gone into it.
> 
> Kudos to the authors.

Thanks :-)

> there is only an informational reference to it.

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.

This actually coincides with what we've experienced in deployment. While
in earlier times I considered TLS and dynamic discovery rather
intertwined, operations people tell me that these are two very distinct
things; most have no problem changing from UDP to TLS, while leaving
their servers behind a firewall and opening it only to the same known
peers as before; merely changing the transport. They do tend to have
more of a problem with opening the port to the world at large and move
away from hard-wired configurations of known peer addresses though.

So it's indeed best to keep both aspects nicely separated.

>    RADIUS/TLS, the use of dynamic discovery has potential future

I'll add that to the text. Since the text about dynamic discovery would
be externalised to the other draft, how about if I add a sentence:

"Readers of this document who are considering the deployment of
DNS-based dynamic discovery are thus encouraged to read
[I-D.ietf-radext-dynamic-discovery] and follow its future development." ?

Then, those who care can read up on it, while the others just read how
to do TLS instead of UDP.

> implementations/deployments defining their own authorization schemes seems

That text is best moved out to dynamic-discovery anyway. But to address
your point: this was discussed numerous times in radext wg meetings. The
conclusion in the end was that it is hard to foresee how trust fabrics
are created by people in the wild, so it seemed like a bad idea to be
too prescriptive. E.g. in eduroam we've already been experimenting with
two (
1) subjectAltName:URI to contain a specific value
2) policyOID to distinguish "authorized eduroam" servers from others

Chances are that we might experiment with more, e.g. DNSSEC subtrees
with DANE records.

This goes together with the current discussion of making dynamic
discovery Experimental - then observe how trust models work, and be more
concrete if the document makes it to standards track.

>    prevent unauthorised connections.

Both of these security considerations apply only to deployers of
dynamic-discovery; so they should be moved to dynamic-discovery.

> [BA] Recommend moving this to a section devoted to dynamic discovery.

Done in my working copy, by using your text above.

>     authentication, accounting and dynamic authorisation traffic."

Done in my working copy.
> consolidating it with other dynamic-discovery material.  

Moved out to dynamic-discovery.

> That is what RFC 5176 Section 3.5 seems to indicate.

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.

I've put the following text into my working copy:

(4) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly
   allocated UDP port to signal that a peer RADIUS server does not
   support reception and processing of the packet types in [RFC5176].
   These packet types are listed as to be received in RADIUS/TLS
   implementations.  Note well: it is not required for an implementation
   to actually process these packet types.  It is sufficient that upon
   receiving such a packet, an unconditional NAK is sent back to
   indicate that the action is not supported.  The NAK MAY contain an
   attribute Error-Cause with the value 406 ("Unsupported Extension");
   see [RFC5176] for details.

> with this Error-Cause can be required to treat this like an ICMP response.

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 occurence table in 5176.

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. And to be honest, I
would even be rather against such a change, and introduce a proper
Accounting-NAK packet type instead; but that's a different story.

The non-ability to indicate "No accounting please" has been discussed in
a radext wg meetint. 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.

> that seems more like a MUST NOT!!

That paragraph was also brought up in the AD review. It was not meant in
the way you perceived it; please see the thread of the AD review of this
document for an extensive explanation how it was really meant.

In any case, I take the point that the text is confusing for readers.

While resolving the AD comments, I agreed with Dan Romascanu to
reformulate this whole paragraph and move it to Security Considerations
instead. I'll follow up with the new text later today.

> into a separate section prior to 3.1.

Moved out of the document, to go into dynamic-discovery.

> [BA] The Crypto-Agility RFC is now published so you should reference that.

Done now in my working copy.

Thanks for this extensive review, much appreciated!

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Thu, 26 Jan 2012 09:08:24 +0100

Hi,

comments inline.

Thanks :-)

Done in my working copy.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Stefan Winter <[email-masked]>
Date: Thu, 26 Jan 2012 13:35:56 +0100

Hi again,

> document for an extensive explanation how it was really meant.

My working copy has the following text in Security Considerations now:

   If peer communication between two devices is configured for both
   RADIUS/TLS transport (using TLS security) and RADIUS/UDP (using
   shared secret security),and where the RADIUS/UDP transport is the
   failover option if the TLS session cannot be established, a down-
   bidding attack can occur if an adversary can maliciously close the
   TCP connection, or prevent it from being established.  Situations
   where clients are configured in such a way are likely to occur during
   a migration phase from RADIUS/UDP to RADIUS/TLS.  By preventing the
   TLS session setup, the attacker can reduce the security of the packet
   payload from the selected TLS cipher suite packet encryption to the
   classic MD5 per-attribute encryption.  The situation should be
   avoided by disabling the weaker RADIUS/UDP transport as soon as the
   new RADIUS/TLS transport is established and tested.  Disabling can
   happen at either the RADIUS client or server side:

   o  Client side: de-configure the failover setup, leaving RADIUS/TLS
      as the only communication option

   o  Server side: de-configure the RADIUS/UDP client from the list of
      valid RADIUS clients

I hope that makes my intended statement clearer.

If I'm not mistaken, IETF LC period is now over. I plan to produce a new
-11 revision tomorrow to prepare the IESG review phase. It would be nice
if you could let me know whether the changes I did in the document
satisfactorily address your concerns.

Greetings,

Stefan Winter

> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Thu, 26 Jan 2012 13:35:56 +0100

Hi again,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Jan 2012 21:16:02 -0800

Stefan said:

 

 
[BA] My issue is the use of a "well known" shared secret with RADIUS/UDP. 
This could be fixed by requiring that a server supporting RADIUS/TLS MUST
check for a RADIUS/TLS connection before allowing use of the "well known"
shared secret.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Jan 2012 21:16:02 -0800

Stefan said:

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Jan 2012 21:51:05 -0800

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.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Jan 2012 21:51:05 -0800

Stefan said:

 
Stefan said:

Stefan said:

Stefan said:

Stefan said:

---

From: Stefan Winter <[email-masked]>
Date: Fri, 27 Jan 2012 08:16:06 +0100

Hi,

> check for a RADIUS/TLS connection before allowing use of the "well known"

Ah, I see. The spec does not mandate a fixed well-known shared secret
for RADIUS/UDP at all. It only specifies that when TLS transport is
used, security is provided on the transport layer, so the shared secret
that used to protect the RADIUS payload is useless is set to this fixed
term.

When using RADIUS/UDP, the shared secret is still chosen by the
administrator by configuration.

Would it help to clarify the first lines to read:

    If peer communication between two devices is configured for both
    RADIUS/TLS transport (i.e. TLS security on the transport layer,
    shared secret fixed to "radsec") and RADIUS/UDP (i.e. shared secret
    security with a secret manually configured by the administrator),
    and where the RADIUS/UDP transport is the failover option if the
    TLS session cannot be established, a down-bidding attack can occur
    if an adversary can maliciously close the TCP connection, or
    prevent it from being established.

Just to make sure people realise that RADIUS/UDP security is untouched
by this spec?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Fri, 27 Jan 2012 08:16:06 +0100

Hi,

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Fri, 27 Jan 2012 08:55:52 +0100

Hi,

comments inline.

> attribute present that indicates that. 

Okay, the argument for a SHOULD sunds very reasonable. I have updated my
working copy to that end.

> RFC 5080:  Error-Cause in Access-Reject (See Section 2.6.1)

Ok... 3579 defines it to be that way, simply pointing to dynauth; my
draft could do so, too, of course.
5080 lists that it is done elsewhere but doesn't reference a particular
RFC; looks to me like it could refer to RFC3579.

> http://lists.cistron.nl/pipermail/freeradius-users/2011-January/msg00255.html

Interesting use. I don't recall "Error-Cause = Invite" being specified
anywhere; it's not in the list of enumerated Error-Cause reasons in the
IANA registry anyway.

And it's one message on the list that was never replied to. Looks to me
like it's one particular NAS sending weird things out-of-spec. I don't
really like that as an example to be honest.

> So I'd argue that RADIUS over TLS is creating a new problem. 

I take your point only partially. It's true that NASes could act on
receipt of ICMP Port Unreachable, and they can't as per this spec.

I would like to note however that ICMP Port Unreachable is a *very*
coarse-grained way of NAKing accounting that is of little use anyway.

Consider classic RADIUS, and a proxy environment where a server provides
accounting services for some clients, but not for others (or even more
fine-grained: for some realms, but not for others - even if they arrive
via the same RADIUS client): a UDP port is either open or closed; it is
an entirely binary way of signalling whether a server processes
accounting for a given client or not.

It is not possible to signal to the misconfigured peer that *his* (or
only some of his) packets are unwanted, while others are.

That is the situation in classic RADIUS, and makes ICMP Port Unreachable
a very poor way of signalling this condition. That's why I don't have
any scruple sacrificing it. (That, and that the wg discussion also was
rather unimpressed about the consequences of this).

That being said, I can change the spec to "patch" the situation with
your suggestion of using Accounting-Response + Error-Cause. It may be
the adequate thing to do since this specification is going for
Experimental only.

In the long run though, I think this solution is inadequate; if
Accounting-NAK signalling is to be fixed, it should be fixed properly
(i.e. on a per-packet basis) for all transports, not just this one.
Maybe by updating 2866 with a consistent use of Error-Cause, or maybe by
adding an Accounting-NAK packet type, analogous to the dynauth NAKs.

It is definitely a useful thing to work on; but it's not for the
RAIDUS/TLS draft to decide. That would need a wg chartered item (luckily
radext is discussing rechartering right now; this might be worthwhile to
include...)

Please let me know if you'd prefer the Error-Cause "patch" to be in this
spec; I'll do as you say :-)

I promised my AD to publish the -11 revision for IESG review later
today; if our conversation didn't converge until then, there can always
be a -12. Probably necessary after the IESG review anyway :-)

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Fri, 27 Jan 2012 08:55:52 +0100

Hi,

comments inline.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 27 Jan 2012 15:55:47 -0800

Stefan said:
 
"Ok... 3579 defines it to be that way, simply pointing to dynauth; my
draft could do so, too, of course.
5080 lists that it is done elsewhere but doesn't reference a particular
RFC; looks to me like it could refer to RFC3579."

[BA] Yes. 
 
Stefan also said:
 
"Interesting use. I don't recall "Error-Cause = Invite" being specified
anywhere; it's not in the list of enumerated Error-Cause reasons in the
IANA registry anyway.
 
And it's one message on the list that was never replied to. Looks to me
like it's one particular NAS sending weird things out-of-spec."

[BA] Since the message was posted on the FreeRADIUS list, I was hoping
that Alan could enlighten us.  The meaning of "Error-Cause=Invite" wasn't
obvious to me (e.g. it didn't look like there was an error involved), 
and as you mentioned, "Invite" isn't in the list of enumerated Error-Cause
values. 
 
Stefan said: 
 
"I would like to note however that ICMP Port Unreachable is a *very*
coarse-grained way of NAKing accounting that is of little use anyway...

[BA] I agree that an ICMP Port Unreachable is not a useful way for a
RADIUS server to tell a RADIUS client that it can't process a particular
Accounting-Request.  However, it does allow the destination to indicate
that RADIUS accounting is not supported at all, in a way that can be
distinguished from a server or network failure.  That's the functionality
missing in RADIUS over TLS. 

Stefan said:
 
"In the long run though, I think this solution is inadequate; if

include...)"

[BA] I agree that ICMP Port Unreachable or an equivalent in RADIUS/TLS
is not a solution to the other problems you mention.

Stefan said:

"Please let me know if you'd prefer the Error-Cause "patch" to be in this
spec; I'll do as you say ;)

[BA] Here is suggested text:

   (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly
   allocated UDP port to signal that a peer RADIUS server does not
   support reception and processing of RADIUS Accounting packets. 
   Since RADIUS/TLS does not utilize a separate port for Accounting
   packets, this mechanism is not available.  In the event that a 
   client is misconfigured to send Accounting-Request packets to
   a RADIUS/TLS server which does not support accounting, the 
   RADIUS/TLS server SHOULD reply with an Accounting-Response 
   containing an Error-Cause attribute with value 406 
   "Unsupported Extension".  A RADIUS/TLS accounting client 
   receiving such an Accounting-Response SHOULD log the error.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 27 Jan 2012 15:55:47 -0800

Stefan said:

[BA] Yes. 
 
Stefan also said:

 
Stefan said: 

Stefan said:

Stefan said:

---

From: Alan DeKok <[email-masked]>
Date: Sat, 28 Jan 2012 09:40:06 +0100

> and as you mentioned, "Invite" isn't in the list of enumerated Error-Cause

  It's not.  This is another instance of a vendor abusing the standard
space.

  The OpenSER project has defined their own dictionary, which is
included by NOT referenced in FreeRADIUS:

https://github.com/alandekok/freeradius-server/blob/master/share/dictionary.openser

  That dictionary has the following comment at the top:

#	This dictionary is NOT included by default, because it conflicts
#	with attributes defined in the RADIUS standard.  Vendors SHOULD
#	be using a VSA space to assign attributes.
#
#	Be aware that if you DO include this dictionary in the main
#	dictionary file, other parts of your configuration may break!

  The user has edited the system to use this dictionary, in violation of
the above recommendations.  The result is that the "SIP-Method"
attribute has the same value and data type as Error-Cause.

  When a packet is received with attribute 101, the Error-Cause name is
printed.  However, the name of the VALUE is taken from SIP-Method.  The
reason is that FreeRADIUS assumes the dictionaries are in a "flat"
namespace.  So when there are conflicts, they are implicitly resolved by
whatever the code happens to do.

  There doesn't appear to be much need to change that behavior, to allow
multiple conflicting dictionaries.  The vendors who do this have mostly
learned it's bad behavior.

>    (5) RADIUS/UDP [RFC2865 <http://tools.ietf.org/html/rfc2865>] uses negative ICMP responses to a newly

  Also STOP SENDING ACCOUNTING PACKETS!

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 28 Jan 2012 09:40:06 +0100

Alan DeKok.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 28 Jan 2012 10:38:50 -0500

I'm fine with Bernard's error text, although I note that section 3 is
non-normative and you're adding normative advice to it.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 28 Jan 2012 10:38:50 -0500

---

From: Stefan Winter <[email-masked]>
Date: Mon, 30 Jan 2012 08:16:32 +0100

Hello all,

> non-normative and you're adding normative advice to it.

Thanks for the inputs and text suggestions. I took Bernard's text,
Alan's addition, and re-shuffled the text into section 2 so that it is
in the normative part now. In my working copy (to be -12), this
currently reads:

2.5 RADIUS datagrams

[... snip ...]

   Due to the use of one single TCP port for all packet types, it is
   required for a RADIUS/TLS server to signal to a connecting peer which
   types of packets are supported on a server.  See also section
   Section 3.4 for a discussion of signaling.

   o  When receiving an unwanted packet of type 'CoA-Request' or
      'Disconnect-Request', it needs to be replied to with a 'CoA-NAK'
      or 'Disconnect-NAK' respectively.  The NAK SHOULD contain an
      attribute Error-Cause with the value 406 ("Unsupported
      Extension"); see [RFC5176] for details.

   o  When receiving an unwanted packet of type 'Accounting-Request',
      the RADIUS/TLS server SHOULD reply with an Accounting-Response
      containing an Error-Cause attribute with value 406 "Unsupported
      Extension" as defined in [RFC5176].  A RADIUS/TLS accounting
      client receiving such an Accounting-Response SHOULD log the error
      and stop sending Accounting-Request packets.

I reckon that the text is still "needs to be replied to" which could
also be a "MUST reply with". For Accouning, I took Bernard's text with a
"SHOULD reply with" - however, for consistency with CoA I could also
imagine cranking it up to MUST. I wonder what your opinion here is.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Mon, 30 Jan 2012 08:16:32 +0100

Hello all,

2.5 RADIUS datagrams

[... snip ...]

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473