Draft of RADEXT WG Minutes for IETF-66

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

This is the draft RADEXT WG session minutes, as submitted for the
IETF-66 Proceedings.

Please review these minutes and reply to the list with any error or
omissions.  Thanks!

IETF-66 RADEXT WG Meeting Minutes
9:00 AM - 11:30 AM
Monday, July 10, 2006
Montreal, Quebec, Canada

Note takers: Mauricio Sanchez, David Mitton.  Edited by: David Nelson.

1. Agenda bashing: no changes proposed


2. Document status (Bernard)

Since last IETF eight (almost nine) documents are completed


3. NAS-Traffic-Rules, NAS-Filter-Rule (Mauricio)

Comment (Glen Z): You can always parse the beginning of a rule.  The end
is harder to recognize. Suggest that you enhance the Diameter filter
rules, as it's not that good.

Comment (Dave N): Suggest that we don't pack multiple rules into one
attribute.

Comment (Bernard A): We need to clarify the issues.

Comment (Glen Z): With NAS-Traffic-Rule you will have to translate
strings.

Answer: We'll we have a proposal coming.

Comment (Dave N): 3GPP has already deployed Diameter, and requested the
NAS-Filter-Rule capability in RADIUS.  We need to meet that requirement.

Issue:  RADEXT Issue 170 --  Precedence and order of server-provided
rules to local NAS-provide rules.

Comment (Bernard A): This is an issue if NASes have local rules and
policies.

This has been around forever.

Comment (Dave N): We are about policy provisioning, not policy
definition.

Comment: The principle should be interoperability of features.

Poll (Bernard A): Who thinks the NAS-Filter-Rules draft is ready last
call? 

    Response: 1

Poll (Bernard A) Who thinks the NAS-Traffic-Rules draft is ready for
last call?

    Response: 0

Comment (Bernard A): We all need to read and submit comments so we can
move forward.


4. Pre-Authentication AAA Requirements (Yoshiro Ohba)

Yoshiro presented two basic requirements identified in the IETF-65 BoF.

Yoshiro presented technical issues related to pre-authentication.

There is a dependency between moving between pre-auth and auth states
and key caching.

Comment (Bernard A.): Key caching was addressed 802.11i and it was
decided that key caching was not going to be managed individually by
user, it is a global parameter.  Given it's a global parameter its
there's no need to control via RADIUS.  Each system is configured with
key cache timeout.

Comment (Nancy C-W): Says that 802.11 revisiting topic and considering
to use something else other than Session-Timeout as a means to signal
when to expire keys.  In 802.11i, there is no notion of session
lifetime, just a key lifetime.

Comment (Bernard A): Asserts that the meaning of the Session-Timeout
attribute is too overloaded. 

Comment (Nancy C-W): Yes this is an issue.  Says that 802.11r has no
notion of pre-authentication.  We are looking at making this more
explicit but it's not done.

Comment (Pat C): Points out that there is no signaling between
authenticator and server about the pre-auth state.  You are trying to do
some sort of signaling on the transition from Pre-Auth to active?  It's
not clear that these events exist, and they are not RADIUS issues.

Comment (Bernard A): Points out that no accounting is generated prior to
session setup.  Accounting is used to know when session starts and ends.
We need to ask implementers what they do.  This is discussed in RFC
3780.

Comment (Pat C): Not sure this is practical for wireless roaming.
Concerned that a client may pre-auth with many APs and if it moves just
a bit...

Comment: Calling-Station-ID - What value shall it take on with
pre-authentication?

Yoshiro presents a summary:

Drives home message that pre-auth requires a lot of work in EAP and AAA
layers.  Most work to be done in HOAKEY.

Comment: Someone asks scope of HOAKEY.

Answer: HOAKEY will define requirements that will need work in
respective working groups.


5. WLAN Attributes (Bernard)

Bernard presented the notion of a pre-auth specific timeout attribute.

Comment (Yoshiro O): Asks whether the absence of pre-auth attribute
should be considered always as a normal session?

Answer (Bernard A):  It depends.  The presence of the attribute in an
Access-Request means it is a pre-auth session.  However, when absent,
it's not always pre-auth.  Need to use RFC3580 behavior.

Comment: Asks about key cache lifetime?

Answer (Bernard A): Thinks that 802.11i drives the lifetime based on the
session-timeout value.

Comment (Dorothy S): Validates Bernard's assertion; states that work on
wireless attributes is good to clear up gaps of understanding.

Bernard asks how to work with other standards groups on open
questions/issues.  

Comment (Dorothy S): Responds that groups should work with liaison
representatives by generating lists of questions/issues.

Comment (Dan R): Points out that the discussion a number of times this
morning has been topics out of scope of RADEXT, e.g. data format for
Diameter's filter rule, 802.11i discussion.  Dan feels we need figure
out how not to talk about issues that other groups need to resolve.

Comment (Pat C): Looked at RFC 3780. Accounting is not required to go to
same server as Authentication.

Comment (Bernard A): If you want state, you setup a server that keeps
state that both Authentication and Accounting talk to.

Comment (Pat C): Does this presume a common backend?

Answer (Bernard A): Yes.

Bernard presented the SSID attribute.


6. RADIUS Attribute Design Guidelines (Dave N. for Greg W.)

Dave presented an overview of document.

Dave presented the open issues.

Comment (Glen Z): Wondering why use by an independent SDO is an issue.
Glen asserts that most SDOs are just looking for IANA code-point
numbers.  This could be solved by giving blanket permission.  Neither
Dave nor Glen believe this is good practice.

Dave presented RADIUS attribute guidelines (section 7 of the draft).

Comment (Glen Z):  Believes all problems have been solved over the
years.  Dave asks in which documents problems have been solved. Glenn
feels that problems should be solved just once, if there are existing
solutions elsewhere, they should be deprecated.  There should be only
one solution.

Comment (Dan R):  Questions whether this document is to be a BCP.  Dave
says yes, that is the plan.

Comment (Dan R):  Says same problem happened with MIBs.  The felling
there was that a guidelines document would make it easier for new people
to ramp up on standards development.

Comment (Glen Z):  Asserts that solutions exist in a protocol called
Diameter.  He points out that most of the problems in design guidelines
were fundamental problems addressed in Diameter.  Sees no need to
re-solve problems that have already been solved once.

Comment (Bernard A):  Points out that the guidelines document should
strictly be about BCP, not defining new extensions to RADIUS.  

Dave describes examples of where several new document rely on complex
data structures, such as GEOPRIV, where having design guideline document
would be (have been) beneficial. 

Dave opens up discussion to group on how to move forward.

Comment (Bernard A):  Points out that design guidelines document has
taken on two hard problems, BCP and designing new RADIUS protocol
extensions (i.e. extended attributes), that will make it difficult to
make progress.  He suggests that problems be split up into two
individual documents.  

Comment (Glen Z):  Agrees with Bernard's suggestion to split up
document.  Having a BCP would be beneficial.

Comment (Hannes T):  Says that time is of essence for this document as
SDOs continue to make progress and they may use non-optimal designs. 

Dave asks group to consider the suggestion to remove any references to
extended attributes. Extended attributes would be treated in separate
effort.

There seems to be rough consensus in the room. We will confirm this
direction on the WG mailing list. 

7. RADIUS Attribute Space Exhaustion (Bernard)

Bernard presented summary of RADIUS attribute exhaustion issues.

Bernard presented possible outcomes of the discussion.

Bernard opened up the discussion to floor to discuss whether solution is
desired, where work should be performed, and whether there any other
problems to solve.

Comment (Pat C):  Believes that RADIUS should not be used for new
applications, but extensions should be allowed for existing
applications.  Doesn't care whether RADEXT tackles problem.

Comment (Dave N):  Believes the problem should be solved.  Believes that
SDOs and implementers will continue to use RADIUS even if IETF stops
work on it.  Believes that the attribute exhaustion solution work should
be done in RADEXT.  Unsure whether there are any additional problems
that need work.  

Comment (Dave N):  Puts out radical suggestion of reclaiming blocks of
reserved but ill-defined attribute code-points, such as the experimental
or implementation-specific blocks.  Bernard says it needs to be
investigated.

Comment (Glen Z): Says that problems have already been solved (i.e.
Diameter).  He's OK with solving problem, again.  However, does not feel
RADIUS attribute space should be extended.  Feels RADEXT is the right
place to do the work, if other solutions are thrown out. 

Comment: Believes that attribute space should be extended, RADEXT is the
right place, and does believe extended attributes is the only problem.

Comment (Glen Z): Disagrees with Dave N. The IETF has more power to stop
people from doing work than we think we do.  The SDOs use the IETF to
talk to each other and standardize interoperation. If there is no RFC,
this will challenge them.

Comment: (Pasi E): Repeats Glen's claim that problem has already been
solved. However, feels usage of vendor-specific attributes offers an
infinite space.

Comment: Points out that allowing on certain applications to use RADIUS
and not

Bernard does straw poll of group on three questions:

Is the problem worth solving?

    13 in favor, 6 against

Is RADEXT the right place to do the work?

    18 in favor, 0 against

Should the extended attribute ID space be the only problem to be solved?

    6 in favor, 3 against

We will confirm this rough consensus on the WG mailing list.

Bernard recaps existing proposals.


8. Extended RADIUS Attributes (Bernard A. for Barney W.)

Bernard presented the motivation for this work. 

Bernard presented usage of Diameter AVP format as the extended RADIUS
Attribute format.

Bernard opens up to the floor for comments.

Comment (Glen Z): Mapping Diameter AVP formats in RADIUS brings up the
RADIUS PDU length problems.

Comment (Dave M): Yes, maybe it is a bad idea in general.  But it may
work for some things.  I think we should start saying things like "This
feature is limited, and if that's a problem, use something else, i.e.
Diameter".

Comment (Dave M): I like the characterization of the issues.  This
provides a good basis for tradeoffs.  We need to make decisions and
perhaps say we don't do some of it.

Comment (Dave N): This draft is proposing solutions rather than just
hand-waving.  Asserts that the backbone of RADEXT will be tested on
whether to address these problems.

Comment (Glen Z): Points out that entire network will have to be
upgraded to support Barney's draft.  Questions why it would be easier to
force a RADIUS forklift upgrade than going to Diameter.

Comment (Dave N): Asks for opinions from RADIUS server vendors.
Questions what server vendor will support all functionality.

Comment (Bernard A): Points out the fundamental change this draft would
have to the RADIUS data-dictionary.  We'd be nearly 75% of the way to
Diameter if this draft is approved.

Comment (Yoshiro O):  Believes RADIUS should remain simple and not take
on Diameter like parsing.

Comment (Joe S): Re-iterates that this draft takes RADIUS nearly all the
way to Diameter.  Agrees with Glen that this is not good.  

Comment (Glen Z): It's still possible to do some grouping using tags.

Comment (Dave N): Asks the group whether group feels that the RADIUS
tagging mechanism is sufficient for all attribute grouping?

Bernard does straw poll:

How many people favor addressing extended attributes using limited
solution proposed by Lior?

    8 in favor, 1 against

This seems to be a solid consensus of the room.  We'll verify this on
the WG mailing list.


9. Issues & Fixes (Bernard for Alan DeKok)

Bernard presented a summary.

Not much discussion.  We need to get more people to read the draft and
comment on the list.


10. RADIUS Attribute for Management Authorization (Dave N.)

Dave presented the background and motivation.

Dave presented current attribute proposals.

Dave asks group whether document is ready for adoption as a WG work
item?

Bernard asks how many people have read document?

  One person in the room has.

The obvious outcome is that additional people need to read document and
comment on the list.


11. GEOPRIV (Hannes T.)

Hannes described the status of GEOPRIV work.

Many changes between the current and previous version.  Open issue on
encoding of location attributes, split complex attributes into two,
wrong references corrected and lot of cleanup work.

Bernard asks how work should progress towards completion, given it's
been around so long.  Decided that next step is that when document goes
last call in GEOPRIV that RADEXT should also review document from a last
call perspective.  Bernard suggests that RADEXT group submit issues
prior to GEOPRIV last call.


12. ISMS WG requirements for RADIUS (Dave N.)

Dave described motivation for Authorize Only operations.

Dave described motivation for an Asserted Identity.

Comment (Hannes T): ISMS requirements seem similar to requirements he's
hearing in other groups. Seems similar to the SIP problem.  Should look
at that.

Comment (Dave N): ISMS is interested in RADIUS because it integrates
something people already have.

Comment (Bernard A):  Points out that the document is making a leap by
integrating technologies like Kerberos and RADIUS.  Questions how these
technologies will be re-conciliated.  

Answer (Dave N):  Responds that Jeff H. (Kerberos WG Chair) believes
that authentication and authorization services should be split.  In his
mind, the authentication and authorization services are/should be
decoupled and independent.  

Comment (Bernard A): Curious to hear whether the security considerations
hve been investigated thoroughly.

Comment (Bernard A):  Points out that ISMS requirements seem to violate
basic key distribution principles, feels it's very ad-hoc, and changes
Kerberos in a fundamental way. Kerberos tickets are bound to
capabilities. Bernard would like agreement from the Kerberos WG before
ratifying such a fundamental change.

Comment (Dave N): This comes from specific deployment requirements in
ISMS, and this situation is not an integration of Kerberos and RADIUS.

Comment: Kerberos does have optional authorization fields, some may be
used or not.  This should be looked at carefully.  Don't know if anyone
does that....

Comment (Joe S): Agrees that additional thought is necessary.

Comment (Hannes T): Questions the viability of splitting authentication
and authorization services, given that most technologies bind
authentication and authorization together.  SAML has similar mechanisms.

Comment (Dave N): Will take this feedback to ISMS WG and see how they
wish to proceed.


13. Wrap-up/final comments

Comment (Glen Z): Would like the crypto-agility work item to be
clarified. What is the problem, the issues, etc.?   The WG should decide
to make this into a formal work item, if that is deemed necessary.

Answer (Dave N): It is already a WG milestone, but we should look at
whether charter language, scope, etc. also needs revision.

End of the meeting.


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