[11:39:36] --- Dave Nelson has joined
[11:40:11] * Dave Nelson has changed the subject to: RADEXT WG Meeting IETF-67
[11:55:15] --- sharonchisholm has joined
[12:05:26] <sharonchisholm> have minute takers
[12:05:32] <sharonchisholm> agenda bashing
[12:06:00] <sharonchisholm> this stuff is all on the ietf 67 meeting materials website
[12:06:18] --- Alan DeKok has joined
[12:06:42] <sharonchisholm> two rfcs published
[12:07:02] <sharonchisholm> received comments on these yesterday - formatting issues and MIB doctor issues
[12:07:10] <sharonchisholm> most are editorial
[12:07:51] <sharonchisholm> errata discussion
[12:07:55] <sharonchisholm> -------------------------
[12:08:42] <sharonchisholm> issues list on a webpage
[12:09:01] <sharonchisholm> www.drizzle.com/~ababa/RADEXT (I think)
[12:09:41] <sharonchisholm> http://www.drizzle.com/~aboba/RADEXT/
[12:10:30] <sharonchisholm> <looking at very small text of issue on projector>
[12:11:01] <sharonchisholm> issue 196
[12:11:29] <sharonchisholm> Do we think these things are serious enough that they could confuse people?
[12:11:44] <sharonchisholm> In the past we got the port number wrong and then did a rappid turn around to fix this.
[12:11:58] <sharonchisholm> I want to get a sense of whether this is in that legue
[12:12:38] <sharonchisholm> comment - yes, I think it should be fixed. When I skimmed things it looked fine, but when I started implementing it I noticed I had no idea what to do. So I raised the issue
[12:13:03] <sharonchisholm> Fixing tables in IANA. scope to these three things. We can probably do it
[12:13:32] <sharonchisholm> WG chair will post something to rfc editor and see where we go from there
[12:13:44] <sharonchisholm> Dave - what sort of IESG review will it ned
[12:14:02] <sharonchisholm> other chair - we won't call it BIS, we will call it errata. It will still require wg review
[12:14:19] <sharonchisholm> -------------------------------------------
[12:14:32] <sharonchisholm> NAS Traffic rule attributes (Mauricio)
[12:15:19] <sharonchisholm> will compare drafts then look at each of them
[12:15:46] <sharonchisholm> filter rules has two attributes; filter has one attribute
[12:16:22] <sharonchisholm> filter is the 'format verbatim'
[12:16:35] <sharonchisholm> filter rules provides more functionality
[12:16:56] <sharonchisholm> Filter rules
[12:17:03] <sharonchisholm> 5 issues since ietf 66
[12:17:07] <sharonchisholm> resolve 2 issues
[12:17:21] <sharonchisholm> there are open issues, quickly reaching closer
[12:17:37] <sharonchisholm> 198: attribute concatenation/splitting
[12:18:47] <sharonchisholm> next steps
[12:18:57] <sharonchisholm> reach concensus on last issue
[12:19:02] <sharonchisholm> take -05 o wg last call
[12:19:23] <sharonchisholm> questions?
[12:19:38] <sharonchisholm> bernard - take a few minutes to try and squash this issue now
[12:19:57] <sharonchisholm> bernard - what if diameter sends both in diameter?
[12:20:11] <sharonchisholm> bernard - is this something we need to support in radius and why?
[12:20:25] <sharonchisholm> bernard - it might imply no one should be supporting it in diameter either
[12:20:29] <sharonchisholm> bernard - comments?
[12:20:34] <sharonchisholm> <silence>
[12:20:49] <sharonchisholm> bernard - anyone with an option to keeping the 'MUST NOT'
[12:20:53] <sharonchisholm> <silence>
[12:21:03] <sharonchisholm> bernard - take to list, we may not have an issue here
[12:21:21] <sharonchisholm> NAS Traffic rule
[12:21:39] <sharonchisholm> no updates since ietf 65
[12:21:59] <sharonchisholm> still waiting for comments
[12:22:08] <sharonchisholm> wide variety of open issues
[12:23:07] <sharonchisholm> since this particular attribute will supercede diameter, is it necessary to wait for the diameter avp?
[12:23:20] <sharonchisholm> bernard - what we have been doing lately is define both in one document.
[12:23:37] <sharonchisholm> bernard - we are now the radext and diamter group ... sort of
[12:23:47] <sharonchisholm> bernard - you own both
[12:24:19] <sharonchisholm> dave - we call for review in both working groups. last call it in both wgs at the same time
[12:24:50] <sharonchisholm> dave - not sure how to do the cross referencing
[12:25:05] <sharonchisholm> <reading charter>
[12:25:25] <sharonchisholm> bernard - <text about aligment with diamter ... same parameter ...>
[12:25:46] <sharonchisholm> next steps
[12:25:59] <sharonchisholm> get concensus on open issues list
[12:26:33] <sharonchisholm> new version
[12:26:41] <sharonchisholm> wants to start new draft on redirection
[12:27:30] <sharonchisholm> -------
[12:27:34] <sharonchisholm> radius issues & fixes
[12:27:54] <sharonchisholm> more deployments of radius
[12:28:01] <sharonchisholm> interation problems
[12:28:09] <sharonchisholm> proposed as wg item
[12:28:18] <sharonchisholm> minor changes from -02
[12:28:37] <sharonchisholm> proper use of state attribute ....
[12:28:47] <sharonchisholm> clarifications ... which attributes where ...
[12:29:11] <sharonchisholm> corrections ... access reject versus access challenge
[12:29:29] <sharonchisholm> questions ....new revisiions comining out
[12:29:36] <sharonchisholm> not a lot of discussion on documnet
[12:29:41] <sharonchisholm> comments?
[12:29:48] <sharonchisholm> <silence>
[12:30:11] <sharonchisholm> dave - how many people have read the draft ?
[12:30:15] <sharonchisholm> <3 or 4>
[12:30:43] <sharonchisholm> these issues are run into by implementers, who may not be here
[12:31:23] <sharonchisholm> dave - anyone object to taking this to working group last call
[12:31:32] <sharonchisholm> sharon - it isn't a working group item?
[12:31:37] <sharonchisholm> dave - we would do both at once
[12:32:12] <sharonchisholm> bernard - do both votes ... frst working group document vote ... then
[12:32:31] <sharonchisholm> <question asked for objections to making it a wg document>
[12:32:33] <sharonchisholm> <silence>
[12:32:39] <sharonchisholm> <silence>
[12:32:56] <sharonchisholm> <so, I think that was interpretted as moving forward>
[12:32:59] <sharonchisholm> ----------
[12:33:07] <sharonchisholm> values for the nas port type attributes
[12:33:18] <sharonchisholm> ieee 802
[12:33:32] <sharonchisholm> ieee 802.16, .20, .22
[12:33:42] <sharonchisholm> ready to accept as wg item?
[12:34:05] <sharonchisholm> dave - anyone read the draft
[12:34:10] <sharonchisholm> <2 people>
[12:34:13] <sharonchisholm> dave - any comments?
[12:34:28] <sharonchisholm> bernard - we have discussed this on the list ... pasi any comments
[12:34:54] <sharonchisholm> pasi - the document has 5 lines of technical content. don't need to make it a working group document
[12:35:20] <sharonchisholm> bernard - the author should have sent an email to iana requesting stuf and point at draft.
[12:35:40] <sharonchisholm> dan - depends how registration is defined in IANA. Some require RFCs
[12:35:57] <sharonchisholm> dave - it is specification required. how much depends on what is being allocated
[12:36:22] <sharonchisholm> dan - if informational it does not need IESG last call
[12:36:51] <sharonchisholm> bernard- <reading something> it does not say specification required. just requires export
[12:37:07] <sharonchisholm> dan - right .. it will be enough to have wiki
[12:37:17] <sharonchisholm> bernard - ask authors to make request to ianan
[12:37:45] <sharonchisholm> bernar d- rfcs cost money. no need
[12:38:02] <sharonchisholm> -----------------------
[12:38:17] <sharonchisholm> wlan attributes
[12:38:24] <sharonchisholm> one update since 65
[12:39:16] <sharonchisholm> attributes already defined in rfc 4072
[12:39:32] <sharonchisholm> pre-authentication spport
[12:39:33] --- BertWijnen has joined
[12:40:07] <sharonchisholm> 3580 overloaded the called-station id
[12:40:54] <sharonchisholm> sending ssid or not depending whether it was pre-auth
[12:41:41] <sharonchisholm> preauth-timeout attribute
[12:41:53] <sharonchisholm> next steps
[12:42:04] <sharonchisholm> should this become a wg item?
[12:43:07] <sharonchisholm> dave - this keeps slipping. we are waitinfor a few things. can we split this document out.
[12:43:16] <sharonchisholm> dave publish the bits we know
[12:43:32] <sharonchisholm> bernard - you would delete the mobility attribute id. that is the bit that would go.
[12:44:24] <sharonchisholm> madjid - yoshi and I did a presentation a few IETFs ago. that could be useful here
[12:44:52] <sharonchisholm> dave - is there a preference among people in the room?
[12:44:59] <sharonchisholm> dave - as is, split, etc?
[12:45:35] <sharonchisholm> madjid - no preference either way. for preauth the hokie group has delivered .. don't know if that is the route we want to take
[12:45:53] <sharonchisholm> midjid - pretty sure this is the simpler approach that people might actually want
[12:45:55] --- BertWijnen has left: Replaced by new connection
[12:45:56] --- BertWijnen has joined
[12:46:28] <sharonchisholm> midjid - hokie work is not related to current preauth stuff
[12:47:00] <sharonchisholm> dave - no one has opinion of what to do? Ad?
[12:47:06] <sharonchisholm> dan - <off mike>
[12:47:18] <sharonchisholm> M - if the preaith relates to 11r,
[12:47:24] <sharonchisholm> bernard - no it does not, just 11 i
[12:47:45] <sharonchisholm> M - wondering about the comment that we should review 11r. How do I interact with them?
[12:47:53] <sharonchisholm> bernard - we would send liaison
[12:48:15] <sharonchisholm> bernard - send them the document, they would read it and send comments back. It might go to other areas such as 11 u
[12:48:40] <sharonchisholm> dave - go formal liaison route and see if we can get this unstuck
[12:48:59] <sharonchisholm> ----------
[12:49:06] <sharonchisholm> extended radius attributes
[12:49:07] <sharonchisholm> glenn
[12:50:13] <sharonchisholm> section 4 of draft
[12:50:38] <sharonchisholm> back in Montreal, lots of discussion. fragmentation of message and other issues
[12:51:08] <sharonchisholm> also consensus that approach similar to abi's approach would be good
[12:51:17] <sharonchisholm> so, got together and did this draft
[12:51:19] <sharonchisholm> anyone read it
[12:51:26] <sharonchisholm> <4-5> people
[12:51:30] <sharonchisholm> any problems?
[12:51:40] <sharonchisholm> <allan has issues with it?
[12:51:42] <sharonchisholm> >
[12:52:20] <sharonchisholm> I don't see any problems with it. Flag for fragmentation. doubles radius attribute space. if this is not enough, we can always get another number. Then we can infinetly expand the attribute space
[12:52:22] <sharonchisholm> that is it
[12:53:32] <sharonchisholm> dave - backwards compatibility issues were a major factor in the draft. how extended attributes would be process by servers, proxies that don't support <stuff>
[12:53:53] <sharonchisholm> if they don't understand the vsa type they might just ignore it.
[12:53:59] <sharonchisholm> that would be a problem
[12:54:14] <sharonchisholm> legacy machines. ancient ones. they won't understand this vsa and hopefully they won't break
[12:54:35] <sharonchisholm> bernard- compatibile with rfc ????? format. although the lenght is interpretted differently?
[12:54:41] <sharonchisholm> no, I don't think so
[12:54:56] <sharonchisholm> bernard - no code change to add it to a dictionary?
[12:55:03] <sharonchisholm> yes, there would be
[12:55:15] <sharonchisholm> bernard - are code changes required, and if so, how much
[12:55:25] <sharonchisholm> bernard - you are saying this requries less code changes then other approaches
[12:55:40] <sharonchisholm> if an attribute requires action, you will always haev to add code
[12:55:52] <sharonchisholm> to understand this particular vsa, you would have to add code
[12:56:04] <sharonchisholm> looks similar to microsoft vda
[12:56:07] <sharonchisholm> vsa
[12:56:15] <sharonchisholm> bernard - other then tag and flag
[12:56:51] <sharonchisholm> bernard - but this is somethign you get to after exhausting existing space, but this <draft> seems to be somethig you would use sooner
[12:57:08] <sharonchisholm> dave - tag is used for grouping
[12:57:20] <sharonchisholm> single level of grouping
[12:57:33] <sharonchisholm> dave - extended type 16 bits or 8 bits and vendor ids
[12:57:36] <sharonchisholm> dave - pros and cons
[12:58:09] <sharonchisholm> glen - pros is I don't think we need another million attributes. 255 more is probably adiquate for the rest of our lives
[12:58:35] <sharonchisholm> if we keep creating attributes there is a built in punishment. you have to go get another vendor it.
[12:58:42] <sharonchisholm> thinks it is a good thing
[12:58:54] <sharonchisholm> we might run out again. but then we can get another vendor id
[12:59:06] <sharonchisholm> we won't run out of vendor ids
[12:59:35] <sharonchisholm> bernard - fragmentation and tagging. what if the fragment that says the tag values are changing.
[12:59:52] <sharonchisholm> bernard - does the tag value need to be the same in the next fragment
[13:00:07] <sharonchisholm> don't need to be contiguous
[13:00:23] <sharonchisholm> ---------
[13:00:26] <sharonchisholm> allan
[13:00:53] <sharonchisholm> extended attributes
[13:01:08] <sharonchisholm> everyone knows we need more
[13:01:26] <sharonchisholm> 2865 VSA
[13:02:04] <sharonchisholm> recent proposals
[13:02:25] <sharonchisholm> cons of vendor id of 0 makes me nervous
[13:02:41] <sharonchisholm> might as well get a real vendor id
[13:04:06] <sharonchisholm> other considerations - why do we need grouping
[13:05:29] <sharonchisholm> glen - don't dislike idea of just getting a new vendor id. 0 is probably incorrect
[13:05:54] <sharonchisholm> glen - if geopriv needs some radius attributes, they can get their own vendor id
[13:06:14] <sharonchisholm> glen - they can bring it here and talk about it, but we don't need to align them a number
[13:06:19] --- alfredprasad has joined
[13:06:27] <sharonchisholm> glen - 0 is traditional. tends to mean ietf
[13:06:58] <sharonchisholm> glen - different experience with packet size. people need large attributes which don't fit into radius packets
[13:07:09] <sharonchisholm> what are they doing with those?
[13:07:16] <sharonchisholm> glen - generally they are doing lame thing
[13:07:28] <sharonchisholm> glen - but that is just my opinion. they want these things
[13:07:47] <sharonchisholm> is there an opportunity to define some additional transport mechanisms for large data in radius
[13:07:58] <sharonchisholm> glen - a similar technique could be used here for radius
[13:08:08] <sharonchisholm> would be need to add that here
[13:08:17] <sharonchisholm> glen - i don't think it necessary to dothat here
[13:08:42] <sharonchisholm> glen - separate document
[13:08:54] <sharonchisholm> glen - arguing about this a long time. need to finish this
[13:10:11] <sharonchisholm> dave - vendor id ... it is the SMI enterprise identifier. have not looked at the rules ... can you get more then one
[13:11:10] <sharonchisholm> dave - if you have data that is defined elsewhere such as EAP ... treated as opaque string ... don't want to encourage custom bit packing ... multiple attributes grouped by tags ...
[13:11:20] <sharonchisholm> dave - structure using what we provide in radius
[13:11:47] <sharonchisholm> dave - have tag. in standard way ... dictionary-driven implementations can take advantage of that
[13:12:17] <sharonchisholm> the tag is ... pack tons of data ... two methods .. somethign in AVP header... length is .... or to say we want to sort of use radius .... then you need the header
[13:12:34] <sharonchisholm> preferes to use length ....
[13:12:38] <sharonchisholm> tag better then nothing
[13:13:28] <sharonchisholm> glen - curious .. this presentation does not seem like much of a criticism. are we going to decide how to do this soon?
[13:13:50] <sharonchisholm> glen - we've been doing this for a year. Are we going to look for consensus
[13:14:14] <sharonchisholm> dave - at some point we need to make some decisions. we had set aside a large chunk of time to get consensus in the room today
[13:14:25] <sharonchisholm> dave - not there yet. Let's open that up now
[13:14:54] <sharonchisholm> alan - change the vendor id. have some interoperable implementaions ... then we are done
[13:15:12] <sharonchisholm> bernard - this is starting to block all radius work in the ietf. we don't have several years to get this done
[13:15:31] <sharonchisholm> bernard - there is stuff chartered that can't get attributes
[13:15:43] <sharonchisholm> barnard - need plan to move forward quickly
[13:16:13] <sharonchisholm> alan - comment early about multiple vendor id for different groups
[13:17:17] <sharonchisholm> dave - how to people feel?
[13:17:27] <sharonchisholm> sharon - from namespace management - you are giving up control
[13:17:45] <sharonchisholm> dave - this could be first come, first serve ... or review required
[13:17:57] <sharonchisholm> dave - detect duplication and conflict detected through IETF last call
[13:18:45] <sharonchisholm> glen - think that is the deal. people are doing this alrady. we have no control. curently if you don't come for the expert review, nothing happens
[13:19:14] <sharonchisholm> glen - if we make it easier for people to get their own numbers ... they have deadlines ... it will be better for everyo
[13:19:16] <sharonchisholm> ne
[13:19:36] <sharonchisholm> glen - if they could get number easier ... they would be more likley togo through review
[13:20:39] <sharonchisholm> dan - with respect to process . IANA came ... following rfc recommendation ... requires expert so that iana has fixed ... the working group ... iana knows to come and get this review
[13:20:49] <sharonchisholm> bernard - that was under a different policy
[13:21:04] <sharonchisholm> dan - want be to careful here
[13:21:32] <sharonchisholm> glen - agree with that. better idea to separate out issues .. allocation of format issues and allocation of vendor id
[13:22:22] <sharonchisholm> bernard - have a draft in front of us. issues raised. what is the preference of the working group on how to move forward
[13:23:30] <sharonchisholm> M - don't have infinite amount of wisdom .... in the past few years. various groups do need attributes . hard for them to wait. if it is an outside SDO. sooner the group decides how to build the attributes ... allow them to have their own ids but to play by our rules... go forward harmonized
[13:23:52] <sharonchisholm> glen - working group adopt as item. then chairs can give direction to editors and then we can finish this
[13:24:07] <sharonchisholm> bernard - get a version that addresses comments brought up here ...
[13:24:30] <sharonchisholm> bernard - we could then move forward quickly
[13:25:11] <sharonchisholm> glen - wanted working group item to not rubber stamp it, but so peopleknow it is an IETF activity rather than random ravings
[13:26:27] <sharonchisholm> dave - issues ... formally track them against this draft. then once they are resolved. it can then become a work item
[13:27:18] <sharonchisholm> glen - don't understand the functional difference between making it a work item and resolving the issue
[13:27:34] <sharonchisholm> bernard - we found once it is a work item it is hard to fix
[13:27:39] <sharonchisholm> <weird>
[13:28:53] <sharonchisholm> dave - is there anyone in the room is uncomforable with using this document as the basis
[13:28:56] <sharonchisholm> <silence>
[13:29:05] <sharonchisholm> dave - so we dothis
[13:29:17] <sharonchisholm> bernard - we should discuss this at the OAM area meeting
[13:29:57] <sharonchisholm> -------------
[13:30:02] <sharonchisholm> dave for greg
[13:31:04] <sharonchisholm> radius design guidelines
[13:31:47] --- bewo has joined
[13:32:09] --- bewo has left
[13:32:27] <sharonchisholm> issues
[13:36:03] <sharonchisholm> does wg still think that attribute design guidance would be helpful
[13:36:09] <sharonchisholm> are there authors/editors
[13:36:22] <sharonchisholm> is this document the right starting place
[13:36:57] <sharonchisholm> bernard - there were concerns about the bits that related to existing space. things that made existing documents illegal. that language would have to go
[13:37:08] <sharonchisholm> dave - does everything published ....
[13:37:39] <sharonchisholm> bernard - give us design guidlines on what we already have rather then trying to deprecating existing stuff
[13:37:54] <sharonchisholm> bernard - don't say old attribute design is bad
[13:38:19] <sharonchisholm> bernard - big difference between guidlines sent from server versus sent from NAS
[13:38:29] <sharonchisholm> bernad no code change; code change
[13:38:43] <sharonchisholm> bernard - servers should not have to change code. this should be he focus
[13:39:01] <sharonchisholm> bernard - changing code has a huge impact. some of this other stuff doesn't . it's about purity
[13:39:13] <sharonchisholm> bernard - perfer to see the draft refocused on that
[13:40:14] <sharonchisholm> bernard - other things about this document. suppose to get us to a point .... with SNMP we have traslated MIBS to IEEE. we want to get to that point as well
[13:40:24] <sharonchisholm> bernard - guidelines and radius doctors
[13:40:56] <sharonchisholm> dave - if you look at the current MIB guidelines ... many existing MIB documents are then illegal
[13:41:07] <sharonchisholm> dave - you seem to be looking for more then that for radius
[13:42:00] <sharonchisholm> dan - back to MIBs, depends on what you mean by illgal. design guidelines are a BCP. It does not conflict in any way. it is an extension. implementation details ....
[13:42:33] <sharonchisholm> dan - building on the existing base of standards would make this 'illegal' not contradict... does not change the legality of the other documents for the protocol itself
[13:43:19] <sharonchisholm> dave - is having a document useful?
[13:43:30] <sharonchisholm> 6-8 hands
[13:43:33] <sharonchisholm> harmful
[13:43:33] <sharonchisholm> none
[13:43:41] <sharonchisholm> depends on what is in it
[13:44:06] <sharonchisholm> bernard - suggestion. remove the stuff related to extended attributes and the things people thought were objectionable from iet f66 ...
[13:44:15] <sharonchisholm> bernard - really need an editor
[13:44:30] <sharonchisholm> glen is and hammas are willing to edit
[13:44:33] <sharonchisholm> ------------
[13:45:00] <sharonchisholm> crypto agility
[13:45:43] <sharonchisholm> text on working item
[13:46:57] <sharonchisholm> glen - where are the requirements for this documented?
[13:47:25] <sharonchisholm> dave - russ asked that we word it that way. requirements came out of SAG. we were pointed at some things
[13:47:32] <sharonchisholm> dave - we can get further guidance
[13:47:55] <sharonchisholm> hannes - question i had ... end to end security between aaa server and aaa client?
[13:48:06] <sharonchisholm> dave - no substitute algorithms
[13:48:20] <sharonchisholm> bernard - it should say algoriths in the text
[13:48:48] <sharonchisholm> M - same questiona s glen. don't know what the requirements are
[13:48:58] <sharonchisholm> M - the work was chartred to no improve radius
[13:49:41] <sharonchisholm> dave - one of the reason we were asked ... it did appear that crypto agility was in conflict. not looking for new things, just the ability to substitute stuff out
[13:50:09] <sharonchisholm> dave - ensure our protocols are not tied to a single algorithm. IETF-wide mandate to decouple protocols
[13:51:11] <sharonchisholm> kaushik - that draft as a lot of general requirements. I don't know if it all applies. it would be better to state exactly what the scope is.
[13:51:21] <sharonchisholm> dave - the issues to be addressed are
[13:51:39] <sharonchisholm> bernard - I think that would help. onl two paragraphs really apply
[13:52:11] <sharonchisholm> bernard - user password attribute, for example .... 1996 ....
[13:52:42] <sharonchisholm> bernard - be more explicity about what we are trying to fix.
[13:53:28] <sharonchisholm> M - capture all of this in the draft. ensure people don't get wrong ideas of what we will do
[13:53:46] <sharonchisholm> bernard - two page document with goals
[13:54:20] <sharonchisholm> k - also want to ensure this isn't a gap analysis of radius against the requirements in the document
[13:54:23] <sharonchisholm> bernard - no
[13:54:42] <sharonchisholm> joseph - the word negotiate worries me. radius doesn't do this well
[13:55:00] <sharonchisholm> dave - other protocols are better. we don't intend to change basic radius
[13:55:31] <sharonchisholm> joseph - more indication than negotiation. hope we don't try to introduce things
[13:55:39] <sharonchisholm> dave - we can clarify that as well. not the intent
[13:56:15] <sharonchisholm> glen - keyrefing for example. can send, get response, but with new stuff you send it and get response or it gets thrown away
[13:56:35] <sharonchisholm> alan - most is driven by the NAS .... dont' see much of a new issue
[13:56:51] <sharonchisholm> bernard - not adding new round trips to radius protocol ... say it explitly
[13:57:53] <sharonchisholm> glen - it would be bad to fall back to old agorithm which we know to not be secure ..
[13:58:10] <sharonchisholm> glen - don't see how this would be possible (crypto agility) without adding new attributes
[13:58:20] <sharonchisholm> bernard - new attributes would not be out of scope
[13:58:53] <sharonchisholm> glen - a better idea ... how to get stronger keys to go with these stronger algorithms
[13:59:16] <sharonchisholm> alan - BOF that started this all off. kickstart draft. did this, but had issue
[13:59:33] <sharonchisholm> alan - older security .. yes, that is an issue
[13:59:44] <sharonchisholm> alan - older servers don't understnad anything else.
[13:59:46] --- m_ersue has joined
[14:00:15] <sharonchisholm> bernard - way forward is to write a very short requirements document. get working group consensus on it
[14:01:01] <sharonchisholm> ------------------------
[14:01:08] <sharonchisholm> geopriv radius
[14:01:28] <sharonchisholm> changed draft based on review comments
[14:01:53] <sharonchisholm> iana
[14:02:16] <sharonchisholm> document status?
[14:02:24] <sharonchisholm> working group alst call?
[14:02:25] <sharonchisholm> don't know
[14:02:34] <sharonchisholm> publication requested
[14:02:53] <sharonchisholm> --------
[14:03:02] <sharonchisholm> radius mipv6
[14:03:29] <sharonchisholm> changes ... editorial, added various bits of text
[14:04:52] <sharonchisholm> nex steps
[14:05:16] <sharonchisholm> glen - if we adopt the radius extensions, will this have an impact on your draft?
[14:05:22] <sharonchisholm> it might, depends what you do
[14:06:04] <sharonchisholm> dave - if we want to conserve the attributes, we would have to revise something to set them aside
[14:06:19] <sharonchisholm> dave - could you give it a snapshot of what this is about
[14:06:54] <sharonchisholm> <in backup slides>
[14:08:59] <sharonchisholm> bernard - does there need to be a document update on <somethign>
[14:09:11] <sharonchisholm> dynamic update
[14:10:00] <sharonchisholm> gerado - we requeted the dns review for the dns update . it is in the spit .... we have not heard anythingback
[14:10:07] <sharonchisholm> bernard - we had a 7 year delay
[14:10:14] <sharonchisholm> integrated scenario
[14:11:25] <sharonchisholm> radius attributes
[14:11:41] <sharonchisholm> additional enhancements
[14:12:43] <sharonchisholm> gerardo - this will be discussed this afternoon in MIP6
[14:12:47] <sharonchisholm> aaa - goal
[14:13:51] <sharonchisholm> dave - send message to radext mailing list requesting review
[14:14:56] <sharonchisholm> glen - confused. don't know who the customer for this draft is.
[14:15:19] <sharonchisholm> glen - i don't know who is using mobile ip yet alone mobile ipv6 in real networks.
[14:16:01] <sharonchisholm> vidya - don't believe this is correct. used in in many networks. proxy mobile ip is not a substitute. does not work across domains
[14:16:10] <sharonchisholm> v - localized solution that compliements
[14:16:19] <sharonchisholm> -----
[14:16:30] <sharonchisholm> handover keys using aaa
[14:16:45] <sharonchisholm> no curent open issues
[14:18:19] <sharonchisholm> solution goals
[14:18:49] <sharonchisholm> faciliate FMIP deployment in systems with a aaa infrustructure
[14:22:01] <sharonchisholm> handover key hierachty
[14:22:55] <sharonchisholm> jari - when you say you don't want a relationto EAP, do you mean the one for access authentication or at all?
[14:23:14] <sharonchisholm> it should be independant of access authentication
[14:24:07] <sharonchisholm> new authentication method, like digest is what we are talking about here.
[14:24:29] <sharonchisholm> the handover key request, do the lookup, pershared key assumed, accept or reject based on the handover request
[14:24:46] <sharonchisholm> think some of the attributes be reused
[14:25:03] <sharonchisholm> had mobile ipv4 separated the authentication we would not be here
[14:25:20] <sharonchisholm> we should be looking at decouplig. not coupling with fast mobile ip
[14:25:43] <sharonchisholm> glen - there is a draft, part of which ... it is called key request. individual submission. thought i would point that out
[14:26:07] <sharonchisholm> I've gone back and forther on that draft ... thought that draft asumed the existing of material from a previous request.
[14:26:23] <sharonchisholm> in this this draft, you have not yet done authentication
[14:26:57] <sharonchisholm> glen - i don't think that is accurate. the asusmption if that there is keying materia that exists. you are requesting new key based on that master key
[14:27:14] <sharonchisholm> glen - it is writen towards EAP, but I don't think that is necessary
[14:27:20] <sharonchisholm> let's talk about about that
[14:27:52] <sharonchisholm> glen - you can put anything in key request that you want.
[14:28:30] <sharonchisholm> bernard - don't understand what this draft has to do with key and key requests
[14:28:44] <sharonchisholm> there is a key coming back for the access router
[14:29:53] <sharonchisholm> jari - basic idea. this is a new method based on a shared secret and must complete in one round trip
[14:30:02] <sharonchisholm> jari - wanted aaa guys to say this is acceptable.
[14:30:17] <sharonchisholm> jari - lot for one application, but if there are multiple reasons (become FMIP)
[14:30:27] <sharonchisholm> no state other then credentials
[14:30:31] <sharonchisholm> no cache
[14:30:48] <sharonchisholm> no dymanic state
[14:31:30] <sharonchisholm> jari - requires deployment of new credentials and support for the transactions
[14:31:40] <sharonchisholm> jari - would there be another way to achieve this
[14:32:40] <sharonchisholm> M - several comments ... related ... how would the design of radius extensions change this draft ... I ran into this as well. ... are you requiing changes in the radius infrustructure
[14:33:01] <sharonchisholm> M - for mobile Ip, what does the radius infrustrucure look like. in the end you end up just asking for attributes
[14:33:27] <sharonchisholm> <this work could end up there with a bit more analysis potentially>
[14:35:29] --- Alan DeKok has left
[14:35:37] <sharonchisholm> k - this seems to be trying to so is have it act as a key server
[14:37:14] <sharonchisholm> k - concerned with radius server being a key server
[14:37:34] <sharonchisholm> <are we not 7 minutes over?
[14:39:17] <sharonchisholm> bernard - cut this off, but what are our next steps?
[14:39:38] <sharonchisholm> dan - concerned by bullet sayin using radius as a aaa protocol for anything in this working group
[14:39:56] <sharonchisholm> dan - this working group needs clear requirements on what extensions are needed
[14:40:47] <sharonchisholm> M - if you give vendor ids to two different working groups, they will get the same attribute and different structures
[14:41:03] <sharonchisholm> jari - request was to see if this was feasible using radius.
[14:41:16] <sharonchisholm> bernard - yes, we can take that to the list. Jari should post request
[14:41:28] --- Dave Nelson has left
[14:41:30] <sharonchisholm> dave - need to adjorn. last item moved to the list
[14:41:46] <sharonchisholm> done
[14:41:49] --- sharonchisholm has left
[14:50:04] --- alfredprasad has left: Replaced by new connection
[14:50:04] --- alfredprasad has joined
[15:00:59] --- alfredprasad has left
[15:25:56] --- BertWijnen has left
[16:03:02] --- m_ersue has left