RE: Issue 101: WG Last Call Review

["Congdon, Paul T (ProCurve)" <paul.congdon@hp.com>]

I think we are converging.  Would love to hear from others if this is
acceptable...
 
> > 
> > I'm assuming the text you provided would be in addition to what is 
> > already there?  Below, I've merged  your text into the 
> existing text 
> > as an entirely new Security section.
> 
> No, the text was intended as a replacement of what's already there.
> 
> The existing text is IMHO unnecessary because it doesn't 
> describe any security considerations of _this_ document. I 
> don't think we need to repeat what's already said in RFC 2865 
> and 3579 in every document that defines a new RADIUS 
> attribute: we just need to describe what new security 
> considerations this document has (in addition to those 
> already adequately described in 2865/3579).
> 

I agree that we shouldn't repeat text from the other documents, but I do
believe some of the security considerations documented in these other
documents may still apply.  I'd like to at least leave the introductory
paragraph, followed by your text.  The security section would then look
as follows:

7.  Security Considerations 
    
      Since this document describes the use of RADIUS for purposes of 
      authentication, authorization, and accounting in IEEE 802.1X-
      enabled networks, it is vulnerable to all of the threats that are 
      present in other RADIUS applications. For a discussion of these 
      threats, see [RFC2607], [RFC3162], [RFC3579], and [RFC3580]. 
    
      This documents specifies new attributes that can be included
      in existing RADIUS messages. These messages are protected
      using existing security mechanisms; see [RFC2865] and
      [RFC3576] for a more detailed description and related security
      considerations.
  
      The security mechanisms in [RFC2865] and [RFC3576] are
      primarily concerned with an outside attacker who modifies
      messages in transit or inserts new messages. They do not
      prevent an authorized RADIUS server or proxy from inserting
      attributes with a malicious purpose in message it sends.
    
      An attacker who compromises an authorized RADIUS server or
      proxy can use the attributes defined in this document to
      influence the behavior of the NAS in ways that previously may
      not have been possible. For example, modifications to the 
      VLAN-related attributes may cause the NAS to permit access to
      other VLANs that were intended. To give another example,
      inserting suitable redirection rules to the NAS-Filter-Rule
      attribute may allow the attacker to eavesdrop or modify
      packets sent by a legitimate client.
  
      In general, the NAS cannot know whether the attribute values
      it receives from an authenticated and authorized server are
      well-intentioned or malicious, and thus it is not possible to
      completely protect against attacks by compromised nodes. In
      some cases, the extent of the possible attacks can be limited
      by performing more fine-grained authorization checks at the NAS. 
      For instance, a NAS could be configured to accept only certain
      VLAN IDs from a certain RADIUS server/proxy, or not to accept
      any redirection rules if it is known they are not used in
      this environment.

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