FW: secdir review of draft-ietf-radext-filter-06.txt

["Nelson, David" <dnelson@enterasys.com>]

The following security review of the draft-ietf-radext-filter-06.txt was
recently provided by Sam Weiler.  Any comments or suggested changes
based on this review?

-------------------------------------------------------------

I've reviewed draft-ietf-radext-filter-06.txt 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.

I suspect the document is more or less okay, but I'm concerned about
three things:

-- possible underspecification
-- legacy NAS
-- authentication of the filter list (or lack thereof)

These concerns may stem, in part, from the document's brevity and
propensity to cite other docs -- as someone not steeped in RADIUS and
Diameter lore, I found it a bit hard to decipher.  The table in
section 3, for instance, seems like it must be there to mirror some
table in other specs.  Plainer language throughout might be helpful.

Underspecification: the "String" definition in section 2 refers to
section 4.3 of RFC3588.  That definition includes a number of fields
and options (e.g. dir, frag, ipoptions, tcpoptions, etc.) which I
wouldn't find obvious how to interpret in this context.  That omission
leads me to wonder what else is being lost in the referral to other
docs.

Legacy NAS: the security considerations (section 6) raises this point:

        A NAS-Filter-Rule attribute sent by a RADIUS server may not be
        understood by the NAS which receives it.  A legacy NAS not
compliant
        with this specification may silently discard the NAS-Filter-Rule
        attribute while permitting the user to access the network.  This
can
        lead to users improperly receiving unfiltered access to the
network.
        As a result, the NAS-Filter-Rule attribute SHOULD only be sent
to a
        NAS that is known to support it.

But there's no method defined to finding out what a NAS does or
doesn't support.  Is it reasonable to assume that those deploying this
will readily know which NAS devices support these rules?

Authentication of the filter list: section 6 just points to the base 
radius spec for all authentication, without explicitly saying "the 
methods required by those docs are adequate to assure that a filter 
list can't be spoofed away, nor can it be augmented in such as way as 
to effect a downgrade attack".


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