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

[Bernard Aboba <aboba@internaut.com>]

> It's not.  From the point of view of authentication protocols (PAP,
> CHAP, EAP, etc.), both RADIUS and Diameter are just "wires": the
> operation of the auth protocols should be exactly the same as if
> they terminated in the AAA client, instead of elsewhere.  Basically,
> the purpose of AAA (again, from the POV of an authentication
> protocol) is simply scaling.  BTW, a lot of misery has been caused
> by the erroneous belief that EAP is (or can be) a three-party
> authentication protocol: it isn't, and can't be.  It could _carry_ a
> three-party protocol (like Kerberos), but EAP in itself is a
> two-party protocol.
>
> > why do you care that only one party knows that radius is
> > used? it could also be diameter.
> >
> > i would like to better understand why some people dislike the aaa
> > architecture (radius, diameter).
>
> I think that the misunderstanding mentioned above might have
> something to do with it...

As Glen said, EAP is a two-party protocol (run between EAP peer and
server).  RADIUS is also a two party protocol (between the authenticator
and server).  The system may also include a protocol run between the peer
and authenticator (the Secure Association Protocol).

An application has the flexibility to define new AAA attributes
(e.g. Diameter EAP); to define requirements with respect to EAP methods
(e.g. RFC 4017); and to define the Secure Association Protocol
(e.g. 802.11i 4-way handshake).

This flexibility is both a blessing and a curse.  It is a blessing in
that there is a lot of flexibility available to meet requirements if they
are well defined.  It is a curse because a key management application
needs to do considerable work in defining and analyzing the security
properties of the system in order to meet the security requirements
described in RFC 4017 (the Housley Criteria).

To enable analysis, the specification needs to detail the required AAA
protocol and EAP method properties as well as to define the security
properties of the Secure Association Protocol.  The best existing example
of this to date is probably IEEE 802.11i, but even that effort left out
some important pieces.

Note that the ISMS charter explicitly mentions RADIUS support:

"Version 3 of the Simple Network Management Protocol (SNMPv3) was
elevated to Internet Standard in late 2002 and added security to the
previous versions of the protocol. Although the enhanced protocol
is secure, operators and administrators find that deploying it can
be problematic in large distributions. This is due primarily to two
synchronization problems. The first is the addition of yet another
authentication system specific to SNMPv3 that needs to be maintained
across all networking devices. Most of these devices already
contain local accounts and/or the ability to negotiate with
authentication servers (e.g. RADIUS servers). However, SNMPv3 does
not make use of these authentication mechanisms, and this causes
additional synchronization burdens. The second issue found with
deploying SNMPv3 is that distributing and maintaining View-based
Access Control Model (VACM) rules is also difficult in large-scale
environments."

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