Minutes or the RADEXT Session at IETF-65

["Nelson, David" <dnelson@enterasys.com>]

(As always, please make comments on errors or omissions to the WG
mailing list.  This version has been submitted for the IETF-65
Proceedings.)

--------

IETF65 - Dallas, TX
March 21, 2006
RADIUS Extensions Working Group Minutes

Minute taker: David Mitton.  Edited by David Nelson, with input from the
Jabber Room log file.

Agenda bashing.

Milestone review -- We are trying to get to done.
The revised WG milestones, recently approved and posted to the WG's IETF
web site, were presented.  We will be managing the work flow to keep to
the new milestones.

Document Status (see slides for overview)

------
Digest Authentication: Wolfgang Beck

Wolfgang presented his recommendations for resolutions of IESG review
comments.

The one outstanding issue was the security concerns over the option for
client supplied nonces.  Sequence numbers are an option, but as
timestamps they present issues.

Glen Zorn: The size of the synchronization window is pretty large.

Dave Nelson:  There had been a request from 3GPP2 to add the option for
client supplied nonces.  Do they still need this?

David S:  We could live without it.  It's a round-trip reduction
optimization.

Bernard Aboba polled the WG members present to sense consensus:

(1) Remove the added Sequence number, and simple recommend that client
supplied nonces be used not use - several hands
(2) Keep the added Sequence number as described - nobody
(3) Remove the client supplied nonce option altogether - several hands
(3) Keep the client supplied nonce option - nobody

The consensus of the room was to remove the client supplied nonce option
altogether.  This will be confirmed on the WG mailing list.

Bernard asked for people to confirm if issues with this are closed, adn
to send that notice to the WG mailing list.

John Loughney - His issue is cleared.

------
Dynamic Authorizations MIB - Stefaan DeCnodder 

The status of open issues was reviewed.  There seems to be consensus on
how to address the AD review comments.

The authors will submit a revised version, and a pre-submittal notice to
the WG mailing list so we can check the revisions.

------
RADIUS IPv6 MIBs - Dave Nelson

Reviewed the status of open issues from AD review, numbers 182 and 177,
item 2.  Similar in nature to the comments on the Dyn Auth MIBs.  Will
submit a revised version.

------
VLAN and Priority Attributes - Mauricio Sanchez

Split out from the IEEE 802 Attributes draft. Trying to progress the
non-contentious attributes and work on the NAS-Filter-Rule separately.
Completed WGLC last week.

Strawman revision draft posted to Bernard's web site to address WGLC
comments.  After IETF 65 and any additional comments, the revised
version will be formally submitted.

Open issue number 180, coding of attribute values:

Bernard proposes: 
  - VLANID as an integer
  - Priority Table as a string
  - VLAN Flag? Naming and encoding questions?

It is currently 0x31 because it's easer to type an ASCII "1" as part of
name string.  It gets added to a VLAN name, but also used as a number.

VLAN Tag-Indicator is preferred as the field in by large margin of those
in the room.

NAS-Filter-Rule Attribute

Asked the DiME WG for their input, as the original version was defined
in the Diameter RFCs. The question of how to keep RADIUS and Diameter in
sync on this feature is not yet resolved.  It will require cooperation
of RADEXT with DiME.

Bernard Aboba:  3GPP has recently requested the Diameter Filter-Rule
feature in RADIUS.

Dave Nelson:  RADIUS and Diameter should not have separate dialects of
filter rules.

Bernard Aboba observed that the syntax is defined in RFC 3588, but only
used in RFC 4005.

John Loughney suggested that the NAS-Filter-Rule move to an RFC 4005
revision draft.  

Glen Zorn:  If we're doing translations in a gateway anyway, just do
another one.  If it's just a syntax issue... (that is not answered)

Dave Nelson: The identity translation operator is always easier.

John Loughney: Agree with the proposal, but we need to write down
translation rules.

Q:  Is there a plan to continue rules for translation?

John Loughney:  This is a topic for the DiME WG, and we would like a
volunteer.

Glen Zorn: The translation rules are in RFC 3988 and RFC 4005.

--------
Delegated IPv6 Prefix - Ralph Droms

Revisions and issues because from WGLC were reviewed.

Created an attribute to match a similar one in RFC 3162.

An issue was rained with respect to attribute design guidelines.

Bernard Aboba: The issue have been resolved on the WG mailing list.

Question: What is the use case?

One use case is DOCSIS authorization.

Comment: Could also use in WiMax.

------
WLAN Attributes - Bernard Aboba


Several attributes to pass 802.11 new things
  - EAP-Key-Name
  - EAP-Peer-Name

Parviz Yegani: What is Mobility-Domain-ID for?

Bernard: Thought that IEEE 801.11r specified the need.  If you see this
advertised, then you can roam between them and get fast handoff.

Nancy Cam-Winget: Not required, but could be useful for accounting.

-------
RADIUS Design Guidelines - Greg Weber

Dave Nelson:  We have a milestone to go to WGLC in June, so we need to
get motivated on this.

Bernard Aboba: If your draft will get gated by this one, then you must
read it.

Question:  What is the level of compliance expected?

Bernard Aboba:  The content of the document is a WG issue.  If the
working group doesn't think everything needs to be enforced, then those
items should be removed from the draft.

Glen Zorn: My understanding is that the reason there is pressure to get
this out is that it is holding up other work.

Dan Romascanu: Wants the design guidelines work to move forward.  Don't
want other documents to move forward with things contrary to the
guidelines. In MIB world we have CLRs (crappy little rules), which don't
always add value.

Various commenters:  A lively discussion of when the format and
structure of complex attributes matters and when it doesn't.  The
general sense of the discussion is that it matters when some RADIUS
entity needs to pick apart and take action on individual sub-elements.

Bernard Aboba: The Wolff draft looks like Diameter VSAs.

VSEs - No, use standard attribute values instead.

Glen Zorn:   Per-attribute encryption applies only to only
User-Password. 
Tunnel-Password is not standardized.

Greg Weber: Encrypt the whole message.

Glen Zorn: How?

Greg Weber: Use IPsec.

Glen Zorn: IPsec has problems with authentication and Trojan horse
issues.

Greg Weber: Security must be done at the application layer, because
cannot tell if IPsec is operating as desired.  Do we have an IPsec
problem in general?

Glen Zorn: I think we do.

Dave Nelson: The expectation is to produce a new standard for crypto
agility for the current mechanisms, and a guideline for accommodating
other mechanisms.

Bernard Aboba: Are we saying don't use existing RADIUS security
mechanisms?

Glen Zorn: As written, this is band-aiding the broken stuff.
 
Bernard Aboba: Security statement or guideline?  Don't do it as we did,
but like we might say in the future.

Bert Wijnen: SDO related attribute design rules?  Do they want them?

Bernard Aboba: No, we need to give something for them to use in creating
RADIUS Extensions, without a full review here [in the IETF].  Other SDOs
try to come through the IETF or go via IANA.  Allow them to do work
independently.

Dave Nelson: Encourage SDOs to design for the standard attribute space.
Discourage them from inventing novel encapsulations, particularly when
multi-vendor interoperability is required.

Glen Zorn: Using the Vendor-Specific attribute space has kept them from
infringing on an already crowded standard attribute space.

Wolff draft on Extended RADIUS Attributes.  (See slides)

Bergen draft on Extended RADIUS Attributes.  (See slides)

Discussion of Extended RADIUS Attributes:

Question: Are we recommending Sub-Attributes?  Will these be nested or
flat?
 
Greg Weber:  They would be hierarchical.

Parviz Yegani: Should we be following this structure?

Greg Weber: That's the issue in question.

Bernard Aboba:  Do people like it or not?  Nested is fine, but the
format is an issue.

Dave Nelson:  This is like coding standards, you love them or hate them.

Parviz Yegani:   We need to move on.  Should we redo things?

Bernard Aboba: If you don't like them, propose something better or
different.

Dave Mitton:  What is the status of these drafts?
 
Bernard Aboba:  They are pre-WG items.

Dave Mitton: Suggest two documents, one for guidelines and one for
extended attributes. 

------
Issues and Fixes - Bernard Aboba

Presented the current draft status.  It probably needs more input before
becoming a WG work item.

----
RADIUS-Diameter-VSAs  - Dave Mitton

Presented the status of the draft, and it relation to the Extended
Attribute ideas.

Glen Zorn:  Has an issue with putting Diameter AVPs in RADIUS messages,
becasue of the overall RADIUS message length limitation.  He is working
on a solution to the RADIUS message length constraint.

Dave Mitton: Please publish and I-D on this.

----
Pre-Paid Attributes - Parviz Yegani

Presentation of the changes from the last draft version.

Glen Zorn: Removing Authorize-Only reduces usefulness, please put it
back.

Bernard Aboba: To clarify the issue: Authorize-Only raises the
opportunity for DOS attacks, and has to be tied to State attribute to
prove prior authentication.

Glen Zorn: Issue with requiring a minimum number of positive reviews to
advance documents.

Bernard Aboba:  This recommendation came from our AD and the IESG chair.

-----
GEOPRIV RADIUS Attributes - Jouni Korhonen

Presented the changes based on RADEXT WG reviews so far.  This document
is being advanced in the GEOPRIV WG.

Bernard Aboba: We are not coming to convergence quickly enough.  We need
to figure out how to finish this.  Do we need to assign a team?  

Dave Nelson: The major issue is with the attribute structure?

Bernard Aboba: I think there are values that will need to be picked
apart, so the current [attribute] design won't work.

Greg Weber:  This may represent another class of data blobs that need to
be picked apart, but need to be carried by multiple transports (RADIUS,
Diameter, DHCP).

Bernard Aboba: Yes, I wish I knew what DHCP was doing with location
information encoding.
 
From the Jabber room:  Alan DeKok: Is the format defined elsewhere?

Bernard Aboba: Yes, in the case of the civic and geospatial location
data.

Dave Nelson: How do we move forward?

Bernard Aboba: We need to get the RADIUS people to decide what they want
to do. with the help of the location people.

Dave Nelson:  The chairs will attempt to set up a small group to
facilitate this.

With this, the session time expired and the meeting adjourned.



--
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/>