RE: DISCUSS and COMMENT: draft-ietf-radext-filter

["Bernard Aboba" <bernard_aboba@hotmail.com>]

How about if we change Section 6 to the following:

"6.  Security Considerations

  This specification describes the use of RADIUS for purposes of
  authentication, authorization and accounting.  Threats and security
  issues for this application are described in [RFC3579] and [RFC3580];
  security issues encountered in roaming are described in [RFC2607].

  This document specifies a new attribute that can be included in
  existing RADIUS packets, which are protected as described in
  [RFC3579] and [RFC3576].  See those documents for a more detailed
  description.

  The security mechanisms supported in RADIUS and Diameter are focused
  on preventing an attacker from spoofing packets or modifying packets
  in transit.  They do not prevent an authorized RADIUS/Diameter server
  or proxy from modifying, inserting or removing attributes with
  malicious intent.  Filter attributes modified or removed by a
  RADIUS/Diameter proxy may enable a user to obtain network access
  without the appropriate filters; if the proxy were also to modify
  accounting packets, then the modification would not be reflected in
  the accounting server logs.

  Since the RADIUS protocol currently does not support capability
  negotiation, a RADIUS server cannot automatically discover whether a
  NAS supports the NAS-Filter-Rule attribute.  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."


> From: Russ Housley <housley@vigilsec.com>
> To: iesg@ietf.org
> CC: radext-chairs@tools.ietf.org
> Subject: DISCUSS and COMMENT: draft-ietf-radext-filter Date: Thu, 11 Jan 
> 2007 11:07:43 -0500
>
> Discuss:
>
>   It is clear that the integrity protection of the filter list is
>   beyond the scope of this document.  However, I do think that the
>   security considerations ought to say something about the impact if
>   that protection is not provided.  What are the consequences of a
>   modification to the filter list.  Consider adding entries, removing
>   entries and altering entries.
>
> Comment:
>
>   From the SecDir Review by Sam Weiler:
>
>   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.



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