[08:56:36] --- sharonchisholm has joined
[08:56:49] --- Dave Nelson has joined
[08:56:54] <Dave Nelson> hi
[08:57:14] <sharonchisholm> howdy
[08:58:42] <Dave Nelson> starting
[09:00:34] <sharonchisholm> Dave Mitton is the designated victim
[09:01:26] --- barneyatdatabus has joined
[09:01:51] <sharonchisholm> RFC 4590 just published!
[09:02:15] <sharonchisholm> Completed 8 documents (almost 9) since the last IETF
[09:02:29] <sharonchisholm> Some documents in working group review ...
[09:02:46] <sharonchisholm> ----
[09:02:58] <sharonchisholm> radext filter-rules
[09:03:28] <Dave Nelson> Jabber room at home--is teh streaming audio OK?
[09:03:32] <sharonchisholm> radext-filter-rules
[09:03:56] <barneyatdatabus> no - can't connect to uoregon.edu
[09:04:17] <sharonchisholm> comparing drafts (filter rules and filter)
[09:04:28] <sharonchisholm> First has two attributes; latter has one attribute
[09:04:47] <sharonchisholm> The first also has acct-nas-traffic rule
[09:05:10] <sharonchisholm> the first is an extension of diameter's stuff and the other is a copy
[09:05:14] <barneyatdatabus> now getting 404 for uoregon
[09:05:38] <Dave Nelson> let me try...
[09:05:44] <sharonchisholm> Wht would we want this? Lots of people still using radius and need to be able to tranlate this into radius
[09:06:20] <Dave Nelson> works for me here.. http://videolab.uoregon.edu/events/ietf/
[09:06:41] <sharonchisholm> first draft recently posted, but has an issue raised already
[09:06:56] <sharonchisholm> Issue 198: Attribute concatenation/splitting
[09:07:11] <barneyatdatabus> yeah - the list of things for each session, but connection to radext session gets 404
[09:07:15] <sharonchisholm> long rules > 253 bytes (attribute limit)
[09:07:35] <sharonchisholm> A number of proposals to resolve ... deal with fragmentation that results
[09:07:43] <barneyatdatabus> working now
[09:08:22] <sharonchisholm> Glenn - does it matter? It doesn't seem to matter to end-server or end-client what the granularity of the rules is
[09:08:27] <sharonchisholm> Glenn - this is a set of rules
[09:08:47] <sharonchisholm> Glenn - the end client will presumably put this all back to gether to create a set
[09:09:05] <sharonchisholm> Glenn - do the intermede notes need to deal with the individual rules
[09:09:17] <sharonchisholm> A - I thought it was <for a reason I missed>
[09:09:57] <sharonchisholm> Glenn - If you look at the text format. You can tell when a rule starts (Action), you know when it ends because that is the last rule you receive. You can't find the end of a rule with any certainy
[09:10:07] <sharonchisholm> Glenn - you can always find the start
[09:10:23] <sharonchisholm> A - while true for this case, NAS traffic rule does not have this behaviour
[09:10:31] <sharonchisholm> A - it could be in the field too.
[09:10:44] <sharonchisholm> A - we should look at uniform fragmentation methods
[09:11:20] <sharonchisholm> Glenn - I think the diameter ip filter rules, I think it was il-considered thing to do. I wodul not build on them. It would make more sense to make diameter into something that makes sense
[09:11:49] <sharonchisholm> Dave N - when you have one long rule that needs to be frag or if you want to pack a number of rules into a single attribute
[09:11:53] --- joelmhalpern has joined
[09:12:43] <sharonchisholm> Dave N - I agree with Glenn, if things always start with action, but as we add more to it, it makes sense to have a mechanism with well-defined attribute. We could also say that people should not pack multiple rules in an attribute and that would solve that problem
[09:13:20] <sharonchisholm> other chair - if we say we don't pack that helps. Then the other thing is how you tell where the end is
[09:13:47] <sharonchisholm> other chair - always split on 253 boundaries. But, then does that mean it continues or that it coincidently was that lenght
[09:13:58] <sharonchisholm> other chair - is this the same debate for the NAS traffic rule
[09:14:18] <sharonchisholm> A - when we did that we did add a character to show terminiation. We did in this case not want to modify the filters
[09:14:19] <Dave Nelson> othre chair = Bernard Aboba
[09:14:32] <sharonchisholm> Glenn - I think we should do something about diamter avt.
[09:14:56] <sharonchisholm> A - NAS traffic rule ..... is a literal translation
[09:15:13] <sharonchisholm> Glenn - right now we are talking about the NAS filter rule ... let's stick to that... no switching back
[09:15:31] <sharonchisholm> Glenn - still need to translate ... diamter compatbility ... build strings and take them apart in this translation process
[09:15:36] <sharonchisholm> A - not necessarily
[09:15:44] <sharonchisholm> Glenn - or create a new diameter avt ..
[09:15:57] <sharonchisholm> A - exactly. Create a diamter Avt of nas traffic rule
[09:16:20] <sharonchisholm> Dave N - has received request from 3GPP to add this functionality to radius because they have already deployed it for diamter
[09:16:50] <sharonchisholm> Dave N - if folks are already deploying it, then re-designing from scratch may not be the correct approach
[09:17:03] <sharonchisholm> Now to the second draft
[09:17:17] <sharonchisholm> Radius attributes for Filtering and redirection
[09:17:29] <sharonchisholm> A number of open issues
[09:17:38] <sharonchisholm> Have made some progress, but is has been slow
[09:17:53] <sharonchisholm> Diamter compatability is an issue
[09:18:16] <sharonchisholm> Two proposals have been on the table and rejected
[09:18:24] <sharonchisholm> third proposal now on the table
[09:19:30] <sharonchisholm> create a new AVP that copies radius nas traffic rule attribute
[09:20:06] <sharonchisholm> precedence and order for NAS filter rule
[09:20:19] <sharonchisholm> ... debate around a sentence ...
[09:21:24] <sharonchisholm> so, delete the text
[09:21:26] <sharonchisholm> ?
[09:21:40] <barneyatdatabus> need to say NAS cannot ACCEPT packets before RADIUS rules!!
[09:22:06] <sharonchisholm> other chair - There are many cases of local configuration that we don't discuss
[09:22:26] <sharonchisholm> Dave N - radiuus is all about provisioning ... we are not here to define policy rules ....
[09:22:56] <sharonchisholm> Dave N - if there is an argument about how gets to apply the filters ... I don't think we get to solve that here. Someone should, but I don't think we have the charter
[09:23:20] <sharonchisholm> Glenn - Isn't that backward .... (the text in the draft)
[09:23:30] <sharonchisholm> Glenn - if it applies the rules after the supplied rule
[09:23:40] <barneyatdatabus> no - rules are applied in forward order
[09:23:47] <sharonchisholm> A - I think we are coming to agreement that thiat statement should be removed.
[09:24:05] <sharonchisholm> Next Steps for Drafts
[09:24:28] <sharonchisholm> close off open issues
[09:24:32] <sharonchisholm> rev drafts
[09:24:41] <sharonchisholm> take to working group last call
[09:25:00] <sharonchisholm> Dave H - how many have read either one of these two drafts
[09:25:03] <sharonchisholm> (handful)
[09:25:15] <sharonchisholm> Dave h - how many think they are ready for wg last call
[09:25:18] <sharonchisholm> (one hand)
[09:25:34] <sharonchisholm> Existing rules (1 think ready for last call)
[09:25:46] <sharonchisholm> Extensions (no one thinks ready for working group last call)
[09:26:03] <sharonchisholm> Dave H - more people read and get your issues intot he tracker
[09:26:09] <sharonchisholm> -------------------------
[09:27:05] <sharonchisholm> Pre-authnetication
[09:27:09] --- aboba has joined
[09:27:31] <sharonchisholm> network access autntication by peforming EAP authen tication witha target authenticator via the serving networking
[09:27:41] <sharonchisholm> IEEE 802.11i
[09:28:13] <sharonchisholm> Basic pre-auth AAA requirements
[09:28:34] <sharonchisholm> - AAA needs to know that this is a pre-authentication not normal authentication
[09:29:01] <sharonchisholm> AAA needs to know how long to hold the session before timing out
[09:30:04] <sharonchisholm> other potential pre-authentication AAA requirements/issues
[09:30:18] <sharonchisholm> pre-authentication session lifetime may need to be exteneded
[09:30:33] --- dromasca has joined
[09:30:51] <sharonchisholm> maximum pre-aith session lifetime may need to be defined in order to aboid unlimited attempts for extending pre-auth session lifetime
[09:31:09] <sharonchisholm> reverting to pre-auth state from full authorized state
[09:31:35] <sharonchisholm> .. a session with a fully authorized state may need to be changed to a pre-auth state
[09:32:38] <sharonchisholm> maximum number of pre-auth sessions for different authenfication
[09:33:26] <sharonchisholm> Bernard - it was decided that the key cache would likely not be managed separetly for each user
[09:33:41] <sharonchisholm> Bernard - set on the device ... and all things would have the lifetime
[09:34:10] <sharonchisholm> Bernard - Dave and Mike would not have different values ... so does not need to be set via radius
[09:34:39] <sharonchisholm> Nancy - in the 11i sessions ... there isn't any explicit concept of session ... it is assumed that the authenticator ...
[09:34:51] <sharonchisholm> Nancy - we want to use the session timeout from radius
[09:35:07] <sharonchisholm> Bernard - 11i has changed some definitions ... now overloaded
[09:35:38] <sharonchisholm> Bernard - setting a timeout in pre-auth ... is this for the session or for the pre-auth? THere isn't independent control for the new things
[09:36:11] <sharonchisholm> Nancy - in 11i, there was an implicit overloading ... we are trying to fix. In 11r ... there are explicit things defined
[09:36:51] <sharonchisholm> Pat - It seems like you are trying to do some explicit signalling ... want to be able to enforce the numbe of active sessions that a user has at any given time?
[09:37:10] <sharonchisholm> Pat - is the implication that the server is going to maintain state?
[09:37:29] <sharonchisholm> Pat - once key exchange ,,, nothing is sent back to the server that says this is no longer pre-auth ...
[09:37:44] <sharonchisholm> Pat - a lot of the methods on limitting were designed for the dial-up network ...
[09:38:19] <sharonchisholm> Bernard - I think the way it works, you don't get accounting in pre-auth ... you get auth and nothing ... then you send accoutning. So, the accounting tells you
[09:38:24] <sharonchisholm> Pat - not original intent
[09:38:29] <sharonchisholm> Bernard - state in an RFC
[09:38:33] --- yjs has joined
[09:38:59] <sharonchisholm> Pat - what do I do as a mobile Ip ... don't know the network. I've moved 10 feet to the right. This can be done, but is it practicle
[09:39:18] <sharonchisholm> Information on the serving netowkr
[09:39:51] <sharonchisholm> Calling station id
[09:40:14] <sharonchisholm> What should calling station id be in the case of inter-technology pre-auth
[09:40:47] <sharonchisholm> Network initiated pre-authentication
[09:41:08] <sharonchisholm> Summary
[09:41:35] <sharonchisholm> Need thorough requirements for both AAA and EAP
[09:42:03] <sharonchisholm> topic of the HOEKY BOF ( Sorry, spelt that wrong)
[09:42:20] <sharonchisholm> spelled
[09:43:05] <sharonchisholm> M - hoeky has pre-auth ... there are a lot of things that it will look at, anything AAA related would likely come here
[09:43:08] <sharonchisholm> ---
[09:43:14] <sharonchisholm> WLAN Attributes
[09:43:29] <sharonchisholm> RFC 4072 already defines some
[09:43:39] <sharonchisholm> eap-keying defines some
[09:43:48] <sharonchisholm> IEEE defines some
[09:43:58] <sharonchisholm> Pre-auth timeout attribute
[09:44:11] --- gr8k@jabber.org has joined
[09:44:33] <sharonchisholm> - absense of ssid in call station ID is the only way to differentiation pre-auth from auth. This field is actually optional in the first place
[09:44:40] <sharonchisholm> not the best method then
[09:45:04] <sharonchisholm> session timeout attribute is overloaded
[09:45:44] <sharonchisholm> Dave h - question. in .. can be specify a pre-aith specific attribute instead?
[09:46:00] <sharonchisholm> A - in this case you would want to set two timeouts ...
[09:46:12] <sharonchisholm> Dave h - would you be re-authenticating ....
[09:46:50] <sharonchisholm> Yoshi - when attribute not included ... considered as normal authentication, not pre-authentication?
[09:47:25] <sharonchisholm> Bernard - current implementations don't send this. if it not there, it might be a pre-auth or not. If it was sent you would know it was a pre-auth
[09:48:31] <sharonchisholm> doesn't address key cache remaining problem that yoshi brought up
[09:48:58] <sharonchisholm> if sent session time of one hour. If the users was on 30 minutes. they key session state would remaing for another half hour until is expired
[09:49:09] <sharonchisholm> M - that 30 minute is decided by accounting?
[09:49:19] <sharonchisholm> Bernard - send a pre-aiuth timeout and session time out
[09:49:58] <sharonchisholm> Bernard session 1 hour ... if stays on then re-authentication. in 11i, if they leave after 30 minutes, the stufff sticks around for another 30 minutes
[09:50:09] --- rjaksa has joined
[09:50:29] --- gr8k@jabber.org has left
[09:50:34] <sharonchisholm> yoshi - key cache lifetime.. lower protocols .. need <do something> with cache timelife . that would help interopability ( the lower layers carry the session lifetime information)
[09:50:39] <sharonchisholm> (cache lifetime)
[09:50:58] --- gr8k@jabber.org has joined
[09:51:05] <sharonchisholm> Dorothy - I beleive you are right in the 1 hour and 30 minutes case. Applies to botht he pre-auth and the auth case
[09:51:22] <sharonchisholm> Dorothy - I think it is a good idea to define these new attributes and add some clarify
[09:51:37] <sharonchisholm> bernard - how do you recommend we get clarity on the issues. more then IETF
[09:52:02] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has joined
[09:52:05] <sharonchisholm> Dorothy - if there are specific questions on the 11i spec, there are avenues ... could send a liaison or an interpreation requestion
[09:52:20] <sharonchisholm> bernard - want to get a point where IETF and IEEE have some understanding
[09:52:41] <sharonchisholm> Dan - for the second time in this meeting we are discussing non-radext data model issues.
[09:53:01] <sharonchisholm> Dan - this should be tackled separately from how it is being carried in radext
[09:53:49] <sharonchisholm> Pat - pointed me at an RFC ... there are not guidelines in the radius that they accounting stuff and auth go to the same place. So, this is ambiguous. So the pre-auth versus auth is trying to enforce something.
[09:53:56] <sharonchisholm> Bernard - accounting will go were it goes
[09:54:07] <sharonchisholm> Bernard - separate server but the auth will talk to it
[09:54:12] <sharonchisholm> SSID attribute
[09:54:53] <sharonchisholm> In rfc 3580 the SSID is included in the called station if attribute along with the NAS MAC Address
[09:55:06] <sharonchisholm> --------------
[09:55:12] <sharonchisholm> Radius attribute design guidelines
[09:55:59] <sharonchisholm> Dave N for the author ...
[09:56:12] <sharonchisholm> This is working group item
[09:56:16] <sharonchisholm> also for aaa doctors
[09:56:49] <sharonchisholm> thorny issues ... complext data types
[09:57:03] <sharonchisholm> diameter has them, but radius doesn't ... backwards compatibility
[09:57:52] <sharonchisholm> issues
[09:57:58] <sharonchisholm> recommend against vendor specific attributes
[09:58:13] <sharonchisholm> not precluding per attribute encryption
[09:58:25] <sharonchisholm> endable SDOs to work independently
[09:59:07] <sharonchisholm> structured data categorization ...
[09:59:56] <sharonchisholm> Glenn - enable SDOs independently ... what they block on is numbers. THey really like RFC numbers ... a blanked ok for anything what you want to do is difficult to get blocking factor
[10:00:24] <sharonchisholm> Dave h - assist them in working independently so when it comes in for review, there is less work.
[10:00:38] <sharonchisholm> Dave h - not that they can do whatever they want
[10:00:43] <sharonchisholm> people read draft?
[10:00:44] <sharonchisholm> 6
[10:01:03] <sharonchisholm> Section 7 is where we need consensus
[10:02:33] <sharonchisholm> should comply with 2865 unless there is a good reason not to
[10:03:26] <sharonchisholm> guidance on when toe use which mechanisms to affect the logical grouping ...
[10:03:29] <sharonchisholm> Glenn - go back one slie
[10:03:31] <sharonchisholm> slide
[10:04:37] --- dromasca has left: Disconnected
[10:04:44] <sharonchisholm> Glenn - it appears that all of these bullets has already been solved ... several years ago .... I'm not against re-inventing the wheel, but ... there is an AD here, I'm interested in hearing from WG chairs or AD, as to why these bullets exist considering they have already been solved already
[10:05:11] <sharonchisholm> Glenn - existing solution might already be deployed. If we try and solve this again, it might. Solve all the problems in one place
[10:05:26] <sharonchisholm> Bernard - this is the point that got the concern at the last IETF
[10:05:40] <sharonchisholm> Bernard - we could describe the existing solutions instead of doing this new draft
[10:05:46] <sharonchisholm> Glenn - they have document numbers
[10:05:56] <sharonchisholm> Bernard - it still might require some extra text to help explain things
[10:06:08] <sharonchisholm> Dan - Is this targetting to be a BCP?
[10:06:11] <sharonchisholm> Bernard - Yes
[10:07:00] <sharonchisholm> Dan - similar situation happened with MIBs ... format was chosen to provide a guidelines document that was easier to access for people coming from outside the IETF, or other parts of the IETF
[10:07:40] <sharonchisholm> Glenn - actually, I don't think that was my question. These extensions are things that already exist. The question, why are they on the slide. If they don't belong on this slide, then this document does not existing
[10:07:49] <sharonchisholm> Dave h - what documents
[10:07:58] <sharonchisholm> Glenn - I am talking about diameter
[10:08:14] <sharonchisholm> Dave h - do we want to extende radius or kill it?
[10:08:37] <sharonchisholm> Glenn - they can use it now. One person on the mailing list said no one needed this stuff
[10:09:22] <sharonchisholm> Bernard - this document is not about extending radius, it is getting into stuff like this is why people object. This stuff shouldn't be there. If you read this document, it wants to deprecate a bunch of RFCs
[10:09:38] <sharonchisholm> Dave h - clearly no intent to deprecate existing RFCs
[10:10:17] <sharonchisholm> DAve h - geo priv draft ... others ... had large structures ... (c -like) ... no understanding of how to encode in radius ...
[10:11:12] <sharonchisholm> Glenn - isms ... geopriv ... no SNMP deployments that use RADIUS so why do they want to use it
[10:11:31] <sharonchisholm> Glenn - do we want to prop up radius for the rest of our lives
[10:12:05] <sharonchisholm> Jueregen - just to clarify ... goal is to integrate into existing authentication systems ... existing boxes use radius for CLI ... that is the goal
[10:12:13] <sharonchisholm> Glenn - does not answer my question
[10:12:49] <sharonchisholm> further recommendations ...
[10:13:23] <sharonchisholm> what does the group think the requirements are?
[10:14:02] <sharonchisholm> Bernard - taking two hard problems and puting them together makes an imposible problem. This draft does that
[10:14:29] <sharonchisholm> Bernard - if this draft broke in two ... original radius guidelines and everything else
[10:14:47] <sharonchisholm> Bernard - would not talk about extending the protocol
[10:15:15] <sharonchisholm> Dave h - what part is particularly problematic
[10:15:23] <sharonchisholm> Bernard - when it talks about extensions to the protocol
[10:15:46] <sharonchisholm> Bernard - remove the dependencies
[10:16:14] <sharonchisholm> Dave h - guidelines for radius as we know it. If we have an extended format, that would contain its own guidelines
[10:16:32] <sharonchisholm> Dan - looks like you want to split the document. restrict the scope to existing radius guidelines.
[10:17:32] <sharonchisholm> Glenn - Agreeing with Bernard. Would like to disagree with Dave. It could contain a lot of valuable material by translating the common wisdom. lots of people designing radius applications that have no clue as to how it was designed to be used
[10:18:20] <sharonchisholm> M - agree with the last comment. Have not read the draft. No opinion. As a user, I would need ... In mobile IP, ther eis a lot of interest in using radius. Serveral problems, if we would have complex attributes to combine things that were very related
[10:18:41] <sharonchisholm> M - this is an application that SDOs were already using radius for. it would be very good to have guidelines
[10:19:02] <sharonchisholm> M - nervoius about letting SDO do things .. what if they do things differently
[10:19:17] <sharonchisholm> Dave h - unless we have liaisons, we can only provide guidelines
[10:20:01] <sharonchisholm> Q - I could not find a helpful information ... I would appreciate if there are guidelines of what we should do to push new format back to other organizations
[10:20:23] <sharonchisholm> M - not planning on thinking about how to structure attributes. use whatever I'm given
[10:21:04] <sharonchisholm> ---------------------
[10:21:46] <sharonchisholm> Radius Attribute Space: A status report
[10:22:40] <sharonchisholm> 77 attributes available for allocation
[10:23:20] <sharonchisholm> current queue for 64-79
[10:24:26] <sharonchisholm> what to do about it?
[10:26:16] <sharonchisholm> If a solution is desirable ... is he issue only radius attribute extension, or do we need to solve other problems at the same time
[10:26:38] <sharonchisholm> sense of room
[10:26:55] <sharonchisholm> is the problem worth solving
[10:26:59] <sharonchisholm> is this the right place to solve
[10:27:07] <sharonchisholm> is this the only problem we should solve
[10:27:48] <sharonchisholm> Pat - the bigger problem, is we close the door ... if we do 11N and have to do diameter just for that?
[10:28:33] <sharonchisholm> Pat - but if we open it up, then is that killing diameter. So, extend, but onlyfor existing applications
[10:28:33] --- barneyatdatabus has left: Lost connection
[10:28:33] --- joelmhalpern has left: Lost connection
[10:28:33] --- rjaksa has left: Lost connection
[10:28:33] --- aboba has left: Lost connection
[10:28:33] --- gr8k@jabber.org has left: Lost connection
[10:28:33] --- Dave Nelson has left: Lost connection
[10:29:22] <sharonchisholm> Dave N - probably worth solving. can't stop things from happening. If no numbers, they will invent some. Don't want to be an enabler of that vacation, we should not overestimate our ability to stop it
[10:29:52] <sharonchisholm> Dave N - don't know if it is the only problem to solve or not. Perhaps the datamodel if a number of people agree it is a problem
[10:30:18] <sharonchisholm> Dave N - can we consider deprecating and reclaiming some of the existing 256 values?
[10:30:33] <sharonchisholm> Bernard - would have to investigate
[10:30:56] <sharonchisholm> Glenn - The problem has already been solved (diameter)
[10:31:19] <sharonchisholm> Glenn - if we throw away the already existing solution, then this is the best place to do it.
[10:31:22] --- aboba has joined
[10:31:25] --- Dave Nelson has joined
[10:31:28] <sharonchisholm> Glenn - but there are other problems
[10:31:51] --- joelmhalpern has joined
[10:32:23] --- gr8k@jabber.org has joined
[10:32:25] <sharonchisholm> M - yes to all three
[10:33:01] <sharonchisholm> M - I know there are other problems to be solved, but want people to use diamtter
[10:34:00] <sharonchisholm> Q - repeat Glenn's claim that this problem has already been solved. If you add a new attribute, it doesn't matter what the number is in the vendor specific problem. It is political problem that some numbers are nicer then others
[10:35:02] --- dromasca has joined
[10:35:09] <sharonchisholm> Glenn - want to disagree with Dave - I think the IETF has more power to stop people from doing things then you think they do. The SDOs that I am aware, use the IETF to talk at each other. They don't really care about what the IETF does. They use it as a communication device so they can talk to each other. They use the RFCs so they can interoperate.
[10:35:24] <sharonchisholm> Glenn - they will move to diamter if it doesn't exist
[10:35:43] <sharonchisholm> M - I don't think you can come here and say may application is better then yours because I was here first/
[10:36:21] <sharonchisholm> is the thing worth solving
[10:36:35] <sharonchisholm> 13 hands
[10:36:36] --- dromasca has left: Disconnected
[10:36:40] <sharonchisholm> Is it not worht solving
[10:36:46] <sharonchisholm> 6
[10:37:05] <sharonchisholm> Would the radext be the right place to solve the problem
[10:37:07] <sharonchisholm> 18
[10:37:12] <sharonchisholm> Not the right place?
[10:37:13] <sharonchisholm> 0
[10:37:27] <sharonchisholm> Is the attribute exhausion the only problem that should be solved
[10:37:30] <sharonchisholm> 6
[10:37:36] <sharonchisholm> Other problems should be solved as well
[10:37:38] <sharonchisholm> 3
[10:38:12] <sharonchisholm> Two active drafts
[10:38:18] <sharonchisholm> One expired draft
[10:38:53] <sharonchisholm> Diameter AVP format within radius
[10:38:58] <sharonchisholm> fields not byte aligned
[10:39:11] <sharonchisholm> Mitton's is in different order
[10:39:16] <sharonchisholm> then the webber
[10:39:58] <sharonchisholm> third one ... uses vendor id
[10:40:08] <sharonchisholm> 32 bits extended atrtibute space
[10:40:21] <sharonchisholm> The first two added functionality to radius
[10:40:28] <sharonchisholm> the last one didn'e
[10:40:59] <sharonchisholm> Glenn - isn't there a mathmatical problem in putting diameter avp's into radius?
[10:41:07] <sharonchisholm> lenghtwise?
[10:41:07] --- joelmhalpern has left
[10:41:48] <sharonchisholm> Dave M - yeah, probably isn't a good idea, and we should say that.
[10:42:22] <sharonchisholm> Dave M - the guidelines could say, we have some mechanisms, these are the limitations, if you don't like it, go use diameter
[10:42:42] <sharonchisholm> M - an example ... we have run into this problem in the field
[10:43:02] <sharonchisholm> The Barney Wolf prop.
[10:43:53] <sharonchisholm> remove 255 limit on attribute type number
[10:44:00] <sharonchisholm> remove 253 limit on attribute ...
[10:44:22] <sharonchisholm> how to evaluate the choices
[10:44:36] <sharonchisholm> agree on criteria and priorities before evaluating formats
[10:46:08] <sharonchisholm> Dave M - It's actually focusing on real issues instead of waving hands on them
[10:46:12] <sharonchisholm> Dave M - gosh
[10:46:19] <sharonchisholm> Dave M - we seem to be on the right track here
[10:46:37] <sharonchisholm> Dave M - he puts the issues on the table. Need to figure out what they backbone of the group is
[10:47:03] <sharonchisholm> M - kind of like this ... (not close to the mike)
[10:47:24] <sharonchisholm> Glenn - interesting question ... huge resistence to adopting diamter ...
[10:47:51] <sharonchisholm> Glenn - you would need to upgrade your entire network in order to support this. Yeah, that is much better then supporting diamter ;-)
[10:48:08] <sharonchisholm> Bernard - yes, you are right. This is a big upgrade
[10:48:27] <sharonchisholm> Dave N - the people who did were addressing requirements that were not in radius ...
[10:49:02] <sharonchisholm> Dave N -looked at proposals ... Barney and others .. if we have formal ways to express structure ... going to have to invent, why not use something that exists - in diamter
[10:49:19] <sharonchisholm> Dave N - the downside si that you have suched in most of what is in diamteter
[10:49:40] <sharonchisholm> Dave M - Interesting issue is to hear from some of the radius server vedors. Who is going to implement all this?
[10:49:50] <sharonchisholm> Dave M - what does it mean to put this in?
[10:50:45] <sharonchisholm> Bernard - from my understging. I think I agree with Glenn. Massive changes to the dictionary. This is a much bigger change to the radius server. Then the only difference between this and diamter is the transport
[10:50:59] <sharonchisholm> Bernard - you are then about 70% of the way diamter
[10:51:16] <sharonchisholm> Dave h - so we tell people who need this feature to go with diameter instead?
[10:51:46] <sharonchisholm> Q - I wrote a parse. 10K lines of source code to do diameter parser and dictionary. Want to keep radius simple (that was Yoshi)
[10:52:03] <sharonchisholm> Q - how much of that is the total effort for dimater?
[10:52:34] <sharonchisholm> Q2 - server part is 40%. Parsing part is a large chunk
[10:53:07] <sharonchisholm> Jo - I like the idea of having the attributes, but then it seems like you are goinf a long way towards daimeter
[10:53:19] <sharonchisholm> <music interlude via Glenn's phone>
[10:53:50] <sharonchisholm> Glenn - you can still group attributes .. something like structured data and would work with existing servers
[10:54:10] <sharonchisholm> Bernard - people could adopt Avi's proposal today
[10:55:06] <sharonchisholm> Dave H - If you had 10 related items encoded in C, separate but related. 10 attributes with the same tag or one attribute with a sub-division?
[10:55:18] <sharonchisholm> Glenn - I don't think tags can do everything that is in C.
[10:55:32] <sharonchisholm> Glenn - arrays and pointers ... no way
[10:55:40] <sharonchisholm> Dave H - rephrase
[10:56:04] <sharonchisholm> Bernard - do people favour Avi's approach or one of the Diameter approaches?
[10:56:14] <sharonchisholm> <Avi - 8)
[10:56:23] <sharonchisholm> <One of diameter avp - 1 >
[10:57:02] <sharonchisholm> --------------
[10:57:54] <sharonchisholm> Is there interset in this document (missed the document title)
[10:58:19] <sharonchisholm> Hannes - you went too quickly. don't know what document it is
[10:58:35] <sharonchisholm> radex-fixes-03
[10:59:16] <sharonchisholm> Dan - open issue on document we approved
[10:59:32] <sharonchisholm> Dave h - implementation questions
[10:59:43] <sharonchisholm> Bernard - not sure how to do certain counters
[11:00:03] <sharonchisholm> Dan - conserving format. modifying semantics of MIB objects from previous version?
[11:00:27] <sharonchisholm> Bernard - no, it is clarification of how to do the counters. Different implementations did different things
[11:01:02] <sharonchisholm> Dan - Not sure that implemeters of MIB modules know where to go. Then there is a problem in the MIB document
[11:01:49] <sharonchisholm> Bernard - didn't want to give the impression that things had changed, so put the change here instead
[11:02:00] <sharonchisholm> ------
[11:02:20] <sharonchisholm> Radius Attributes for Management Authorization
[11:02:33] <sharonchisholm> Need for management attributes
[11:02:58] <sharonchisholm> two management attributes, both for CLI
[11:03:07] <sharonchisholm> People use SNMP, HTTP
[11:03:30] <sharonchisholm> Need for attributes to specify secure vs non-secure managemnet interaces (SSH, etc)
[11:03:56] <sharonchisholm> Need for attributes to specify roles or privilafe levels
[11:04:29] <sharonchisholm> audit trail
[11:05:52] <sharonchisholm> Is there an interest
[11:06:08] <sharonchisholm> Enterasys Networking is doing this
[11:06:14] <sharonchisholm> Could also be useful for Netconf
[11:07:06] <sharonchisholm> how many people have read the document
[11:07:06] <sharonchisholm> 1
[11:07:19] <sharonchisholm> Dave h - in previous meetings there were more hands
[11:07:39] <sharonchisholm> Dave h - since no one here has read this, we will suggest things to the list and hopefully move forward
[11:07:54] <sharonchisholm> ---------------------
[11:08:07] <sharonchisholm> Hannes does not have slides
[11:08:34] <sharonchisholm> Had list of issues
[11:08:40] <sharonchisholm> had offline discussions of how to resolve
[11:08:47] <sharonchisholm> (this is geopriv)
[11:09:02] <sharonchisholm> split an attribute
[11:09:47] <sharonchisholm> lots of changes
[11:10:16] <sharonchisholm> because the attribute split had a lot of impact
[11:10:39] <sharonchisholm> Bernard - how would you like to get this completed? Final review by working group
[11:10:53] <sharonchisholm> H - yes, the 3GPP are always asking when this will be done
[11:11:20] <sharonchisholm> Bernard - when it goes into geopriv last call, we will announce that in radext. When? Another month?
[11:11:33] <sharonchisholm> H - I'll raise this issue that the meeting this week
[11:11:45] --- washad has joined
[11:11:50] <sharonchisholm> Bernard - then we should ask the radext people to review
[11:11:56] <sharonchisholm> --------------
[11:12:18] <sharonchisholm> ISMS Requirements for RADIUS
[11:12:43] <sharonchisholm> would like an authorized-only service, but a bit difffent then 3546
[11:12:57] <sharonchisholm> want to be able to separate authentication and authorization
[11:13:15] <sharonchisholm> for example, work with kerberos
[11:14:00] <sharonchisholm> asserted identity
[11:14:45] <sharonchisholm> Hannes - in some sense, this reminds me of SIP discussions. Maybe it would be good to align things a bit.
[11:15:04] <sharonchisholm> Hannes - instead of using radius
[11:15:17] <sharonchisholm> Dave h - radius came from wanting to work with existing deployments
[11:15:57] <sharonchisholm> Hannes - probably depends on who you ask. moved from LDAP to web services based things. people want something cooler
[11:16:19] <sharonchisholm> Bernard - we seem to be wanting to integrate kerberose and radius
[11:16:26] <sharonchisholm> Bernard - not clear how they interact
[11:16:33] <sharonchisholm> Bernard - can then interact with each other
[11:17:51] <sharonchisholm> Dave h - there should be an authentication server that only does authentication.
[11:17:56] <sharonchisholm> Dave h - came from Jeff
[11:18:23] <sharonchisholm> Dave h - in this model, ther eis no intergration in this model. They work independently
[11:18:48] <sharonchisholm> Hannes - some folks have kerberose in mind because that is what is used where they come from. Key distribution
[11:19:38] <sharonchisholm> Bernard - there are ways to do this ... security implication. Curious of whether the security area has been brought into this
[11:19:53] <sharonchisholm> DAve h - isms is a security area group and Jeff is a security person
[11:20:51] <sharonchisholm> Dave H - my clarification ... we are connecting with SSH underneath. SSH talks to radius to find out if it is OK to set up SNMP. There is a second type of authentication we've been looking at. Access to the database, MIB, etc.
[11:21:11] <sharonchisholm> Dave H - left that out, because I was not sure there was consensus
[11:21:35] <sharonchisholm> Bernard -you describe a simple use of radius that has already been done. It is the intergration with Kerberose that makes me nervous
[11:21:47] <sharonchisholm> Bernard - kerberose does have authentication too
[11:22:18] <sharonchisholm> dave h - hearing some push back?
[11:22:55] <sharonchisholm> Bernard - not necessarily pushback, but this is a major change to radius being done in a non-radius group and does some questionable architecture things
[11:23:08] <sharonchisholm> Bernard - violates basic key management principles
[11:23:15] <sharonchisholm> Bernard - adhoc
[11:23:27] <sharonchisholm> Bernard - going to effect kerberose models world wide
[11:23:47] <sharonchisholm> Bernard - want agreement from the Kerberose folks
[11:24:02] <sharonchisholm> Dave h - the guy who asked is kerberose co-chair
[11:24:39] <sharonchisholm> Q - we ned to look at this carefully. different data from different places
[11:25:09] <sharonchisholm> Q - we split authentication and accounting
[11:25:22] --- yjs has left
[11:26:16] <sharonchisholm> Hannes - if you have this model ... policy enforcement points ... there is a lot of work going on. Not totally trivial. Look at the SAML document
[11:26:57] <sharonchisholm> ok. we will take this feedback to ISMS to see how they wish to proceed
[11:27:08] <sharonchisholm> blue sheets?
[11:27:25] --- washad has left: Computer went to sleep
[11:27:27] --- aboba has left
[11:27:35] <sharonchisholm> ask folks to focus on shorter term milestones
[11:27:51] <sharonchisholm> other items
[11:28:20] <sharonchisholm> Glenn - Would like to see crypo agility stuff clarified in the charter
[11:28:33] <sharonchisholm> is it a working group item. Otherwise delete it. Clarify
[11:29:30] <sharonchisholm> done
[11:29:37] --- Dave Nelson has left
[11:30:04] --- gr8k@jabber.org has left: Logged out
[11:31:36] --- rjaksa has joined
[11:31:36] --- sharonchisholm has left
[11:32:46] --- rjaksa has left
[11:39:33] --- j.schoenwaelder@jabber.eecs.iu-bremen.de has left: Logged out
[19:00:30] --- LOGGING STARTED
[19:07:02] --- adekok has joined
[19:07:32] --- adekok has left