[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IETF-63 Proceedings Submission
IETF-63 RADEXT WG Minutes
Scribes: Paul Congdon, Greg Weber (Editor: Dave Nelson)
No jabberer. (Later Hannes Tschofenig joined the jabber room.)
Bluesheets started.
No agenda changes requested.
Presentations and agenda online at:
http://www.drizzle.com/~aboba/IETF63/radext/
RADEXT Issues Tracker location:
http://www.drizzle.com/~aboba/RADEXT
Streaming audio archive location:
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf63/ietf63-ch5-we
d.mp3.1 [start time index: 20:34]
Brief status of WG work items:
- 2684bis in AD follow-up
- Dynauth MIBs completed WGLC, 9 issues
- CUI in AD follow-up
- Digest Auth completed WGLC, 5 issues
- 802 Extensions in WGLC, 3 issues (so far)
Presentations:
- RFC2684 bis presented by Jari Arkko.
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-06.txt
Problem with internationalization found in IESG review. Added
clarifying text for ABNF vs. document text requirements and the use of
UTF-8 vs. IDN-unware ASCII for the realm part. Revision back to IESG
for approval -- very soon, e.g. about a week. Realm strings will be
IDN unaware (no "!").
- Chargeable User Identity presented by Avi Lior.
http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id
-03.txt
All issues have been addressed in the current version of the document.
Several SDOs are interested in this draft - WiMAX is one who will be
submitting a liaison letter to IETF for this. Pasi Eronen clarifies
that this document is in AD evaluation stage and not at the IESG.
Bernard may need to update the web-site to indicate the appropriate
document status. ID Tracker from IETF homepage is definitive on status.
- Digest Authentication update by Wolfgang Beck.
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-03.txt
Diameter compatibility is the current main issue with the document.
There is also an issue regarding client-side nonce generation when
interoperating with Diameter - additional text will be added to address
this. We could move forward two ways; one it get client side nonce
generation added to diameter, or simply drop this. The 3GPP2 liaison
would like to see client side nonce generation remain because they
currently use it. Avi Lior recommends that we operate in both modes of
operation and when working with Diameter, and get Diameter to update to
support client side nonce generation. The 3GPP2 people are waiting for
an RFC number on this document so they can publish their spec. The
security considerations need to be updated to discuss what to do when
realm check fails. There were also some typos that will be corrected.
Desire to get -04 version out shortly after IETF-63.
- Dynamic Authorization MIBs - Greg Weber speaking for authors who could
not attend.
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib
-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib
-01.txt
These MIBs are companions to RFC 3576. They are expected to be
completed by the end of the year. Issues 96/97 have been resolved and
are simply editorial in nature. Issue 105 resolution relates to where
the MIBs are to be located in the OID tree. It is believed that new
MIBs should be rooted off of mib-2 and the authors are willing to make
the change to support this. Issue 92 is the most controversial. A few
new terms are defined by this document; DAC and DAS. It was suggested
to match RFC 3576 and not introduce new terms in MIB, however the terms
are embedded in all of the object names. It is still the belief of the
WG that the terms should be consistent and it sounds as though the
object names will be globally searched and replaced. Bernard Aboba: RFC
3576bis would be within WG charter, and we could address the terminology
issues there. That would mean either delaying the MIBs or revising them
later.
- 802 Extensions draft presented by Paul Congdon.
http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-00.txt
Discussed recent changes, but not current issue status. Changes include
removal of controversial (Diameter-like) extended attribute types, no
new data-types or M-bit, fleshed out the NAS-Filter-Rule, can now
specify L2 encapsulations, removed IP-redirection rule type in favor of
tunneling. Among the interested parties are TNC of TCG, 3GPP, WiMAX
(hot-lining). Glen Zorn questioned the chairs on why this document was
so quickly moved to last call. The chairs believe that the previous
issues in the individual submissions were sufficiently resolved and
there being a number of SDOs waiting on this document see the need to
expedite the review and closure of this document. WG last call closes
on Aug 10th. There was a question regarding when the wireless
attributes would be documented. There is a -00 draft on WLAN attributes
to be discussed on this later in the meeting.
- RADIUS IPv6 MIBs discussed by Dave Nelson.
http://www.ietf.org/internet-drafts/draft-nelson-rfc2618bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2619bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2620bis-01.txt
http://www.ietf.org/internet-drafts/draft-nelson-rfc2621bis-01.txt
New textual conventions for address objects have been included. Review
comments from the MIB Doctors have been resolved in the -01 revisions.
The drafts UPDATE their predecessor RFCs, deprecate old tables (not
doing table augmenting anymore), added new tables to mirror old ones,
added specific usage guidelines new IP address objects. The question of
whether these should be WG work items was posed and no objections were
heard. The RADEXT -00 drafts will be created and moved to WG last call.
- Common Radius Implementation Issues and Fixes presented by Dave
Nelson.
http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-00.txt
The document was created based upon a long laundry list of issues that
have been discussed on the mailing list. This document identifies many
of the problems identified in the field and makes suggestions to resolve
the problems. Areas discussed include:
- Proper use of the state attribute
- Request ID supplementation alternative
- Re-transmit schemes
- How to handle overload conditions
- Clarification of accounting attribute updates
- Clarification of using multiple Filter-ID attributes
- Treating access-accept for unknown services as a reject
- Avoiding sending VSAs to a NAS that doesn't understand them
A question about this recommendation is how to reliably detect supported
vs. unsupported VSAs. The capabilities attribute is a possible
solution. Glen Zorn suggested the possibility of a version number.
Since this is just -00, it was suggested to post issues against the
document. It was noted that some issues were currently in the tracker
but not yet included in the draft.
- Corrections to RFC 2869, section 2.2 regarding miss-stated
Access-Challenge.
- Handling multiple services
- Defining how to calculate Message-Authenticator for Disconnect, COA
and others
- Authorize only discussion
There were some questions of how this document should progress. The
document is useful, but perhaps an RFC 3576bis additionally needs to be
created. Also, some of the issues are against earlier RFCs as well.
These are standards track and may be more difficult to update. This
document is intended to address existing and past issues. Another
forward looking document discusses future issues. Other issues not
addressed were NASes with multiple IP addresses and accounting interval
updates. These should be included and consensus on a solution for these
needs to be proposed.
- RADIUS Attribute Design Guidelines presented by Greg Weber.
http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-0
0.txt
This is a forwarding looking document addressing design recommendations
for new attributes. This document describes what is considered a good
attribute design and reviews the current RADIUS data types, as well as
the divergence in the Standard and Vendor Specific data models. A few
have reviewed this document so far. The current document does include
some recommendations, but these are straw-man recommendations. The
motivation for this document is to get better alignment with data models
in vendor attributes, address attribute space exhaustion and align
better with diameter. The scope of the document includes consideration
for backward compatibility, existing VSAs, supporting the existing
transport, non-AAA applications and Diameter compatibility. The document
straw-man proposes a single standards base format for VSAs as a
recommendation. The document also includes recommendations on when
particular formats should be used and when to use existing VSA format
verse the new one. Lots to do on this draft. Avi Lior agrees this
document is a good starting point and is willing to work on the draft.
There was a question whether SDOs should be differentiated from Vendors,
but the group doesn't believe so. There was a question whether IANA
considerations are included, but the authors believe this is already
spelled out elsewhere. Glen Zorn asks if it was considered to extend
the size of RADIUS attributes rather than dealing with fragmentation.
Greg Weber did not consider this because he felt it would be beyond the
scope of the charter.
- WLAN Attributes presented by Jari Arkko.
http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-00.txt
The list of attributes that were removed from the 802 Extensions draft
was presented. There is some overlap that needs to be discussed.
[Technical difficulties with slides caused us to move forward to the
next topic.] Upon return, some relationships to the EAP keying draft
were described. A list of key management attributes were described and
the issues. Privacy can be addressed similar to NAI and by omitting
Peer-ID and Server-ID attributes. Key-wrap options were described as
three choices; AES key wrap, a Key Encryption Key (Zorn draft) or IPSec.
The later is not used in industry. The key-wrap options may be
difficult to resolve. The questions on this document are whether this
should be a WG item and how to solve the privacy and key-wrap problems.
- RADIUS attributes for Cryptographic Keys presented by Glen Zorn.
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-07.txt
The motivation for this draft was to allow RADIUS to be used in certain
government environments. While RADIUS isn't a key provisioning
protocol, there are keys that are passed around in RADIUS and perhaps
aren't wrapped securely enough. Several editorial changes were made in
the -07 revision, but also HMAC-MD5 was removed and other key transport
attributes (e.g. MPPE-xxx) were outlawed if the same data is also
transferred in the new attributes. Questions about how keys are
transferred to the client - hop-by-hop or end-to-end? They are passed
along the path in the way they are set-up - may be hop-by-hop. Glen
plans to add AES-CMAC and some other technical changes in the -08
revision.
- General WG discussion on key-wrap issues.
Glen Zorn points out that the keying issue is not just an 802.11 or
Wireless problem. Also, Glen believes that IPSec is inappropriate as a
protection mechanism for an application level protocol. Glen believes
that NIST is in agreement that IPSec is not appropriate for this use.
Nancy Cam-Winget from Cisco summarized the NIST meeting that took place
back at the end of June. She also agrees that it isn't just wireless
that needs the keying solutions. They wanted to know if a new key-wrap
attribute with a new algorithm would be sufficient or would IPSec work.
Nancy believes that the latest draft of the Zorn document has all the
changes included based upon the NIST discussion. Nancy believes that
NIST's reaction to the use of IPSec to protect RADIUS key distribution
was that it would require further review by NIST. Jari Arkko also
believes the key work isn't just for wireless and would like to see it
in a separate draft from other WLAN attributes. There was a question
about the relationship to the Zorn document and the Aboba document? We
do have keying attributes for WLAN as a charter item for this group, but
can't introduce new security mechanisms. Bernard's document comes from
the EAP key framework perspective. A question about a new message
authenticator algorithm and attribute being described by Glen. It can
be used in any RADIUS message because it is independent of the
authenticator value in the RADIUS message. Message-Authenticator cannot
be used in Accounting-Request or CoA messages. The new one is
cryptographically stronger; the old one is not FIPS compliant (MD5).
The new attribute can be used as a complete replacement of the old style
message authenticator. Alternatively, the old message authenticator
could still be used. Bernard's draft reuses the RADIUS shared secret,
while Glen's draft assumes a cryptographically separate pre-shared key.
Bill Burr cautions that NIST is not looking very closely at RADIUS usage
and so there isn't a good view of what is being done here. He
characterized the existing wireless key distribution mechanism (i.e. as
used in 802.11i with RADIUS) as somewhat "Rube Goldberg". Bill
described the process of obtaining a FIPS-140 certification and how
painful it may be for vendors. Glen points out that there is a lot of
interest in solving this problem and it has been solved, so why is there
a new WLAN draft addressing the keying mechanisms? Dave Nelson (Chair)
indicated that the keying problem seems to have a lot of interest. The
WG might consider amending its charter (security mechanism restriction)
to address this issue, if needed.
[Ed. Note: Only the statements of Bill Burr should be considered as the
position of NIST. Other statements are the opinion of the speaker.]
- End-to-End capability exchange presented by Avi Lior.
http://www.ietf.org/internet-drafts/draft-lior-radext-end-to-end-caps-01
.txt
The proposal describes an end-to-end, per-session mechanism to negotiate
capabilities. The attribute contains a string of octets where each
capability is encoded in 2 bits that define, not-supported, supported
and required. Avi points out other documents need this work; location
in the GEOPRIV WG, VLAN, priority and filtering, CUI and prepaid could
all use this. Should it be a WG document? No one objects to making
this a WG item, but we will confirm this on the list. This document
should be in alignment with Greg's work on Design Guidelines if we are
defining a new data type.
- RADIUS Prepaid attributes presented by Avi Lior.
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions
-08.txt
The document was re-organized for read-ability and updated. Flow based
prepaid is becoming a requirement. Requested by 3GPP2 and WiMAX. The
difference between RADIUS credit control (a.k.a. prepaid) and Diameter
credit control was described. It is believed that some of the
differences are regarding some features that may compromise the privacy
of the client (e.g. balance check and cost inquiry). Other differences
are not clear yet and need to be discussed. How can Diameter credit
control and RADIUS prepaid be translated? The recommendation is that
the server must do this itself. A recommendation from the audience was
to have scenarios documented or analyzed - not necessarily included in
the draft, but available. Different SDOs are using Diameter and RADIUS,
and there will likely be some issues related to translation. Resolution
of these issues may require assistance from 3GPP, 3GPP2 and WiMAX, as
the RADEXT WG didn't anticipate supporting different "dialects" of the
prepaid extensions. The authors believe the document is ready to become
a WG item. Since the authors are not in complete alignment it was
suggested that they hash out their problems before making it a WG
document. The authors believe they have enough alignment, but being
out of time, we will continue the discussion on the WG mailing list.
- RADIUS Bandwidth attributes presented by Avi Lior.
http://www.ietf.org/internet-drafts/draft-lior-radius-bandwidth-capabili
ty-01.txt
Issues from Bernard Aboba's extensive review have all been addressed,
except one which is related to the length of the attribute size. Should
this be a WG document? Discuss on the WG mailing list.
- RADIUS QoS attributes presented by Hannes Tschofenig.
http://www.ietf.org/internet-drafts/draft-tschofenig-radext-qos-01.txt
Hannes describes a more general QoS environment. This work is related
to the Diameter work. They are addressing a generic description
described in NSIS QSPEC work. As compared to Avi Lior's bandwidth
document, this is a more heavy weight description. Avi's document is
viewed as a short term solution. There is the question of charter scope
in RADEXT.
- General WG Discussion about QoS and Bandwidth.
Allison Mankin (Transport AD) points out that we shouldn't use RADIUS as
a resource management protocol. She believes that RSVP and NSIS are the
protocols to do resource allocation. There was an RSVP and Diameter
document that is similar to proposed RADIUS document. John Loughney
comments that the Diameter QoS document is an individual submission and
not a current AAA WG document. John will post the link to the RADEXT WG
mailing list for this document, so that we can review it. Allison
mentions that we don't want to start extending the bandwidth draft to
include a bunch of new things like latency and jitter, but they are
happy with simple rates that are currently defined. Combining Avi's
bandwidth draft and Hannes' QoS draft would certainly delay the simple
bandwidth parameter attribute that has been requested by other SDOs. A
comment from 3GPP is that they are depending upon the bandwidth draft to
be complete for reference in their specification release 7, by mid-2006.
The group doesn't believe they should be combined. Dave Nelson (Chair)
asked what the overlap is between the documents. Avi points out that
the QoS "blob" includes a bandwidth component and could be used, but
John Loughney and the other authors believe there may be a solution on
how cross reference the documents and avoid overlap. Dave (Chair)
indicated he would work to facilitate the cross-WG and cross-Area
coordination that will be required to move forward in this area.
--
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/>