RADEXT WG Minutes IETF 78 Maastricht, Netherlands Wednesday, July 28, 2010 Meeting start 9:00AM CET Chairs: Bernard Aboba Mauricio Sanchez Agenda 0900-1015 Morning Session (0.8 Rome) ------------------------------------ 0900 - 0910: Preliminaries Blue Sheets, Note takers, Jabber Scribe Agenda bash, Document Status 1. Bernard reviewed the agenda. No suggested changes. - Jabber scribe: Dan Romascanu - Note taker: Dorothy Stanley 2. Bernard reviewed the document status, see https://datatracker.ietf.org/wg/radext/ . 0910 - 0930: RADIUS over TLS, Stefan Winter (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec - WGLC completed. Are all the issues cleared? No. - Proto write-up will start after issues are completed. - Client identity. There are many attributes in an X.509 certificate which can be used to classify connecting clients. Could be open, configurable, use a default identity scheme, or use draft-saintandre-tls-server-id-check-08. o Comment: have thought it through, the server-id-check draft is about server identity, not client identity. Suggest taking from the server identity draft for the client side. There are some of their issues that apply to client. Issue with marching identities. Need to reference it appropriately. o There are a couple of ways to go. Could make a new draft, a client id check that borrows heavily from server-id-check. o Checks the DNS name against the content of the certificate. Can't do that with the client. - Packet flow constraints: RADIUS/UDP sessions flow one way. With RADIUS/TLS, transport creates a bidirectional channel. Text now enumerates packet types which can flow in different directions. There might be more elegant wording. o Might be transport issues with running TCP, COA over the same tunnel. TCP document needs to address this. o Look through TCP transport document and describe issues related to transport. TCP splits between two ports; this draft puts both authorization and accounting on a single port. - Connection back-off: what happens if a client attempts to connect to a server but fails? Retry immediately could generate DOS, Backing off is required. Check text in Status-Server and use that or produce new text. - Implications for server side validation? For NAI discovery. 0930 - 0940: RADIUS over DTLS, Alan DeKok or Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-dekok-radext-dtls - Current draft is -03 - Changes are mostly terminology. - Implementers: RadSecProxy and FreeRADIUS implementing now. Need to get comments back from the implementers on any issues they saw. - Design Guidelines are the next step. - Is there interest in adopting this as a WG work item. Show of hands: 7 for adopting, 0 opposing. - Dan Romascanu (as AD): assume that those who supported the document agree to help advance the document. - Will verify the "call for adoption" on the mailing list. 0940 - 0955: NAI Discovery, Stefan Winter (20 minutes) http://tools.ietf.org/html/draft-ietf-radext/dynamic-discovery - Status of draft: still in WG process - Issues 13 and 14 open - Fixes in pending rev: o Only about RADIUS, not AAA in general - yes, not DIME o i18n in user name: Purge references to 4284, only stuff right of the last @ in user-Name o Wording and editorial fixes: RadSec, abstract - Do we need a separate document for internationalization? o Update 4282? Doesn't address protocol use. How NAIs are encoded depends on whether the domain name slot is "internationalization-aware" or not. RFC 4282 describes how encoding is done when the domain name slot is not "internationalization aware", but both EAP and RADIUS support UTF-8 and implementations commonly treat them as "internationalization aware". o Suggestion to have a separate document that doesn't reference 4282. o Not sure how much there is to say. When encountered, a U-label should be converted to an A-label prior to DNS look up. What does the supplicant send? Typically it will send a U-label, both in EAP and RADIUS. However, the server should be "liberal in what it accepts": if an A-label is sent, then the sever can use it as is; if a U-label is sent, it can be converted. o Write up a paragraph about what should be said on the topic. If not a lot, don't need a separate document. - TLS server-ID check, how to secure dynamic discovery? Hosting a RADSEC server somewhere else. how can we determine whether an SRV RR delegation is legitimate? Other than using DNSSEC, RFC 4985 (SRVName) allows the validity of the SRV RR to be checked against the SRVName in the target certificate. It is also possible to use specialized CAs. This is what Eduroam does. 0955-1005: RADIUS Attributes for DS-LITE Address Family Translation Router, Roberta Maglione (10 minutes) http://tools.ietf.org/html/draft-maglione-softwire-dslite-radius-ext - B4 element needs to know the remote endpoint Address or Name - Draft-ietf-softwire-ds-lite-tunnel-option already defines DHCPv6 options for DS=Lite Tinnel Address and Name - Two new RADIUS Address to carry address and tunnel name - Establish tunnel from DHCPv6 client to AFTR - Combine DHCP with RADIUS: NAS translates tunnel Address/Name Radius attribute into DHCPv6 options - Format of DS-Lite-Tunnel-Addr Radius attribute - Format of DS-Lite-Tunnel-Name Radius Attribute. Contains FQDN. o seems straightforward o Both simple attributes, one a string, one an IPV6 address (make sure this is a valid type) - Review this document in last call in RADEXT as well - Concern about the need for this info, not just in softwire, use in other tunnels. Parameters that need to be passed really are different. Define new extensions. - NAT is like an HA or an LMA. Could I re-use the attributes from there? - Started with 3162 attributes, concern about overloading existing attributes. Need to prepare for scenarios when need to send both tunnel attributes. Maybe put type in the attribute itself. Think about creating something generic enough and differentiate with type. - Would be similar, but not the same. Need to create a very big set of options. May as well have unique options. - In diameter, group like attributes together. - Are we seeing the complete picture of how RADIUS is used in this application (DS-Lite and other softwire applications)? - Have an IPv6 access document. Covers the accounting case. Interesting to think about what of that document would apply here. Have this attribute in Access set and in accounting, and can it be changed in dynamic authorization. - If want to review how RADIUS/Diameter is used in softwire? Intent the current draft. - How to account for IPv4 and IPv6 traffic, but when it is tunneled? Counted as an IPv6 packet. The NAS isn't in the bearer path. AFTR has data on IPv4. Can count them, just in different places. What is NAI? How do I correlate the accounting from AFTR to the session authenticated at the RADIUS server? Larger issue than these 2 attributes. - Review from a RADIUS and Diameter perspective, for accounting. Treat as 2 activities - define the attributes now. - Tunnel Server issues accounting attributes, system has to correlate the IP addresses. AFTR may be in separate accounting domain. Concern with WiMax applications in actual use. May be an interoperability issue. - Good to describe use of all the attributes. - Avi volunteers to review and raise any issues. Request WG review prior to last call. Treat as 2 issues - attributes and use. 1030 - 1130 Morning Session II (0.8 Rome) ----------------------------------------- 1030 - 1040: Preliminaries - Bernard reviewed agenda. No suggested changes - Jabber scribe: Dan Romascanu - Note taker: Dorothy Stanley - Blue sheets sent around again - Update based on break discussion: RADIUS TCP unclear which port would be used. For disconnect, under TLS unclear which port to use. Both documents need to change, Bernard has filed an issue. 1040 - 1100: Design Guidelines, Alan DeKok (20 minutes) http://tools.ietf.org/wg/radext/draft-ietf-radext-design/ - More changes since IETF77, more bugs since this morning. - The draft does not forbid or require anything new - Issues 15 & 16 & 17 issued - Reorganized text - Addressed a few issues in the Trac system. Minor, should be resolved in -17. - Section 3.2.2 has been updated, probably means multiple values in an encoding - 3.2.3 and 3.2.4 added. - Next steps: double check for consistency and duplication, resolve new issues, then final review. Rate of bug addition, and review comments is slowing. 1100 - 1120: Extended Attributes, Avi Lior and Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-extended-attributes - Document has been moribund for a while. - Review requirements i. Grouping, named groups (Firewall rule) ii. Larger type space: 8 bits isn't enough iii. Standardized length extensions: longer than 253 bytes of data iv. Encapsulation - in a VSA with [EXTEN], approx 4 bytes of overhead, or in a normal RASIUD attribute? What do proxies do? Compatibility with old systems? Capability negotiation? v. Proposals are for Nested groups (Diameter, 3GPP and Wimax) or nested attributes (can fall across the boundary of the attribute that is encapsulating them, need multiple. vi. Could use nested groups with a flat name space. The groups nest, but the attributes don't. Seems complicated. Is different. 2868 tags: same tag-same group. What happens when one of the group entries is a group? Include another tag. How do you know how many tags are present? Needs to be defined - indicate how many tag bytes there are. vii. Encoding matters: grouping is handled, larger namespace, find a way to deal with length restrictions, find a way to get VSAs to use this format viii. Nested attributes TLV(TLV(TLV(TLV(data)))). Grouping comes naturally, larger namespace is easier. Need to determine how to implement length. ix. Prefer the elegance of the flat space. Less confusing to users. Onus is on vendors to not get crazy with the nesting. x. Benefit to proposal-probably already support, if support 3Gpp, etc. xi. 8 bit: is it enough? How close are we today? See www.iana.org/assignments/radius-types/radius-types.xhtml xii. Want to switch over to the new mechanism. 144-191 are unassigned, 192-223 is experimental use. Finish the work soon, to move to the new system. xiii. Length: length of 253 means "continuation" if the next attribute is of the same type. Rule works for the EAP-Message and for NAS-filter-Rule. It works less well for "text" attributes. This is problematic, overloading the length field. May find that we need a flag field anyway. Top level should indicate the nesting & group structure. xiv. Is the nesting multilevel? Yes. Have attribute of type "nested", then contains "integer", etc. xv. Issue with tagging mechanism. Not named. Have to look at what is being grouped. Need named containers. 3Gpp2: uses nested groups. Only one example of a container that no one uses. Over 200 named groups. Generic containers as an afterthought. xvi. Orient the proposal to what people are using and like. Why not follow diameter example, "Diameter-lite" for RADIUS. 16 bit type space. Attribure header is longer, but simpler. Wrap into 8-bit RADIUS though. Would need to justify why we're not taking that path. xvii. Discussion: Nested, Flat, Named groups xviii.Get feedback from users on the chosen proposal. xix. Running code: have in 3Gpp, etc. Wouldn't kill us to actually reuse stuff. xx. Name has to be involved. xxi. Extended attributes document has tried to do 2 things: attribute exhaustion and additional attributes. xxii. Use some of the reserved bits for extension, and for grouping. How to do VSAs? xxiii.One document or 2? If can do in one, better. Need to do in a reasonable amount of time. Have 3-4 years for exhaustion. Could get something out first to solve exhaustion, then work on the group. Proceed with one document, see if we make progress over next couple of meetings. If no progress, then split into two. xxiv. Discussion on means to extend: 0 in VSA space (viewed as awkward/wasteful - use 4 octets for nothing, some servers may treat 0 differently), versus taking an attribute. 1120 - 1130: Wrap-up (10 minutes) - Any additional business? None raised. Meeting adjourned at 11:20am.