Re: Review of draft-ietf-radext-design-07

[Alan DeKok <aland@deployingradius.com>]

Phillip Hallam-Baker wrote:
> As always with Radius documents it is somewhat hard to do a security
> review of a security protocol that admits that the protocol does not
> offer security.

  I agree.  However... we are working with a legacy protocol here.

> While the security is provided through layering on another protocol
> (e.g. IPSEC), the mix and match approach is unsatisfactory. Security
> is a property of a system. It is really not possible to analyze the
> security of a system when one half of the system is unspecified.

  While it is not part of this document, the WG is working on RADIUS
over TLS / DTLS.  These specifications should improve the security of
the protocol.

> The Security Considerations section is adequate and given the purpose
> of this draft it is appropriate to cite external documents where the
> security issues are discussed in detail rather than repeat the caveats
> here. But the question does have to be asked why we have so many
> security caveats in what is a foundational security protocol.

  Historical practice, and the cost of upgrade.  When the new TLS-based
documents are approved, we expect that they will be the preferred
approach for RADIUS transport.

> While IPSEC security is certainly adequate for some applications, I
> have a really hard time accepting it as the security layer for a
> foundational security protocol. I prefer basic authentication and
> authorization protocols to have security built in. In particular I
> want to know what happens at the RADIUS protocol level when there is
> an error at the IPSEC layer or vice versa. IPSEC is not secure against
> active attack unless error conditions are appropriately handled.

  I agree.  However, it's outside of the scope of this document.

  Alan DeKok.

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