IETF 73 - RADEXT WG Meeting Minutes Tuesday, November 18, 3008 Agenda Bashing -------------- No changes to agenda. Document Status --------------- For update, see http://www.drizzle.com/~aboba/RADEXT/ Completed IETF last call NAS Management Authorization (completed November 11, 2008) Design Guidelines (completed November 11, 2008) Completed WG last call Crypto-agility requirements (2 issues still open) Extended Attributes (6 issues still open) In WG Last Call RADSEC (completes November 25, 2008) Status Server (completes November 25, 2008) WG Work items draft-tiwari-radext-tunnel-types-02 Individual submissions draft-dekok-radext-tcp-transport-00 (review completes November 19, 2008) draft-lourdelet-radext-rfc3162bis-02 (discussion in progress) draft-aboba-radext-wlan-09.txt (IEEE 802.1 review completed) draft-zorn-radius-encatrr-15.txt draft-dekok-radiusext-dlts-02.txt draft-zorn-radius-pkmv1-01.txt (IEEE 802.16 review in progress) IEEE 802 Reviews ---------------- Initial IEEE 802.1 review of draft-aboba-radext-wlan completed, comments incorporated into -09. More comments may still be coming; aspects such as Status indications are still in flux. Joe Salowey: Stuff still happening in 802.1, but it's settling down. We'll get more comments when the new 802.1X-REV draft comes out. WiMax Forum and IEEE 802.16 (comments received today) have reviewed draft-zorn-radius-pkmv1. Completed IETF Last Call 9:10 - 9:20 AM  RADIUS Authorization for NAS Management, David Nelson (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-management-authorization-06 David Nelson: IETF last call comments received. 1 issue was talking about understanding of text, discussion of SNMP vs. RADIUS terminology. Another comment involved editorial nits (nothing earth shaking), a request for changes to the ASCII art. Typically DIME WG uses dots/colon, RADIUS docs don't use anything. There was a missing reference for HTTPS; a request that IANA actions about code points to be assigned remain in the published RFC. Might not be necessary to keep those in. That's it -- no technical or substantive comments received. WG Chair instruction is to address the comments, issue an -07 revision. 9:20 - 9:30 AM RADIUS Design Guidelines, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-design-05 Alan DeKok: A few comments were received in IETF last call. These Will be addressed in next revision. 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. David Nelson: Remember that documents in IETF last call are under IESG change control. So you need IESG permission to make this change. Perhaps you could consider it an IETF last call comment; however, you need to talk to the AD to get permission to make the change. In WG Last Call 9:30 AM - 9:40 AM Status-Server, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-status-server-02 Alan DeKok: A few comments received in WG last call, will be fixed in next revision. One issue is whether to permit an Access-Accept sent from an accounting port. David Nelson: The charter of this work item is to document existing practice, not to extend the protocol. I flinch at Access-Accepts coming from Accounting ports. RADIUS meets itself at the end and snaps.... Alan DeKok: RFC 2865/66 doesn't tie down originating ports, only destination ports. Bernard Aboba: Status-Server has been around since the mid-1990s, when it was originated by Ascend Communications. So we are documenting existing practice. Agree that RFC 2865/66 doesn't talk about originating ports, so it's legal. But do existing implementations do this? There are many things in this document that were judged nonconformant/inappropriate at the time (which is why it was not published as an RFC). We are documenting it because it's widely implemented. David Nelson: It is historical... but not creating a precedent. Alan DeKok: The Access-Accept cannot contain authorization attributes. Client sends a Status-Server (application layer ping), server responds with an Access-Accept & no authorizations. TCP draft uses this as the application layer watchdog. Suggestion from Glen: Extend Status-Server to a CoA port... for server to tell the NAS that they're up again. dave mitton: some of us are trying to forget the Ascend days! Bernard Aboba: Do existing implementations actually do this? Alan DeKok: maybe WG consensus is to remove text on CoA. 9:40 AM - 9:50 AM RADSEC, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec-02 Stefan Winter: New version published. Two open issues (281, 282). WG last call lasts until 25 november. One question is whether to use SRV RRs (as in SIP) or A/AAAA RRs (as in DIAMETER). There is also a question on how to register NAPTR RRs with IANA. The draft currently follows RFC 3588, which says to do NAPTR lookup, if unsuccessful, look up A/AAAA RRs within _radsec._tcp.domain. This may not be an appropriate thing to do. Why not just use SRV RRs? Bernard Aboba: There are some avantages to using SRV (can specify ports, weighting). We talked about this on the list. Stefan: Diameter is the only one using A/AAAA with NAPTR. Everyone else (e.g. SIP) uses SRV. Bernard Aboba: SIP has separate document on how to find a server (RFC 3263). It might be a good thing to split this out into a separate document, rather than including it in RADSEC, especially for i18n issues. Stefan: document is silent on i18n issues. Could put algorithm into another document. RFC 3263 is an example of how to do this. Joe: Does diameter have any recommendation here? Bernard: yes, RFC 3588. But does anyone implement it? (silence) Stefan: How do I register NAPTR construct? I have no clue! Asking for help... Bernard: Ask Hannes. I think DIME WG is considering a revision to use SRV RRs, instead of A/AAAA RRs. Bernard: Last call on the RADSEC document goes to November 25th. Please read it. Completed WG Last Call 9:50 AM - 10:00 AM Extended RADIUS Attributes, Bernard Aboba (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-extended-attributes-05 Bernard Aboba: The Extended Attributes document has completed RADEXT WG last call. We are currently in issues resolution. Some issues are currently in dispute; we currently have 5 open issues, some open more than a year. Other WGs have dependencies on this document, but it doesn't seem to be moving forward. We are hoping that the discussion will converge, but it is hard to determine consensus from a small group of people saying "yes" and "no". We are requesting that the WG read it and send comments/opinions on the open issues. Open issues include 225, 251, 278, 279 and 287. Issue 250 was closed by Greg Weber. Issue 272 was withdrawn by Glen. The issues status has been updated on the RADEXT WG Issues web page (http://www.drizzle.com/~aboba/RADEXT). Stefan: There is an issue about when you are allowed to fragment if you have less than 246 octets... no consensus so far. Alan DeKok: doing weird little fragments is a great way to break things Dave Nelson: if it's a matter of efficiency, then it would be a RECOMMENDED or SHOULD behavior, unless it breaks interoperability. It doesn't need to be a MUST. Bernard Aboba: I think there is an issue with the DIAMETER considerations section. Since the Type-Code was changed to two bytes, Extended Attributes doesn't conform to the RFC 2865 recommended VSA format any more. RFC 4005 assumes that VSAs are in this format, for translation from RADIUS to Diameter. So an update to RFC 4005 is probably required. We will need to bring in DIME WG folks to deal with this. As RFC 4005 stands, attribute 26 is not allowed in Diameter. Dave Nelson: Dave mitton had presented slides about attribute 26 and Diameter Bernard: Yes. See: http://www.watersprings.org/pub/id/draft-mitton-diameter-radius-vsas-01.txt However, DIME currently doesn't have a work item for revision of RFC 4005. In response to Issue 251, Glen Zorn has claimed that the extended attributes can be translated to Diameter using the RADIUS/Diameter gateway defined in RFC 4005. That used to be the case, before the Type Code was extended to two bytes. But it isn't the case any more. Also, there is an IANA considerations issue. Can we allocate from the Extended Attribute space before the standard RADIUS attribute space is exhausted? Some documents are specifying use of Extended Attributes; should they have to wait until the standard attribute space is exhausted before they can get an allocation? Or can they request an allocation from the Extended space, and get one right away? What about documents that are specifying standard RADIUS attributes? Do they automatically get an allocation from the Extended RADIUS attribute space once the standard base is exhausted? Or do we need to find a way to extend allocations in the standard RADIUS attribute format as well? Also, we have documents that are requesting a lot of attributes (5+). IESG has asked whether DIAMETER AVPs should be allocated within the RADIUS attribute space (MIPv6, Diameter QoS, etc.). This could result in rapid exhaustion of the standard RADIUS attribute space. Should requests for a lot of attribute receive automatic allocations within the extended Attribute space, rather than the standard space? Dan Romascanu: what do we do if we have a request for allocation of Extended Attributes? Bernard: Since the draft isn't approved for publication as an RFC, IANA cannot make the allocation. Dan Romascanu: This draft needs to be progressed in sync with changes to Diameter. Bernard: Yes, DIME WG has to figure out how to translate RADIUS Extended Attributes. Dave Mitton's proposal might be one way forward. Dan Romascanu: This is an action item for the DIME WG, and text needs to be put into the IANA and DIAMETER considerations sections. This text isn't in the document now, People shoudl be able to sit down at a table for 1-2 hours and get consensus on these issues. Bernard; might be good to show up in DIME WG and discuss this. David Nelson: We can also talk about this at the AAA Doctors lunch. There are functional enhancements as well as exhaustion issues. In the absence of text, IANA should allow allocations in the extended space prior to exhaustion of the RADIUS standard attribute space, on request. People shouldn't need to wait until standard space is exhausted. davem: Can I resurect the draft if there is interest? Bernard: Ask the DIME WG. 10:00 AM - 10:10 AM RADIUS Cryptoagility Requirements, David Nelson (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements-02 David Nelson: 2 open issues (274, 275), some editorial issues. -01 submitted this week. We have had some discussion relating to automated key management; there was consensus that this was not a requirement. There is also an issue relating to ciphersuite negotiation. RADIUS doesn't support negotiation in general. The best we can do is for the NAS to provide a hint, and for the RADIUS server to accept or reject the hint. The question is how to avoid bidding down attacks. Bernard Aboba: What happens if the NAS offers an upgraded ciphersuite, but the packet is integrity protected and authenticated using MD5? If the MD5 secret is recovered by an attacker, then the attacker can create a new packet that removes the upgraded ciphersuite offer and any upgraded security services (integrity/confidentiality). If the RADIUS server is configured to require upgraded security, then it can reject this (tampered) Access-Request. But if it is configured to still accept MD5 security as well as upgraded ciphersuites, then it will be fooled by the bidding-down attack. Joe Salowey: How does the RADIUS client know why its been rejected? Bernard Aboba: If it is rejected because of an inappropriate ciphersuite offer, then maybe it can figure out that something went wrong (unless the attacker also modifies the error message coming back). Not clear that the RADIUS Error-Cause attribute is sufficient for this.... Joe Salowey: The problem is that the RADIUS Access-Request is not really a hint. If a password or key is encrypted with a new ciphersuite, then the two sides need to agree. David Nelson: We could use another round trip as call-check.. Bernard: We don't need to design a solution here... but we do need to figure out the requirements. One requirement is to avoid cascaded compromise. If the MD5 secret is compromised, don't also want to compromise keys used for the upgraded ciphersuites. For example, we can require that keys used in enhanced ciphersuites be cryptographically independent of the MD5 secret. So if the MD5 secret is compromised, then this doesn't also compromise enhanced ciphersuites. Joe Salowey: There has been lots of discussion on the list about requirements. We don't want to write stupid requirements. Bernard Aboba: The big question is what the transition model is. During some period we will have a mixture of MD5 and ugpraded ciphersuites, at least before MD5 compromise of a strong shared secret becomes practical. Once that happens, we can try to limit the damage (e.g. via cryptographic independence of keys), but without policy (requiring upgraded ciphersuites) we probably cannot prevent bidding down attacks. Maybe we should explicitly describe the transition strategy: do you upgrade the RADIUS server first, so as to support the new functionality and upgraded ciphersuites? This is usually easier than upgrading legacy NASes. Also, what policy configurations do we assume/require? Maybe an upgraded RADIUS server initially accepts MD5 as well as upgraded ciphersuites, then eventually requires upgraded ciphseruites once all NASes are upgraded. Or maybe upgraded NASes can be configured to require that the RADIUS server supports crypto-agility. In that configuration, the NAS would not accept a response from the RADIUS server protected with MD5; it assumes that it MUST support upgraded ciphersuites. Perhaps the NAS can be configured not to use MD5 at all, just an upgraded ciphersuite. If the RADIUS server only supports MD5, then the RADIUS server will silently discard the packet (unless an attacker already knows the MD5 secret and can forge integrity/authentication). David Nelson: Crypto-agility solutions can't depend on introduction of new negotiation capabilities into RADIUS. We are looking for feedback on this (either in the room, or on the list). Joe: back to issues slide David Nelson: slides were proposal; let's see if it's reasonable Joe: seems reasonable, seems to be right direction Individual Submissions 10:10 AM - 10:20 AM TCP Transport, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-dekok-radext-tcp-transport-00 Goal is to take TCP-specific issues in RADSEC draft that were independent of TLS issues and handle them separately. The goal is to describe how to transport RADIUS over TCP. The RADIUS protocol isn't changed; this should simplify implementations. There are some TCP-specific issues. Once the three-way handshake is set up, you don't have to validate the IP address on each message. The TCP connection has to be reset after receiving a malformed packet. Magnus Westerlund: It depends on how you structure the protocol. If you would provide framing around it, not raw RADIUS, then perhaps you could recover from a malformed packet. Alan DeKok: No framing... just raw RADIUS. So if the packet is malformed, there is no way to re-sync. Magnus: I understand.. Alan: Also, if you have attributes with length of 0 or 1, you reset the TCP connection. There is a problem with Identifiers. The Identifier space is only 8 bits, so you can only have 256 IDs... so only 256 messages can be in flight for a single Op Code. RADSEC sends both accounting and authentication packets over one TCP connection. Magnus: Is it outstanding requests or packets in flight? Alan: Outstanding requests. Magnus: This will interact badly with TCP connection state.... won't keep enough traffic in flow. Opening another connection will also be problematic with respect to congestion. Bernard Aboba: You don't want to have lots of connections open, all in slow start, ramping up rapidly.... Bernard Aboba: Are we trying to enable RADIUS over TCP without RADSEC? Magnus Westerlund: It seems generic. SCTP might be a better fit. Also, the applicability statement seems to be a bit off. My impression is that sending less than one packet per RTT doesn't disqualify TCP. What is the applicability and what do you want to gain here? David Nelson: There is WG consensus, and there is what makes sense. We had WG consensus to separate the document, so it could be used for things other than RADSEC. We may need to revisit this if we determine that this was a bad idea. Alan DeKok: The document is relatively silent on this right now. Alan: The issue of 256 IDs interacts with the watchdog timer. There needs to be a way to distinguish Access-Accepts sent in response to a Status-Server from Access-Requests sent in response to an Accesss-Request. Otherwise, the RADSEC client can have 256 outstanding requests, using up all the ID space. Now you try to send a Status-Server packet, but you can't because there are no free IDs yet. Nobody likes this idea. If anyone has a better suggestion? WG: Collective groan. Alan: This is RADIUS. It is disgusting. Bernard: This is beyond disgusting... it's badly broken. David Nelson: We need to avoid this.... Bernard: We should open an issue on this... Alan DeKok: Another issue that has arisen is with respect to SNMP MIBs. Should RADSEC implementations use the existing RADIUS client/server MIBs? Dan Romascanu: We might want to separate UDP/TCP counters... could do this in next MIB revision. In the standard MIB... there is only global counters. Magnus Westerlund: There is an issue here when you are using TCP for one leg and another leg is using UDP. This could cause transport problems. Bernard Aboba: This is an issue even if TCP is being used for both legs. Today's RADIUS proxies forward UDP packets without sending an acknowledgement, so that the transport dynamics (RTT, frame loss) are effectively end-to-end. This isn't true anymore when there is even one TCP leg in the path. RFC 3539 talks about this. Two control loops are always less stable than one. Bernard: We should open an issue on this as well. Alan DeKok: A lot of transport area review needs to be done. Bernard: We will ask the Transport Directorate for assignment of an advisor. 10:20 AM - 10:25 AM New Tunnel-Type Values, Abhishek Tiwari (5 minutes) http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type-02 David Nelson: Is there any objection in the room to starting WG last call on tunnel-type value draft? Room: None. David Nelson: I will start the WG last call. 10:25 AM - 10:30 AM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (5 minutes) http://tools.ietf.org/html/draft-aboba-radext-wlan-09 Bernard Aboba: This draft contains attributes for IEEE 802.11i, 11r, 11s as well as IEEE 802.1X-REV. IEEE 802.1X-REV has been evolving. IEEE 802.1X-2004 included text from what was eventually published as RFC 3580. That text has now been removed in favor of a reference to RFC 3580. IEEE 802.1X-REV D2.9 now references this draft in Appendix E. The -09 draft contains 2 attributes to support IEEE 802.1X-REV: Network-ID-Name and Access-Status. Network-ID-Name can be up to 253 octets, so it is smaller than the SSID (32 octets) and wouldn't necessarily fit within a Called-Station-Id attribute, so it has to be separate. The current draft includes functionality for IEEE 802.11s (Mesh Key Distributors), but 11s status is uncertain. The ETA of 11s has slipped; there is currently no editor for the document; there was a suggestion at the last IEEE 802 plenary that the group be dissolved. Since IEEE 802.1X-REV has a dependency on this document, and it has an ETA of 2009 (was December 2008, but it slipped), depending on IEEE 802.11s functionality that isn't solid probably isn't a good idea. Next steps are to sync the draft with the next revision of IEEE 802.1X-REV, and also to remove material relating to 11s. At that point, we will request wider review and adoption as a RADEXT WG work item. 10:30 AM - 10:40 AM , Transmitting Confidential Data in RADIUS, Joe Salowey (10 minutes) http://tools.ietf.org/html/draft-zorn-radius-encattr-15 Joe: Quick update on the encrypted attributes draft. In the latest draft, we merged multiple attributes into 1 for wrapper to encrypt data. This may be keys or other data. Alan DeKok: "Comsiderations" ? Very telco-centric. Joe: Is this document ready for adoption as WG item? David Nelson: We are currently discussing crypto-agility requirements. Are there additional WG work items that this document depends on? Joe Salowey: would need to be some supporting things around negotiation. May be some kind of error indication. Dave Nelson: would be nice to keep requirements && solution documents in sync Bernard: Keep in mind that this document negotiates a bunch of different things. We want to be able to avoid bidding down attacks, either via cryptographic or policy measures. Joe: Every RADIUS response now has crypto implied. Many requests do, too. Bernard: say MD5 gets cracked tomorrow... that wouldn't allow the attacker to recover encryption keys or passwords, right? Joe: We might say that passwords should be encrypted with AES rather than MD5. Dave: It is implicit in crypto agility that all algorithms will someday fail. We can't assume that there's no bidding down attack. Bernard: if we assume that you wouldn't be doing encryption with an enhanced ciphersutie without a stronger hash as well, we'd be better than where we are now. When MD5 gets cracked, you lose both encryption and integrity of RADIUS as it currently exists. Once that happens, the transition becomes a lot tougher, because you need a "flag day". Once this document is implemented, we will have crypto-graphic negotiation in place; assuming that the algorithm protecting the negotiation itself is not compromised, then we will be able to securely negotiate new ciphersuites if an existing one is compromised. David Nelson: if we're talking about a transition strategy from RADIUS to this new approach, negotiations can only be protected with classic RADIUS. Bernard: In an environment where the RADIUS proxy/server only supports MD5, yes. In that situation, I don't believe we can avoid a bidding down attack, but we can avoid compromise of keys used to protect the enhanced ciphersuite, by keeping them cryptographically separate from the MD5 secret. However, if the RADIUS proxy/server supports this document, then a NAS can be configured to require support for enhanced ciphersuites, and avoid use of MD5. So overall, we need to describe the migration strategy. Joe: If we can get this document deployed, then this solves a lot of problems. Bernard: The document should talk more about the migration strategy (e.g. what is upgraded first, how to avoid bidding down via policy, how to deal with compromise of MD5 and other algorithms, etc.). Internationalization 10:40 AM - 11 AM i8n Issues with RFC 4282, Alan DeKok (10 minutes) http://tools.ietf.org/html/rfc4282 Bernard Aboba: How many people were present in EMU WG and have heard this talk already? Room: Quite a few hands go up. Bernard Aboba: I guess we don't need to repeat the EMU WG presentation. Alan DeKok: The main issue here is that RFC 4282 is out of sync with what implementations actually do. In practice, Windows, MacOS and Linux implementations of EAP and RADIUS use UTF-8, both for the username and the realm. Bernard Aboba: Not all versions of Windows use UTF-8. In Vista, IEEE 802.11 is based on an RFC 3748 implementation (EAPHOST). This uses UTF-8. However, the EAP implementation used by PPP and VPN (L2TP, PPTP, SSTP) is based on RFC 2284, and this implementation uses code pages. Windows XP SP2 and earlier as well as Windows 2000 also use this earlier implementation, so they will also not put out UTF-8 in EAP-Response/Identity packets. Stefan Winter: We also saw non UTF-8 coming from Windows xP SP3. Bernard Aboba: That is under investigation. Alan DeKok: There are several issues that this brings up: * RFC 3748 says that the EAP-Request/Identity uses UTF-8 but not the EAP-Response. This looks like an oversight. * RADIUS RFCs state that the User-Name attribute is encoded in UTF-8. * Both EAP and RADIUS are 8-bit clean. So there is in practice no need for punycode in order to support a 7-bit channel. * Existing implementations often treat the NAI like an opaque blob. The NAI may be configured for the user, or the user may not even able to enter it (e.g. Windows). In these cases, there is no normalization issue; the client sends what the server is configured to accept. Bernard Aboba: I think the problem originated from the assumption of RFC 2486 that the NAI had the same syntax as an email address. Shortly thereafter, operating systems began to support UTF-8 based hostnames and usernames, so this wasn't true any more. Alan DeKok: Another issue with RFC 4282 is that it isn't in sync with IDNAbis. This means that RFC 4282 can't support new versions of UNICODE or new scripts. It isn't in sync with the new bidi draft, with the updated tables, etc. Character have since been prohibited/added, new scripts have been added, etc. Bernard Aboba: So far, we've just been discussing the NAI. However, there are also issues with respect to password handling, and in some cases, EAP methods. For example, it appears that RFC 2759 refers to usernames/passwords encoded in ASCII. There are documented cases where UTF-8 usernames have failed to authenticate. For some reason the hashes are actually failing to run over the UTF-8 bits in the username. There is an errata filed on RFC 2759 currently which appears to relate to this. RFC 3748 Section 5 talks about non-ASCII characters in passphrases: EAP methods MAY support authentication based on shared secrets. If the shared secret is a passphrase entered by the user, implementations MAY support entering passphrases with non-ASCII characters. In this case, the input should be processed using an appropriate stringprep [RFC3454] profile, and encoded in octets using UTF-8 encoding [RFC2279]. A preliminary version of a possible stringprep profile is described in [SASLPREP]. Does anyone actually implement this? Alan DeKok: I don't think so. Passphrases (like NAIs) are generally treated like opaque bits. Bernard Aboba: Maybe a step forward would be to create a draft describing what implementations actually do? This might require some testing... but at least we'd know how big the issue really is. IPv6 11:00 AM - 11:10 AM  Prefix Authorization, Behcet Sarikaya (10 minutes) http://tools.ietf.org/id/draft-sarikaya-radext-prefix-authorization-01 Bernard Aboba: Some background. RFC 3162 was developed largely to support IPv6 over PPP. Ralph Droms and others attempted to use this to support DHCPv6 prefix delegation and discovered it didn't work, because if the user had a router on the premises, then the IPV6 address model required that the prefixe be assigned to the link between the user and the NAS, not for use in the user network. So we had to develop RFC 4818 to support DHCPv6 prefix delegation. Then we discovered some additional confusion in RFC 3162 with respect to the Framed-IPv6-Prefix attribute. Could this attribute be used to configure a /128 prefix for the user (e.g. assign an IPv6 address)? If the intent was to cause the assigned prefix to be advertised by the NAS in an RA sent to the user, then this doesn't make sense. Such a prefix could only be as large as a /64. The Framed-Interface-Id attribute is used to specify the Identifier portion of the address. This issue was clarified in RFC 5080 (which unexplicably, did not update RFC 3162). Behcet: Now we need the Authorized-UserId-Prefix attribute. Joe Salowey: what is a prefix authorization user id? Behcet: The RADIUS server needs to identify the user. Joe Salowey: So the the RADIUS client stores this value, and puts this value in an Access-Request? Behcet: It is also needed for renumbering via a CoA-Request and CoA-ACK. Bernard Aboba: If renumbering occurs, how does the end user obtain their new address? RFC 3162 assumes this happens by having the NAS issue an RA with the new prefix. But this draft is assuming another address assignment mechanism, right? Joe Salowey: The RADIUS Access-Request already has context information about who's requesting things, namely the User-Name Attribute. So why do we need a separate attribute to specify this? Bernard: Are there other things associated with the prefix? Benoit: How does this draft relate to RFC 4818? Is it using DHCPv6 Prefix Delegation? Behcet: It is completely different from RFC 4818. In RFC 4818, the AAA server provides prefixes to the NAS, for use with DHCPv6 prefix delegation. Here the AAA server provides prefixes to the AAA client. Bernard Aboba: How does the AAA client communicate the prefixes to the user? Does this document assume that the NAS is implementing an alternative to DHCPv6 prefix delegation? If so, what mechanism is being used? One constraint in the RADEXT WG is that we cannot define new network functionality in this WG. Documents have to reference an existing service model. RFC 4818 references the DHCPv6 prefix delegation RFCs. RFC 3162 refers to the PPP over IPv6 RFC 2472, the IPv6 addressing architecture and other IPv6 documents. What existing prefix assignment mechanism is being depended on here? The RADEXT WG can't be used to define an alternative mechanism for prefix delegation. Frank: The DHCP radius interface excludes the possibility that this can be done by AAA only. DHCPv6 can deal with renumbering. AAA can't do that. This draft violates the basic principles of IPv6 address allocation. 11:10 AM - 11:20 AM  RFC 3162bis, Benoit Lourdelet (10 minutes) http://tools.ietf.org/html/draft-lourdelet-radext-rfc3162bis-02 Benoit: This document is being proposed to accomodate IPv6 production networks, in which there is an issue of how to configure the DNS server address. This can be delivered to the client either via DHCPv6 or via a Router Advertisement option. Bernard Aboba: it would be great to have those references in the document. However, this also raises the question of whether we might also have requests for allocations of RADIUS attributes corresponding to other DHCP options. We don't have enough remaining RADIUS attribute space to handle all the potential allocation requests that this could generate. So, should we be defining a single RADIUS attribute to carry lots of DHCP options, rather than a single RADIUS attribute? Benoit: The need to configure a DNS server is independent of DHCP, since it can also be communicated in a router advertisement. So we probably need a separate DNS server attribute in RADIUS. But future DHCPv6 options might require a more generic approach. Bernard Aboba: Another issue that was discussed on the list was whether this document needed to update RFC 3162 or not. From the draft, it looked like the only issue that needed clarification was the use of the Framed-IPv6-Prefix attribute to carry IPv6 addresses. RFC 5080 discourages that, so you don't need to revise RFC 3162 to clarify that issue; you can just reference RFC 5080 and perhaps include an Updates: RFC 3162 in the document header. That said, I don't want to discourage you if you want to volunteer to update RFC 3162... it's just that you don't need to do that in order to progress this document. Benoit: I'd rather go with a standalone document, if that can be done. Bernard Aboba: A separate document (rather than an RFC 3162 revision) seems to be the way forward. David Nelson: if this is talking about services other than DHCP... do we define a new service in a RADIUS document? Bernard: It looks like this document just references existing services such as DHCPv6 and Router Advertisement. Glen: I am opposed to both this draft and the previous one, because they are not AAA-related. It might not be a bad idea to define a new service as they are not per-user attributes. The RADIUS client is likely to be a DHCP server/relay rather than a NAS. Bernard Aboba: Couldn't the DNS server attribute be used with a NAS implementing either a DHCPv6 server or stateless autoconfig (e.g. RA)? The authentication could be IEEE 802.1X or PPP, for example. So there are some usage cases that seem quite conventional. David Nelson: This document still has some issues that need attention. We need an indication of what goes in what document. Do we have two separate documents, or do we merge them? Or do we deal with the "service reference" issue first? Bernard Aboba: All RADEXT documents need to be able to provide a service reference in order to be accepted as WG work items. We can't define new services here; we just define how RADIUS can manage existing services. Bernard: The 2 documents in IETF last call, plus the 4 documents in WG last call have consumed the group. We need to make more rapid progress on those work items, get the documents in IETF last call into the RFC Editor Queue, get the 4 documents in WG last call ready for consideration by the IESG. Once we have done this we will have more cycles for the other work that people want to get going on. However, document authors of individual submissions can still make progress on their own. They can solicit feedback, they can get get their own reviews from other areas, they can clarify the service references, provide applicability statements, etc. So work doesn't need to stop waiting for RADEXT WG attention and cycles to free up. Meeting Ended.