Re: Continued discussion of RADIUS Crypto-Agility

[Leif Johansson <leifj@it.su.se>]

>   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.
>   
Correct. My point was that people know how to do that and that
these steps need to be defined and well understood för keywrap.
>   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.
>   
You can use x509 as a key-only mechanism too. Just configure
each radius endpoint with a self-signed cert and use the (say)
fingerprint to express trust. That is equivalent (in terms of
the work involved) to a shared-secret database and can be
automated (in tools) almost the same way.
>   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.
>   
Not unless you "click ok" by manually configuring the trust. This
gives you the crypto agility of tls with almost no extra complexity
from TLS.
>   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?
>   
Sure but they don't have to :-)

Also deployments of EAP-TLS already perform these steps today.

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