[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minutes of the RADEXT WG Meeting at IETF-61
Please reply to the list (ASAP) with any errors or omissions.
Minutes of RADEXT WG meeting at IETF61
Monday November 8, 2004, 9:00AM-11:30AM
Hilton Washington, Military Room
Chairs: Preliminaries
---------------------------------------------
The Co-chairs presented the agenda. All slides are available from
http://www.drizzle.com/~aboba/RADEXT/IETF61/
Blue sheets were circulated.
Document status:
- Having completed WGLC
- 2486bis
- SIP authentication
- Requiring review
- GEOPRIV WG has requested us to review the RADIUS Extensions
for GEOPRIV (and some people are doing that already). Preferably
this should be stable by December due to 3GPP deadlines. Will go
to GEOPRIV WGLC soon.
- IPv6 MIB revisions will go to WGLC once we get the submissions
- Two documents being evaluated as potential WG work items
- Chargeable user identities
- RFC 3576 MIBs
Milestones:
- Some documents are pretty much ready, and some have been worked
on for a long time -- we should move fast on those.
- If something doesn't move, we interpret that as a lack of
interest and drop it. So authors, please keep moving them.
Jari Arkko: draft-ietf-radext-rfc2486bis-01.txt
----------------------------------------------
Overview
- Passed WGLC
- All issues raised in WGLC have been resolved
- Three new issues brought up since then
- Better examples (#16)
- Bernard's review and editorial nits (#15)
- Josh's editorial nit (#17 part 1)
- Suffix vs. prefix for the home realm (#17 part 2)
- All have been addressed, except last one
- It was discussed extensively in EAP WG early in this work
- Prefix approach works better with unmodified AAA nodes
Next steps:
- Will submit -02 as soon as submission opens again
- Jari thinks it's ready to go to IESG
- This is one of the 3GPP R6 dependencies marked as "critical", so it
should be stable (approved by IESG) by December
- There is one reference to an internet-draft, but that's already in
RFC editor queue, so it's not a problem
Wolfgang Back: RADIUS Extensions for Digest Authentication
(draft-sterman-aaa-sip-04.txt)
----------------------------------------------------------
This is now a WG item, but missed deadline for renaming it. Trying to
align the draft with the Diameter application (ietf-aaa-diameter-sip).
Response-Auth:
- Could not be calculated by RADIUS client alone, so we added a new
attribute.
- Comment: MD5 might not be acceptable anymore.
- Response: This draft is not actually using MD5, just providing
support for HTTP digest (which uses MD5).
Message-Authenticator:
- This is a good thing to do, but RFC3579 is Informational
- Added in -04 as "MAY"
What's a "secure connection"?
- Added some clarifications
- Question: What exactly is a secure connection (IPsec, MPLS VPN, ...),
and should we rely on the operator getting this right?
- Comment: IPsec is used in RFC3579, so using it here should not be
a problem.
- Comment: It's important that the RADIUS client/server knows that
IPsec was used.
- Comment: The distinction is that this ID requires application to
know that IPSec is being used. That requirement is not in RFC3579.
- Comment: RADIUS includes other means to hide attributes besides
IPSec.
Other documents specify this.
IANA allocation
- IANA request has been submitted long ago, but received no decision
yet.
- Comment: It's probably been lost; resend it and CC the Chairs.
Review
- Chairs: We need people to check -04 and say that it's OK.
Silence does not mean WG consensus.
- Chairs: We may need a security review, too, considering the issues
discussed today. The chairs will contact the Security ADs to solicit
reviewers.
Farid Adrangi: Carrying Location Objects in RADIUS
(draft-ietf-geopriv-radius-lo-01.txt)
--------------------------------------------------
Farid presented the history, motivation and overview of the draft
(see the slides). The goal is to convey location information to the
home AAA server while taking privacy into consideration. This will
support location-based authorization, taxation, location-based services,
a mid-session method for transfer. It is based on the CoA RFC and
reuses existing GEOPRIV work as much as possible.
- Question: What exactly does "not sharing the location information"
mean, e.g., can RADIUS proxy forward it? Or how the home AAA server
can use it?
- Response: The policy rules are intended for the home AAA server,
and the policy is mostly about passing the information beyond the AAA
infrastructure.
- Question: About retention: ISPs store accounting records for several
years (because they're required to), so how the does the
"retention-expires" work in this case?
- Response: Most likely the entities are assumed to have business
relationships and contracts that deal with some of these issues.
- Question: Should the users be setting their own location privacy
policies?
- Response: This is mostly between operators and based on operators'
policy (if an operator needs the location for authorization and
accounting).
- Question: So this is not about customers, it's about operators?
- Response: Yes.
- Comment: The location of the NAS often does not have anything to do
with the location of the user. The document supports both,
and in case of wireless, the radio range is limited.
- Comment: Restricting this to only NAS location would simplify the
draft and improve understandability.
- Comment: The location of the user is important.
- Question: Where does the NAS gets the location information?
- Response: NAS or AAA proxies are configured with this information.
There was discussion about alternative solutions. Since NASes don't in
general move, why this could not be solved by some other approach?
A table mapping NAS-Identifier to location at home AAA server does
not scale in roaming situations (consider 100,000 APs and 10,000 home
AAA networks). It's probably better to have this information in one
place and send it to home AAA server where it's actually used.
Chairs: We've had good discussion here, please continue it on the
mailing list.
Bernard Aboba (on behalf of Paul Congdon): 802.1 Support Attributes
(draft-congdon-radext-ieee802-02.txt)
-------------------------------------------------------------------
- Missed the ID update deadline
- Not many changes to the previous version
- Added VLAN-Name attribute
- There as been interest from Trusted Computing Group (TCG)
in referencing RADIUS attribute documents, most likely this one
and the bandwidth draft.
- Work has been slow, a new author should accelerate things
- Some people are interested in new Layer 2 filter attributes
- Is NIST ever going to speak up about key management attributes?
- Paul Congdon would like to get a "design team" to work on this draft,
please contact him to volunteer
- Question: Does this document replace RFC3580?
- Response: No, it adds attributes for 802 stuff that was not covered
by 3580, but explicitly stating this might help.
- Comment: Some have expressed an interest in working on a RFC3580-like
document for IPsec VPNs, "RADIUS usage guidelines for IPsec/IKE/IKEv2
stuff". This would not necessarily define any new attributes, but at
least clarify how existing ones should be used. Anyone interested
should contact Pasi Eronen.
Farid Adrangi: Chargeable User identity
(draft-adrangi-radius-chargeable-user-identity-02.txt)
------------------------------------------------------
Farid went through current issues. Issues 13, 14 and 15 are addressed
in the most recent draft. There are two open issues: (a) backward
compatibility and (b) the lack of general capability negotiation
mechanism in RADIUS. We could send a "hint" attribute in the Access-
Request message as indication of CUI feature support.
There was some discussion about why this draft is needed. The main
reason seems to be that currently User-Name is overloaded for both
routing and identification. The Class attribute works for two parties,
but not so well for multiple parties (like roaming clearinghouses).
It seems that the draft needs a better explanation of the problem
being solved.
Glen Zorn volunteered to send a paragraph clarifying the problem
statement to the list.
- Question: Clarification about the different identity type prefixes?
It seems that the document defines a new number space, but does not
say how numbers get added to that space.
Chairs: We would like more than two people to read this, and say on
the mailing list that they like it and would like it to be WG item.
Farid Adrangi: RADIUS Redirection
(draft-lior-radius-redirection-01.txt)
--------------------------------------
No activity.
Chairs: Please review and comment upon the draft.
Farid Adrangi: Bandwidth Capability
(draft-adrangi-radius-bandwidth-capability-01.txt)
--------------------------------------------------
In previous versions of the draft, there was some confusion about what
exactly NAS should do with these attributes, e.g. what kind of algorithm
it should apply to actually doing something about the traffic, or
reserving something, or something.
Farid presented the idea of having a general framework that would allow
different types of actions.
- Comment: A general framework without any concrete mechanisms is not
useful.
- Response: The draft would define one or two concrete mechanisms as
well, but allow others to define more in the future.
- Comment: This ID uses structured attributes, which are not very
nice in RADIUS. Having separate attributes might be better from
RADIUS point of view.
- Response: We are running out of RADIUS Attribute ID space.
- Comment: It's not clear that this is imminent, and when we do run
out, there have been several proposals made on how do extend the ID
space. We could pursue one of those proposals, as needed.
- Comment: There's probably overlap with QoS-Filter-Rule attribute in
the
802.1 LAN Attributes draft.
- Question: What is the relationship to Diameter QoS application draft.
- Comment: Having something very simple would probably be better than
something complex and general.
Jari Arkko (on behalf of David Mariblanca): EAP lower layer attributes
(draft-mariblanca-aaa-eap-lla-01.txt)
----------------------------------------------------------------------
Jari presented the approach (see slides).
- Question: Do we want to just know the physical layer used to carry
EAP,
or tell the difference between what kind of service the user is
using?
- Response: The main goal was to tell the difference between 802.1X and
IKEv2 cases, and allow policies like "this user can use 1X but not
IKEv2".
-Comment: Using Service-Type or some other attribute might be more
appropriate.
Chairs: It seems that several people are interested in NAS-Port-Type
and/or Service-Type usages. It would be good if they can get together
and review the alternatives. Volunteers: Glen Zorn, Pasi Eronen,
Jari Arkko.
Chairs: MIB work
----------------
RADIUS and RADIUS Accounting MIBs. An IPv6 MIB update was intended for
this meeting, but was delayed. The work is straightforward. MIB doctor
review and input will be sought for the MIB updates, once the drafts are
available.
RFC3576 MIB. (draft-decnodder-radext-dynauth-server-mib-01.txt)
Murtaza Chiba was not present. We should proceed with this work, as it
is in the charter. Will seek volunteers to review the current draft,
and
seek MIB Doctor review, as well.
The meeting ended about 11:00AM.
------------------------------------------------------
--
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/>