[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Hi Kuntal,
Please see inline responses!
I still have a question for the group and chairs?
Is the group saying: go to Diameter for those needs? or there is not enough room in charter now? or people are not interested? or as Bernard said the group only wants to deal with other SDOs?
Madjid
In 3GPP2 text:
1. There is no pre-shared secret between the MN and the FA, so let's not
talk about it.
Madjid>> I am not sure what you mean by "let's not talk about it". That is exactly the point, there is no pre-shared secret and it must be established. You can't ignore that problem.
2. The distribution of MN-HA shared-secret to the HA (from HAAAs) is a bad
practice. We are not doing that for MIP6 and we may fix that in a bug fix
release for MIP4.
Madjid>> Bad practice or not, it is something that both MIPv4 and AAA are standardizing in their respective groups. And I don't know what you mean by "We"? You mean IETF, or 3GPP2 (I am not sure I care about the latter!)
3. FA-HA IKE pre-shared key distribution is a generic issue. The same
applies to any two tunnel end points that wish to use IKE and wish to
acquire share-secret via AAA infrastructure. It is NOT a MIP4 issue.
Madjid>>Please look at MIP key management drafts.
Therefore, I still don't think we need a MIP4 specific RADIUS work. Not from
3GPP2's perspective.
Madjid>>Thanks, But I still like to hear from the group and chairs?
Is the group saying: go to Diameter for those needs? or there is not enough room in charter now? or people are not interested? which is it?
The world does not just revolve around 3G!
-Kuntal
>-----Original Message-----
>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
>Sent: Wednesday, May 19, 2004 3:18 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri
>Madjid-MNAKHJI1; radiusext@ops.ietf.org
>Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins'
>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>
>
>Hi Kuntal,
>
>I guess it is fare to say that whenever I see a VSA, I call it
>proprietary! First the support for Mobile IP is not according
>to the same model as Diameter, some keys are established using
>direct IKE, others sent from AAAH. Second, whenever RADIUS is
>used, VSAs are used. I have provided more details below. But
>first I wanted to make a point and that is if one is to
>support both RADIUS and Mobile IP, one is forced to use VSAs.
>This leads to lack of interoperability.
>
>I looked very quickly through their documentations,
>X.S0011-002-C and -005-C, which talk about Mobile IP and
>RADIUS: From what I can understand, only the RFC 3012
>(challenge/ response) is supported, while the key management
>is not supported. I can understand that since the key
>management is not an RFC yet. So basically:
>
>1-No MN-FA (PDSN) security associations/ authentications are
>discussed, and this means distribution of keys for these SAs
>are not discussed either (this is part of my original concern
>with RADIUS: No attributes for AAAH-FA interaction).
>
>2-FA-HA security associations are established directly through
>IKE (either through certificates or through pre-shared secrets
>that distributed from AAAH using VSAs (IKE Pre-shared secret
>26/1, pre-shared secret 26/3, etc).
>
>3-MN-HA keys are distributed through VSAs again.
>
>Let me know if I missed something.
>
>Regards,
>
>Madjid
>
>-----Original Message-----
>From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com]
>Sent: Tuesday, May 18, 2004 5:59 PM
>To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org
>Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins'
>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>
>
>>I didn't
>>think that IETF should stop its standardization process, in
>>this case defining attributes for MIP the way Diameter did,
>>just because 3GPP2 has a proprietary way to do it.
>
>Could you elaborate on what you think is a proprietary way in
>3GPP2? As far as I am concerned, 3GPP2 used standard RADIUS
>attributes. As I said, I am not against MIP4 specific RADEXT
>work, but I don't feel it is needed, that's all.
>
>-Kuntal
>
>>-----Original Message-----
>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
>>Sent: Tuesday, May 18, 2004 5:50 PM
>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri
>>Madjid-MNAKHJI1; radiusext@ops.ietf.org
>>Cc: Pete McCann; tom.hiller@lucent.com; 'Charles E.Perkins'
>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>>
>>
>>Sure, I am not saying the draft does not work for RADIUS.
>>What I am saying is that MIP WG goes as far as they can with
>>MIP-AAA signaling as far as defining extensions for MIP.
>>However FA-AAAH and AAAH-HA messaging is assumed to be out of
>>scope and left for AAA protocol.
>>Diameter comes from the other end and plugs the holes, while
>>RADIUS doesn't.
>>
>>I always thought IETF designs for the Internet and IP, and
>>other SDOs come to IETF to borrow those standards. Of course,
>>when it does not exist or they don't have time to wait, they
>>do it their own way and the fact that they designed VSA attest
>>to the fact that it is not standardized by IETF. I didn't
>>think that IETF should stop its standardization process, in
>>this case defining attributes for MIP the way Diameter did,
>>just because 3GPP2 has a proprietary way to do it. Should we
>>go to 3GPP2 for our RADIUS standards from now on? That said, I
>>have nothing against 3GPP2 approaches, and I am guessing Tom
>>and Pete had a hand in designing it, which means it is of high
>>quality. But shouldn't we look at it and consider whether it
>>will fit the mold for an IETF standard that can be applied to
>>other instances. Maybe Tom and Pete know the history of why
>>the RADIUS draft (I myself have not seen it) didn't make it.
>>
>>I ccd Charlie on this, to hear his opinion!
>>
>>Regards,
>>
>>Madjid
>>
>>-----Original Message-----
>>From: Kuntal Chowdhury [mailto:chowdury@nortelnetworks.com]
>>Sent: Tuesday, May 18, 2004 4:56 PM
>>To: Nakhjiri Madjid-MNAKHJI1; radiusext@ops.ietf.org
>>Cc: Pete McCann; tom.hiller@lucent.com
>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>>
>>
>>I think AAA keys draft for mobile IPv4 was RADIUS/DIAMETER
>>agnostic i.e. it would work with both. I CCed Pete McCann and
>>Tom Hiller for their comments on the AAA keys draft.
>>
>>For normal authentication and authorization of MIP sessions I
>>think are fine. We have not felt the need to define new AVPs
>>or VSAs yet to carry MIP4 credentials to/from RADIUS. However
>>I won't be opposed to any work if other folks feel that we
>>need to define something new. We need to be careful to NOT
>>break existing 3GPP2 implementations that uses standard RADIUS
>>attributes.
>>
>>-Kuntal
>>
>>>-----Original Message-----
>>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
>>>Sent: Tuesday, May 18, 2004 4:34 PM
>>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; radiusext@ops.ietf.org
>>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>>>
>>>
>>>Hi Kuntal,
>>>
>>>Thanks a lot for the 3gpp2 doc number.
>>>3012 leaves a lot of details out. The MIP key mgmt drafts
>covers some
>>>more details, but still leave the AAA server to HA and FA messaging
>>>out, specially when it comes to key distribution. I have not yet
>>>completely read the Diameter-MIP draft yet, but it looks like it
>>>defines AVPs and messages for that.
>>>
>>>AAA group seems to only be doing Diameter, so the RADIUS draft
>>>probably went no where.
>>>
>>>Shouldn't this group provide attributes and specs for RADIUS?
>>>
>>>Madjid
>>>
>>>-----Original Message-----
>>>From: owner-radiusext@ops.ietf.org
>>>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of Kuntal Chowdhury
>>>Sent: Tuesday, May 18, 2004 3:53 PM
>>>To: radiusext@ops.ietf.org
>>>Subject: 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/>
>>>
>>
>
--
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/>