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

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> Designation
>  
> I thought that this document was a BCP, no?  -01 states that
> it is "Standards Track". 

  -00 was Standards Track, too.  The next version can be changed to a BCP.

> Sections 1 and 1.1
>  
> There is some overlap in coverage.  My recommendation is to reorganize
> the discussion as follows:
...

  OK.

> BTW, I would also suggest a statement that this document does not apply
> to new uses of RADIUS (e.g. uses of RADIUS that go beyond conversations
> between a RADIUS client and server).
> Section 2.1.1

  OK.

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

>    integer64      64 bit unsigned value, most significant octet first.
>  
> I believe that this type has also been used to express an IPv6 Identifier
> value, no?

  Yes.  That is mentioned in the following paragraph.  I'll add a line
here saying the same thing.

> limitatations -> limitations

  Fixed, thanks.

> Section 2.1.3
..
> I think it may be worth expanding this discussion of opaque data types
> somewhat and covering additional implications, security related ones
> in particular.

  Section 2.1.3 is already over two pages long.  I suggest adding a new
section immediately following it, "Complex attributes and Security":

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.  Any such application
   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.

  I've also added text in the security section referencing 2.1.4.

> Section 3.1.3
...
> Can you expand "PEC" on first use?

  Done in Section 2.2.

> Rehosting may also require changes to the RADIUS data model
>    which will affect implementations that do not intend to support the
>    SDO specifications
> 
> Period needed at the end of the sentence.

  Fixed, thanks.

> 
> IDNITs check
...
> ----------------------------------------------------------------------------
>   == Using lowercase 'not' together with uppercase 'MUST' is not an accepted
>      usage according to RFC 2119.  Please use 'MUST NOT' (if that is
> what you
>      mean).

  Text changed to MUST NOT.

>   -- Looks like a reference, but probably isn't: '8' on line 1191

  It's in a quote from another document.

>   == Unused Reference: 'RFC4005' is defined on line 795, but no explicit
>      reference was found in the text
>      '[RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton,
> "Diamete...'

  That reference can be deleted.

>   -- No information found for draft-ietf-radext-extended-attributes - is the
>      name correct?

  Yes.

  Alan DeKok.

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