Re: "Last Look" at the RADIUS Design Guidelines document

[Alan DeKok <aland@deployingradius.com>]

Avi Lior wrote:
> Sorry i have more to say......
> 
> Section 2.1.4 makes the following assertion. Exchanging information as a complex type has potential for introducing more security vulnerabilities.

  It doesn't say that.

  It says:

   ... New data types require
   new code, which may introduce new bugs, and therefore new attack
   vectors.

  Emphasis on "new", not "complex".

> What?
> 
> You mean if i have to send the following information element a b c to the client or the server; if i send them concatenated in one attribute as say a String foobar containing a+b+c or that will pose more of a security risk the sending them as three separate attributes.
> 
> Help me understand this.....

  I think this message is the third or fourth re-iteration of the topic.
  From now on, I will simply ignore nonsensical claims about the document.

> I think it would be worth while to define the RADIUS model first.  Not the old RADIUS model but rather the one that we are all living with today.  That model is not really different then Diameter.
> 
> Where:
> 
> we have an Application layer and a Base layer.
> 
> Then define the roles of each.

  Suggest some text.

  Or... perhaps we shouldn't re-visit the design of RADIUS.  We've
already gone through one set of revisions where the guidelines document
was attacked because of inconsistencies in the original RFCs.

  The guidelines document is *not* attempting to re-define RADIUS.
Creating a spurious dependency on re-defining RADIUS is a blatant
attempt to shut down the document for more years of revision.

  For a more detailed explanation, see my earlier message:

http://ops.ietf.org/lists/radiusext/2009/msg00612.html

> Where is parsing done and what type of parsing is done.
> Which layer is responsible for security and to what extent.  It seems that security is the responsibility for both layers but not to the same extent.
> 
> The role of the dictionary...
> 
> The document intermixes these topics ....  and I am telling you this will create confusion
> 
> 
> I want a more formal definition.

  Write one.

  In another document.

> BTW on that note....in section 1.1 You define RADIUS proxy but the term is never used anywhere!!!! I find that hard to believe - cause I am sure we would have to say something about Proxies.  

  I'll delete the definition.

  Or, you can suggest some "guidelines" text for RADIUS proxies.

> I think if we did talk about RADIUS as an APplication layer and transport layer etc then we would have to say something about Proxies.

  Seeing as you have no suggestions about what to say, I think the
document is adequate as is.

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