Minutes of the RADEXT WG Virtual Interim October 13, 2009 8 AM - 10 AM PDT Chairs: Bernard Aboba David Nelson Design Guidelines Alan DeKok: -09 has been submitted. This includes a number of clarifications with respect to tags, VSA formats, simple versus complex types. There are no MUSTs or MUST NOTs in the document. Guidelines try to encourage good practice, but should not be followed slavishly. Dan: Jari has cleared his DISCUSS. So the document could be sent to the RFC Editor for publication immediately. Bernard: Not clear that the document is ready. There are still two open issues from IETF last call: Issues 313 and 314. Issue 313 concerns the "security exemption". Does this apply to any attribute relating to security or authentication? There was confusion on this point during the review of the PKMv1 document. It does not seem that this issue was addressed in -09. Alan: There were some changes in Appendix A.2.2. Bernard: Yes. However, A.2.2 still exempts attributes "for purposes of authentication or security". The question is whether the exemption is too broad, or even whether that is the correct distinction. Is the issue security/authentication or is it computation? For user authentication or RADIUS security attributes there is computation involved: the client has to compute something and the server has to verify, or vice-versa. If an attribute relates to security (e.g. sending a certificate) but there is no computation, does the exemption still apply? In that case, it might have been possible to use the String type to enable a legacy server to configure the certificate to be sent as an opaque blob. It's not pretty, but it could be done without upgrading the server. However, if a complex attribute is defined, now you need to upgrade the RADIUS server as well as the client. So should we give authors of security/authentication attributes a blanket exemption on this? Hannes: There may be other examples of computation. So could the exemption also be too narrow in some respects? Bernard: Possibly, yes. Right now we are making the distinction based on experience, but maybe not articulating the principle behind it. David Nelson: That may also be an issue elsewhere in the document. Is there enough background for someone not versed in RADIUS to understand where the document is coming from? If we are judging by recent experiences, the answer is "no". Bernard: I agree that recent experience is not encouraging. Alan DeKok: Are people actually reading Design Guidelines and not understanding it, or are they blowing it off? Bernard: In some cases, people are questioning the fundamental wisdom behind it. Issue 314 was filed by Hannes. It was to be followed by specific text to address the concerns, but this wasn't provided. If time hasn't already run out (it's approved for publication!) then we are very close to that time... Hannes: The state of the art has advanced. In some designs addition of code is no longer a big issue, scripts can be plugged in. Also, parsers have improved, and could enable complex attributes to be supported automatically. So are we locking ourselves into the past? David Nelson: Many RADIUS server implementations utilize a data dictionary. This allows administrators to add the definition of a new attribute without having to upgrade the server. If an attribute doesn't have to require a server upgrade, that is probably a good thing. Bernard: There are a lot of legacy RADIUS servers out there that implement the data dictionary model described in RFC 2865. For those implementations, the data dictionary provides benefits. It can save administrators time and money, allowing them to support a new attribute immediately without waiting for a RADIUS server upgrade. David Nelson: It is also possible to use opaque attributes, where the data is not parsed by RADIUS but by some other component. Those attributes are sent to and from a plugin. So the model still has flexibility. Dan Romascanu: There is also the question of whether normative language is being used in the same way as described in RFC 2119. Do we need to update the draft? Bernard Aboba: How about an RFC Editor note? Dan: That would be easier. David Nelson: I think it would be best to get the document published and then see how well it works in the real world. Bernard: So far, we've used it in reviewing two documents, the PKMv1 document, and the IPv6 access document. In both cases, there was confusion about how the guidelines applied that required clarifications in the text. So the "real world" experience is not so good. That's why the document has taken so long to finish. Bernard: Alan -- can you take the action item to work with Dan on addressing the RFC 2119 issue as well as proposing an RFC Editor note to address issue 313? Status Server Alan: This draft was revised. An applicability subsection was added. There were some terminology changes. David Nelson: Does this document just describe what has been deployed, or does it also describe how Status-Server is used in RADSEC? Alan: It is focused on what has been implemented. The RADSEC document uses Status-Server as an RFC 3539 Watchdog, but that is covered in the RADSEC document, not in this document. Bernard: Status-Server was originally implemented by Ascend in their concentrators. Alan: It was subsequently implemented in RADIATOR and FreeRADIUS. Bernard: It would be good if we could get some additional reviewers to look at whether the document accurately describes their implementations. This isn't a standards-track document; its job is just to describe what has been implemented. We had talked to Ignacio Goyret, who is with Ascend about reviewing it for accuracy. Alan: RADIATOR has also implemented it. So maybe Mike McCauley could review it. Bernard: If we could get those folks to review it for its accuracy with existing implementations that would improve the level of confidence. Do we have other reviewers? David Nelson: I will review it for clarity and coherency, but I'm not an expert on what exactly was implemented, so I can't vouch for the accuracy with which the draft reflects deployments. RADIUS over TCP Alan: We added text to the applicability section. We're now using the term "RADIUS over TLS" instead of a vendor's product name (RADSEC). We also added text on the head-of-line blocking issue. Bernard: As I recall, Magnus Westerlund (Transport AD) raised this issue initially. What can can be done to address this issue other than opening multiple TCP connections? Alan: Nothing. Dan: What is the issue specifically? Alan: If a packet is lost, then all traffic that was intended to travel on the TCP connection has to wait until the data at the head-of-the-line is acknowledged. This isn't an issue with UDP. Hannes: One of the reasons we created the SCTP transport for Diameter was to address the head-of-line blocking issue. But SCTP has not been widely implemented. Alan: For those that are interested, FreeRADIUS now supports RADIUS over TCP, so you can play with it. Bernard: Does the latest revision address Issues 315 and 316? Alan: Yes. Bernard: OK. If there are no open issues, then we could do another WG last call. RADIUS over DTLS Alan: RDTLS has been implemented in Stefan's RADSEC Proxy. I am implementing it as well. This draft was not revised. David Nelson: Isn't this draft expired? What is the status? Alan: It is not expired. Bernard: We issued a call for interest. Only one or two people responded. There are no open issues at the moment. We need more reviews. IEEE 802 Attributes Dan Romascanu: Is this document only about WLAN attributes or wired IEEE 802 attributes as well? Are the attributes usable on multiple technologies? I found the document confusing in this respect. Bernard: A number of the attributes are specific to a technology. For example, there are attributes that relate to IEEE 802.11r specifically. There are also attributes that relate to IEEE 802.1X-REV. Joe Salowey: IEEE 802.1X-REV does apply to wireless, but there are aspects (such as announcements) that were only meant to be implemented on wired networks. We should be clear about the applicability of each attribute. Bernard: At one point we had attributes specific to IEEE 802.11s, but the security model changed, so we removed them. David Nelson: What is the status of the document? Bernard Aboba: It expires on October 30, 2009. IEEE 802.1X-REV has completed Sponsor Ballot. We were waiting until resolution of Sponsor Ballot comments to align the document with IEEE 802.1X-REV. Joe Salowey: IEEE 802.1X-REV is now going into recirculation ballot. So it is a good time to look at it again. Bernard Aboba: The document is referenced in Appendix E of IEEE 802.1X-REV. But it is not a normative dependency. Joe Salowey: Now that IEEE 802.1X-REV has settled down, I will review the document again, to see what changes may be needed. Bernard Aboba: After Joe is done with his review, what are the next steps? Dan Romascanu: For a standards track document, it can either be a WG work item, or an AD sponsored document. I would prefer a WG work item, especially since this topic is on the WG charter. Bernard: There was a call for interest in November 2007, but it never completed. So the document has been in limbo for almost two years now. David Nelson: Did anyone respond to the call? Bernard Aboba: Some people responded, yes. David Nelson: I was waiting for IEEE 802.1 to send their requirements. Bernard Aboba: IEEE 802.1 provided their review of -08 in July 2008. That is now up on the liaison archive. David Nelson: We can either send the document to the RFC Editor or run a quick WG last call on it, once it is aligned with IEEE 802.1X-REV. IPv6 Attribute Design Considerations Hannes: This document initially did not have much interest, then there was a lot of discussion on the list due to interest from the Broadband Forum. There are a number of ways to address the review from Alan. The document utilizes a tagging scheme similar to, but not exactly the same as RFC 2868. The authors did not want to depend on Extended Attributes since it has not been progressing (and is now expired). Bernard: It seems like many of the attributes that are tagged relate to a router advertisement, correct? Hannes: That is my understanding. Bernard: One of the objections to the current scheme is that it creates multiple new tagged data types. A new attribute is needed for each element of the RA that needs to be expressed. It occurred to me that it might actually be easier to define an opaque blob that carries much of (or the entire) RA. David Nelson: It seems like the lack of progress on Extended Attributes is creating a problem. Design Guidelines says that the RFC 2868 tagging scheme isn't suitable for generic use. But it doesn't make a recommendation. If we don't get Extended Attributes done, then we will be creating a problem. After finishing Design Guidelines, it seems like this needs to be our #2 priority. Bernard: Agreed. To be clear though, this document does not currently depend on Extended Attributes. Question: If Extended Attributes were further along, would this document use it? David Miles: I don't think so. David Nelson: It seems like there are a number of use cases here, and they are not clearly described. Bernard: Previous documents have had very well defined uses cases. RFC 3162 supports address auto- configuration. RFC 4818 supports DHCPv6 Prefix Delegation. This document supports multiple modes, and that is confusing. David Miles: In looking at the attribute list, there are a set of attributes relating to router advertisements that require tagging, but another set of attributes like IPv6-Address and IPv6-DNS-Server-Address that do not. Would it make sense to split the document into two parts, one focusing on DHCPv6, and the other one on router advertisements? Bernard Aboba: Yes, I think this would help. David Nelson: Which attributes are you interested in? David Miles: For the Broadband Forum, IPv6-Address is of the most immediate interest. IPv6-DNS-Server-Address is relevant but isn't as important since in most cases name resolution is being handled over IPv4. Bernard Aboba: If that is what you need, then focusing on that would enable things to go forward much more quickly. Can you put a document together that focuses on that? David Miles: There is already a document that does that. David Nelson: Which one? David Miles: http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-dhcp-00 Bernard Aboba: Yes, that document just handles the attributes you are interested in. However, it confused the WG because it only talked about DHCPv6 and RADIUS, but did not talk about authentication. RADIUS is spoken between a RADIUS client and server. So if the RADIUS client is also a DHCPv6 server, then it makes sense. But if the DHCPv6 server is separate, then it's not clear how it works. Does the NAS pass the RADIUS attributes to the DHCPv6 server, and if so, how? Is there authentication going on between the DHCPv6 server and the RADIUS server? Is the DNS server attribute just one of a series of DHCP attributes that need to be encoded in RADIUS, and if so, should we handle that in a more general way? Is the DHCP server talking to the RADIUS server with no authentication involved? In that case, is the interaction a Call Check, or is there no authentication at all (which would violate RFC 2865)? David Miles: I can include material on the Broadband Forum scenarios. These all involve authentication, either via PPP (e.g. CHAP, EAP) or via DHCP authentication. If I work with Benoit to create an -01 with that additional material would that help? Bernard Aboba: Yes, it would help a great deal.