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

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



See inline
On 10-01-2010, at 05:41 , Alan DeKok wrote:

> Avi Lior wrote:
>> I still think it is silly  -  it is saying that a new things are buggy and potentially have security issues.
>> 
>> But so is the use of a new attribute using an existing data type.
> 
>  Again, the logical fallacy of "change is change, so all change has the
> same risk".
sure ... some change has more risk then other changes....but it is obvious no?  Why talk about it...but if you must then go ahead...

> 
>> But anyway if you insist on having some text about new data types then look at my changes.
> ...
>> New text..... AND MOVE THIS TO THE SECURITY SECTION....
>> 
>> 2.1.4.  New Data types and Security
>> 
>>   The introduction of NEW data types brings the potential for the
>>   introduction of new security vulnerabilities.
> 
>  That's true, though it encourages view that simple changes have the
> same risk as complex ones.  This isn't true, and the existing text does
> not have that problem.
So make up your mind! first you tell me this is not about complex attributes and now you tell me it is!  

"Emphasis on "new", not "complex"." is what you wrote in the previous email.  So make it so.  Please use my corrected text.


> 
>> """ TAKE THE FOLLOWING TWO PARAGRAPHS OUT SINCE YOU ARE TALKING ABOUT RADIUS IN THIS DOCUMENT. """
> 
>  Those paragraphs talk about BCP for RADIUS.  (The word RADIUS appears
> 4 times in the two paragraphs).  If they ignored RADIUS, and only
> discussed application-layer issues, I could see your point.
Just because you use the word RADIUS one hundred times in said paragraphs does not make the paragraphs about RADIUS.  There paragraphs speak about an "applications" 

"The threat merely moves from the RADIUS server to the
  application that consumes that opaque data."
The subject is the Application not RADIUS....did i miss something here?

"Applications consuming opaque data that
  reside on the RADIUS server SHOULD be properly isolated from the
  RADIUS server,..." 
The subject is the application right?  did I miss something.

So out of the 4 RADIUS instances 3 of them were about the Application

The fourth one:

"The threat is particularly severe when the opaque data originates
  from the user, and is not validated by the NAS.  In those cases, the
  RADIUS server is potentially exposed to attack by malware residing on
  an unauthenticated host."

Is probably about the Application since it is not validated by the NAS.  The other point about this particular text and the section is at one hand you are talking about new data types and the risks of them.  And intermixed with that you talk about opaque data.  Opaque data does not require new code in the RADIUS server.  It requires no code in the RADIUS server.  This is another reason why the paragraphs dont make sense so get rid of them.

So again since you insist this is document is about RADIUS and not applications.  And you dont want to define applications.  Then dont talk about applications.  Just remove these paragraphs!

You asked for text -- I gave you text.  You haven't convinced me that my text is invalid.  So what seems to be the problem?


> 
>  But the text could arguably appear in the security section of the
> document.  There's no compelling reason to keep it in the main body of
> the document.

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