[14:14:17] histerrier joins the room [14:49:50] Dave Nelson joins the room [14:49:58] Dave Nelson has set the subject to: RADEXT WG Meeting at IETF-73 [15:03:18] alan.dekok@jabber.org joins the room [15:04:07] Jabber scribe && minutes will be done by me (when I'm not presenting) [15:04:20] 1 comment on design guidelines, 1 on management. David has a slide that summarizes that [15:04:33] 2 documents completed last call - crypto agility && extended attributes [15:04:35] davem joins the room [15:04:45] 2 in wg last call - radsec && status-server [15:04:50] 1 - just adopted as WG item [15:04:52] Good morning [15:04:54] individual submissions [15:05:08] tcp document review finished tomorrow [15:05:33] radext wlan document - 802.1 sent initial comments? more comments coming? [15:05:51] Joe: Still stuff happening in .1, but it's settlien down. We'll get more comments when new draft comes out [15:06:06] PKMV1 draft sent to WiMAX forum && 802.16 just responded today [15:06:14] completed 802.16 review [15:06:24] DTLS && encryptred attributes still in progress [15:06:31] documents in IETF last call [15:07:01] David Nelson: [15:07:08] management authorization draft [15:07:36] 1 issue was talking about udnerstanding of text? [15:07:45] discussion of SNMP versus RADIUS terminology [15:07:56] seemed out of place [15:08:07] was another last call review, editorial nits (nothing earth shaking) [15:08:21] request that ASCII art use a different form [15:08:41] DIME uses dots / colon, RADIUS docs don't use anything [15:08:50] missing reference for HTTPS (2818) [15:09:14] request that IANA actions about code points to be assigned should remain in published RFC. [15:09:23] Might not be necessary to keep those in the RFC [15:09:44] none of this is technical or substantitive [15:10:07] Klaas Wierenga joins the room [15:10:33] WG chair instructions is to address comments [15:11:26] Alan DeKok talking about Design Guidelines. A few comments in IETF last call. Will be addressed in next revision. [15:11:41] behcet.sarikaya joins the room [15:11:54] Appendix B lists the complex attributes and why they are good/bad. Might be good to put in Called-Station-Id which has SSID/Mac Address. [15:12:59] Alan DeKok on Status Server. [15:13:25] A few comments received, will be fixed in next revision. Permit Access-Accept from an accounting port. [15:14:10] David Nelson: This is documenting existing practice. Allowing Accounting ports to be used is fine... I do flinch at Access-Accepts coming from Accounting ports. [15:14:20] RADIUS meets itself at the end and snaps.... [15:14:38] Alan DeKok: RFC 2865/66 doesn't tie down originating ports.... [15:16:13] Bernard: This has been around since the mid-1990s... it is documenting existing practice... [15:16:31] David Nelson: It is historical... but not creating a precedent. [15:16:54] Alan DeKok: The Access-Accept cannot contain authorization attributes. [15:17:01] Klaas Wierenga leaves the room [15:17:02] Klaas Wierenga joins the room [15:17:52] Client sends a Status-Server (application layer ping), server responds with an Access-Accept & no authorizations. [15:19:11] TCP draft uses this as the application layer watchdog. [15:19:55] Suggestion from Glen: Extend Status-Server to a CoA port... for server to tell the NAS that they're up again. [15:20:10] ldondeti joins the room [15:21:53] some of us are trying to forget the Ascend days! [15:22:14] may bw WG consensus to remove text on CoA. [15:22:18] RadSec document ---- [15:22:25] who is speaking? [15:22:31] stefan winter [15:22:42] new version published [15:22:45] 2 open issues [15:22:57] WG last call lasts until 25 nov [15:23:09] Q: whether to use SRV's or not [15:23:15] Q: how to register NAPTR with IANA [15:23:24] draft follows 3588 [15:23:47] which says do NAPTR lookip, if unsuccessful, look up _radsec._tcp.domain [15:23:49] may not be nice [15:23:55] Q: why don't we just use SRV records? [15:24:06] suggestion: do SRV lookups [15:24:17] Bernard: some advantages to using SRV (ports, weighting) [15:24:34] Diamter is the only one using A/AAAA NPTRs. Everyone else uses SRV. [15:24:37] Stefan: OK [15:25:01] Bernard: SIP has separate document on how to find server. It might be a good thing to split this document into two [15:25:12] especially for i18n issues [15:26:20] Stefan: document is silent on i18n issues [15:26:33] could put algorithm into other document 3263 is an example [15:26:42] Joe: does diameter have any recommendation here? [15:27:00] Bernard: yes, 3588. [15:27:07] Does anyone use it? (silence) [15:27:15] Stefan: how do I register NAPTR construct. No clue! [15:27:25] Asking for help... [15:27:33] Klaas Wierenga leaves the room [15:27:41] Klaas Wierenga joins the room [15:27:44] Bernard: ask Hannes [15:28:27] Bernard: last call goes to 25th. Please read it. [15:28:34] Extended attributes document --- [15:28:58] We are in issues resolution. Some are under dispute [15:29:37] we have 5 open issues. Document has been around for 18 months. Hoping that discussion will converge. [15:30:02] it's hard to determine consensus from people saying "yes" and "no" [15:30:21] it doesn't seem to be moving forward. Other WG's have dependencies on it. [15:30:38] request that WG look at it. [15:31:05] Stefan: issue about when you are allowed to fragment if you have less than 246 octets... no consensus [15:31:35] Bernard: doing weird little fragments is a great way to break things [15:31:53] Dave nelson: if it's a matter of efficiency, then it ould be a recommended or a should. [15:32:08] Unless it breaks interoperability. It doesn't need to be a MUST [15:32:23] Issue 272 was withdrawn by Glen? [15:32:52] we will need to bring in folks from Dime. IANA considerations aren't well completed. How will Diameter deal with it? [15:33:10] Proposal to deal with it as attribute 26, but 3588 doesn't deal with that. [15:33:24] potential big issue (related to 0..255). [15:33:41] Do we allocate from this space before the RADIUS attribute space is all used [15:33:45] Klaas Wierenga leaves the room [15:33:53] Klaas Wierenga joins the room [15:33:54] If you need a lot of attributes, do you allocate from this space. [15:34:03] As Diameter/ RFC 4005 stands, attr 26 is not allowed directly. [15:34:13] Dave Nelson: Dave mitton had presented slides about attribute 26 && Diameter [15:34:28] Bernard: no one in DIME is thinking about this. Glen is claiming no dependence, and it's wrong. [15:34:42] Dan: what do we do if we have a request for allocation [15:34:52] Bernard: draft isn't approved. [15:35:00] Dan: needs to be passed in sync with diameter. [15:35:12] Bernard: is intent to allocate after / before exhaustion of standard space. [15:35:31] Diameter has to figure out how it translates the attributes [15:35:56] Dan: action for Dime, and text needs to be put into IANA considerations && Diameter considerations. Text isn't in the document now [15:36:25] People should be able to sit at a table for 1-2 hours, and get consensus on these issues. [15:37:02] Bernard; might be good to show up on Dime && discuss this [15:37:09] Dave Nelson: talk about this at AAA doctors lunch. [15:37:35] There are functional enhancements as well as exhaustion issues. In the absence of text, IANA should allow allocations in the extended space. [15:37:38] I can resurect the draft if there is interest? [15:37:47] People shouldn't need to wait until standard space is exhausted. [15:38:27] Crypto agility draft ---- [15:38:53] 2 open issues, some editorial issues. -01 submitted this week. [15:39:58] automated key mgmt [15:40:10] radius doesn't have negotiation of things. [15:40:20] best we have is hint && accept, or hint && reject [15:41:00] how to avoid bidding down attacks... [15:41:09] how does client / supplicant know why it's been rejected. [15:41:50] who is speaking? [15:41:52] Joe: problem is that it's not really a hint. If password is encrypted, you need to agree [15:41:57] Joe Salowey [15:42:20] Dave: use another round trip as call-check.. [15:42:31] Bernard: don't design solution. [15:42:51] trying to avoid compromising highest cipher suite during negotiation [15:43:38] been lots of discussion on the list about requirements: don't write stupid requirements... [15:44:02] Bernard: should what extend should you be able to Just Work when there's a mixture of things [15:44:28] do you get a RADIUS server upgrade first.. then the NAS? (e.g. TTLS) [15:44:54] maybe clients can assume that the server is capable if they're capable? [15:45:48] Dave: Bidding down attacks [15:45:58] What happens if MD5 is crached? [15:46:05] [15:46:34] crypto-agility solutions can't depend on introduction of new negotiation capabilities into RADIUS. [15:47:19] looking for feedback in room / list [15:47:35] behcet.sarikaya leaves the room [15:47:36] Joe: back to issues slide [15:48:18] Dave: slides were proposal to see if it's reasonable [15:48:28] Joe: seems reasonable. [15:48:39] seems to be right direction [15:49:37] Bernard: Extended attributes [15:49:49] Alan DeKok on RADIUS over TCP [15:50:07] Goal is to take TCP-specific issues in RADSEC draft that were independent of TLS issues and take them out. [15:50:12] Describe how to do RADIUS over TCP [15:50:32] RADIUS protocol isn't changed. This should simplify implementations. [15:50:39] Some TCP-specific issues.... [15:51:05] Don't have to validate IP every time. [15:51:26] Have to reset after receiving a malformed packet. [15:51:49] Magnus Westerlund: It depends on how you structure the protocol. If you would provide framing around it, not raw RADIUS, then... [15:51:56] Alan: No framing... just raw RADIUS. [15:52:15] Magnus: I understand.. [15:52:31] Alan: If you have attributes with length of 0 or 1, you reset the TCP connection. [15:52:54] You can only have 256 IDs... so only 256 connections. RADSEC puts both accounting and authentication packets over one TCP connection which helps a bit. [15:53:10] Magnus: Is it outstanding requests or packets in flight? [15:53:23] Alan: Outstanding requests. [15:53:39] Magnus: Will interact badly with TCP connection state.... won't keep enough traffic in flow. [15:54:51] Bernard: Are we trying to enable RADIUS over TCP without RADSEC? [15:55:06] histerrier leaves the room [15:55:10] Magnus: It seems generic.... SCTP might be a better fit.... [15:55:48] Magnus: Applicability statement seems to be a bit off. My impression.... sending less than one packet per RTT doesn't disqualify TCP.... [15:56:13] Magnus: What is the applicability and what do you want to gain here? [15:57:08] David Nelson: There is WG consensus, and there is what makes sense. When we had WG consensus to separate the document... so it could be used for things other than RADSEC. We may to revisit this if we determine that revisiting that was a bad idea. [15:57:19] Alan: Document is relatively silent on this right now. [15:57:28] histerrier joins the room [15:58:38] Alan: Need a way to distinguish Access-Accepts from Status-Server from normal ones... otherwise you send 256 packets... you try to send Status-Server but can't because there are no free IDs yet. Nobody likes this idea. If anyone has a better suggestion.... [15:58:47] Collective groan. [15:58:57] Alan: This is RADIUS... it is disgusting. [15:59:06] Bernard: This is beyond disgusting... it's badly broken. [15:59:26] David Nelson: We need to avoid this.... [16:01:25] Bernard: We should open an issue on this... [16:02:44] Alan: SNMP MIBs can be used... [16:03:00] Dan: We might want to separate UDP/TCP counters... could do this in next MIB revision. [16:03:19] In standard MIB... there is only global counters. [16:05:42] Magnus: You could have TCP for one leg and not for the second leg... that could cause transport problems. [16:07:08] behcet.sarikaya joins the room [16:08:52] (Discussion of congestion issues with UDP on one leg and TCP on another) [16:09:01] Bernard: We need to talk about this... [16:09:15] Alan: A lot of transport area review that needs to be done [16:10:33] Dave: Is there any objection in the room to starting WG last call on tunnel-type value draft? [16:10:34] None. [16:10:38] 802 drafty [16:10:58] liason from 802.1 received. Referenced in 802.1X-Rev D2.9, Appendix E [16:11:12] added 2 new attributes to support 802.1x [16:12:03] 802.11s status is uncertain [16:12:20] may have to remove 11s stuff from document [16:12:35] next steps - sync draft with 802.1x-rev [16:12:41] adoption as WG item? [16:14:32] draft -zorn-radius-encattr ---- [16:14:52] Joe: quick update for encrypted attributes draft. [16:15:18] merged attributes into 1 for wrapper to encrypt data, which may be keys or other data. [16:16:43] "Comsiderations" ? Very telco-centric. ;-) [16:16:48] :) [16:17:34] ready for adoption as WG item [16:18:02] Dave: discussion of crypto-agility requirements... are additional WG items that this document would need? [16:18:14] Joe: would need to be some supporting things around negotiation. [16:18:21] May be some kind of error indication [16:18:45] Dave: would be nice to keep requirements && solution documents in sync [16:19:16] Bernard: keep in mind that this document negotiations a bunch of different things. No bidding down attacks [16:21:03] Joe: every RADIUS response now has crypto implied. Many requests do, too. [16:21:54] Bernard: say MD5 gets cracked tomorrow... that wouldn't get you encryption keys [16:22:34] Joe: might say that I want to encrypt password with AES rather than MD5. [16:23:31] Dave: implicit in crypto agility that all algorithms will someday fail. We can't assume that there's no bidding down attack. [16:23:59] Bernard: if we assume that you wouldn't be doing encryption without stronger hash as well, we'd be better than where we are now. [16:24:09] When MD5 gets cracked, you lose both encryption && integrity [16:24:27] This document makes it easier to work if compromise of one algorithm [16:28:55] Dave: if we're talking about a migration strategy, negotiations can only be protected with classic RADIUS [16:29:02] (discussion of security and negotiation) [16:29:27] Joe: we can get somewhere that solves a lot of problems. [16:29:43] Bernard: suggestion to talk about transition more in this document. (traditional RADIUS to this, etc.) [16:30:34] i18n discussion-- [16:30:40] Anyone present in EMU [16:43:21] Is beating vendors a recommended practice of RadExt? [16:45:58] ldondeti leaves the room: Replaced by new connection [16:45:58] ldondeti joins the room [16:46:40] who is that? [16:48:06] behcet.sarikaya leaves the room [16:49:39] I was speaking for a while... various comments from other people.. [16:49:45] k [16:50:12] IPv6 prefix assignment document [16:50:33] Bernard: 3162 was pre-eap. PPP or something else. [16:51:32] Need Authorzed-UserId-Preifx attribute [16:51:38] Joe: what is prefix authorization user id? [16:52:11] A: Server needs to identify user. [16:52:50] Joe: client stores this value, and puts this value in a request? [16:53:31] message flows slide [16:54:06] renumbering via CoA request && ack [16:54:50] Bernard: if renumbering happens, how does the end user get their new address? [16:55:50] Joe: RADIUS packet already has context information about who's requesting things [16:56:36] Joe: may not need to encapsulate in separate attribute [16:58:22] Bernard: may be other things associated with prefix [16:58:51] Q: how does this draft relate to 4818? [16:58:59] A: completely different [16:59:19] Here, AAA server gives prefixes to AAA client. 4818 gives prefixes to DHCP server [17:02:06] Bernard: can't say we're creating a new way of delegating prefixes without bringing in some other body [17:02:20] davem leaves the room: Replaced by new connection [17:05:40] who is that? [17:05:41] Frank: DHCP radius interface excludes possibility that this can be done by AAA [17:06:34] only DHCP can deal with renumbering. AAA can't done that. This draft violates that [17:08:37] 3162bis document --- [17:09:06] document needs additions to accomodate IPv6 production networks [17:09:58] how to provide DNS information. Delivery to client. [17:10:24] Bernard: it would be great to have those references in the doc itself. [17:10:36] Q about 3646: could there be a flood of requests for more DHCP options? [17:10:59] Ralph had a draft that allowed many DHCP options in one RADIUS attribute [17:11:06] There may be more DHCP options needed... [17:15:47] how to move forward: acknowledge independence from DHCP [17:16:05] agree on document path. RFC 3162bis isn't right approach... separate document is preferred. [17:17:22] Glen: 3162bis would be oK. It's not DHCP specific [17:17:43] i thought glen was not there [17:18:19] that does sound like him though [17:18:30] came in 1 minute ago [17:19:07] behcet.sarikaya joins the room [17:19:08] Glen just came in. [17:19:35] Dave: if this is talking about services other than DHCP... do we define a new service in a RADIUS document? [17:20:03] Bernard: this document references existing services. [17:20:44] Glen: opposed to both drafts because they're not AAA related. Might not be a bad idea to define new service, as they're not per-user. [17:20:58] RADIUS client is likely to be a DHCP server / relay rather than a NAS. [17:21:14] Bernard: separate document seems to be the way forward [17:21:51] Summary && wrap-up [17:22:00] behcet.sarikaya leaves the room [17:22:06] Dave: still have some issues that need attention [17:22:32] need indication of what goes in what document... [17:23:17] Bernard: 2 documents in WG last call have consumed the group. Others need to help move things along, like getting their own reviews. [17:23:29] get feedback pro-actively. [17:24:27] THANKS TO JABBER SCRIBES :-) [17:27:02] ldondeti leaves the room [17:27:49] histerrier leaves the room [17:28:39] alan.dekok@jabber.org leaves the room [17:28:54] Klaas Wierenga leaves the room [17:29:53] Dave Nelson leaves the room [18:04:16] Alan DeKok joins the room [18:38:10] Alan DeKok leaves the room [18:39:04] Alan DeKok joins the room [18:51:25] Alan DeKok leaves the room [19:01:46] Alan DeKok joins the room [20:57:13] Alan DeKok leaves the room [21:10:33] Alan DeKok joins the room [21:18:57] Alan DeKok leaves the room [21:22:03] Alan DeKok joins the room [21:24:21] Alan DeKok leaves the room [23:00:39] Alan DeKok joins the room [23:39:02] Alan DeKok leaves the room [23:42:01] Alan DeKok joins the room [23:47:40] Alan DeKok leaves the room