Minutes of the RADEXT WG IETF 75 Stockholm, Sweden Friday, July 31, 2009 Note Well The Note Well and IETF IPR obligations were presented. Agenda Bash Extended Attributes and Crypto-agility Requirements documents are not on the agenda at IETF 75. They were discussed at the interim. Diameter/RADIUS compatiblity issues blocking Extended Attributes will be discussed in DIME. Document Status update NAS Authorization for NAS Management published as RFC 5607. RADIUS Location is in AUTH48. Design Guidelines has completed IETF last call and is in AD Followup. Tunnel-Type Values document has completed WG last call, and is ready for IETF last call, pending a PROTO writeup. RADSEC, Crypto-agility Requirements and Extended Attributes documents have completed WG last call, with open issues. See RADEXT issues track for details: http://www.drizzle.com/~aboba/RADEXT/ The Status Server and RADIUS over TCP documents are in WG last call. NAI-based peer discovery has been adopted as a WG work item. RADSEC, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec Bernard: What is the definition of the term "RADSEC"? Stefan Winter: In places the documents refer to both RADIUS over TLS and RADIUS over DTLS as "RADSEC". Alan DeKok: RADSEC is RADIUS over TLS/SSL, NOT over DTLS. Alan DeKok: "RADSEC" is a product name. Is using this ok in IETF documents? Dan Romascanu: We should not use a product name for the technology. Bernard agrees. Solution: The term "RADSEC" will no longer be used in RADEXT WG documents; the term "RADIUS over TLS" will be used instead to refer to TLS transport. "RADIUS over DTLS" will be used to refer to the DTLS transport for RADIUS. Stefan agrees to change the terminology in the next revision of the document set. Rev -05 of the document addresses most comments from WG last call. There have been dscussions on the mailing list relating to on bidding down from TLS to UDP. Bernard: When upgrading a NAS to RADIUS over (D)TLS how does the RADIUS server link the upgraded NAS to the previous (legacy) RADIUS over UDP instance in order to block future RADIUS over UDP transactions? Is the NAS identified by IP address or by an attribute such as NAS-Identifier? Stefan: I doubt that attributes can be useful, since that's only after (D)TLS is establshed. (D)TLS identifiers are used to denote clusters. Bernard: So the IP address could change? Stefan: Conceivably. The assumption is that (D)TLS configuration is available on the RADIUS server, in addition to legacy RADIUS configuration. There are different (D)TLS operating modes (PSK, certificates) so that pre-configuration may be necessary. Bernard: RFC 5280 makes recommendations about the use of the subject and subjectAltName fields; we should probably have the part of the document relating to certificates reviewed by a PKI expert. Dan Harkins: why not leave this decision to implementations? Bernard: this is to prevent bidding down attacks. Dan: not really, you'd still need to have the shared secret. Bernard: this is just a recommendation, though. RADIUS Tunnel Values, Abhishek Tiwari (10 minutes) http://tools.ietf.org/html/draft-tiwari-radext-tunnel-type The document has been "sitting around" for 18 months. It has completed WG last call, with no open issues, and is pending a PROTO writeup prior to IETF last call. This seems like a lot of process for allocation of a Tunnel-Type value. RFC 3575 Section 2.1 states that values are allocated by Designated Expert with some exceptions. However, RFC 3575 did not update RFC 2868, so it is claimed that this does not apply to Tunnel-Type values. Dan Romascanu: If the problem is an errata in RFC 3575, then we should fix the errata, rather than forcing every tunnel-type value to go through IETF last call. This could allow the document to be approved much faster! Bernard: Agreed. NAI-based Peer Discovery, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery -01 cleaned up the algorithm, added i18n examples. Assumption is that the realm is a valid domain name. Bernard: can you discover if you're using TLS or DTLS thru the NAPTR? Stefan; yes. Bernard: Does the reference to RFC 4282 make sense? Alan has documented i18n issues with that document. Maybe we should just refer to IDNA (bis) documents instead. RADIUS attributes for IEEE 802 Networks, Bernard Aboba (10 minutes) http://tools.ietf.org/html/draft-aboba-radext-wlan 802.11s schedule changed, as did the architecture. Dan Harkins: Key Distribution Server doesn't exist any more in 11s. Bernard: 11s attributes have been removed; the document focuses on 11i, 11r and IEEE 802.1X-REV (now in Sponsor Ballot). Next step: Complete the WG adoption call started in November 2007 -- 18 months ago! RADIUS over TCP document, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp-transport This document is in WG last call until August 7, 2009. Please read it and comment! Bernard: Is the use of Status Server is exactly as described in the Status Server doc? Or is there some difference between use with (D)TLS and UDP transports? Stefan: As far as I know, usage is the same. Stefan: what is the status of the head of line discussion? Bernard: we should have a Transport Area review of the document; Magnus asked a lot of questions when it was first presented. Bernard: Does this document only apply to use with TLS? Alan: Yes, this is really uninteresting unless using RADIUS over TLS. Design Guidelines document, Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-design Document has completed IETF last call. There is an open DISCUSS from Jari Arkko. There has also been a "test case" document which exposed ambiguities in the Design Guidelines document. Is it clear enough to allow reviews to be based on it, or will we have interpretation problems going forward? Alan: the only major thing is removing the normative ref on Extended Attributes. Bernard: Extended Attributes should have its own design guidelines anyway. Bernard: some intrepretation issues were exposed by the RADIUS PKMv1 document review. What does the "security exemption" apply to, exactly? Glen thought it applied where attributes related to security (e.g. the whole document) Alan said it is only for attributes relating to RADIUS security (maybe not authentication, such as EAP). Bernard: The document needs to be clear enough to avoid these kind of disputes. The overall goal is to enable attributes to be added in the Server Dictionary without code changes, if possible. The Security exemption was added since authentication attributes (CHAP, EAP, Digest, etc.) or RADIUS security attributes (Message-Authenticator) require computations to be performed on the RADIUS client and server. So you need to change code; changing the server dictionary isn't enough. So the question is whether the PKMv1 document is requiring a code change on the server when none should be necessary. As an example, a server can send a certificate as a String attribute by adding a Dictionary entry and filling it in. However, in order to verify a certificate, code changes are needed. Design Guidelines should probably be clarified to deal with these issues. Status-Server document, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-status-server The document is in WG last call until Aug. 7. 3 people have read it. Bernard: We should ask for review from Ignacio Goyret of Ascend, who implemented it. Mark Jones: do implementations ("wide use") use the message authenticator? Alan: some do. Ascend implementation did not. Alan: status server the only way of knowing that a proxy came up after disconnecting. RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-dekok-radext-dtls Major new content in -02. Done as a diff from RADIUS over TLS document. Stefan: why reuse same port as RADIUS, app-level multiplexing? Stefan and Yaron: will not work well with firewalls that inspect traffic. They'll conclude that the traffic is not "really" RADIUS. Alan DeKok: We use code 22 to differentiate a RADIUS packet from RADIUS over DTLS. Bernard: code 22 has been allocated. Is DTLS transport used for Dynamic Authorization? In that case couldn't code 22 end up being confused with something else? Alan: but it's a response packet, so it's safe for multiplexing. Bernard: Has DTLS been implemented? Alan: it is in RadSec proxy, will move in the future into FreeRADIUS. RADIUS Attributes for IPv6 Access Networks, Behcet Sarikaya (10 minutes) http://tools.ietf.org/html/draft-lourdelet-radext-ipv6-access Stefan Winter: Why is RADIUS being used along with DHCP? There is no authentication here. Alan: These slides do not make sense. Bernard: What is actually happening is that PPP authentication is occurring (e.g. DSL), and the DNS server attribute is being delivered as part of that. Then when the client does DHCPv6 with the NAS, the NAS has got the DNS server attribute ready. The Prefix lifetime and DNS server attribute can be sent along with the RA as well. So the slides showing the packet timings (e.g. RADIUS Access-Request being sent synchronously with DHCP) are wrong. RADIUS exchange occurs before DHCP or RA is sent out, no relationship there. RADIUS is not carrying DHCP packets, or anything like that. The slides are misleading (and confusing!). Stefan: Why is this document using the Tag field. Isn't that deprecated by Design Guidelines? Bernard: Yes Stefan volunteers to read the document and comment on it. Concluded 10:10. ------------------------------------------------ RADEXT WG Virtual Interim Meeting June 10, 2009 Minutes RADIUS Crypto-agility Requirements Open Issues include 274, 275, 303. Of the open issues, 303 (from Pasi Eronen's review) overlaps with some of the comments in the other issues. David Nelson: Addressing Pasi's comments will probably require a complete rewrite of the document, but I haven't had the time... Bernard Aboba: Pasi had comments in the following areas: Hop-by-hop/end-to-end: Explaining why solutions only need to focus on "hop-by-hop". Forward secrecy: Whether this is necessary or not. Issue is transmission of keys that could be used for a long time. Credentials: what kinds of credentials solutions are expected to support. Replay protection: Access-Request messages currently aren't replay protected. Do we need to do better? Negotiation: Does this require negotiation in the protocol, or between admins? Automated Key management: If you don't have automated key management, there can be issues; more explanation is needed. Compromise of legacy shared secret: The requirement in the document seems difficult to meet, since if MD5 is cracked, then how do you avoid bidding down attacks? Backward compatibility: It is hard *not* to meet this requirement. Is the goal to require some kind of negotiation? Operational model: What does this mean? RADIUS service: What is a RADIUS service? Hannes: Do we really need the requirements document anymore? Isn't Glen's document obsolete? Glen Zorn: I am no longer pursuing it, though Cisco might want to publish a document describing what they have implemented. David Nelson: So do we now just have a single proposed solution (TLS/DTLS)? The other approach can just go forward as an Informational RFC, via the RFC Editor. Glen Zorn: To be clear -- I still think that the approach has value. Diameter adopted TLS, but it isn't deployed. Many implementations actually use no security at all. So do we really think that RADSEC will solve this problem? It seems unlikely. David Nelson: RADSEC is only for use by proxies, right? Alan DeKok: Yes. David Nelson: So how can RADSEC solve the problem of protecting communication between a NAS and a proxy? Bernard Aboba: It can't. But presumably DTLS would be used for that situation? Alan DeKok: I am revising the DTLS draft. Glen Zorn: The problem is bigger than that... what credentials will you use? Is it possible to require certificates on every NAS/proxy? Bernard: Judging from the situation with Diameter, the answer to that is "No." Glen Zorn: The solution provided in my draft is something that has actually been implemented... and that operators could actually deploy. Isn't that important? Bernard: It would seem that Pasi's questions apply to all approaches... and that they need to be answered in order for us to understand when we're done. For example, the "bidding down" problem can occur with TLS/DTLS as well. Alan DeKok: With DTLS it is possible for a RADIUS server to detect whether an incoming packet is DTLS or not, and switch automatically. Bernard: But how does the NAS know to attempt DTLS? Does it use DNS discovery? And what if DNSSEC isn't in use? Couldn't that be spoofed? Alan DeKok: You can have policy to require TLS/DTLS. Bernard: That works once you know that you have transitioned the NASes... but what about when you're operating a mixed network? Alan DeKok: The RADIUS server can keep a list of what NASes have ever attempted TLS/DTLS. Bernard: So once the NAS tried DTLS/TLS it is assumed that it will always use that. Alan DeKok: Yes. Glen Zorn: Also, my draft provides a mechanism for encrypting RADIUS attributes. That has value beyond what TLS can provide. Bernard: In the "end-to-end" case, which is what Pasi was asking about. So to answer Hannes' question, the requirements document would seem to have value, since the issues Pasi raised come up regardless of the approach taken. David Nelson: So what are the next steps? Discussion on the list? Bernard: Yes. RADIUS Extended Attributes Open issues: 251, 290, 298. These issues largely concern Diameter compatibility and IANA allocation policies. Bernard: With respect to IANA allocation policies, allocation of Extended Attributes isn't just for when we run out of standard attributes. Couldn't someone request allocation from the extended attributes space before then? Glen Zorn: Yes. The Diameter compatibility issues arise because the Extended Attributes document does not use the VSA format recommended in RFC 2865 (one octet type field). As a result, the procedures described in RFC 3588 cannot be applied for translating RADIUS Extended Attributes to Diameter. David Mitton: I had a draft long ago that covered this.... Bernard: Yes. Has their been progress on introducing that within DIME? Glen Zorn: No. Hannes: Does anyone really run mixed Diameter/RADIUS networks anyway? From what I have seen, they do not. Glen Zorn: I have not seen it either. David Nelson: So why do we require Diameter Compatibility boilerplate in all of our documents? Is this really necessary? Bernard: If nobody is doing translation, maybe it is not necessary. In any case, Diameter will have its own equivalent of the RADIUS Extended Attributes features (e.g. grouping), so you'd probably want to allocate separate Diameter AVPs anyway. David Nelson: So maybe this is a non-problem? Should we check with DIME? Bernard: Probably.