[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADIUS-Mobile IP support??: RADEXT WG Charter
RFC3012 based CHAP style authentication for MN-AAA works fine with MIPv4.
3GPP2 is using standard RADIUS attributes such as CHAP-Challenge and
CHAP-password for this purpose. There is a VSA defined for carrying the HA
address, but HoA is carried in the framed-IP address attribute.
For AAA key distribution for Mobile IPv4, I think AAA WG has/had a draft on
this. Not sure what happened to it.
You can visit www.3gpp2.org for the relevant specification (X.S0011-C).
-Kuntal
>-----Original Message-----
>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
>Sent: Tuesday, May 18, 2004 3:42 PM
>To: radiusext@ops.ietf.org
>Subject: RADIUS-Mobile IP support??: RADEXT WG Charter
>
>
>Hi,
>
>I am not sure if it is too late to have anything added to the
>charter and I don't know how much interest for Mobile IP
>exists in the group, but here is a RADIUS-Diameter question anyway:
>
>AAA WG has been working on providing specs and AVPs in
>Diameter for Mobile IP support: specifically on how to
>authenticate the registration requests and replies as well as
>how to do key distribution for establishing security
>associations between mobile nodes and mobility agents. RADIUS
>does not seem to provide anything for that, unless I missed something!
>
>It seems that 3GPP2 is doing its own thing (I personally
>haven't found the specs, so I appreciate it if somebody sends
>it to me). Is the ongoing opinion that people should use VSAs
>for that purpose? or there is just not enough interest for
>Mobile IP within RADIUS community?
>
>Thanks,
>
>Madjid
>
>-----Original Message-----
>From: owner-radiusext@ops.ietf.org
>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Bernard Aboba
>Sent: Thursday, April 15, 2004 6:52 PM
>To: radiusext@ops.ietf.org
>Subject: RADEXT WG Charter, Take 10
>
>
>Just thought I'd post the most recent charter text, so that
>folks could have a last look at it. Based on the previous
>discussion, it did not appear that there was a concensus to
>change the focus to handling both RADIUS & Diameter in a
>single charter.
>
>---------------------------------------------------------------------
>RADIUS Extensions Working Group (RADEXT) Charter
>Last Modified: 2004-04-12
>
>Chair(s):
>David Nelson <dnelson@enterasys.com>
>Bernard Aboba <aboba@internaut.com>
>
>Operations and Management Area Director(s):
>David Kessens <david.kessens@nokia.com>
>Bert Wijnen <bwijnen@lucent.com>
>
>Operations and Management Area Advisor:
>David Kessens <david.kessens@nokia.com>
>
>Technical Advisor:
>Paul Congdon <paul_congdon@hp.com>
>
>Mailing Lists:
>General Discussion: radiusext@ops.ietf.org
>To Subscribe: radiusext-request@ops.ietf.org, In Body: subscribe
>Archive: http://ops.ietf.org/lists/radiusext
>
>Description of Working Group:
>
>The RADIUS Extensions Working Group will focus on extensions
>to the RADIUS protocol required to enable its use in
>applications such as IP telephony and Local Area Network
>authentication, authorization and accounting.
>
>In order to ensure backward compatibility with existing RADIUS
>implementations, as well as compatibility between RADIUS and
>Diameter, the following restrictions are imposed on extensions
>considered by the RADEXT
>WG:
>
>- All RADIUS work MUST be backward compatible with existing
>RADIUS RFCs,
> including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579,
>and 3580.
>- All RADIUS work MUST be compatible with equivalent facilities in
> Diameter.
>- The RADIUS maximum packet size (4K) will not be increased.
>- No new RADIUS transports (e.g. TCP, SCTP) will be defined.
>
>Work Items
>
>The immediate goals of the RADEXT working group are to address
>the following issues:
>
>- RADIUS design guidelines. This document will provide guidelines
> for design of RADIUS attributes, including discussion of the
> appropriate use of RADIUS SDO-Specific Attributes (SSAs). This
> document will also review RADIUS data types and associated
> backwards compatibility issues, and may address common
> RADIUS implementation errors and fixes.
>
>- Revised NAI specification. This document, known as "RFC 2486bis"
> will revise the NAI specification to provide more details on
> routing as well as handling internationalization.
>
>- Pre-paid support. Prepaid services are contemplated in a number
> of potential applications, including wireless LAN access and IP
> telephony. In order to enable support of pre-paid services in an
> interoperable way, the WG will provide definitions of the
> attributes required to support operator service models for
> pre-paid, as documented in liaison communications.
> This document will be compatible with Diameter Credit Control.
>
>- SIP support. RADIUS is currently used for SIP authentication,
> authorization and accounting. Standardization of these attributes
> will enable improved interoperability.
>
>- LAN attributes. New attributes have been proposed to enable use of
> authentication, authorization and accounting in wired and
> wireless LANs. Standardization of these attributes will enable
> improved interoperability.
>
>- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatiblity, and modest
> changes are required to address this issue.
>
>Goals and Milestones:
>
>Dec 04 Updated RADIUS MIBs submitted for publication.
>Dec 04 RADIUS design guidelines submitted as an Informational
>RFC. Dec 04 SIP RADIUS authentication draft submitted as a
>Proposed Standard
> RFC.
>Feb 05 WLAN attributes draft submitted as a Proposed Standard
>RFC. Feb 05 RFC 2486bis submitted as a Proposed Standard. Dec
>05 LAN attributes draft submitted as a Proposed Standard RFC.
>Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC.
>
>Quality Control Plan
>
>In order to ensure quality of work:
>
>* This WG will not be chartered until sufficient resources can be
> demonstrated to be available to guarantee a high probability of
> success. This includes recruitment of a core of editors and
> reviewers with significant IETF experience and demonstrated time
> commitment.
>
>* All drafts will need to undergo review prior to acceptance as WG work
> items, which includes demonstration that the drafts are backward
> compatible with RADIUS RFCs and are compatible with equivalent
> facilities in Diameter. Given the backwards compatibility issues, no
> document including sub-attributes will be considered for
>publication as
> an RFC before the RADIUS design guidelines and RADIUS/Diameter
> translation work items are completed, analyzing the issues in
> a comprehensive way.
>
>* The WG will utilize an automated issue tracking system.
>
>* XML to RFC will be used in production of documents. This enables
> production of HTML and text files from a single source file as
> well as automated production of difference files.
>
>--
>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/>
>
>--
>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/>
>
--
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/>