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

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 22 Apr 2005 00:32:43 -0400

>Where RADIUS proxies are present there is no trust relationship
>between the NAS and RADIUS server.  This is in contrast to Diameter,
where
>such a relationship can be established via re-direct.
>
>The distinction is important in a number of cases.  In Kerberos, the
KDC
>is able to provide a ticket to any principal because it has a shared
>secret that it shares with that principle.
>
>Within RADIUS this is not possible.  A RADIUS server cannot
>provide the user with a ticket to a NAS because it may not have a trust
>relationship with that NAS.

Yet NAS takes "go/no-go" decision from RADIUS, and takes the keys to
talk to the client... If this is not trust - what is it?

_______________________________________________
Isms mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isms

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 21 Apr 2005 21:51:29 -0700 (PDT)

> talk to the client... If this is not trust - what is it?

There is no IETF standard defining how keys are provided within
RADIUS for exactly that reason -- there is no trust relationship defined
when a proxy is present.  The "Housley Criteria" described in RFC 4017 do
not allow disclosure of keys to additional parties.

The problem does not exist in Diameter EAP, which enables keys to
be provided directly without access by proxies.

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 22 Apr 2005 08:16:43 -0400

Dear all:

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? 
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.

This is part of a proposal ("A session-less fix to SNMP security 
issues?", 
http://www1.ietf.org/mail-archive/web/isms/current/msg00527.html) to the 
isms audience.

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.

Regards,

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Apr 2005 07:52:58 -0700 (PDT)

> 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

> server) and the application-specific component co-located with the

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.

> mailing list early on. Perhaps it has been overlooked at some point in

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.

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 22 Apr 2005 13:56:28 -0400

Thanks for these explanations.

See comments in-line below.

Bernard Aboba wrote:

[... explanations about end-to-end (NAS to server) and current RADIUS 
protocols ...]

> used by ISMS?  That seems like a lot of work for little overall benefit

I did assume that an implementation-specific attribute to the RADIUS 
Access-Accept packet would pass unmodified through a RADIUS proxy, which 
in fact is a matter of proxy policy (RFC2865 , section 2.3). With this 
erroneous assumption, I thought I was proposing an 
implementation-specific use of existing RADIUS protocol facility. I did 
not expect any "benefit to the RADIUS community".

> that it be chartered outside of ISMS.

Point well taken. I just looked at RFC3576, abstract reproduced below

    "This document describes a currently deployed extension to the Remote
    Authentication Dial In User Service (RADIUS) protocol, allowing
    dynamic changes to a user session, as implemented by network access
    server products.  This includes support for disconnecting users and
    changing authorizations applicable to a user session."

Unfortunately, the security section of RFC3576 raises a number of 
concerns. E.g. the following sentence: "It is RECOMMENDED that IPsec be 
employed to afford better security."

Again, thanks for your comments.

-- 

- Thierry Moreau

Tel.: (514)385-5691
Fax:  (514)385-5900