Re: Continued discussion of RADIUS Crypto-Agility

["Dan Harkins" <dharkins@lounge.org>]

  Hi Leif,

On Fri, August 10, 2007 6:07 am, Leif Johansson wrote:
>
>> Glen has explained to us why he thinks that TLS is excluded on
>> procedural
>> grounds (charter exclusion).  I haven't heard much debate about the
>> relative
>> merits of an internal vs. external solution.
>>
>>
>>
> I've tried to argue that I favor TLS/DTLS on the grounds that
> the work required can be done by radius experts which there
> are lots of in this wg as opposed to the aes-keywrap draft which
> requires work by security protocol experts (to specify
> how to do key agreement etc) of which there are few in this wg.

  Using (D)TLS does not absolve you of the requirement to have some
sort of credential on the client. To be secure you MUST enroll every
RADIUS client in a certification authority and install the server's
certificate in a trusted store. In addition you need to provision some
client-side credential, either a username and password or a certificate
and private key.

  Each RADIUS client MUST go through the step of obtaining the certificate
of the certification authority and affirmatively trusting it before it is
used to authenticate the TLS exchange. Now I happen to believe that PKI is
not that big of a deal. But the continued existence of this working group
underscores the fact that such a belief is a minority one. People are
much more comfortable with massive secret key databases than with PKI.

  There is a dangerous attraction to (D)TLS because people can do server-
side authentication only and base that on a self-signed certificate--
they typically say something along the lines of "just click <ok> when
asked if you want to proceed!". They think that since they're using TLS
then everything is secure when, in fact, their deployment is patently
insecure.

  The keywrap draft defines 2 new keys, one for wrapping the key and
another for integrity verification of the entire message. (Note that using
a different algorithm as "enc-type" could obviate the need for the second
one). This sort of provisioning is something that people who manage
RADIUS servers have done before since it's how the current RADIUS secret
is provisioned. Asking administrators to install a certificate in a
trusted store on every RADIUS client, in addition to asking them to install
a username and password, might be alot to ask. Would demanding that they
deploy a PKI and assign a certificate and private key to every RADIUS
client be too much to ask?

  Dan.




--
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/>