Minutes of the RADEXT WG Meeting at IETF-61

["Nelson, David" <[e-mail]>]

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 [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>