|
RADEXT WG Minutes IETF 79 Beijing, China Friday, November 12, 2010 Meeting start 9:00AM CST Chairs: Bernard Aboba <bernard_aboba@hotmail.com> Mauricio Sanchez <mauricio.sanchez@hp.com> Agenda 0900 - 0920: Preliminaries *Blue Sheets, Note takers, Jabber Scribe *Agenda bash, Document Status 1. Mauricio reviewed the agenda. No suggested changes. - Jabber scribe: Dan Romascanu - Note taker: Nancy Cam-Winget 2. Mauricio reviewed the document status, see https://datatracker.ietf.org/wg/radext/ . 0920 - 0930 Hot Errata, WG Chairs (10 minutes) - Discussion of issue 1469 (RFC 2865) and issue 753 (RFC 4282) o Dan Romanascu asks whether status should really be changed? Per guideline review rules, this is what seems to be an appropriate resolution. Dan believes that it may be misleading. o Dan states”verified means that it has been verified, accepted and enforced” which is typically for errata that need small fixes with technical meaning. “held for doc” means that the errata is not enforced but discussion is deferred until the document is updated; is this what we really want? Chair says “no”, but want to acknowledge that the issue does exist. o Dan asks if intent is to “enforce” vs. “hidden until doc is revised”? Chair believes the latter, so from procedural view, take lodge recommendation with AD (Dan). o Bernard comments why “held for verify”, the error was intentional. we do not want it enforced. Dan clarifies that 1469 should be “held” vs “verify”, 753 should be changed from verify to “rejected” asks Bernard to confirm. Bernard confirms on 753 and 1469 should stay “verify”. Dan takes note to update status of these docs. -Discussion of issues 2507 and 2508 of RFC 5597 o More editorial comments came in around “access-accept” misleading note (2507) and typo in mention of “server” should be “client” (2508). Status is to keep them as “held for document update”. o Alan comments that someone should be reading this well before final publication. 0930 - 0940 RADIUS over TCP, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-tcp - One change (issue 59) to fix issue, believes there’s nothing left to resolve in the document. Removes reference to CoA. - Should be ready to go and get it reviewed again. Bernard asks if it should go to IESG discussion? Mauricio believes group signed off on document. Dan suggests can go to the next step. Bernard believes Ralph may not believe issue is addressed. Alan mentions that Ralph had reviewed and had not added any other comment. If more comments come, Alan can respond to them. Dan suggests to make sure loop with Ralph is closed as Bernard believes issue is not closed (according to Ralph). 0940 - 0950 Design Guidelines, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-design/ -Cleared open issues, review from Lionel Morand, clarifications and grammar fixes reports; new version -19 released on Mon. -Current timeframe for reviews (theoretically it’s a bit late but will try to put it on next week’s agenda with good chance of it being deferred till the 1st week of Dec). 0950 - 1010 RADIUS over TLS, Stefan Winter (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec - No new rev as issues 59 (CoA) and 60 need discussion. - Should all traffic run on a port or should 3 diff ports be used (session acct, CoA, etc). Q1: 1812, 1813, 3799 or 2083 for all though all existing implementations do 2083. Suggests that there are merits to using 3 diff ports, but would like to solicit feedback of 1 vs 3 ports. - If there are 3 diff ports, which should they be: new or resued 1812, 1813 and 3799? Cleaner to take separate ports but usurps IANA real estate, reuse of ports puts us at whim of TLS (1st byte will need to be different). - Next steps: poll and consensus of 1 vs. 3 ports, new ports vs. multiplex. - Comment from Alan: for existing radius (radsec admins should talk to each other so can work today but) should not rely on this in the future. Not sure if it should be part of Radius over TLS doc. There may need to be other interdependent docs that show how to use radius packets with tls. Difficult to say what’s better. - Stefan comments that then 3 ports may be better. - Bernard comments that radius/dtls discovers the use of udp, so if its tcp should this be an issue? - Alan if radius over tcp over ipsec, that should be valid. Question is it is an admin config issue or have the protocol figure it out? - Stefan comments that tcp should be considered so demultiplexing may be appropriate. - Bernard asks what is in the first byte of tls? - Alan says it’s a tls handshake byte and believes it would not change as things like https may break. Can ask the tls folks, but doubts that packets like start tls would change too much. - Mauricio agrees that we could potentially make it a constant. - Suggestion is to ask Eric Rescorla/Joe Salowey and TLS experts to confirm this. - Bernard states that feedback from implementers will also be key. - Stefan suggests reuse of existing. - Bernard agrees that yes, with multiplexing. If vendors are willing to do this then we can go this route, otherwise we’ll have to take a different approach. 1010 - 1030 Dynamic Peer Discovery, Stefan Winter (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery - No new rev as discussion on port/packet type needs discussion. Dependency on the ports used (1 vs 3) - Would need 3 labels: auth, acct, dynauth if 3 ports chosen. - Could look like S-naptrs (radius.tls, radacct.tls, raddynauth.tls). - Mauricio says as there’s dependency on previous draft, we should hold off until decisions on prev draft are made. This will be in holding pattern until confirmation on prev draft decisions are made 1030 - 1040 RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls - No major changes done. Issues of doc is that it is really a diff of the RADIUS over TLS document. So rather than rewrite, it docs what applies or how it is different. - Open issues: need to re-sync with RTLS draft. Make sense to reuse same port but would like review from Stig Venaas (radsecproxy). - Bernard asks Alan whether implementers are in agreement on port implementation? - Alan says no…in looking at RADIUS over TLS source code, they are treated separately. The goal for freeradius is that it should accept radius and tls on the same port. 1040 - 1110 Extended Attributes, Alan DeKok (30 minutes) http://tools.ietf.org/html/draft-ietf-radext-extended-attributes History: Need more attributes as 256 is too limited, the grouping is not adequate (RFC 2868 not sufficient). - Previous WG discussion was that diameter attrs were too complex. The existing draft for extended attrs had some traction but realization was that they didn’t actually work so prev authors dropped it as they don’t believe its relevant. At last IETF, Stefan and Alan whiteboarded (and then Avi joined) to put this doc together. - New TLV: adds one byte to call it the “extended type”: 4 attrs from the reserved space . Need to name new attributes and grouping defining a TLV data type already in WiMax, 3Gpp2 and other sdo’s/vendors; while not as powerful in diameter, it is leveraging existing code (e.g. proven usefulness in radius). - TLV data type reuses radius format (e.g. TLV).imposes a nest in TLV within TLV, can be nested to arbitrary depth and limited by the length field (sum of TLV lengths must add up to the encapsulated length); though anything beyond depth 5 can become confusing. - TLV naming: IANA to track, leverage same dotted notation (e.g. 241.1.2 = Radius attr 241 of type “ext-attr”, extend attr 1, data type “tlv”, tlv 2, data type “integer”). - Use of long attributes definitions includes a new flag (1 octet). - Suggestion is to make ‘flag’ be compatible with wimax. More details to be sorted with by Alan and Avi….not sure that extra 7 bits would be used for anything. - Extending vsa space 24{1-6}.26 are VSAs and allows for more to be supported. - Motivation: believes that a solution is needed w/in 2-3 yrs. - Stefan asks why not have flag in these attributes? Alan responds that half of the defined attrs are <20 bytes, so having a flag for them, best guess is that they would be < 20bytes and having a flag for each of them would not be efficient. - Stefan asks how may deployments have gone the “simple” string mechanism as they were no longer “attributes”. Alan mentions audit was not perfect, but its easy to strip out something “small” and looking at the rest; though indiv class attributes only about 20 require 253 octects, including wimax that defines attrs that carry tlv’s. the tlv’s tend to be generic filter rules that can be nested and carry a substantial amount of data within one attribute. So believes there’s not great demand that require more than 253 bytes of data and most are defined by rfc 5907 (not sure of #?) and those tend to include certs. The rest seem to be small. And even those are allocated rarely (e.g. once every 2-3yrs)…giving us ability to have a simpler format. - 2 interop implementations for this already: basic support in freeradius (no long attrs yet), client support in IEA software. - Todo: define VSA data type (easier than repeating attr definition), more guideline recommendations, more examples and clarifications. - Bernard asks if guidelines need to be covered in this draft or if a different doc may be needed? Alan says its a good question, some guidelines would be good to show applicability on some of this, but it may be OK to keep them high level in this doc. - Bernard asks if Alan envisions carrying over some of the guidelines from the guidelines doc to this one. Alan: yes. - Bernard asks if vendors are ok with new VSA type? Alan says no, though idea is to use something similar to RFC 2865 (4byte vendor ID).so most people have followed TLV fmt per rfc, some have not.given some attr have length attached, for compatibility rfc 2865 are typically encapsulated in a vendor specific attr though its not been done by all vendors. - Stefan asks if proposed attrs been hijacked yet? Alan mentions as the new vsa’s are in context of extended attrs, believes that those attrs have been hijacked by vendors and doc discusses this and how proxies can help detect these. Eduroam did an audit to show that most proxies were ok, but a few were not; so doc makes suggestions on what to do (.e.g take existing hijacked defns and discard them. Take old equipment and deprecate them) - Chairs believes this is important work item and want to poll from the WG to see about making this an official WG item. Do you feel this is a WG that would be willing to review? - 2 respond yes. None one responds negatively - Bernard and Stefan in jabber also support this - Chairs will take this to mail list for final consensus call 1110 - 1130 Discussion and Wrap-up, WG Chairs & AD (20 minutes) - Many things on the pipelines, requests group review of existing - Last Call on IPv6 attrs will be opened up - Dan has nothing to add but would like to see more reviews and contributors |