IETF-64 RADEXT WG Agenda
Tuesday, November 8, 2005
0900-1130 Salon F
ADMINISTRATIVE
--------------
Chairs: Bernard Aboba
David Nelson
Scribes: Pasi Eronen and Jari Arkko
Jabber scribe: John Loughney
Open Issue Summary:
http://www.drizzle.com/~aboba/RADEXT/
Presentations and agenda online at:
http://www.drizzle.com/~aboba/IETF64/radext/
Dave Mitton: Do you have enough bandwidth on your server?
Bernard Aboba: Yes.
1. Preliminaries
- Bluesheets
- Agenda Bash
2. Document Status
- 2486bis, CUI are in RFC editor queue
- IETFLC completed on radius digest authentication
- Completed WGLC, awaiting issue resolution: VLAN/Priority.
- In WGLC: RADIUS IPv6 MIBs, RFC 3576 MIBs
- Pre-work item review: issues & fixes, design guidelines
Discussion on the need for at least four people to review documents
(in addition to authors). David reminds that a lack of comments
means the document needs extra careful review from the AD, and it's
difficult to determine whether the document is useful for anyone
(if nobody bothers to read the document in the WG, why should the
AD spend time on it?). Hannes to suggest that WGLCs not be arranged
at the same time as IETF meetings.
WORK ITEMS IN IETF Last Call (30 minutes)
-----------------------------------------
3. Digest Authentication, Wolfgang Beck (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-06.txt
There has been a discussion of the security of the RADIUS transaction
from SIP to AAA. Parts of the SIP messages are revealed over
RADIUS as-is. Should there be a mandate to use encryption if the user
uses TLS or SIPS?
Glen Zorn worries that MPLS is listed along with security methods in
the slide. But Wolfgang put it there just because someone had
mentioned it.
Hannes Tschofenig is not convinced that this usage of RADIUS is any
different than others. Should be enough with the use of local methods
or IPsec VPNs, etc. This is what Wolfgang's resolution suggests, and
failing if this can not be done. Miguel Garcia worries that the RADIUS
server does not know whether it is running IPsec or not. The SIPS URI
implies that all communications should be protected hop-by-hop at
least by TLS or equivalent. There's no mechanism to tell the SIP user
that we can not provide the requested security.
Bernard: is there an objection to the resolution?
Miguel: No.
Discussion on the AAA WG mailing list is also affecting this draft.
For instance, is Digest-Username attribute redundant? The proposal for
this issue is that the draft will not be changed.
4. Diameter SIP Application, Miguel Garcia (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-10.txt
We are discussing this draft here due to the lack of a AAA WG
meeting. Status of the draft is that it has passed three WGLCs.
New issues were brought up after WGLC. There's an issue with CX and
Diameter SIP application alignment. There are some incompatibilities
that are being looked at.
Issue 49 - required authentication parameters. There are possible
optimizations, raised by the 3GPP folks. Proposal is to make
Digest-Nonce AVP optional in SIP-Authenticate AVP, make Digest-URI
and Digest-Response AVP optional in the SIP-authorization AVP, make
Digest-Nextnonce AVP optional in the SIP-Authentication-Info AVP.
Issue 50 - User-DATA AVP in Push-Profile-Request (PPR) command.
This is also about alignment with CX. Proposal is to make User-Data
AVP optional because it is possible that only the accounting
information but not user data changes. Glen Zorn asks why this
command is used just for accounting information. Miguel says that
this command can also be used to update the URIs related to
accounting. These URIs are not a part of the profile data object
due to historical resons.
Issue 51 - Result-Code AVP. The worry is that formats are not open
to extension because all commands mandate Auth-Application-ID
AVP. But this is what standard Diameter applications should do.
Proposal is to do nothing.
Issue 53 - MAR processing. Miguel needs to take a deeper look at
this. The issue relates to the Authentication flag in the MAA/MAR
commands. It looks like the flag must be cleared when processing the
SAR/SAA commands instead, not in MAA/MAR.
Issue 54 - Syntax issues in the Auth-Application-ID. Seems like an
editorial error.
John Loughney, co-chair of AAA, says that the ADs are worried about
late comments after WGLC. But the draft will go to IETF LC, and the
open issues are taken as IETF LC issues.
Glen Zorn: I am still confused. I thought that IETF LC comments go
to the IETF discussion list, not to some database in control of the
chairs. John Loughney: What is being suggested is that if there are
issues, submit them to the ietf or aaa mailing lists or both. The
WG will consider whether it will be fixed or not. Glen Zorn: OK.
Bert Wijnen (AD): after three WGLCs, people should not come up
with more issues.
WORK ITEMS COMPLETING WG LAST CALL (30 minutes)
-----------------------------------------------
5. Dynamic Authorization MIBs, Greg Weber (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-02.txt
These are in WGLC, to end on Nov 14th.
Issues 92, 96, 97, 105 resolved in -02. New issue 137 received.
Someone asks about the security considerations of counters: although
the information is going only to the SNMP manager, the security
considerations section might mention that some people would consider
this information sensitive.
Bernard: Are these MIBs being implemented? Greg: At least one vendor
is implementing them.
6. RADIUS IPv6 MIBs, Dave Nelson (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt
Bernard Aboba presents this on Dave's behalf. There has been a MIB
Doctor review. New revision has been produced based on this. No
comments received to date -- please review and comment as
soon as possible. Drafts are in WGLC.
Changes in -01 are very similar for all four drafts. All known
issues have been addressed. Based on issue 135, new RFCs must
obsolete the base RFCs.
7. VLAN/Priority, Paul Congdon (15 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt
Paul indicates that one should never change ones domain password one
hour before taking a trip, or if one does, it would be useful to
write the password down.
There is no new draft, too many unresolved issues. A few issues are
closed and there's progress on others; discussion is still required
on many.
Issue 110 - compliance and coherence. Hard to define conformance
when the draft defines attributes for many different types of
devices. Should we split the draft?
Dave Nelson: It may be more convenient to split the document and
claim conformance per document, but this would create more documents.
Dave Nelson: IP redirect will break things.
Bernard: IP redirect is no longer in the document, only HTTP.
Issue 102 - Pasi's issue with many subissues. Relates to parsing
Tunnel-Assignment-ID and issues in NAS-Filter-Rule definition.
Escape characters may be needed.
Issue 113 - Confusion on how to concatenate multiple filter
attributes. Issues with Diameter filter rule syntax usage. Three
potential ways to go forward (see slides), including dropping the
functionality. Hannes: I was wondering how this relates to the other
documents, such as the bandwidth document.
Bernard: This is mainly priority marking, but there is overlap
with the metering part and the bandwidth draft.
Jari: sounds like there are technical issues and lack of requirements and
no implementations. Sounds like we should drop it.
John: Or alternatively break it out and put it in the
qos document.
Paul: I'm ok with dropping it, it allows the uncontroversial
parts to proceed faster.
Issue 130 - Diameter compatibility. Major discussion on whether to
retain Diameter compatibility or not. Jari Arkko believes that this
is very much necessary, and Glen Zorn believes it should be
ignored. David Mitton comments that if we need new functionality, we
need to develop that. Jari points out that new functionality and
superset of the Diameter format is fine. Just that we'd like to
see one format going forward, rather than several.
We will bring this issue to the list.
Other issues -- see slides.
PRE-WORK ITEM REVIEW (30 minutes)
---------------------------------
8. Common Radius Implementation Issues and Suggested Fixes, Bernard
Aboba (10 minutes)
http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-01.txt
(No discussion)
9. Design Guidelines, Greg Weber (10 minutes)
http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-01.txt
Question about the possibility to allocate vendor-specific
values in standard attributes. This would require a RFC 3575
(RADIUS IANA policy) revision.
Fragmentation of data. Is there a simpler method than attribute
flagging?
Other issues - look at the slides.
Is this a reasonable starting point for a working group item?
Volunteers for this work? How many people have even read it?
(six hands)
John: Channeling Jabber - 2-4 people have spoken in favor of
this draft.
David Kessens (AD): Need to be strict here. Milestones are
slipping. More discussion is needed before adding new work.
General topic, not related to this draft.
10. RADIUS/Diameter VSA Translation, David Mitton (10 minutes)
http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-00.txt
Generally Diameter is upwards compatible with RADIUS. There are
exceptions, however, such as RADIUS Vendor-Specific attributes.
Draft analyses the problem with the VSAs, and suggests a method
to overcome the problems. Problems include long attributes.
Glen: I cannot send down a 25K blob via RADIUS. Can you really
maintain any kind of actual data integrity over the transformation
without constraining Diameter, which would be a bad thing.
Diameter server can be told that the message to which it responds
is coming through RADIUS. To respond correctly, however, it
would need two sets of attributes.
Someone: Is this a real case?
Glen: I know people who would send attributes of 20-40K. But
this approach would still work for some upper limit.
Paul Congdon: Length is just one issue. This is a slippery slope,
e.g. not sure if we have any way of doing mandatory bits.
David Nelson: Sees a RADIUS->Diameter requirement but
not necessarily a Diameter->RADIUS requirement.
John Loughney: AAA WG shutting down, but a Diameter maintenance
WG might be started up.
Shof Lee (?): Can a vendor hop on Diameter immediately or should it
use RADIUS or RADIUS with extensions.
Bernard: We recommend that the vendors attempt to satisfy the needs
of their customers.
David Mitton: I'm here not to extend RADIUS, but to move people to
Diameter.
Glen Zorn: There's an actual way to do this.
Bernard: Bring this to the list. Let's not try to solve it here.
Glen will send text.
WORK ITEMS IN OTHER WGs (40 minutes)
------------------------------------
11. RADIUS Support for Delegation, Ralph Droms (5 minutes)
http://www.ietf.org/internet-drafts/draft-salowey-radext-delegated-prefix-01.txt
http://www.ietf.org/rfc/rfc3633.txt
http://www.ietf.org/rfc/rfc3162.txt
Scenario is assignment of IPv6 prefixes from ISP devices
to CPE. Assignment of prefix to a customer is left to the
implementation. One solution is to associate a prefix
with the user via RADIUS. RFC 3162 defines the
Framed-IPv6-Prefix attribute, and RFC 3633 suggests that
this attribute be used for prefix delegation.
However, what happens if the ISP wants to assign one
prefix to the CPE, and another prefix for prefix-delegation?
The same Framed-IPv6-Prefix attribute can't be used for
both purposes; this is overloading. The draft suggests
a new attribute be sent from the AAA server to the NAS
for delegation.
Bernard: Is this new document redefining the
Framed-IPv6-Prefix attribute? The original intent was
that this attribute would include prefixes to be announced
via RS/RA? Is that still the behavior that is desired?
What behavior is implied if a prefix larger than /64 is
assigned? Does anything more granular than a /64 make sense?
One approach would be to update RFC 3162, with the
new attribute as well as explaining what the other
existing attributes actually mean.
We will get a draft together as this is urgent. ("We"
means the draft authors as well as RFC 3162 authors.)
Pasi and Hannes suggest that if delegation is urgent, it
might be easier to go individual instead of working group item,
especially since the draft is simple and doesn't need extensive
review.
12. ISMS Requirements, David Harrington (5 minutes)
The following mechanisms are popular for securing CLI according
to a NANOG survey:
66% local accounts
49% SSH
40% RADIUS
29% TACACS+
SNMPv3 requires authentication. USM is an SNMPv3 security
model that employs local account authentication, and ISMS
is in the process of using SSH to do this.
No current AAA attributes are suitable for use with SNMP access
control. Draft-nelson-radius-management-authorization is very much in
line with the needs of the network management comunity. We'd like to
see this work not just for SNMPv3, but also CLI.
There's a need to have the AAA map an authenticated user to a named
policy. The mapping of policy names to policy implementation should
be left to the management protocols. ISMS would like RADIUS experts
to do the AAA parts, but the secure shell model is not sufficiently
mature yet to have exact AAA requirements.
Hannes Tschofenig would like to see a more complicated approach
to authorization than the delivery of a policy name.
Discussion moved to the list due to lack of time.
13. Management Authorization, Greg Weber (5 minutes)
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-02.txt
Adds new value to Service-Type (Framed-Management). Provides new
attributes to indicate the type of protocol (e.g. SNMPv3, HTTP,
SSH), management policy ID, etc.
How to progress? Is there a need for a formal request from ISMS?
ISMS and RADEXT will figure it out. One way is for the ISMS to say
we want this particular draft.
14. RADIUS/MIPv4 Extensions, Madjid Nakhjiri (5 minutes)
http://www.watersprings.org/pub/id/draft-nakhjiri-radius-mip4-02.txt
Adds RADIUS support for Mobile IPv4. Becoming a MIP4 WG work
item. Possibly comes for review also in RADEXT later.
Diameter spec for Mobile IP already defined in RFC 4004.
Draft defines attributes and procedures for RADIUS,
and includes Diameter translation.
For RADEXT, issues include status of the key wrap status
and guidance on Diameter-RADIUS translation.
15. RADIUS/GEOPRIV, Hannes Tschofenig (5 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-04.txt
Capability exchange was the main sticking point. Now people have
come to a conclusion how this can be handled. Emile Van Bergen
has prepared slides describing the solution.
Discussion appears to have converged on the Supported-Location approach.
The remaining issue is how to deal with the Challenge problem.
Jari, Bernard: this part may need some more thinking/review.
Allison: so we are past the impasse that we had on the capability part.
Bernard: Yes.
Post challenge issue to the list and discuss.
Glen: I would like to work on the general capability problem.
Hannes: Not sure we want to wait for another document.
Dave Nelson via Jabber: Does not understand the trust model.
RADIUS security is hop-by-hop. Why does GEOPRIV need to be told
by the RADIUS server when it can send the location information?
Hannes: Because the AAA user or the end user wants to control
how the location data is revealed. Dave
Nelson: But proxy servers can lie.
Hannes: True. But this is the assumption is in the document, the
AAA infrastructure needs to be trusted.
Last comment from Dave: We can't change the way RADIUS works.
But is the way that it works suitable for GEOPRIV? Discussion
to be taken to the list.
16. RADIUS Capabilities Problem Statement, Alan DeKok (10 minutes)
Goal is to esbtalish a framework, terminology for capabilities.
Rigorous approach. Mathematical approach makes it possible to be
exact. Need to establish WG opinion on the assumptions and approach.
Hannes Tschofenig is not sure if a simple problem needs to be
turned into a complex one. Discussion about whether mathematical
notation helps.
Next Steps, ADs & WG Chair (10 minutes)
---------------------------------------
David Kessens, AD, is concerned that we are not meeting charter
milestones. How can we take on more work? Particularly concerned
about progress on the RADIUS design guidelines document. This
document is fundamental, because it provides help for others
doing RADIUS work, and would guide the future of RADIUS. This
would be a step forward.
Hannes Tschofenig: Do you think the issue is bad initial milestone
deadlines, or something else.
Bernard thinks that much of the problem is due to the failure
to progress on the design guidelines.
Bert Wijnen says that existing deadlines are kept while new
work is being taken on board. Would be good to adjust deadlines.
Glen Zorn thinks that the charter and milestones were articifially
constrained and not a result of a consensus process. The charter
would look different if this had been the result of a consensus
and not a result of management action.
Hannes questions why prepaid is being delayed. Bernard responds
that during chartering, it was agreed that design guidelines
needs to be done first, since prepaid depends on things like
compound attributes.
Paul: Where have these dates on the slide come from?
Bernard: These are the original deadlines from chartering/re-chartering.
David Kessens: Wants to see a realistic plan to produce design
guidelines. If we can see this, no need to put roadblocks on
other documents.
|