|
Minutes of the RADIUS Extensions (RADEXT) WG IETF-69, 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. |