[radext] #11: Review

["radext issue tracker" <trac@tools.ietf.org>]

#11: Review
-----------------------------------+----------------------------------------
 Reporter:  jsalowey@â             |       Owner:  aland@â                  
     Type:  defect                 |      Status:  new                      
 Priority:  blocker                |   Milestone:  milestone1               
Component:  design                 |     Version:  1.0                      
 Severity:  Submitted WG Document  |    Keywords:                           
-----------------------------------+----------------------------------------
 Date first submitted:  December 18, 2009
 Reference: http://ops.ietf.org/lists/radiusext/2009/msg00662.html
 Section:   2.1.3, 2.1.4, 5, A2.1, A2.2

 I gave the RADIUS Design Guidelines document a "last look".  I had not
 looked at the document for a while and have not really been following
 discussions on the document.  In general I think the document provides
 some useful information.  There are a few places where I had issues with
 the document.  I'm not sure if these are part of the IESG and Last call
 comments or not.

 A. Section 2.1.3

 I did not find the discussion of complex attributes very compelling.
 Its not clear to me what the difference between string and complex
 attribute is.  If your RADIUS server supports string then it seems that
 it would be possible to support a complex attribute without requiring a
 "code change".

 B. Section 2.1.4

 I'm not really sure what this section is trying to accomplish.  It seems
 to be a lot about deployment guidelines instead of design guidelines.
 I'm also not convinced that the use of complex attributes makes things
 less secure.  It does not seem this section belongs in this document.

 C. Section 5

 This section references section 2.1.4, however it does not seem there is
 anything actionable for a protocol document to do with section 2.1.4.

 D. Section A.2.2

 Since I did not agree with the motivation for section 2.1.3, I don't
 find this section compelling.

 E. Section A.2.1

 I don't see how defining a polymorphic attribute as multiple attributes
 helps.  I'm probably missing something, do you have an example?
 [Bernard Aboba]
 > A. Section 2.1.3
 >
 > I did not find the discussion of complex attributes very compelling.
 > Its not clear to me what the difference between string and complex
 > attribute is. If your RADIUS server supports string then it seems that
 > it would be possible to support a complex attribute without requiring a
 > "code change".

 There are several distinct aspects that are discussed in Section 2.1.3:

 a. Enabling a RADIUS server to send a complex attribute;
 b. Enabling a RADIUS server to receive a complex attribute;
 c. Enabling a RADIUS client to send a complex attribute;
 d. Enabling a RADIUS client to receive a complex attribute.

 However, rather than examining each of these aspects separately, the
 section
 appears to switch between the aspects, sometimes within the same
 paragraph.
 As a result, it is not always clear what aspects are being discussed.
 Since the
 arguments made depend on what aspect is being discussed, it can be hard to
 follow.

 For example, the second paragraph of Section 2.1.3 seems to focus largely
 on a).  As you say,
 in this case, a RADIUS server can send a complex attribute without a code
 change
 (merely by encoding it as a string).

 However, while the first bullet appears to apply to aspect a) (e.g. ease
 of data entry),
 the second and third bullets appear to relate either to aspect b) or d).

 On reading the second and third bullets, I'm not sure which aspect is
 being referred to.
 In paragraph 4, it is noted that RADIUS clients require code changes to
 support any
 attribute, regardless of whether it is complex or not.   Therefore one
 cannot make
 an argument about additional code changes arising from aspect c) or d),
 only
 aspect b).

 Presumably, with respect to aspect d), a RADIUS client receiving a complex
 attribute
 would also implement the required parsing and validation routes for that
 attribute (if not, then the client would either ignore the attribute, or
 possibly reject the
 Access-Response).   So on reading this, I'm not sure that the "additional
 error checking"
 applies to, exactly.

 In reading paragraph 3 about server code changes, there does not appear to
 be a
 distinction between aspect a (in which code changes are not required) and
 aspect b
 (in which a code change would be necessary).

 Paragraph 4 does make the distinction between aspects c and d.

 However, paragraph 6 mixes aspects a) and b).  Paragraph 4 seems to assert
 that code
 changes are not required for aspect a), while this paragraph does seem to
 say
 that this is possible, though it is not clear in what circumstances this
 would be
 necessary.
 [Bernard Aboba] With respect to security vulnerabilities, here are some of
 the issues:
 http://securityvulns.com/Cdocument579.html
 http://securityvulns.com/docs2178.html
 http://www.vuxml.org/freebsd/96ba2dae-4ab0-11d8-96f2-0020ed76ef5a.html
 [Avi Lior]
 Section 2.1.4 makes the following assertion. Exchanging information as a
 complex type has potential for introducing more security vulnerabilities.

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

 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.

 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 think if we did talk about RADIUS as an APplication layer and transport
 layer etc then we would have to say something about Proxies.

 Original text....

 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.

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

 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. Experience shows that
 the existing 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 attribute
 type would be that an attacker is capable of taking complete
 control over the RADIUS server.

 """ TAKE THE FOLLOWING TWO PARAGRAPHS OUT SINCE YOU ARE TALKING ABOUT
 RADIUS IN THIS DOCUMENT. """

 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.

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

 I dont understand how adding a new attribute of an existing type to an
 Access-Request does not require code changes in the RADIUS server? The
 RADIUS server has to process this attribute no? It has to make policy
 decision based on this attribute no?

 Next you talk about the following:

 "On the RADIUS client, code changes are typically required in order to
 implement a new attribute. The RADIUS client typically has to
 compose the attribute dynamically when sending. When receiving, a
 RADIUS client needs to be able to parse the attribute and carry out
 the requested service. As a result, a detailed understanding of the
 new attribute is required on clients, and data dictionaries are less
 useful on clients than on servers."

 But this confuses me.... I think that Clients and Servers have to do the
 same work. I think that both require a detailed understanding of a new
 attribute.

 I do agree that Servers get attributes from a database when composing a
 response and certainly that is true for older generations of server. But
 today and going forward this is not true. More often now servers have to
 compose their response by computing the attributes dynamically.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/11>
radext <http://tools.ietf.org/radext/>


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