[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: secdir review of draft-ietf-radext-filter-06.txt
Comments below.
-------------------------------------------------------------
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.
Yes, there is a tradition to include a table of this format in RADIUS
specifications. People seem to expect this kind of table by now, so it
probably makes sense to keep it.
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.
Since the RFC 3588 IPFilter syntax is outside the scope of the RADEXT WG,
I'm not sure what we can do with this, other than refer the problem to the
DIME WG, which can choose to include clarifications (or not) in RFC 3588bis.
If and when such clarifications are made, this document will inherit them.
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?
We have learned from painful experience that some legwork is required before
deploying filtering attributes to make sure that the NAS understands and
provisions them the way that the RADIUS server admin intended. This may be
quite painful at times (e.g. particular between providers with roaming
agreements), but it is currently the best we can do. So the language in the
draft is meant to suggest that such legwork is currently unavoidable, and to
suggest that administrators not punt it.
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".
Adding a statement defending the adequacy of MD5 is probably not
appropriate. The overall message (which I think is conveyed in the document)
is that this particular attribute relies on existing RADIUS security
mechanisms, whether they be good, bad or ugly. The point is that the
mechanisms are not unique to this particular attribute.
--
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/>