Last Call Review of draft-ietf-radext-design-

Request Review of draft-ietf-radext-design
Requested rev. no specific revision (document currently at 19)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2009-05-05
Requested 2009-03-13
Authors Alan DeKok, Greg Weber
Draft last updated 2009-05-24
Completed reviews Secdir Last Call review of -?? by Phillip Hallam-Baker
Secdir Last Call review of -?? by Phillip Hallam-Baker
Assignment Reviewer Phillip Hallam-Baker
State Completed
Review review-ietf-radext-design-secdir-lc-hallam-baker-2009-05-24
Review completed: 2009-05-24


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

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.

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.

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.

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.

New Website:

View Quantum of Stupid podcasts, Tuesday and Thursday each week,