IETF 72 - RADEXT WG Meeting Minutes Wednesday, July 30, 2008 Agenda Bashing -------------- No changes to agenda. Document Status --------------- AD Review: NAS Management Authorization Completed WG last call: Design Guidelines In WG last call: Crypto-agility Requirements Extended Attributes WG work items: RADSEC Status Server Under review as WG work items: IEEE 802 Attributes RADIUS over TCP RADIUS over DTLS RADIUS Encrypted Attributes Other Documents RADIUS Location (completed IESG Review) AAA Multicast Reqts (in MBONED WG Last Call) Extended RADIUS Attributes, Glen Zorn, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-04.txt ------------------------------------------------- No slides. Glen mentions that the -04 document was updated to address the WG consensus on the size of the Type field (now 2 bytes), as well as applicability to existing RADIUS attributes (not applicable). No other changes. Hannes: There are now quite a few open issues on this document. Several have been open for a while. Was this document really ready for WG last call? Glen: Yes, a number of issues are still open. For example, text needs to be added in the RADIUS/Diameter compatibility section, and the IANA considerations section needs to be re-written. Hannes will solicit a review from the DIME working group on this document. RADIUS Design Guidelines, Alan DeKok, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-radext-design-04.txt ------------------------------------------------- Bernard: This document is pending updates to address the WG last call comments. After those issues have been addressed, we will do a short "last look" and if there are no further issues, we will send the document off to the IESG. Hannes Tschofenig: Asks for more information on the considerations for the RADIUS server / NAS implementations. Hannes will also ask the DIME group for reviews. Transport Documents (40 minutes) TCP Transport, Alan DeKok, 10 minutes http://www.ietf.org/internet-drafts/draft-dekok-radext-tcp-transport-00.txt --------------------------------------------------------------------------- Dan: You need can get information from other MIBs as well, such as UDP and TCP MIB. He does not believe that there is a need for new objects. Alain: TCP servers do not necessarily need to be located in the same box as the corrsponding UDP port Avi: Not specific about TCP. Put it into the guidelines document. Alan: speaks about silent discards. Bernard: asks whether it is a good idea to close the connection or whether it would be better to keep it alive. Hannes: refers to a comment by Alan that there are problems when you do not send enough packets and the timers will expire. Bernard: In most cases the minimum window size (1 for *NIX, 2 for Windows) will be used if parameter decay is implemented, since packets are so few and far between. So TCP windowing (and congestion control) really isn't operative in most cases; behavior will be similar to UDP except with the addition of ACKs. Alan: TCP isn't really for use by NASes, more for proxies. Hannes: Lots of interest in Diameter UDP transport now, due to higher scalability. So while RADIUS is defining TCP, Diameter wants to define transport over UDP. Bernard: Should we ask for a Transport Area advisor? He asks whether the work in DIME on the congestion control was advanced. Hannes responds that the group didn't want to do that work. Stefan: One benefit of TCP is handling fragmentation in RADIUS. We do see RADIUS (particularly with EAP) packets that are fragmented. UDP fragments may get dropped by network elements. Stig: I implemented RADIUS over TCP; I did not like the number of sockets that have to be opened. Alan: Will add it to the guidelines document. Status Server, Alan DeKok, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-00.txt ------------------------------------------------- Bernard: How does the watchdog timer work? Is it based on RFC 3539? Alan: If you do not send traffic then you are do not send "are you alive?" messages. If you are sending traffic, but do not receive responses, then you should be sending status packets. Fail back is supported. Glen: It would be much better for the server to tell the client it is back. Alan: Yes. But unsolicited packets from the server are likely to be discarded. Glen: We have unsolicited packets in RFC 5176. Alan: CoA and Disconnect packets use a different port; Status-Server uses the existing RADIUS port. In any case, we're focused on documenting an existing protocol, not creating a new one. This protocol dates back to the mid-90s. Typically firewalls will not allow unsolicited traffic to be sent to a NAS on the RADIUS port. Stefan: When would this scenario arise? Glen: When a server crashes and comes back online. Alan: If you have a CoA port for the NAS then it is better to let the RADIUS server send a message that it is back. However, this is not how the existing protocol works. RADIUS over DTLS, Alan DeKok, 10 minutes http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-01.txt ------------------------------------------------- Alan: There are several potential options for mutual authentication between the RADIUS client and server. One is to use TLS with pre-shared keys. Glen: Does the authenticator use a fixed shared secret? Alan: For TLS PSK, yes. If you are doing certificate-based mutual auth, no. Alan: Maybe you want to derive the keys for the Authenticator from the TLS Master Keys. Stefan: The question would also come up with RADSEC. Joe: In TLS we are working on an extractor document. This might be useful. Stig: The authenticator does not make a lot of sense since there is DTLS below it. Alan: that's true but we want to keep the protocol the same. Kauschik: I also believe that the authenticator is not too useful. Stefan: We should support DTLS ciphersuites with encryption. Bernard: it is useful to require encryption and mutual auth. RADSEC, Stefan Winter, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-00.txt ------------------------------------------------- Bernard: Who has read this draft? 3 people raise their hands. Stefan: mentions a number of the challenges. Dan+Stefan+Hanna: Discussion about splitting normative and informative text in the protocol description. Stefan: I think the document is now ready for its first WG last call. Glen: Can we jump immediately to the fifth WG last call, the one where people actually read the document? Bernard: We will ask for reviews to be sent to the list. Once the issues are addressed, we will go to WG last call. RADIUS Cryptoagility (20 minutes) RADIUS Cryptoagility requirements, David Nelson, 10 minutes http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-00.txt ------------------------------------------------- Bernard: So far there have been no comments in WGLC. How many people have read the draft? 5 people raise their hands. Bernard: Can you send comments on it? If you have no issues, but think it's fine, please post that opinion to the list as well. Bernard: Once we address the review comments, we will also seek review from the Security Directorate. RADIUS Confidentiality, Glen Zorn, 10 minutes http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-11.txt ------------------------------------------------- Glen: A number of changes have been made to address WG feedback (Issues 220, 221 and 244). Also this document has been reworked to utilize the extended attributes document. Discussion about the grouping of the attributes from draft-zorn-radius-encattr-11.txt. Glen: The grouped attribute in the extended attributes draft doesn't have a label. Only individual attributes do. Is this a problem? Alan: possibly. Bernard: Let's discuss this on the list. Additional Documents (30 minutes) RADIUS Attributes for IEEE 802 Networks, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-08.txt ------------------------------------------------- Bernard mentions that the dates for the completion of this document and the IEEE 802.1X-REV. Dan mentioned that the IETF and the IEEE dates are different. Dan suggested to go through the fast path. It does not mean that work in the IETF cannot go fast but they are hard to predict. Avi: We start using EAP methods with identity hiding but on the other hand we shuffle the MAC address around. Bernard: The keys are indexed using the MAC address. It is a lame reason. Avi: We, the IETF, need to tell them. Joe: The MAC address is not necessarily important for the RADIUS server. Some of the discussions in .1 the called station id might not be the appropriate way. Alper: What is the reason for placing a "PANA (no pre-authentication)" in the registry for the EAP lower layers. Bernard: We might want to add PANA in addition to PANA pre-auth. Bernard points to some privacy issues. David Nelson asks regarding the Access-Level. Access-Level refers to levels of what happens when you finish acess authentication. This Access-Level is more for the end user rather than for the NAS. Stefan: Would it make sense to have a way to tell something the user? (e.g., whether they are allowed todo certain things) Joe: It would be possible to communicate additional information but a text string has add Avi: what channel would you use? Joe: In 802.1X-REV there is a channel to communicate additional information to the end point. Alper: Does this feature plug-in into RADIUS or EAP? Bernard: it may. Depending on the environment the end host may do something different Hanna: We should care about internationalization. Avi: We are struggeling with similar issues in Wimax. This channel is somehow protected? Bernard: The Beacon isn't secured but there is a 4-way handshake that provides security. We will not go into the details here. Alper wants to add a few more fields into the registry. Problem Statement and Requirements for Diameter/Radius Prefix Authorization Application, B. Sarikaya, 10 minutes http://www.ietf.org/internet-drafts/draft-sarikaya-dimeradext-prefix-auth-ps-00.txt ------------------------------------------------- Glen: This has nothing todo with AAA. What user is being authenticated? Bernard: I am confused about what certificate is being used here. Avi: I am confused about what is being authenticated and how authorization works. If this is indeed needed then why isn't it covered already by the Diameter MIPv6 / RADIUS MIPv6 aspects. Behcet: There are values in having it separate from MIPv6. Avi: By having separate applications this means separate transactions. If this is always required then I would have to trigger another transaction for prefix authorization. Glen: The question of what is being authenticated and authorized is the crutial aspect. I don't see any users involved. The thing you are authorizing is not a human. You are shipping a bunch of prefixes via RADIUS, with no authentication. Ralph: The draft you refer to is in the NEMO WG. Those prefixes are not delegated. Bernard: This is an extension to RFC 3162, no? Ralph: The delegated prefixes are sent to a customer router and then are used within that network. Bernard: How is this different from RADIUS support for Prefix Delegation (RFC 4818)? AVi: I don't understand why the lifetime of the session is not tied to the lifetime of the prefix. We better understand what is missing, before writing a draft. Bernard: When RFC 3162 was written, the assumption was made that the lifetime the prefix and the lifetime of the session were the same (determined by Session-Timeout. Maybe they are distinct things. The RADIUS server might want to tell the NAS something about the prefix lifetime. Avi: What would happen when the prefix expires? Ralph: The lifetime could be the prefix lease time or the values of the RA. These expire separately. Avi: When the lifetime expires, would this lead to some AAA action? Ralph: This is a separate, I think. Glen: Is this actually a AAA problem? Ralph: You need to decide that. Bernard: When you renumber you can send a CoA-Request to change the advertised prefixes and/or delegated prefixes. However, you have to do this for every user attached to every NAS affected by the renumbering. IPv6 Attributes for DHCP Networks, B. Lourdelet, 10 minutes http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-00.txt ------------------------------------------------- Avi Lior: Why wouldn't this be a DHC WG item? Bernard: The document doesn't relate to DHCP, it deals with RADIUS support for IPv6. Avi Lior: In other cases we have done the work outside the RADEXT group. We should be consistent. Ralph: In DHC WG, we provide advisory reviews of work that is being done in other working groups. However, we don't do work relating to other protocols such as RADIUS. Glen: There also another option: don't do it at all. Is there some user authentication going on here? The slide doesn't show that. B.: There is a PPP authentication exchange going on here that is not shown on the slide. The request happens before the PPP authentication process. Avi: There is no authentication happening between the DHCP client and the DHCP server. PPP address assignment doesn't involve DHCP. I'm confused. B.: PPP authentication happens first. Bernard: This is an alternative to RFC 3162, it would seem. But the diagram does not make sense. Alper: There is no Framed-IPv6-Address attribute, only Framed-IPv6-Prefix and Framed-Interface-Id. Bernard: The issue is that RFC 3162 might have some text on what actions are required. Glen: I liked Avi's suggestion to revise RFC 3162 document. Bernard: Let's do a hum. How many people would like to handle this as a separate document? How many want to do an RFC 3162bis and handle it that way? Results: Mild preference for incorporating the functionality in RFC 3162bis rather than a separate document.