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-extensi
on-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.