Re: [eap] RE: [Isms] RADIUS is not a trusted third party

[Bernard Aboba <aboba@internaut.com>]

> Is it concievable to design end-to-end security (i.e. from NAS to RADIUS
> server through any intermediate RADIUS proxies) with an
> implementation-specific attribute to the RADIUS Access-Accept packet?

Diameter CMS enabled the creation of attributes that could be sent between
the RADIUS server and NAS without being revealed to an intermediate proxy.
Therefore it could be said that it enabled "end-to-end" trust, something
that was already possible within Diameter in other ways (re-direct).
Since re-direct needed to be supported anyway and also solved the
problem, that was the direction that was taken once it became clear
that there was not enough interest in Diameter CMS to continue the
work.

Note that Re-direct-based trust is built on the following elements:

    1. Support for DNS discovery of RADIUS servers within a domain.
       This allows the RADIUS client to discover which RADIUS server
       it needs to talk to.

    2. Support for certificate-based authentication.  For inter-domain
       purposes, this is handled via TLS within Diameter.  This
       allows a Diameter client to contact an arbitrary Diameter server
       and mutually authenticate to it, provided that the certificate
       chain can be validated.  With TLS it is possible to create
       application-specific trust chains, something that is much more
       difficult within IKE, so that the trust anchor for Diameter
       (e.g. certificates signed by a roaming consortium CA) need
       not be the same as for other applications (e.g. Verisign
       certificate for a Web server).

It is conceivable to add support for both of these elements to RADIUS, but
of these, element #2 is more difficult. RADIUS over IPsec is defined in
RFC 3579, but it is not deployed for inter-domain usage. To address the
limitations, RADIUS over TLS (RADSEC) has now been defined and is shipping.
My understanding is that it is being considered for deployment within large
inter-continental roaming networks (e.g. TERENA).  More info on RADSEC is
available here:

http://www.terena.nl/mail-archives/mobility/msg01225.html
http://www.open.com.au/radiator/radsec-whitepaper.pdf

> This requires a pre-shared secret key between the RADIUS server (or more
> precisely an implementation-specific server co-located with the RADIUS
> server) and the application-specific component co-located with the
> RADIUS NAS.

Are you proposing creating a new RADIUS security model that would only be
used by ISMS?  That seems like a lot of work for little overall benefit
to the RADIUS community.

> The security implication of RADIUS proxies has been noticed in isms
> mailing list early on. Perhaps it has been overlooked at some point in
> the discussion.

Rather than designing a new version of RADIUS to meet its needs, it seems
more profitable for ISMS to either figure out how to use the protocol as
it exists today, or to summarize its requirements for new work and ask
that it be chartered outside of ISMS.

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