Minutes of the RADIUS Extensions (RADEXT) WG IETF-69, Chicago, IL, USA Thursday, July 26, 2007 9 AM - 11:30 AM Note takers: Alan DeKok and Mauricio Sanchez. Edited by Dave Nelson. ÿ Call for revision to agenda items... none Documents completing IETF last call (10 minutes) RFC4690bis. Problems caught in the examples. Will be fixed in AUTH48. Hopes no others are found. Documents completing RADEXT WG last call (10 minutes) Two documents completed WGLC RADIUS Issues & Fixes RADIUS Location Attributes (GEOPRIV WG) Two documents completing WGLC RFC3576bis RADIUS attributes for filtering and redirection Several individual submissions are currently under review. Hannes: Asks about how extensibility will work in the filter document, for Diameter interoperability? The current approach is to add grouped AVP around it. Maybe it could be handled via IANA considerations? Request Hannes to submit this as a formal ISSUE. 9:10 - 9:20:ÿ Issues & Fixes, Alan DeKok http://www.ietf.org/internet-drafts/draft-ietf-radext-fixes-04.txt ÿ Draft -03 sent to IESG for comments, lots of comments and -04 came out. Mostly clarifications; Retransmit timers had not been discussed in -03 and discussion added to -04 Draft -05 published, yet more comments streaming in. Discussion around invalidation of cache and why. Suggest usage of client authenticator to protect against forging. Bernard question on how. Backwards compatibility a concern. Many vendors have done strange thing with their implementations. Bernard asked group to read group document and comment. If only one document should be reviewed. It's this one. Dave asks whether Alan picked up the post-resolution text from the PANA document? Grab updated timer text from PANA. 9:20 - 9:30 Attributes for Filtering & Redirection, Mauricio Sanchez http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-03.txt This is a new version draft -03. No comments, on the list. Open issue: 172, suggested text looks good. In response to Hannes? comment: use a version number. Hannes: Version capability negotiation? Copy whole ABNF into new document? Yes, it is a monolithic approach. Hannes: In Dime, create grouped AVP, and associate the two. Alan D: Add "chain" actions? Glen Z: Get rid of the goofy BSD syntax, and put it into an extended attribute. String parsing is very unpopular on the NAS. Parsing strings is not good. Hannes: Avi submitted document to DIME on that issue. Do encoding as different attributes, which simplifies the extensibility. Mauricio: Send link, and take it to the list. Glen: It looks just like Diameter which is good, but the Diameter way is broken. We shouldn't continue this approach. Bernard: is DIME going to change document? Hannes: Not really. Post issues to list. Hannes: Encoding isn't a minor issue. Glen: Is there a forgotten issue? Bernard: We decided to do whatever DIME is doing. Hannes: DIME is following RADEXT. Bernard: We're chasing tails. Hannes: People who care are in both groups. Multiple encodings are bad... but we have them. Suggest to talk to AD. Ask both WG's what to do. Mauricio: Document presented to both groups, with little argument. It's tradition... no better way. Alan D: Might as well wait to do it right. Dan: Decisions need to be validated by list; wait a week, and confirm decision. David: If we change encodings, do simultaneous last calls in both DIME & RADEXT 9:30 - 9:40 Attribute Type Extension, Glen Zorn http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-02.txt Extend attribute ID space, extend the length, support sub-attributes and grouped attributes. Described how type values are extended. Uses VSAs with a vendor code of 0. Described how large attributes are to be supported. Use a fragmentation bit in the header. Described how attribute grouping is to be supported. Uses a tag field in header similar to RFC 2868. Alan D: MUST have similar attributes next to each other. Would like the draft to strengthen the usage of fragmentation to prevent implementers fragmenting attributes throughout the packet. Would like some usage rules defined. Bernard: Questions whether we are setting up two different ways of treating "standard" attributes as specified by this draft and the RADIUS Issues and Fixes draft. Must be able to ignore something you don't understand. Glen: good question. Bernard: Behavior is different... Glen: We're defining a standard attribute here. Should be handled the same way as standards. Bernard: This can become WG work item. David: Is zero a special value for VSA's? Glen / Bernard: Nope. It seems to work in implementations. 9:40 - 9:50 WLAN Attributes, Bernard Aboba http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.txt Recently completed IEEE 802.11 review. Removed Allowed-SSID and SSID. Added EAP-Lower-Layer. Might want to change policy based on lower layer or pre-authentication. Ask folks in 802.1af to look at this. Alan D: Asks what is done with EAP fragments? The issue is with TLS. Apps may think they have a greater lower-layer MTU than they actually have. Bernard asserts it's an issue outside the scope of RADEXT to figure out how to prevent fragmentation. Accept as WG item? 9:50 - 10:10 Design Guidelines, Bernard Aboba Alan DeKok has accepted the editing responsibility. Design guidelines deal with the current data model, not extensions. We don't deprecate formats, but to explain them and articulate design principles. Went through document outline section by section. Section 2 describes vendor space. Bernard raises question whether anyone in group knows all possible formats used by vendors. We may want to describe the various VSA formats. Alan DeKok says he has a pretty good handle. Glen Zorn says it's likely not possible. He doesn't even know all the formats for his company (Cisco). Cisco has 4 kinds. Dave N. asserts that it was unfortunate that 2865 essentially described VSAs as private sandboxes. Dan: Do we make a distinction between SDO's and vendors? Is SDO the correct term? Industry forum? Bernard asks Glen Z. whether it's possible to synchronize what's going on in the standard space with what's going in the vendor space? Glen says no. He feels it's not useful to spend the time. Bernard asserts that it's absurd to force SDOs to define attributes in the standard space if they already have a fully defined vendor space attribute. Glen: We should encourage people to publish informational RFC's on their VSAs and VSA formats. Joe S. points out that that SDOs that define vendor space attributes are also in control of those attributes. It may be useful to have the IETF the controlling body, as it is for the standard space. Bernard chimes that having the IETF in the middle of SDOs is probably not useful. Dave N. feels that one basic step we should take is define a basic data model. He feels that it would help a lot towards improving interoperability. Bernard took poll of room whether to accept as WG work item. Raised hands in favor of accepting as WG item won over those not in favor. 10:10 - 10:20 RADEXT Crypto-agility Requirements and Selection Process, David Nelson ÿ 10:20 - 10:30 RADIUS + DTLS (Alan DeKok) http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.txt Bernard has question on resource allocation whether we can distinguish resource allocation requests. Alan says yes based on the usage of RADIUS length of 0 to use as markers. Joe asks whether there is more to do on the server besides the code snippet described in Alan's presentation. Alan says there is additional work, mostly on the server side in order to do the muxing and demuxing. Scott Kelly chimed in that he has implemented DTLS and didn't find it too onerous. Asserts that there are issues with the OpenSSL implementation. He pointed out that fragmentation is not supported in DTLS and causes operational headaches. Bernard asks whether the RADIUS 4K limit would effectively be limited to the DTLS MTU. Scott says yes and feels it needs to be addressed.ÿ Comment: Isn't that hard to do. DTLS packets can't be fragmented. We have little implementation experience. 10:30 - 10:50 RADIUS Crypto-agility (Joe Salowey) http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-06.txt ÿ Bernard asked whether there are cryptographic property differences between the generic attribute and key wrap attributes. Joe replied that there are because usage scenarios for each attribute drive unique needs around cryptographic properties. Hannes: End to end key distribution? Or hop by hop? Joe: Hop by hop. But it?s possible to encrypt between arbitrary parties. Hannes: DTLS is hop by hop. CMS in Diameter has similar issues. Bernard: CMS is unrelated. Joe / Hannes: It is the same. Hannes: Issues that don't show up in a neighboring relationship need to run a discover step. Joe: This draft is limited to hop by hop. Not intending to do end to end. Glen asserts scope of document is limited by trust topology of network. If key is shared across many hops, then one could build an end-to-end solution. It's not the intention of this draft to create a radius key management system. Hannes: Additional issues that need to be addressed when you address messages to non-neighboring nodes. Glen: That?s not an issue. If a key is configured, you can use it. Dan Harkins asks about the purpose of the IV. Joe replied that NIST specs state that IV in draft should be used. Dan replies that it's not necessary. Dan asks about purpose of the MAC randomizer. Joe says that not all messages may contain keys (which are key wrapped) and hence the need for the MAC randomizer arises. Dan: Make Message-Authentication-Code not dependent on keywrap. Bernard: We need a separate shared secret for each MAC algorithm. Joe: Yes. Dan: Divorce Id's from attributes, and move them into other drafts. Joe: There are advantages to having them here. Dan questions the lack of any key management scheme. Glen mentions the utter failure that Diameter CMS in trying to define a key system. Hannes: The use of transport layer security seems to be OK for Diameter. Steve Hanna: Pre-shared keys exist for TLS, we can use the same thing for DTLS. It is compatible with existing practice. Dan: DTLS & keywrap are equally new. Glenn questions whether DTLS/TLS proposal makes key management any easier. Leif J. feels that key management in DTLS/TLS is easier because there are existing libraries to answer question. Steve H. asks Alan what key management scheme he had in mind. Alan replies that he hasn't specified any and acknowledges it must be discussed. Steve states he favors DTLS because more existing work Bernard asks for clarification on the DTLS fragmentation. Scott Kelly responds that it an oversight in the DTLS stack specification, but a workaround does exists that relies on manual fragmentation. Suggests that issue be taken to TLS WG and get them to fix it. Steve H. chimes in that he feels that we should use existing security mechanisms rather than invent one. RADIUS WG has a bad track record in developing new security mechanisms. Glen Z. highlighted past examples where security group has not taken well the re-use of existing security mechanisms. Ex. PEAP/TLS. Dan H. feels that we're not defining a new security mechanism when in fact AES keywrap is a well established technology designed by smart cryptographers. Steve feels that if we go down the AES keywrap the security area should be consulted and have them review RADIUS work. Leif. J seconds Steve's recommendation for review by security area. Room poll taken on various questions "Who favors the DTLS proposal?" 4 hands in favor "Who favors the keywrap proposal?" 8 hands in favor "Who doesn't like either proposal?" 1 hand 11:10 - 11:20 RADSEC (Stefan Winter) http://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt Hannes: This is re-inventing Diameter. Glen: It?s mostly used between roaming providers. Stefan: We can use it on NASes, radsec proxy exists. Bernard asks whether this proposal assumes PKI, pre-shared secrets, etc. for key management. Stefan responds that their implementation uses PKI, but in theory there is no inherent limit on how the keys are managed. Glen Z. asks whether the TLS connection is just between realms. Glenn asks what IPR issues exist with Diameter. Bernard points Glenn to IETF IPR page that lists several claims against RFC3588. Steve: Any issues with TCP? Stefan: That hasn't been a problem. Dan: Be careful about overlap with Diameter. Dave polls the question whether this work should be accepted as the solution to the crypto agility work (assuming transport issue with RADEXT charter is overcome)? 8 in favor 6 against Dan R. chimes in that it may possible to change the RADEXT charter to allow the TLS proposal to be worked on in RADEXT. Glen is not hostile to the proposal itself, but hostile to changing the charter. Feels there are better reasons to change the charter than for this document. He would appeal if we changed charter to add this work. Keywrap has been extensively reviewed. Leif J. is surprised about hesitancy on changing charter. Other groups change charter and survive. Asks whether there is a rush to get this work done. Glenn says no, the keywrap draft has been around for three years. Lief: All proposals have issues, should we keep them all alive? Dan: Yes, but WG is under pressure to do work. Do it as fast as you can. Comment: We should be able to resolve on mailing list. Don't wait. Comment: RADSEC wants to change the transport, it's a bigger issue than it appears. Comment: Other protocols needs key transport. 3GPP2 will put dependencies on keywrap. We need to get it done quickly. Hannes suggests a proposal that takes elements from keywrap and from DTLS. Bernard asserts that trying to mix DTLS and keywrap is going to result in a protocol that takes the worst from both and would be universally ignored.