Glen has explained to us why he thinks that TLS is excluded on proceduralgrounds (charter exclusion). I haven't heard much debate about the relativemerits of an internal vs. external solution.
I am not sure that internal vs. external is the right point of comparison. To me the issue comes down to static vs. dynamic keying.
To my mind, there are some major negatives associated with an approach that depends on static keying, whether it is internal or external. These involve both management issues as well as security concerns.
From a management perspective, the existing RADIUS shared-secret mechanism already seems to be more than many deployments can handle. We now have many deployments with hundreds or thousands of NASes, and in these situations, allocating a different shared secret for each NAS-RADIUS server pair is difficult to manage. As a result, in many cases, a single RADIUS shared secret is used, and this not only creates domino effect vulnerabilities, but negates many of the security guarantees that RADIUS is required to provide in key management applications.
When combined with l ack of client or server conformance to the RFC 2865 recommendations on shared secret length, use of a single shared secret creates a vulnerability to offline dictionary attack.
This is not an issue that crypto-agility by itself can address.On the other hand, with dynamic keying, it is possible to have some confidence that the keys used to protect traffic between NAS-RADIUS server pairs are unique and fresh, and are not susceptible to offline dictionary attack. Of course, a vulnerability to offline dictionary attack may still exist if the dynamic keys are themselves derived based on pre-shared keys (e.g. IKE or TLS pre-shared key authentication modes). If certificates are used instead of pre-shared keys, then the result is a substantial increase in footprint and certificate management issues on the NAS.
The end result of this is that static keying, while probably more easily deployed than dynamic keying, will probably not improve RADIUS secruity substantially in the long-term, given existing practice.
-- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>