[18:01:58] dromasca joins the room [18:06:13] bernarda joins the room [18:06:31] Alan DeKok joins the room [18:06:37] dromasca has set the subject to: Virtual Interim meeting - February 23, 2010 [18:07:16] dromasca/Stefan Winter joins the room [18:10:17] dromasca/Stefan Winter leaves the room [18:11:57] HannesTschofenig joins the room [18:12:56] Are you guys in the audio conf. call as well? [18:13:17] webex [18:13:39] do you have the info? [18:13:42] I am on the bridge with Dave but I don't hear you guys. Hmmm. [18:13:46] No, I don't think so. [18:13:51] I am using http://ops.ietf.org/lists/radiusext/2010/msg00161.html [18:14:24] Topic: RADEXT WG Virtual Meeting Date: Tuesday, February 23, 2010 Time: 10:00 am, Pacific Standard Time (San Francisco, GMT-08:00) Meeting Number: 962 354 516 Meeting Password: (This meeting does not require a password.) ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=131933892&UID=1115189972& RT=MiM0 2. Enter your name and email address. 3. Enter the meeting password: (This meeting does not require a password.) 4. Click "Join Now". [18:16:14] Will join in a sec [18:32:07] davem joins the room [18:38:10] davem leaves the room [19:10:16] dromasca leaves the room: Replaced by new connection [19:10:45] dromasca joins the room [19:23:19] I'm back [19:31:21] dromasca leaves the room [20:03:13] 2. RADIUS Data Model The Remote Authentication Dial In User Service (RADIUS) defined in [RFC2865] and [RFC2866] uses elements known as attributes in order to represent authentication, authorization and accounting data. Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does not define a formal data definition language. The data type of RADIUS attributes is not transported on the wire. Rather, the data type of a RADIUS attribute is fixed when an attribute is defined. To explain the implications of this early design decision we distinguish attributes into 'basic' and 'complex' attributes. The basic attributes are those defined using a single basic data type, namely: * ... list of basic data types ... Attributes that use sub-fields instead of using a basic data type are referred as "complex attributes. When designing new RADIUS attributes the protocol designer has to ask himself / herself the following two questions: (a) Will this attribute require code changes at the RADIUS server when sent from the RADIUS server to the RADIUS client? (b) Will this attribute require code changes at the RADIUS server when sent from the RADIUS client to the RADIUS server? Many RADIUS server implementations utilize a data dictionary to recognize data types and also offer a simple policy language that only provides limited operations (such as comparisons or arithmetic operations) on these basic data types. Many existing RADIUS policy languages typically are not capable of parsing sub-elements, or providing sophisticated matching functionality. Ideally, a protocol designer might want to write a specification that does not require code changes to most exist RADIUS servers. Sometimes, however, code changes will be unavoidable and they lead to additional implementation efforts, more testing overhead and additional security vulernabilities as more lines of code lead to more potential vulnerabilities. It is RECOMMENDED that protocol designers briefly describe their expected processing model and in particular if they expect RADIUS server changes (for example due to the need for the RADIUS server to analyse incoming RADIUS attributes and to return responses based on the presence of a more sophisticated policy language). 3. Standard vs. Vendor-specific Attribute Space >>> discussion about standard vs. vendor-specific attribute space. [20:32:12] Hannes: can you mail that to the list so I can review it offline? [20:38:18] bernarda leaves the room [22:18:35] Alan DeKok leaves the room