[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Review of draft-ietf-radext-design-01.txt

   IPv6 address   128 bit value, most significant octet first.
   IPv6 prefix    8 bits of reserved, 8 bits of prefix length, up to
                  128 bits of value, most significant octet first.

Judging by some recent specifications, there appears to be some confusion
between these two types.  Should an IPv6 address type always be used to
represent an address (as opposed to the prefix type).  If so, you might
state this explicitly using some normative language.


 Hmm... suggestions?


How about this?
"Where the intent is to represent a specific IPv6 address, the IPv6 address type SHOULD be used. Although it is possible to utilize the IPv6 Prefix type with a prefix 
length of 128 to represent an IPv6 address,  this usage is NOT RECOMMENDED."


2.1.4.  Complex Attributes and Security

  The introduction of complex data types brings the potential for the
  introduction of new security vulnerabilities.  Experience shows that
  the common data types have few security vulnerabilities, or else that
  all known issues have been found and fixed.  New data types require
  new code, which may introduce new bugs, and therefore new attack
  vectors.

  RADIUS servers are highly valued targets, as they control network
  access and interact with databases that store usernames and
  passwords.  An extreme outcome of a vulnerability due to a new,
  complex type would be that an attacker is capable of taking complete
  control over the RADIUS server.

  The use of attributes representing opaque data does not reduce this
  threat.  The threat merely moves from the RADIUS server to the
  application that consumes that opaque data.


Suggest adding:  "The threat is particularly severe when the opaque data
is not originated or checked by the NAS, so that the RADIUS server is
potentially exposed to attack by malware residing on a host.  Applications
consuming opaque data that reside on the RADIUS server


  SHOULD be properly isolated from the RADIUS server, and SHOULD run
  with minimal privileges.  Any potential vulnerabilities in that
  application will then have minimal impact on the security of the
system as a whole. 


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