[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Draft Minutes of RADEXT WG Meeting at IETF 75
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 OpenRADIUS.
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.