[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minutes of the RADEXT WG session at IETF-67
Here are the RADEXT minutes, as posted to the meeting material web site.
Please review for any errors or omissions and comment back to the list.
Thanks!
------------------------------------------------------------------------
IETF 67 RADEXT WG Minutes
Harbor Island I
9:00 - 11:30 AM
Tuesday, November 7, 2006
Note takers: Mauricio Sanchez, Madjid Nakhjiri
Jabber scribe: Sharon Chisholm
Minutes editor: Dave Nelson
* Meeting started at 9:05am
* Agenda bashing. No changes.
Look for info in http://www.drizzle.com/~aboba/RADEXT/
Look for presentations at IETF meeting material page:
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67
* Bernard went through WG document status.
------------------------------------------
- 7 docs published as RFCs, 4 RADIUS IPv6 MIBs and 2 Dynamic RADIUS
MIBs
- some comments on the MIBs came after RFC publications, but mostly
editorial
- Dave described comments made on the RADIUS MIB RFCs relating to
structure and format; No substantive comments, just editorial.
* Wolfgang Beck went through RFC 4590 errata issues.
----------------------------------------------------
- A week after the RFC publication, an implementer sent email about an
error about an IANA type.
- It seems to be easier to change the IANA website than to change the
RFC.
- Bernard asks whether WG feels that errata are severe enough to cause
confusion
- Alan DeKok (Infoblox) feels strongly that there are issues at hand and
should be addressed; He ran into questions.
- Bernard recommends that minor clarifications be made; IANA table
updates. Feels that a quick spin of document is possible
- Bernard moreover recommends that issues not be treated as errata;
Indicates that a quick "bis" draft and WGLC would be advisable.
* Mauricio Sanchez presented NAS-Filter-Rule and NAS-Traffic-Rule draft
-----------------------------------------------------------------------
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-
- A draft comparison slide was shown between the radext-filter-rules and
radext-filter-05
- the filter-rule draft is simpler since it is based on Diameter,
- there are two attributes in the first draft and one attribute in the
second draft.
- NAS-filter-rule status
- 5 new draft versions since IETF66
- resolved issues: attribute length and Diameter-READIUS GW behavior
- open issues: concatenation/splitting
- Base questions: how to split a long rule across multiple rules?
- 6 proposals since IETF 65
- usage of tag field was favorite out of IETF 66.
- It seems that a consensus is being reached quickly on this issue.
- Plan to go to WG last call with 05 draft.
- Bernard: Can we deal with the issue right now? What if Diameter sends
both kinds of attribute?
- Implementers of Diameter come and say what use does it have in RADIUS
and why?
- Comment: <silence>
- Bernard: Anybody has an objection to have a MUST not use both here?
- Comment: <silence>
- Bernard: OK, done.
- NAS-traffic-rule status
- no new drafts since IETF 65
- Editor to go talk to individuals to get opinions
- big variety of open issues existed:
-- accounting issue mostly closed waiting for 3GPP insights
-- NAS filter rule accounting
- Diameter compatibility
- Bernard: There is a VLAN attribute draft that is not just for RADIUS
but also for Diameter.
- AD: Pointed the charter to Dave: All RADIUS functions must be
compatible with
- Diameter and attributes must be reused as much as possible.
- Next step: To close the issues to talk to issue owners in the next
couple of weeks
- new version 02 within a month
* Alan DeKok presented RADIUS issues & fixes draft
--------------------------------------------------
- A list of clarification (e.g. on EAP), a list of correction, question
relatively little discussion or disagreement on list about the issues
and fixes draft.
- Alan asks the group how many have people have read the draft; Few
people have
- Dave suggests we take it to last call to force everyone to read it
- Someone pointed out that this draft is not a WG item, yet is already
being considered for last call. Bernard contends that this has been done
in the past to take an individual submission and turn it into a WG item
at the same time it went to last call.
- Dave asks group whether anyone objects to taking document to working
group last call. No one does. Dave and Bernard to confirm consensus on
email list.
* Dave presented NAS-Port-Type attribute draft
----------------------------------------------
- Dave asks group whether to take document to WG last call
- Pasi Eronen says that draft has five lines of technical content, just
ship it.
- Bernard points out that the RADIUS IANA Considerations in RRC 3575
says additional values for attributes can be approved by designated
experts do not require a published specification.
- Bernard suggests that it not be published as an RFC to reduce IASA /
RFC Editor publishing costs.
- Simply request the values from IANA.
- WG chairs will provide IANA with an expert review contact.
- AD: As long as we have regular get-togethers where people oversee
these
assignments.
* Bernard presented WLAN attributes draft
-----------------------------------------
- Some attributes already assigned in RFC 4072
- Pre-auth support
-- It was discussed in HOKEY BOF
-- There is a use case in 802.11 and there are some tricky issues
- SSID attribute
- Pre-auth key lifetime attribute
-- A STA pre-auths with an AP, but it does not know what the AP SSID
is, and the AAA server does not know the diff between pre-auth and full
auth.
-- Situation, when the admin want to cache the keys just for a short
time when it is pre-auth compared to longer time for regular auth.
- Bernard asked group whether to make draft an official WG item
- Dave questions whether to split document into attributes that are
necessary now and those that need further definition. Draft is already
behind from a milestone perspective. Bernard points out that IEEE
802.11r group may have requirements, but is busy with other issues at
this point.
- Dave asks group whether group has preference on what to do with
document
- Majid points out that HOKEY does have dependency on AAA pre-auth
requirements that from a timeline perspective are further out.
- Majid asks about the process of getting comments from .11r group;
Bernard explains the formal liaison process to request comments
- Bernard suggests that we submit a liaison request to IEEE 802.11r to
get them to review document.
* Glen Zorn presented Extended RADIUS attributes draft
------------------------------------------------------
- Glen asks how many people have read it; Only a couple have
- Alan DeKok points out that he has comments, but has separate
presentation for his points.
- Dave asks Glen how extended attributes should be treated by servers
not supporting extended attributes; Glen replies that servers that don't
understand the attribute will ignore it, whether that's a problem is a
different question. Glen expects all contemporary servers to support
extended attributes. If ancient servers can't, then so be it.
- Dave asks whether having just an 8-bit type value for extended
attributes is too small. An 8-bit value would only allow for 256
additional extended attributes. Glen believes this is good because it
would force conservation and have a built-in penalty for creating new
attributes willy-nilly. If the type space were once again exhausted, a
new vendor-id would have to be allocated.
* Alan DeKok goes through his commentary of extended RADIUS
-----------------------------------------------------------
- Glen agrees with the argument that a non-zero vendor-ID should be
allocated; He went on to say that GEOPRIV should be given their own
vendor-id; He argues that the value of 0 traditionally means IETF.
- Dave points out that it's unclear of whether multiple vendor-id values
can be registered to a singe entity; Someone in group says that it is
possible.
- Dave made comment on tag and feels that it is of value; It's not a
con. Alan agrees that it's the most practical option available; Points
out that EAP clients and servers are currently forced to mangle
attributes. It would be useful just to do it once.
- Glen points out that Alan's presentation isn't as much a criticism as
an exposition of issues; Questions whether there will be any short-term
decision to make progress; Dave responds that a large block of time was
allocated up front but asks opinion of group. Alan says he's fine with
the state of the document other than vendor-id. Suggests that group
pick a vendor-id value and have some preliminary interoperability
testing. Bernard says that the extended attribute draft is necessary to
be able to complete ongoing attribute work; Code space will run out
based on proposed work and something must be done.
- Someone points out that granting control code space control to other
groups
(other than RADEXT) needs to be considered. Bernard points out that
there are already something like 12 different dialects of RADIUS. IESG
needs to answer whether this is acceptable or not.
- Glen suggests that allocation of vendor-id/type values be separated
out from format issues. Bernard nodded in agreement.
- Dave opens floor to ask group what should be done with document
* Majid points out that other groups do need attributes, groups can't
wait. Sees value in allowing groups control their own destiny and
manage their own attribute space.
* Glen recommends cutting to the chase and making document a WG item.
* Bernard recommends that a new version with local RADEXT issues be
addressed, thereafter document should be open to other groups for
review.
* Glen points out that making document a WG item would force control of
document by greater group than where it is as an individual submission.
Glenn wants to be under the control of the chairs.
* Group agrees to make a new version and distribute to greater
community.
* Dave presents RADIUS guidelines draft
---------------------------------------
- Bernard comments that the objectionable part of the draft is to try to
deprecate old RFC and say that current way RADIUS works/designed is bad.
Objective of document should be limited to things that prevent
deployment, such as those things that force server code change issues.
Document should strive for architectural purity, since most don't force
server code changes.
- Bernard wishes that document be basis for other groups to define their
own attributes that adhere to guidelines and not force groups to pass
their attributes through RADEXT. Dave counters that MIB example is not
a valid example.
- Bernard suggests that document remove extended attribute discussion
and other things people find objectionable. Take a look at the core and
see whether enough remains to take on as official WG item.
- Glen Z. and Hannes T. step forward to volunteer as co-editors of
document
* Dave presents crypto-agility work item
----------------------------------------
- Glen questions where security requirements are documented. Dave
responds that Russ said to write security requirements as stated to
point to SAAG
- Hannes T. asks whether this work item would provide end-to-end
security between client and server. Dave and Bernard say no. This
document only describes how new crypto algorithms can be used in the
current protocol framework. Dave states that genesis is document is to
address the security issues arising from the recent identified
weaknesses in MD5.
- Someone comments that if addressing MD5 issues is really the problem
at hand, then the document should state that as the scope. Feels
current document has many general requirements. Bernard points out that
there are probably two paragraphs that actually address the MD5 issue.
Feels that document needs to be explicit in what it intends to fix.
Bernard recommends title 'Crypto-Agility Goals in RADIUS'
- Someone wanted confirmation that this work item was not undertaking a
huge gap analysis. Bernard says emphatically no.
- Joe S. is concerned by 'negotiation'. Dave contends that there is
already a very simple 'negotiation' present in RADIUS. The client
proposes via hint attributes in the Access-Request. The server disposes
via provisioning attributes in the Access-Accept. This work item would
not upset the balance in RADIUS.
- Glen concerned about the recommending MD5 as lowest common denominator
when no other crypto supported. Feels like a security issue to him.
* Hannes presented GEOPRIV cross-WG review item
-----------------------------------------------
- Bernard asked about document status.
- Hannes unsure and would need to look at the issue tracker.
* Hannes presented RADIUS MIPv6 draft
-------------------------------------
- Glen asks whether acceptance of extended radius attribute draft will
have impact. Hannes says it depends. Glen feels that remaining radius
standard code-space should be set aside for future use, a conservation
measure
- Dave says that RFC 3575 would need to be updated to ensure reservation
of remaining code space.
* Vidya presented handover key draft
------------------------------------
- Group discussed what to do with draft; Bernard and Jari agree that
this draft conceivably create a new authentication method for RADIUS,
just like digest authentication.
- Glen points out that an existing individual submission, key request,
that presumably does some of the same things Vidya's draft provides.
Questions arises on whether mechanics used by Glen's draft are similar
to handover draft. Glen suggests that key request draft be reviewed for
changes that would address handover draft.
- Bernard comments he doesn't understand how this draft has anything to
do with keying. Vidya explains how key material is transferred as part
of handover exchange.
- Bernard asks whether handshake is stateful or stateless. Vidya says
it's stateless. Bernard now sees parallels to other authentication
transactions, like http digest authentication.
- Bernard asks what is the question MIPSHOP desires RADEXT to answer.
Is it the case that all options needs to be reviewed, just one? Jari
says that there may be some of both.
- Someone expresses concern of using RADIUS as a key server. Vidya
points out that key material is not tied to the RADIUS server and can be
logically separated from server.
- Glen points out that this draft is shoehorning a function not serviced
well by RADIUS; It's key exchange protocol that happens to use RADIUS.
Glen doesn't feel this is the way to go.
* Dave notes that we are over our allotted time, so remaining
discussion, as well as the remaining agenda item will need to be
discussed on the WG mailing list.
Regards,
Dave
David B. Nelson
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330
E-mail: dnelson@enterasys.com
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>