Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Date: Mon, 31 May 2004 11:00:44 -0400

Nakhjiri Madjid-MNAKHJI1 <[email-masked]> wrote:
> Sorry for the delayed response. I saw the draft and read it, was
> interested in it too. But I heard it went to another working group
> (enroll), true?

  Yes and no.  Bob has been pushing SSPP for a while, in a number of
groups.  So far, there haven't been many takers.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 28 May 2004 16:01:19 +0000
Date: Fri, 28 May 2004 09:03:27 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: [email-masked]
Subject: Rationalizing the RADIUS data model

> So I don't know what the benefit of having a new class of attribute.  What
> are we really fixing here?

Presumably what we would be fixing is:

a. Providing a migration path from current SDO VSAs to the IETF standards
   space.

b. Rationalizing the RADIUS VSA data model with the IETF standard
   attribute data model.

Today because the data models are different and the IETF standards space
is only 8 bits, we have difficulties in migrating arbitrary SDO VSAs to
the IETF standards space.

To get there, I'd suggest we need to do the following:

1.  Take inventory of the data types used in current RADIUS RFCs.  We've
    discussed this on previous emails, but we still need to summarize this
    and draw conclusions from it so we can understand what the current
    RADIUS data model is.

2.  Take inventory of the data types that folks feel they need/want going
    forward.  Certainly sub-attributes are one element of this, but there
    is probably more as well (such as an IPv6 address type).

3.  Put together a draft summarizing what we have now, and analyzing
    where we need to go, including the Diameter/RADIUS translation
    issues.

In terms of attribute definition, we have two proposals on the table:

a.  Using a Vendor-Id of zero (0) within the existing VSA attribute 26,
    in order to define an extended IETF standard attribute space that
    would mirror the VSA data model, including support for sub-attributes.

b.  Creating a new attribute that would mirror the VSA data model,
    including support for subattributes.

As I understand it, the primary argument for b) over a) relates to
potential backward compatibility issues with a).  To determine whether
this is an issue or not we will need to survey existing implementations.

Proposal for an IETF extended attribute space:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           |M|R|      Vendor type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vendor length |  Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      26 for Vendor-Specific

   Length

      >= 7

   Vendor-Id

      The high-order octet is 0 and the low-order 3 octets are the SMI
      Network Management Private Enterprise Code of the Vendor in
      network byte order.  A value of zero (0) denotes the IETF
      extended attribute space.

   M
      1 = Mandatory
      0 = Non-mandatory

   R
      Reserved for future use, and set to zero (0).

   Vendor type

      The vendor type field is 14 bits.

   Vendor length

      The Vendor Length field is one octet, and indicates the length of
      this Attribute in octets, including the M, R, Vendor type, Vendor
      length and Attribute-Specific fields.

   Attribute-specific

      The Attribute-Specific field is dependent on the definition of
      the Attribute.

   Multiple subattributes MAY be encoded within a
   single IETF extended attribute, although they do not have to be.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 28 May 2004 15:28:04 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter 
Date: Fri, 28 May 2004 10:27:34 -0500

Hi Alan,

Sorry for the delayed response. I saw the draft and read it, was interested in it too. But I heard it went to another working group (enroll), true?

Madjid

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Alan DeKok
Sent: Wednesday, May 19, 2004 6:20 PM
To: [email-masked]
Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter 

"Kuntal Chowdhury" <[email-masked]> wrote:
> MN-HA shared secret can be changed every moment or may be static (other end
> of the spectrum). Distribution of static pre-configured keys (not derived)
> is not a good crypto practice. May be we should ask security area experts to
> comment on key distribution.

  Robert Moskowitz & I proposed a key bootstrap & distribution method
for RADIUS clients (client kickstart).  It's not exactly the same
thing, but it's related.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 26 May 2004 09:41:16 +0000
From: "David Mariblanca (ML/EEM)" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: FW: I-D ACTION:draft-mariblanca-aaa-eap-lla-00.txt
Date: Wed, 26 May 2004 11:40:52 +0200

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C44305.88FFA921
Content-Type: text/plain;
	charset="ISO-8859-1"

Hi all,
probably you have read this announcement. Comments to the paper are welcome, please send them to this AAA WG list.

Thanks and best regards,
David.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: martes, 25 de mayo de 2004 17:03
To: [email-masked]
Subject: I-D ACTION:draft-mariblanca-aaa-eap-lla-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: EAP lower layer attributes for AAA protocols
	Author(s)	: D. Mariblanca
	Filename	: draft-mariblanca-aaa-eap-lla-00.txt
	Pages		: 6
	Date		: 2004-5-24
	
This document defines a new AVP to be transported in RADIUS or
   Diameter when EAP is carried over these protocols. The purpose of
   this AVP is to determine which layer 2 protocol was used to
   encapsulate the EAP messages at the point they were initiated.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-mariblanca-aaa-eap-lla-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_000_01C44305.88FFA921
Content-Type: message/rfc822

To: 
Subject: 
Date: Wed, 26 May 2004 11:40:55 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C44305.88FFA921"

------_=_NextPart_002_01C44305.88FFA921
Content-Type: text/plain

------_=_NextPart_002_01C44305.88FFA921
Content-Type: application/octet-stream;
	name="ATT34897"
Content-Disposition: attachment;
	filename="ATT34897"

Content-type: message/external-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-mariblanca-aaa-eap-lla-00.txt

------_=_NextPart_002_01C44305.88FFA921
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-mariblanca-aaa-eap-lla-00.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"

------_=_NextPart_002_01C44305.88FFA921--

------_=_NextPart_000_01C44305.88FFA921
Content-Type: text/plain;
	name="ATT3489756.txt"
Content-Disposition: attachment;
	filename="ATT3489756.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce

------_=_NextPart_000_01C44305.88FFA921--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 17:23:42 +0000
Content-class: urn:content-classes:message
Subject: FW: WG Review: RADIUS Extensions (radext)
Date: Thu, 20 May 2004 13:20:50 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

A new IETF working group has been proposed in the Operations and
Management Area. The IESG has not made any determination as yet. The
following description was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list
([email-masked]) by May 26th.

RADIUS Extensions (radext)
---------------------------

Current Staus: Proposed Working Group

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. Where possible, new attributes should be defined so that
    the same attribute can be used in both RADIUS and Diameter without
    translation. In other cases a translation considerations
    section should be included in the specification.
- 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.

- RADIUS implementation issues and fixes. This document will
    address common RADIUS implementation issues and describe
    proposed solutions.

- Revised NAI specification. This document, known as "RFC 2486bis"
    will revise the NAI specification to correct known errors,
    add support for privacy and internationalization, and provide
    more details on routing.

- 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
    include within it a specification for interoperation with
    Diameter Credit Control.

- SIP support. RADIUS is currently used for SIP authentication,
    authorization and accounting. Standardization of these attributes
    will enable improved interoperability.

    This document will be upwards compatible with the Diameter SIP
    application, and conform to existing IETF RFCs on HTTP Digest,
    including RFC 2617, 3261, and 3310.

- 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 compatibility, and modest
    changes are required to address this issue. MIBs for RFC 3576 are
    also needed.=20

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

------- End of Forwarded Message

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 16:19:00 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked], "'Bernard Aboba'" <[email-masked]>
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Thu, 20 May 2004 11:18:22 -0500

Hi Dave, Bernard,

I appreciate the work the chairs and IESG are going through to approve the charter. So I don't want to jeopardize anything for now. Is it possible to have a 5-10 minute slot to present the problem to the group/birds :), for future consideration? I am not sure if I can put a draft together by next IETF, but it is not completely out of question!

Regards,

Madjid

-----Original Message-----
From: Nelson, David [mailto:[email-masked]]
Sent: Wednesday, May 19, 2004 5:02 PM
To: Nakhjiri Madjid-MNAKHJI1; Kuntal Chowdhury; [email-masked]
Cc: Pete McCann; [email-masked]; Charles E.Perkins
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter

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

The charter is currently in IESG review.  The announcement went out to
the IETF-Announce list today.

There is quite a bit of work on the charter now.  Unless there is an
urgent requirement from 3GPP or 3GPP2 for this work, or unless another
IETF WG requests it, it would seem inadvisable to take on this
additional work now.

There is always the possibility of re-chartering after all (or most) of
our current deliverables have been achieved.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 16:15:09 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Kuntal Chowdhury'" <[email-masked]>
Cc: [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RAD EXT WG Charter
Date: Thu, 20 May 2004 11:13:34 -0500

A peach in mind is not a bad thing maybe, I like the smell :)

-----Original Message-----
From: Kuntal Chowdhury [mailto:[email-masked]]
Sent: Thursday, May 20, 2004 10:35 AM
To: Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins'
Cc: Lila Madour (QA/EMC); [email-masked]; Pete McCann;
[email-masked]
Subject: RE: RADIUS-Mobile IP support??: RAD EXT WG Charter

s/peach/peace

>-----Original Message-----
>From: Chowdhury, Kuntal [RICH1:2H18:EXCH] 
>Sent: Thursday, May 20, 2004 10:03 AM
>To: Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins'
>Cc: Lila Madour (QA/EMC); [email-masked]; Pete McCann; 
>[email-masked]
>Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP 
>support??: RAD EXT WG Charter
>
>
>I will not loose my peach of mind if people want to spend time 
>on MIP4-RADIUS work. However, I don't see the need for it. 
>
>If it is so important, then a generic (dynamic) key 
>distribution mechanism with RADIUS may be of some interest to me.
>
>-Kuntal
>
>>-----Original Message-----
>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
>>Sent: Thursday, May 20, 2004 9:47 AM
>>To: 'Charles E. Perkins'; Chowdhury, Kuntal [RICH1:2H18:EXCH]
>>Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; 
>>[email-masked]; Pete McCann; [email-masked]
>>Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP 
>>support??: RAD EXT WG Charter
>>
>>
>>Hi Kuntal
>>
>>I agree what Charlie. The problems of RADIUS supporting Mobile
>>IP extensions and RADIUS hop by hop security are different. 
>>Although solutions to both is required for some scenarios, 
>>that is not always the case. Lets remember I am not asking 
>>radext to solve all MIP security problems (if they exist). 
>>If I had issues with security of MIP, I would go to MIP 
>>mailing list, not this list. And for folks interested in those 
>>issues, please lets meet over at MIP list! 
>>I am saying MIPv4 and its key mgmt drafts as protocols being 
>>standardized by IETF need support for RADIUS, which also is an 
>>IETF protocol.  For folks that argue 3GPP2 has done it this 
>>way or the other, I should say: 
>>The interoperability problems for IETF protocols "Must" be 
>>resolved in IETF, not in other SDOs. What would you tell IEEE 
>>folks, or APCO folks? Please go to 3GPP32 for the second half 
>>of the solution?
>>
>>IETF AAA community has acknowledged RADIUS problems and solved
>>many of those in Diameter, but Diameter has a small deployment 
>>base, please show me a Diameter vendor that supports all IETF 
>>specs and I may just go buy from them. 
>>The problem is people are stuck with RADIUS for a while and if 
>>you are using Mobile IP, problems needs to be solved.
>>
>>I can understand the group might be having a pressing charter,
>>but I don't buy the argument of "there is no need because 
>>3GPP2 has done it since 2000". Technology grows!
>>
>>Regards,
>>
>>Madjid
>>
>>
>>-----Original Message-----
>>From: Charles E. Perkins [mailto:[email-masked]]
>>Sent: Wednesday, May 19, 2004 7:50 PM
>>To: Kuntal Chowdhury
>>Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1;
>>[email-masked]; Pete McCann; [email-masked]
>>Subject: Re: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP 
>>support??: RADEXT WG Charter
>>
>>
>>Hello Kuntal,
>>
>>> Kuntal Chowdhury wrote:
>>>
>>>We cannot assume that the HA and the HAAA server SHALL always
>>be in the
>>>same administrative domain.
>>>
>>That means another solution is required for expanded
>>applicability. It doesn't mean that the offered solution is 
>>inappropriate for its domain of applicability.
>>
>>> Moreover, for RADIUS, every proxy in the PATH will
>>>see the MN-HA shared secret.
>>>  
>>>
>>Well, since the secret didn't exist at all anyway until the
>>AAAH created it, I don't see the big deal here. If there is 
>>some worry, then:
>>(a) use a shorter lifetime and/or
>>(b) use another key when moving to another domain
>>
>>>Again, this issue should be discussed with security area folks.
>>>  
>>>
>>They've looked at it pretty close a few dozen
>>times by now I reckon.
>>
>>Regards,
>>Charlie P.
>>
>
>--
>to unsubscribe send a message to 
>[email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 15:36:39 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, "'Charles E. Perkins'" <[email-masked]>
Cc: "Lila Madour (QA/EMC)" <[email-masked]>, [email-masked], Pete McCann <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RAD EXT WG Charter
Date: Thu, 20 May 2004 11:35:24 -0400

s/peach/peace

>-----Original Message-----
>From: Chowdhury, Kuntal [RICH1:2H18:EXCH] 
>Sent: Thursday, May 20, 2004 10:03 AM
>To: Nakhjiri Madjid-MNAKHJI1; 'Charles E. Perkins'
>Cc: Lila Madour (QA/EMC); [email-masked]; Pete McCann; 
>[email-masked]
>Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP 
>support??: RAD EXT WG Charter
>
>
>I will not loose my peach of mind if people want to spend time 
>on MIP4-RADIUS work. However, I don't see the need for it. 
>
>If it is so important, then a generic (dynamic) key 
>distribution mechanism with RADIUS may be of some interest to me.
>
>-Kuntal
>
>>-----Original Message-----
>>From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
>>Sent: Thursday, May 20, 2004 9:47 AM
>>To: 'Charles E. Perkins'; Chowdhury, Kuntal [RICH1:2H18:EXCH]
>>Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; 
>>[email-masked]; Pete McCann; [email-masked]
>>Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP 
>>support??: RAD EXT WG Charter
>>
>>
>>Hi Kuntal
>>
>>I agree what Charlie. The problems of RADIUS supporting Mobile
>>IP extensions and RADIUS hop by hop security are different. 
>>Although solutions to both is required for some scenarios, 
>>that is not always the case. Lets remember I am not asking 
>>radext to solve all MIP security problems (if they exist). 
>>If I had issues with security of MIP, I would go to MIP 
>>mailing list, not this list. And for folks interested in those 
>>issues, please lets meet over at MIP list! 
>>I am saying MIPv4 and its key mgmt drafts as protocols being 
>>standardized by IETF need support for RADIUS, which also is an 
>>IETF protocol.  For folks that argue 3GPP2 has done it this 
>>way or the other, I should say: 
>>The interoperability problems for IETF protocols "Must" be 
>>resolved in IETF, not in other SDOs. What would you tell IEEE 
>>folks, or APCO folks? Please go to 3GPP32 for the second half 
>>of the solution?
>>
>>IETF AAA community has acknowledged RADIUS problems and solved
>>many of those in Diameter, but Diameter has a small deployment 
>>base, please show me a Diameter vendor that supports all IETF 
>>specs and I may just go buy from them. 
>>The problem is people are stuck with RADIUS for a while and if 
>>you are using Mobile IP, problems needs to be solved.
>>
>>I can understand the group might be having a pressing charter,
>>but I don't buy the argument of "there is no need because 
>>3GPP2 has done it since 2000". Technology grows!
>>
>>Regards,
>>
>>Madjid
>>
>>
>>-----Original Message-----
>>From: Charles E. Perkins [mailto:[email-masked]]
>>Sent: Wednesday, May 19, 2004 7:50 PM
>>To: Kuntal Chowdhury
>>Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1;
>>[email-masked]; Pete McCann; [email-masked]
>>Subject: Re: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP 
>>support??: RADEXT WG Charter
>>
>>
>>Hello Kuntal,
>>
>>> Kuntal Chowdhury wrote:
>>>
>>>We cannot assume that the HA and the HAAA server SHALL always
>>be in the
>>>same administrative domain.
>>>
>>That means another solution is required for expanded
>>applicability. It doesn't mean that the offered solution is 
>>inappropriate for its domain of applicability.
>>
>>> Moreover, for RADIUS, every proxy in the PATH will
>>>see the MN-HA shared secret.
>>>  
>>>
>>Well, since the secret didn't exist at all anyway until the
>>AAAH created it, I don't see the big deal here. If there is 
>>some worry, then:
>>(a) use a shorter lifetime and/or
>>(b) use another key when moving to another domain
>>
>>>Again, this issue should be discussed with security area folks.
>>>  
>>>
>>They've looked at it pretty close a few dozen
>>times by now I reckon.
>>
>>Regards,
>>Charlie P.
>>
>
>--
>to unsubscribe send a message to 
>[email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 15:03:52 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, "'Charles E. Perkins'" <[email-masked]>
Cc: "Lila Madour (QA/EMC)" <[email-masked]>, [email-masked], Pete McCann <[email-masked]>, [email-masked]
Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP support??: RAD EXT WG Charter
Date: Thu, 20 May 2004 11:03:15 -0400

I will not loose my peach of mind if people want to spend time on
MIP4-RADIUS work. However, I don't see the need for it. 

If it is so important, then a generic (dynamic) key distribution mechanism
with RADIUS may be of some interest to me.

-Kuntal

>-----Original Message-----
>From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
>Sent: Thursday, May 20, 2004 9:47 AM
>To: 'Charles E. Perkins'; Chowdhury, Kuntal [RICH1:2H18:EXCH]
>Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; 
>[email-masked]; Pete McCann; [email-masked]
>Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP 
>support??: RAD EXT WG Charter
>
>
>Hi Kuntal
>
>I agree what Charlie. The problems of RADIUS supporting Mobile 
>IP extensions and RADIUS hop by hop security are different. 
>Although solutions to both is required for some scenarios, 
>that is not always the case. Lets remember I am not asking 
>radext to solve all MIP security problems (if they exist). 
>If I had issues with security of MIP, I would go to MIP 
>mailing list, not this list. And for folks interested in those 
>issues, please lets meet over at MIP list! 
>I am saying MIPv4 and its key mgmt drafts as protocols being 
>standardized by IETF need support for RADIUS, which also is an 
>IETF protocol.  For folks that argue 3GPP2 has done it this 
>way or the other, I should say: 
>The interoperability problems for IETF protocols "Must" be 
>resolved in IETF, not in other SDOs. What would you tell IEEE 
>folks, or APCO folks? Please go to 3GPP32 for the second half 
>of the solution?
>
>IETF AAA community has acknowledged RADIUS problems and solved 
>many of those in Diameter, but Diameter has a small deployment 
>base, please show me a Diameter vendor that supports all IETF 
>specs and I may just go buy from them. 
>The problem is people are stuck with RADIUS for a while and if 
>you are using Mobile IP, problems needs to be solved.
>
>I can understand the group might be having a pressing charter, 
>but I don't buy the argument of "there is no need because 
>3GPP2 has done it since 2000". Technology grows!
>
>Regards,
>
>Madjid
>
>
>-----Original Message-----
>From: Charles E. Perkins [mailto:[email-masked]]
>Sent: Wednesday, May 19, 2004 7:50 PM
>To: Kuntal Chowdhury
>Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; 
>[email-masked]; Pete McCann; [email-masked]
>Subject: Re: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP 
>support??: RADEXT WG Charter
>
>
>Hello Kuntal,
>
>> Kuntal Chowdhury wrote:
>>
>>We cannot assume that the HA and the HAAA server SHALL always 
>be in the 
>>same administrative domain.
>>
>That means another solution is required for expanded 
>applicability. It doesn't mean that the offered solution is 
>inappropriate for its domain of applicability.
>
>> Moreover, for RADIUS, every proxy in the PATH will
>>see the MN-HA shared secret.
>>  
>>
>Well, since the secret didn't exist at all anyway until the 
>AAAH created it, I don't see the big deal here. If there is 
>some worry, then:
>(a) use a shorter lifetime and/or
>(b) use another key when moving to another domain
>
>>Again, this issue should be discussed with security area folks.
>>  
>>
>They've looked at it pretty close a few dozen
>times by now I reckon.
>
>Regards,
>Charlie P.
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 14:46:57 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Charles E. Perkins'" <[email-masked]>, Kuntal Chowdhury <[email-masked]>
Cc: "Lila Madour (QA/EMC)" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked], Pete McCann <[email-masked]>, [email-masked]
Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP support??: RAD EXT WG Charter
Date: Thu, 20 May 2004 09:46:41 -0500

Hi Kuntal

I agree what Charlie. The problems of RADIUS supporting Mobile IP extensions and RADIUS hop by hop security are different. Although solutions to both is required for some scenarios, that is not always the case. Lets remember I am not asking radext to solve all MIP security problems (if they exist). 
If I had issues with security of MIP, I would go to MIP mailing list, not this list. And for folks interested in those issues, please lets meet over at MIP list! 
I am saying MIPv4 and its key mgmt drafts as protocols being standardized by IETF need support for RADIUS, which also is an IETF protocol.  For folks that argue 3GPP2 has done it this way or the other, I should say: 
The interoperability problems for IETF protocols "Must" be resolved in IETF, not in other SDOs. What would you tell IEEE folks, or APCO folks? Please go to 3GPP32 for the second half of the solution?

IETF AAA community has acknowledged RADIUS problems and solved many of those in Diameter, but Diameter has a small deployment base, please show me a Diameter vendor that supports all IETF specs and I may just go buy from them. 
The problem is people are stuck with RADIUS for a while and if you are using Mobile IP, problems needs to be solved.

I can understand the group might be having a pressing charter, but I don't buy the argument of "there is no need because 3GPP2 has done it since 2000".
Technology grows!

Regards,

Madjid

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Wednesday, May 19, 2004 7:50 PM
To: Kuntal Chowdhury
Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1;
[email-masked]; Pete McCann; [email-masked]
Subject: Re: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP support??:
RADEXT WG Charter

Hello Kuntal,

> Kuntal Chowdhury wrote:
>
>We cannot assume that the HA and the HAAA server SHALL always be in the same
>administrative domain.
>
That means another solution is required for expanded applicability.
It doesn't mean that the offered solution is inappropriate for its
domain of applicability.

> Moreover, for RADIUS, every proxy in the PATH will
>see the MN-HA shared secret. 
>  
>
Well, since the secret didn't exist at all anyway until the
AAAH created it, I don't see the big deal here.
If there is some worry, then:
(a) use a shorter lifetime and/or
(b) use another key when moving to another domain

>Again, this issue should be discussed with security area folks.
>  
>
They've looked at it pretty close a few dozen
times by now I reckon.

Regards,
Charlie P.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 14:39:01 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: Alan DeKok <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter 
Date: Thu, 20 May 2004 10:38:43 -0400

This seems to make lot more sense to me than creating a distribution method
for static shared secrets over RADIUS. I did not read your draft yet.

-Kuntal

>-----Original Message-----
>From: Alan DeKok [mailto:[email-masked]] 
>Sent: Thursday, May 20, 2004 9:24 AM
>To: [email-masked]
>Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter 
>
>
>"Kuntal Chowdhury" <[email-masked]> wrote:
>> Did you propose distribution of static shared secrets over RADIUS?
>
>  No.  We proposed distributing dynamic shared secrets, and a 
>method for updating shared secrets.
>
>  See:	http://homebase.htt-consult.com/sspp.html
>
>	http://homebase.htt-consult.com/docs/radiusks.txt
>
>  Alan DeKok.
>
>
>--
>to unsubscribe send a message to 
>[email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 14:36:54 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, "Charles E. Perkins" <[email-masked]>
Cc: [email-masked], Pete McCann <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Thu, 20 May 2004 10:36:25 -0400

I think you got it wrong. The MN-HA shared secrets are not dynamically
generated in the HAAA. At least I don't know of such a text in 3GPP2
standard.

I think what we are discussing is purely key distribution issues. So, why
don't we start the discussion about the need for a key distribution
mechanism with RADIUS and see whether RADEXT can accommodate that?

-Kuntal

>-----Original Message-----
>From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
>Sent: Thursday, May 20, 2004 9:30 AM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Charles E. Perkins; 
>Nakhjiri Madjid-MNAKHJI1
>Cc: [email-masked]; Pete McCann; [email-masked]
>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>
>
>Kuntal, 
>
>As far as I understood, the secrets are hashed with MN-AAA keys. 
>Any key distribution method that happens on-line has to be 
>done this way. Also the secrets are only needed for the 
>duration of Mobile's visit to the foreign network. How is that 
>more long lived than a key established during IKE?
>
>Madjid
>
>-----Original Message-----
>From: Kuntal Chowdhury [mailto:[email-masked]]
>Sent: Wednesday, May 19, 2004 5:18 PM
>To: Charles E. Perkins; Nakhjiri Madjid-MNAKHJI1
>Cc: [email-masked]; Pete McCann; [email-masked]
>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>
>
>Charlie,
>
>sending a users (static or long lived) shared-secret over the 
>wire opens up for attacks. If the MN-HA shared secret is 
>compromised, MIP4 will run into serious security issue. That's 
>why it is a bad idea.
>
>-Kuntal
>
>>-----Original Message-----
>>From: Charles E. Perkins [mailto:[email-masked]]
>>Sent: Wednesday, May 19, 2004 5:11 PM
>>To: Nakhjiri Madjid-MNAKHJI1
>>Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 
>>[email-masked]; Pete McCann; [email-masked]
>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>>
>>
>>
>>Hello folks,
>>
>>Since I'm receiving these e-mails, perhaps someone could enlighten me:
>>
>>>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.
>>>  
>>>
>>Why is this a bad idea?
>>
>>I thought it was pretty good, actually...
>>
>>
>>Regards,
>>Charlie P.
>>
>
>--
>to unsubscribe send a message to 
>[email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 14:32:06 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: "Charles E. Perkins" <[email-masked]>
Cc: "Lila Madour (QA/EMC)" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked], Pete McCann <[email-masked]>, [email-masked]
Subject: RE: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP support??: RAD EXT WG Charter
Date: Thu, 20 May 2004 10:31:18 -0400

Charlie,

Essentially you are saying that sending shared secret from the location
where it is securely stored to another device over RADIUS proxy chain is a
good idea?

-Kuntal

>-----Original Message-----
>From: Charles E. Perkins [mailto:[email-masked]] 
>Sent: Wednesday, May 19, 2004 7:50 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]
>Cc: Lila Madour (QA/EMC); Nakhjiri Madjid-MNAKHJI1; 
>[email-masked]; Pete McCann; [email-masked]
>Subject: Re: [SPAM: Sexually Explicit] RE: RADIUS-Mobile IP 
>support??: RADEXT WG Charter
>
>
>Hello Kuntal,
>
>> Kuntal Chowdhury wrote:
>>
>>We cannot assume that the HA and the HAAA server SHALL always 
>be in the 
>>same administrative domain.
>>
>That means another solution is required for expanded 
>applicability. It doesn't mean that the offered solution is 
>inappropriate for its domain of applicability.
>
>> Moreover, for RADIUS, every proxy in the PATH will
>>see the MN-HA shared secret.
>>  
>>
>Well, since the secret didn't exist at all anyway until the 
>AAAH created it, I don't see the big deal here. If there is 
>some worry, then:
>(a) use a shorter lifetime and/or
>(b) use another key when moving to another domain
>
>>Again, this issue should be discussed with security area folks.
>>  
>>
>They've looked at it pretty close a few dozen
>times by now I reckon.
>
>Regards,
>Charlie P.
>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 14:30:33 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Kuntal Chowdhury'" <[email-masked]>, "Charles E. Perkins" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: [email-masked], Pete McCann <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Thu, 20 May 2004 09:30:07 -0500

Kuntal, 

As far as I understood, the secrets are hashed with MN-AAA keys. 
Any key distribution method that happens on-line has to be done this way.
Also the secrets are only needed for the duration of Mobile's visit
to the foreign network. How is that more long lived than a key established during IKE?

Madjid

-----Original Message-----
From: Kuntal Chowdhury [mailto:[email-masked]]
Sent: Wednesday, May 19, 2004 5:18 PM
To: Charles E. Perkins; Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]; Pete McCann; [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter

Charlie,

sending a users (static or long lived) shared-secret over the wire opens up
for attacks. If the MN-HA shared secret is compromised, MIP4 will run into
serious security issue. That's why it is a bad idea.

-Kuntal

>-----Original Message-----
>From: Charles E. Perkins [mailto:[email-masked]] 
>Sent: Wednesday, May 19, 2004 5:11 PM
>To: Nakhjiri Madjid-MNAKHJI1
>Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 
>[email-masked]; Pete McCann; [email-masked]
>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>
>
>
>Hello folks,
>
>Since I'm receiving these e-mails, perhaps someone could enlighten me:
>
>>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.
>>  
>>
>Why is this a bad idea?
>
>I thought it was pretty good, actually...
>
>
>Regards,
>Charlie P.
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 14:26:25 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Lila Madour (QA/EMC)'" <[email-masked]>, "'Kuntal Chowdhury'" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked]
Cc: Pete McCann <[email-masked]>, [email-masked], "'Charles E.Perkins'" <[email-masked]>
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Thu, 20 May 2004 09:25:58 -0500

I echo Kuntal's statement. The 3GPP2 standard that supports MIPv4 with RADIUS has been around since year 2000. 
I don't see the need to start MIPv4 specific RADIUS work in RADEXT group.
Lila 

Madjid>> I am sorry, but I do. Just because an SDO has an SDO-specific solution does not mean IETF has to stop working on interoperability of its own protocols.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
Sent: Wednesday, May 19, 2004 5:14 PM
To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Cc: Pete McCann; [email-masked]; 'Charles E.Perkins'
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter

In 3GPP2 text:

1. There is no pre-shared secret between the MN and the FA, so let's not
talk about it.

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.

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.

Therefore, I still don't think we need a MIP4 specific RADIUS work. Not from
3GPP2's perspective.

-Kuntal

>-----Original Message-----
>From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
>Sent: Wednesday, May 19, 2004 3:18 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri 
>Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>Sent: Tuesday, May 18, 2004 5:59 PM
>To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 5:50 PM
>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri 
>>Madjid-MNAKHJI1; [email-masked]
>>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 4:56 PM
>>To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
>>Cc: Pete McCann; [email-masked]
>>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:[email-masked]]
>>>Sent: Tuesday, May 18, 2004 4:34 PM
>>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; [email-masked]
>>>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: [email-masked] 
>>>[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
>>>Sent: Tuesday, May 18, 2004 3:53 PM
>>>To: [email-masked]
>>>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:[email-masked]]
>>>>Sent: Tuesday, May 18, 2004 3:42 PM
>>>>To: [email-masked]
>>>>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: [email-masked]
>>>>[mailto:[email-masked]]On Behalf Of Bernard Aboba
>>>>Sent: Thursday, April 15, 2004 6:52 PM
>>>>To: [email-masked]
>>>>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 <[email-masked]>
>>>>Bernard Aboba <[email-masked]>
>>>>
>>>>Operations and Management Area Director(s):
>>>>David Kessens <[email-masked]>
>>>>Bert Wijnen <[email-masked]>
>>>>
>>>>Operations and Management Area Advisor:
>>>>David Kessens <[email-masked]>
>>>>
>>>>Technical Advisor:
>>>>Paul Congdon <[email-masked]>
>>>>
>>>>Mailing Lists:
>>>>General Discussion: [email-masked]
>>>>To Subscribe: [email-masked], 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 [email-masked] 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 [email-masked] 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 [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 20 May 2004 14:19:21 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter 
Date: Thu, 20 May 2004 10:24:24 -0400
Message-Id: <[email-masked]>

"Kuntal Chowdhury" <[email-masked]> wrote:
> Did you propose distribution of static shared secrets over RADIUS?

  No.  We proposed distributing dynamic shared secrets, and a method
for updating shared secrets.

  See:	http://homebase.htt-consult.com/sspp.html

	http://homebase.htt-consult.com/docs/radiusks.txt

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 20 May 2004 00:10:02 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: Alan DeKok <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter 
Date: Wed, 19 May 2004 20:09:38 -0400

>-----Original Message-----
>From: Alan DeKok [mailto:[email-masked]] 
>Sent: Wednesday, May 19, 2004 6:20 PM
>To: [email-masked]
>Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter 
>
>
>"Kuntal Chowdhury" <[email-masked]> wrote:
>> MN-HA shared secret can be changed every moment or may be static 
>> (other end of the spectrum). Distribution of static pre-configured 
>> keys (not derived) is not a good crypto practice. May be we 
>should ask 
>> security area experts to comment on key distribution.
>
>  Robert Moskowitz & I proposed a key bootstrap & distribution 
>method for RADIUS clients (client kickstart).  It's not 
>exactly the same thing, but it's related.
>

Did you propose distribution of static shared secrets over RADIUS?

>  Alan DeKok.
>
>--
>to unsubscribe send a message to 
>[email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 19 May 2004 23:16:35 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: "Lila Madour (QA/EMC)" <[email-masked]>, "Charles E. Perkins" <[email-masked]>
Cc: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked], Pete McCann <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Wed, 19 May 2004 19:16:15 -0400

We cannot assume that the HA and the HAAA server SHALL always be in the same
administrative domain. Moreover, for RADIUS, every proxy in the PATH will
see the MN-HA shared secret. 

Again, this issue should be discussed with security area folks.

-Kuntal

>-----Original Message-----
>From: Lila Madour (QA/EMC) [mailto:[email-masked]] 
>Sent: Wednesday, May 19, 2004 6:08 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Charles E. Perkins
>Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; Pete 
>McCann; [email-masked]
>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>
>
>If the AAA and the HA are in the same administrative domain, 
>and if we assume it is a secure link between the AAA and the 
>HA, the security issue of distributing the key from the AAAH 
>to the HA may not be critical. 
>Lila
>
>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
>Sent: Wednesday, May 19, 2004 6:48 PM
>To: Charles E. Perkins
>Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; Pete 
>McCann; [email-masked]
>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>
>
>Charlie,
>
>MN-HA shared secret can be changed every moment or may be 
>static (other end of the spectrum). Distribution of static 
>pre-configured keys (not derived) is not a good crypto 
>practice. May be we should ask security area experts to 
>comment on key distribution.
>
>-Kuntal
>
>>-----Original Message-----
>>From: Charles E. Perkins [mailto:[email-masked]]
>>Sent: Wednesday, May 19, 2004 5:34 PM
>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]
>>Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; Pete 
>>McCann; [email-masked]
>>Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter
>>
>>
>>
>>Hello Kuntal,
>>
>>How long is too long?
>>
>>Doesn't it matter that the secret is passed in a
>>way that protects it from onlookers?
>>
>>Regards,
>>Charlie P.
>>
>>
>>Kuntal Chowdhury wrote:
>>
>>>Charlie,
>>>
>>>sending a users (static or long lived) shared-secret over the wire
>>>opens up for attacks. If the MN-HA shared secret is 
>compromised, MIP4 
>>>will run into serious security issue. That's why it is a bad idea.
>>>
>>>-Kuntal
>>>
>>>  
>>>
>>>>-----Original Message-----
>>>>From: Charles E. Perkins [mailto:[email-masked]]
>>>>Sent: Wednesday, May 19, 2004 5:11 PM
>>>>To: Nakhjiri Madjid-MNAKHJI1
>>>>Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH];
>>>>[email-masked]; Pete McCann; [email-masked]
>>>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>>>>
>>>>
>>>>
>>>>Hello folks,
>>>>
>>>>Since I'm receiving these e-mails, perhaps someone could
>>enlighten me:
>>>>
>>>>    
>>>>
>>>>>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.
>>>>> 
>>>>>
>>>>>      
>>>>>
>>>>Why is this a bad idea?
>>>>
>>>>I thought it was pretty good, actually...
>>>>
>>>>
>>>>Regards,
>>>>Charlie P.
>>>>
>>>>    
>>>>
>>
>>
>
>--
>to unsubscribe send a message to 
>[email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Wed, 19 May 2004 23:14:54 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter 
Date: Wed, 19 May 2004 19:20:23 -0400
Message-Id: <[email-masked]>

"Kuntal Chowdhury" <[email-masked]> wrote:
> MN-HA shared secret can be changed every moment or may be static (other end
> of the spectrum). Distribution of static pre-configured keys (not derived)
> is not a good crypto practice. May be we should ask security area experts to
> comment on key distribution.

  Robert Moskowitz & I proposed a key bootstrap & distribution method
for RADIUS clients (client kickstart).  It's not exactly the same
thing, but it's related.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 19 May 2004 23:10:32 +0000
From: "Lila Madour (QA/EMC)" <[email-masked]>
To: "'Kuntal Chowdhury'" <[email-masked]>, "Charles E. Perkins" <[email-masked]>
Cc: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked], Pete McCann <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Wed, 19 May 2004 18:08:13 -0500

If the AAA and the HA are in the same administrative domain, and if we assume it is a secure link between the AAA and the HA, the security issue of distributing the key from the AAAH to the HA may not be critical. 
Lila

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
Sent: Wednesday, May 19, 2004 6:48 PM
To: Charles E. Perkins
Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; Pete McCann;
[email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter

Charlie,

MN-HA shared secret can be changed every moment or may be static (other end
of the spectrum). Distribution of static pre-configured keys (not derived)
is not a good crypto practice. May be we should ask security area experts to
comment on key distribution.

-Kuntal

>-----Original Message-----
>From: Charles E. Perkins [mailto:[email-masked]] 
>Sent: Wednesday, May 19, 2004 5:34 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]
>Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; Pete 
>McCann; [email-masked]
>Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter
>
>
>
>Hello Kuntal,
>
>How long is too long?
>
>Doesn't it matter that the secret is passed in a
>way that protects it from onlookers?
>
>Regards,
>Charlie P.
>
>
>Kuntal Chowdhury wrote:
>
>>Charlie,
>>
>>sending a users (static or long lived) shared-secret over the wire 
>>opens up for attacks. If the MN-HA shared secret is compromised, MIP4 
>>will run into serious security issue. That's why it is a bad idea.
>>
>>-Kuntal
>>
>>  
>>
>>>-----Original Message-----
>>>From: Charles E. Perkins [mailto:[email-masked]]
>>>Sent: Wednesday, May 19, 2004 5:11 PM
>>>To: Nakhjiri Madjid-MNAKHJI1
>>>Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 
>>>[email-masked]; Pete McCann; [email-masked]
>>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>>>
>>>
>>>
>>>Hello folks,
>>>
>>>Since I'm receiving these e-mails, perhaps someone could 
>enlighten me:
>>>
>>>    
>>>
>>>>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.
>>>> 
>>>>
>>>>      
>>>>
>>>Why is this a bad idea?
>>>
>>>I thought it was pretty good, actually...
>>>
>>>
>>>Regards,
>>>Charlie P.
>>>
>>>    
>>>
>
>

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 19 May 2004 22:48:30 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: "Charles E. Perkins" <[email-masked]>
Cc: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked], Pete McCann <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Wed, 19 May 2004 18:47:54 -0400

Charlie,

MN-HA shared secret can be changed every moment or may be static (other end
of the spectrum). Distribution of static pre-configured keys (not derived)
is not a good crypto practice. May be we should ask security area experts to
comment on key distribution.

-Kuntal

>-----Original Message-----
>From: Charles E. Perkins [mailto:[email-masked]] 
>Sent: Wednesday, May 19, 2004 5:34 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]
>Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; Pete 
>McCann; [email-masked]
>Subject: Re: RADIUS-Mobile IP support??: RADEXT WG Charter
>
>
>
>Hello Kuntal,
>
>How long is too long?
>
>Doesn't it matter that the secret is passed in a
>way that protects it from onlookers?
>
>Regards,
>Charlie P.
>
>
>Kuntal Chowdhury wrote:
>
>>Charlie,
>>
>>sending a users (static or long lived) shared-secret over the wire 
>>opens up for attacks. If the MN-HA shared secret is compromised, MIP4 
>>will run into serious security issue. That's why it is a bad idea.
>>
>>-Kuntal
>>
>>  
>>
>>>-----Original Message-----
>>>From: Charles E. Perkins [mailto:[email-masked]]
>>>Sent: Wednesday, May 19, 2004 5:11 PM
>>>To: Nakhjiri Madjid-MNAKHJI1
>>>Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 
>>>[email-masked]; Pete McCann; [email-masked]
>>>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>>>
>>>
>>>
>>>Hello folks,
>>>
>>>Since I'm receiving these e-mails, perhaps someone could 
>enlighten me:
>>>
>>>    
>>>
>>>>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.
>>>> 
>>>>
>>>>      
>>>>
>>>Why is this a bad idea?
>>>
>>>I thought it was pretty good, actually...
>>>
>>>
>>>Regards,
>>>Charlie P.
>>>
>>>    
>>>
>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 19 May 2004 22:18:27 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: "Charles E. Perkins" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: [email-masked], Pete McCann <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Wed, 19 May 2004 18:18:11 -0400

Charlie,

sending a users (static or long lived) shared-secret over the wire opens up
for attacks. If the MN-HA shared secret is compromised, MIP4 will run into
serious security issue. That's why it is a bad idea.

-Kuntal

>-----Original Message-----
>From: Charles E. Perkins [mailto:[email-masked]] 
>Sent: Wednesday, May 19, 2004 5:11 PM
>To: Nakhjiri Madjid-MNAKHJI1
>Cc: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 
>[email-masked]; Pete McCann; [email-masked]
>Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
>
>
>
>Hello folks,
>
>Since I'm receiving these e-mails, perhaps someone could enlighten me:
>
>>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.
>>  
>>
>Why is this a bad idea?
>
>I thought it was pretty good, actually...
>
>
>Regards,
>Charlie P.
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 19 May 2004 22:16:47 +0000
From: "Lila Madour (QA/EMC)" <[email-masked]>
To: "'Kuntal Chowdhury'" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked]
Cc: Pete McCann <[email-masked]>, [email-masked], "'Charles E.Perkins'" <[email-masked]>
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Wed, 19 May 2004 17:14:32 -0500

I echo Kuntal's statement. The 3GPP2 standard that supports MIPv4 with RADIUS has been around since year 2000. 
I don't see the need to start MIPv4 specific RADIUS work in RADEXT group.
Lila 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
Sent: Wednesday, May 19, 2004 5:14 PM
To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Cc: Pete McCann; [email-masked]; 'Charles E.Perkins'
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter

In 3GPP2 text:

1. There is no pre-shared secret between the MN and the FA, so let's not
talk about it.

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.

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.

Therefore, I still don't think we need a MIP4 specific RADIUS work. Not from
3GPP2's perspective.

-Kuntal

>-----Original Message-----
>From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
>Sent: Wednesday, May 19, 2004 3:18 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri 
>Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>Sent: Tuesday, May 18, 2004 5:59 PM
>To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 5:50 PM
>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri 
>>Madjid-MNAKHJI1; [email-masked]
>>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 4:56 PM
>>To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
>>Cc: Pete McCann; [email-masked]
>>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:[email-masked]]
>>>Sent: Tuesday, May 18, 2004 4:34 PM
>>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; [email-masked]
>>>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: [email-masked] 
>>>[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
>>>Sent: Tuesday, May 18, 2004 3:53 PM
>>>To: [email-masked]
>>>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:[email-masked]]
>>>>Sent: Tuesday, May 18, 2004 3:42 PM
>>>>To: [email-masked]
>>>>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: [email-masked]
>>>>[mailto:[email-masked]]On Behalf Of Bernard Aboba
>>>>Sent: Thursday, April 15, 2004 6:52 PM
>>>>To: [email-masked]
>>>>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 <[email-masked]>
>>>>Bernard Aboba <[email-masked]>
>>>>
>>>>Operations and Management Area Director(s):
>>>>David Kessens <[email-masked]>
>>>>Bert Wijnen <[email-masked]>
>>>>
>>>>Operations and Management Area Advisor:
>>>>David Kessens <[email-masked]>
>>>>
>>>>Technical Advisor:
>>>>Paul Congdon <[email-masked]>
>>>>
>>>>Mailing Lists:
>>>>General Discussion: [email-masked]
>>>>To Subscribe: [email-masked], 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 [email-masked] 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 [email-masked] 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 [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 19 May 2004 22:02:08 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Wed, 19 May 2004 18:01:57 -0400
From: "Nelson, David" <[email-masked]>
To: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>, "Kuntal Chowdhury" <[email-masked]>, <[email-masked]>
Cc: "Pete McCann" <[email-masked]>, <[email-masked]>, "Charles E.Perkins" <[email-masked]>

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

The charter is currently in IESG review.  The announcement went out to
the IETF-Announce list today.

There is quite a bit of work on the charter now.  Unless there is an
urgent requirement from 3GPP or 3GPP2 for this work, or unless another
IETF WG requests it, it would seem inadvisable to take on this
additional work now.

There is always the possibility of re-chartering after all (or most) of
our current deliverables have been achieved.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 19 May 2004 21:54:49 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Kuntal Chowdhury'" <[email-masked]>, [email-masked]
Cc: Pete McCann <[email-masked]>, [email-masked], "'Charles E.Perkins'" <[email-masked]>
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Wed, 19 May 2004 16:53:44 -0500

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:[email-masked]] 
>Sent: Wednesday, May 19, 2004 3:18 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri 
>Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>Sent: Tuesday, May 18, 2004 5:59 PM
>To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 5:50 PM
>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri 
>>Madjid-MNAKHJI1; [email-masked]
>>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 4:56 PM
>>To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
>>Cc: Pete McCann; [email-masked]
>>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:[email-masked]]
>>>Sent: Tuesday, May 18, 2004 4:34 PM
>>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; [email-masked]
>>>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: [email-masked] 
>>>[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
>>>Sent: Tuesday, May 18, 2004 3:53 PM
>>>To: [email-masked]
>>>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:[email-masked]]
>>>>Sent: Tuesday, May 18, 2004 3:42 PM
>>>>To: [email-masked]
>>>>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: [email-masked]
>>>>[mailto:[email-masked]]On Behalf Of Bernard Aboba
>>>>Sent: Thursday, April 15, 2004 6:52 PM
>>>>To: [email-masked]
>>>>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 <[email-masked]>
>>>>Bernard Aboba <[email-masked]>
>>>>
>>>>Operations and Management Area Director(s):
>>>>David Kessens <[email-masked]>
>>>>Bert Wijnen <[email-masked]>
>>>>
>>>>Operations and Management Area Advisor:
>>>>David Kessens <[email-masked]>
>>>>
>>>>Technical Advisor:
>>>>Paul Congdon <[email-masked]>
>>>>
>>>>Mailing Lists:
>>>>General Discussion: [email-masked]
>>>>To Subscribe: [email-masked], 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 [email-masked] 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 [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 19 May 2004 21:14:15 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked]
Cc: Pete McCann <[email-masked]>, [email-masked], "'Charles E.Perkins'" <[email-masked]>
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Wed, 19 May 2004 17:13:41 -0400

In 3GPP2 text:

1. There is no pre-shared secret between the MN and the FA, so let's not
talk about it.

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.

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.

Therefore, I still don't think we need a MIP4 specific RADIUS work. Not from
3GPP2's perspective.

-Kuntal

>-----Original Message-----
>From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
>Sent: Wednesday, May 19, 2004 3:18 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri 
>Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>Sent: Tuesday, May 18, 2004 5:59 PM
>To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 5:50 PM
>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri 
>>Madjid-MNAKHJI1; [email-masked]
>>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 4:56 PM
>>To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
>>Cc: Pete McCann; [email-masked]
>>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:[email-masked]]
>>>Sent: Tuesday, May 18, 2004 4:34 PM
>>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; [email-masked]
>>>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: [email-masked] 
>>>[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
>>>Sent: Tuesday, May 18, 2004 3:53 PM
>>>To: [email-masked]
>>>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:[email-masked]]
>>>>Sent: Tuesday, May 18, 2004 3:42 PM
>>>>To: [email-masked]
>>>>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: [email-masked]
>>>>[mailto:[email-masked]]On Behalf Of Bernard Aboba
>>>>Sent: Thursday, April 15, 2004 6:52 PM
>>>>To: [email-masked]
>>>>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 <[email-masked]>
>>>>Bernard Aboba <[email-masked]>
>>>>
>>>>Operations and Management Area Director(s):
>>>>David Kessens <[email-masked]>
>>>>Bert Wijnen <[email-masked]>
>>>>
>>>>Operations and Management Area Advisor:
>>>>David Kessens <[email-masked]>
>>>>
>>>>Technical Advisor:
>>>>Paul Congdon <[email-masked]>
>>>>
>>>>Mailing Lists:
>>>>General Discussion: [email-masked]
>>>>To Subscribe: [email-masked], 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 [email-masked] 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 [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 19 May 2004 20:24:39 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Kuntal Chowdhury'" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked]
Cc: Pete McCann <[email-masked]>, [email-masked], "'Charles E.Perkins'" <[email-masked]>
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Wed, 19 May 2004 15:17:53 -0500

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:[email-masked]]
Sent: Tuesday, May 18, 2004 5:59 PM
To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Cc: Pete McCann; [email-masked]; '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:[email-masked]] 
>Sent: Tuesday, May 18, 2004 5:50 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri 
>Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>Sent: Tuesday, May 18, 2004 4:56 PM
>To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]
>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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 4:34 PM
>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; [email-masked]
>>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: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
>>Sent: Tuesday, May 18, 2004 3:53 PM
>>To: [email-masked]
>>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:[email-masked]]
>>>Sent: Tuesday, May 18, 2004 3:42 PM
>>>To: [email-masked]
>>>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: [email-masked] 
>>>[mailto:[email-masked]]On Behalf Of Bernard Aboba
>>>Sent: Thursday, April 15, 2004 6:52 PM
>>>To: [email-masked]
>>>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 <[email-masked]>
>>>Bernard Aboba <[email-masked]>
>>>
>>>Operations and Management Area Director(s):
>>>David Kessens <[email-masked]>
>>>Bert Wijnen <[email-masked]>
>>>
>>>Operations and Management Area Advisor:
>>>David Kessens <[email-masked]>
>>>
>>>Technical Advisor:
>>>Paul Congdon <[email-masked]>
>>>
>>>Mailing Lists:
>>>General Discussion: [email-masked]
>>>To Subscribe: [email-masked], 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 [email-masked] 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 [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 May 2004 22:59:54 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked]
Cc: Pete McCann <[email-masked]>, [email-masked], "'Charles E.Perkins'" <[email-masked]>
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Tue, 18 May 2004 18:59:18 -0400

>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:[email-masked]] 
>Sent: Tuesday, May 18, 2004 5:50 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; Nakhjiri 
>Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]; '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:[email-masked]]
>Sent: Tuesday, May 18, 2004 4:56 PM
>To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
>Cc: Pete McCann; [email-masked]
>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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 4:34 PM
>>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; [email-masked]
>>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: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
>>Sent: Tuesday, May 18, 2004 3:53 PM
>>To: [email-masked]
>>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:[email-masked]]
>>>Sent: Tuesday, May 18, 2004 3:42 PM
>>>To: [email-masked]
>>>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: [email-masked] 
>>>[mailto:[email-masked]]On Behalf Of Bernard Aboba
>>>Sent: Thursday, April 15, 2004 6:52 PM
>>>To: [email-masked]
>>>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 <[email-masked]>
>>>Bernard Aboba <[email-masked]>
>>>
>>>Operations and Management Area Director(s):
>>>David Kessens <[email-masked]>
>>>Bert Wijnen <[email-masked]>
>>>
>>>Operations and Management Area Advisor:
>>>David Kessens <[email-masked]>
>>>
>>>Technical Advisor:
>>>Paul Congdon <[email-masked]>
>>>
>>>Mailing Lists:
>>>General Discussion: [email-masked]
>>>To Subscribe: [email-masked], 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 [email-masked] 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 [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 May 2004 22:50:21 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Kuntal Chowdhury'" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked]
Cc: Pete McCann <[email-masked]>, [email-masked], "'Charles E.Perkins'" <[email-masked]>
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Tue, 18 May 2004 17:49:40 -0500

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:[email-masked]]
Sent: Tuesday, May 18, 2004 4:56 PM
To: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Cc: Pete McCann; [email-masked]
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:[email-masked]] 
>Sent: Tuesday, May 18, 2004 4:34 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; [email-masked]
>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: [email-masked] 
>[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
>Sent: Tuesday, May 18, 2004 3:53 PM
>To: [email-masked]
>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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 3:42 PM
>>To: [email-masked]
>>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: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Bernard Aboba
>>Sent: Thursday, April 15, 2004 6:52 PM
>>To: [email-masked]
>>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 <[email-masked]>
>>Bernard Aboba <[email-masked]>
>>
>>Operations and Management Area Director(s):
>>David Kessens <[email-masked]>
>>Bert Wijnen <[email-masked]>
>>
>>Operations and Management Area Advisor:
>>David Kessens <[email-masked]>
>>
>>Technical Advisor:
>>Paul Congdon <[email-masked]>
>>
>>Mailing Lists:
>>General Discussion: [email-masked]
>>To Subscribe: [email-masked], 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
>>[email-masked] 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
>>[email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 May 2004 22:05:14 +0000
Date: Tue, 18 May 2004 15:08:18 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Kuntal Chowdhury <[email-masked]>
cc: [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter

The RADEXT WG charter is based on work requested by SDOs (3GPP, 3GPP2,
IEEE 802, GSMA, etc.) or by IETF WGs (SIPPING).  So far we have no
outstanding requests for RADIUS support for MIPv4.

On Tue, 18 May 2004, Kuntal Chowdhury wrote:

> 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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 May 2004 21:56:33 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, [email-masked]
Cc: Pete McCann <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Tue, 18 May 2004 17:56:01 -0400

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:[email-masked]] 
>Sent: Tuesday, May 18, 2004 4:34 PM
>To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; [email-masked]
>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: [email-masked] 
>[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
>Sent: Tuesday, May 18, 2004 3:53 PM
>To: [email-masked]
>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:[email-masked]]
>>Sent: Tuesday, May 18, 2004 3:42 PM
>>To: [email-masked]
>>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: [email-masked]
>>[mailto:[email-masked]]On Behalf Of Bernard Aboba
>>Sent: Thursday, April 15, 2004 6:52 PM
>>To: [email-masked]
>>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 <[email-masked]>
>>Bernard Aboba <[email-masked]>
>>
>>Operations and Management Area Director(s):
>>David Kessens <[email-masked]>
>>Bert Wijnen <[email-masked]>
>>
>>Operations and Management Area Advisor:
>>David Kessens <[email-masked]>
>>
>>Technical Advisor:
>>Paul Congdon <[email-masked]>
>>
>>Mailing Lists:
>>General Discussion: [email-masked]
>>To Subscribe: [email-masked], 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
>>[email-masked] 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
>>[email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 May 2004 21:34:25 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Kuntal Chowdhury'" <[email-masked]>, [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Tue, 18 May 2004 16:34:10 -0500

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Kuntal Chowdhury
Sent: Tuesday, May 18, 2004 3:53 PM
To: [email-masked]
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:[email-masked]] 
>Sent: Tuesday, May 18, 2004 3:42 PM
>To: [email-masked]
>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: [email-masked] 
>[mailto:[email-masked]]On Behalf Of Bernard Aboba
>Sent: Thursday, April 15, 2004 6:52 PM
>To: [email-masked]
>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 <[email-masked]>
>Bernard Aboba <[email-masked]>
>
>Operations and Management Area Director(s):
>David Kessens <[email-masked]>
>Bert Wijnen <[email-masked]>
>
>Operations and Management Area Advisor:
>David Kessens <[email-masked]>
>
>Technical Advisor:
>Paul Congdon <[email-masked]>
>
>Mailing Lists:
>General Discussion: [email-masked]
>To Subscribe: [email-masked], 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 
>[email-masked] 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 
>[email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 May 2004 20:53:20 +0000
From: "Kuntal Chowdhury" <[email-masked]>
To: [email-masked]
Subject: RE: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Tue, 18 May 2004 16:52:51 -0400

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:[email-masked]] 
>Sent: Tuesday, May 18, 2004 3:42 PM
>To: [email-masked]
>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: [email-masked] 
>[mailto:[email-masked]]On Behalf Of Bernard Aboba
>Sent: Thursday, April 15, 2004 6:52 PM
>To: [email-masked]
>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 <[email-masked]>
>Bernard Aboba <[email-masked]>
>
>Operations and Management Area Director(s):
>David Kessens <[email-masked]>
>Bert Wijnen <[email-masked]>
>
>Operations and Management Area Advisor:
>David Kessens <[email-masked]>
>
>Technical Advisor:
>Paul Congdon <[email-masked]>
>
>Mailing Lists:
>General Discussion: [email-masked]
>To Subscribe: [email-masked], 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 
>[email-masked] 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 
>[email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 May 2004 20:43:00 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: [email-masked]
Subject: RADIUS-Mobile IP support??: RADEXT WG Charter
Date: Tue, 18 May 2004 15:42:02 -0500

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: [email-masked]
[mailto:[email-masked]]On Behalf Of Bernard Aboba
Sent: Thursday, April 15, 2004 6:52 PM
To: [email-masked]
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 <[email-masked]>
Bernard Aboba <[email-masked]>

Operations and Management Area Director(s):
David Kessens <[email-masked]>
Bert Wijnen <[email-masked]>

Operations and Management Area Advisor:
David Kessens <[email-masked]>

Technical Advisor:
Paul Congdon <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked], 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 12 May 2004 00:47:20 +0000
Date: Tue, 11 May 2004 17:50:43 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Call for Agenda Items for IETF 60

In order to submit a schedule request for RADEXT for IETF 60, we now have
to submit an Agenda.

So consider this a call for agenda items.  Please send mail to me or
David, letting us know:

a. The name of the draft you wish to present.
b. Whether you intend to rev the draft by IETF 60.
c. How much time you need.
d. Whether this is a charter item (charter items get priority).

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 10 May 2004 14:33:37 +0000
Date: Mon, 10 May 2004 07:36:55 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: Re: MIB for RFC3576

Only an update for IPv6 is in the charter currently.  To add a MIB,
there needs to be interest from multiple parties in implementing it.

On Mon, 10 May 2004 [email-masked] wrote:

>
> Hi,
>
> There are 2 new drafts describing a MIB for dynamic authorization
> clients and servers (RFC 3576) available at:
>
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-00.txt
>
> http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-00.txt
>
> All comments are welcome.
>
> The charter says that all work has to be compatible with RFC 3576
> and that MIB updates are also part of the charter. Does this mean
> that these drafts are also in scope of the charter after all it
> completes the existing MIBs in RFC2618-2621, or are only the IPv6
> updates without a full revision of the current MIBs the scope of the
> charter?
>
> thanks,
>
> Stefaan
>
> --
> to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 10 May 2004 09:49:05 +0000
Date: Mon, 10 May 2004 11:48:06 +0200
From: [email-masked]
To: [email-masked]
Subject: MIB for RFC3576

Hi,

There are 2 new drafts describing a MIB for dynamic authorization
clients and servers (RFC 3576) available at:

http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-00.txt

http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-00.txt

All comments are welcome.

The charter says that all work has to be compatible with RFC 3576
and that MIB updates are also part of the charter. Does this mean
that these drafts are also in scope of the charter after all it
completes the existing MIBs in RFC2618-2621, or are only the IPv6
updates without a full revision of the current MIBs the scope of the
charter?

thanks,

Stefaan

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 07 May 2004 20:22:42 +0000
Date: Fri, 07 May 2004 13:22:50 -0700
To: "Nelson, David" <[email-masked]>, <[email-masked]>
From: Parviz Yegani <[email-masked]>
Subject: RE: Meeting at IETF 60

Hello, David,

At 04:13 PM 5/7/2004 -0400, Nelson, David wrote:
>Farid writes...
>
> > I agree that we should have a meeting at IETF-60.
> > It is nice to know the chair's thought on this.
>
>I have inquired, off-list, as to the likelihood of having an IESG-approved 
>charter in time to request a WG meeting.  Otherwise, we could request a 
>second BOF.

Hope we can have a WG meeting instead of having yet another BOF. When do 
you expect to hear from IESG?

-Parviz

>-- Dave
>
>
>
>--
>to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 07 May 2004 20:16:36 +0000
Date: Fri, 07 May 2004 13:16:50 -0700
To: "Adrangi, Farid" <[email-masked]>, "Avi Lior" <[email-masked]>, <[email-masked]>
From: Parviz Yegani <[email-masked]>
Subject: RE: Meeting at IETF 60

--=====================_69462121==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Avi, Farid,

Good idea. I'll be there and can attend.

-Parviz

At 01:08 PM 5/7/2004 -0700, Adrangi, Farid wrote:
>Hi Avi,
>it is great that you bring it up now as we don't want to repeat the same 
>fiasco prior to the last IETF meeting!  I agree that we should have a 
>meeting at IETF-60.  It is nice to know the chair's thought on this.
>BR,
>Farid
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Avi Lior
>Sent: Friday, May 07, 2004 10:28 AM
>To: [email-masked]
>Subject: Meeting at IETF 60
>
>Hi All,
>
>I would like to propose that we have a meeting at IETF-60.
>
>Avi
>

--=====================_69462121==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Avi, Farid,<br>
<br>
Good idea. I'll be there and can attend.<br>
<br>
-Parviz<br>
<br>
At 01:08 PM 5/7/2004 -0700, Adrangi, Farid wrote:<br>
<blockquote type=cite cite><font face="arial" size=2 color="#0000FF">Hi
Avi,</font><br>
<font face="arial" size=2 color="#0000FF">it is great that you bring it
up now as we don't want to repeat the same fiasco prior to the last IETF
meeting!&nbsp; I agree that we should have a meeting at IETF-60.&nbsp; It
is nice to know the chair's thought on this.</font><br>
<font face="arial" size=2 color="#0000FF">BR,</font><br>
<font face="arial" size=2 color="#0000FF">Farid</font>
<dl><font face="tahoma" size=2>
<dd>-----Original Message-----
<dd>From:</b> [email-masked]
[<a href="mailto:[email-masked]" eudora="autourl">mailto:[email-masked]</a>]
On Behalf Of </b>Avi Lior
<dd>Sent:</b> Friday, May 07, 2004 10:28 AM
<dd>To:</b> [email-masked]
<dd>Subject:</b> Meeting at IETF 60<br>
<br>
</font><font face="arial" size=2 color="#0000FF">
<dd>Hi All,</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>I would like to propose that we have a meeting at IETF-60.</font>
<dd>&nbsp;<font face="arial" size=2 color="#0000FF">
<dd>Avi</font>
<dd>&nbsp;
</dl></blockquote></html>

--=====================_69462121==_.ALT--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 07 May 2004 20:13:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Meeting at IETF 60
Date: Fri, 7 May 2004 16:13:12 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Farid writes...

> I agree that we should have a meeting at IETF-60.=A0=20
> It is nice to know the chair's thought on this.

I have inquired, off-list, as to the likelihood of having an =
IESG-approved charter in time to request a WG meeting.  Otherwise, we =
could request a second BOF.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 07 May 2004 20:08:25 +0000
Content-Class: urn:content-classes:message
Subject: RE: Meeting at IETF 60
Date: Fri, 7 May 2004 13:08:03 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4346F.00FA4D9C
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Avi,
it is great that you bring it up now as we don't want to repeat the same
fiasco prior to the last IETF meeting!  I agree that we should have a
meeting at IETF-60.  It is nice to know the chair's thought on this.
BR,
Farid

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Avi Lior
	Sent: Friday, May 07, 2004 10:28 AM
	To: [email-masked]
	Subject: Meeting at IETF 60
=09
=09
	Hi All,
	=20
	I would like to propose that we have a meeting at IETF-60.
	=20
	Avi
	=20

------_=_NextPart_001_01C4346F.00FA4D9C
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1170" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<DIV><SPAN class=3D492480320-07052004><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Avi,</FONT></SPAN></DIV>
<DIV><SPAN class=3D492480320-07052004><FONT face=3DArial color=3D#0000ff =
size=3D2>it is=20
great that you bring it up now as we don't want to repeat the same =
fiasco prior=20
to the last IETF meeting! &nbsp;I agree that we should have a meeting at =

IETF-60.&nbsp; It is nice to know the chair's thought on=20
this.</FONT></SPAN></DIV>
<DIV><SPAN class=3D492480320-07052004><FONT face=3DArial color=3D#0000ff =

size=3D2>BR,</FONT></SPAN></DIV>
<DIV><SPAN class=3D492480320-07052004><FONT face=3DArial color=3D#0000ff =

size=3D2>Farid</FONT></SPAN></DIV></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Avi Lior<BR><B>Sent:</B> Friday, May 07, 2004 10:28=20
  AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Meeting at =
IETF=20
  60<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D599102517-07052004>Hi=20
  All,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D599102517-07052004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D599102517-07052004>I=20
  would like to propose that we have a meeting at =
IETF-60.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D599102517-07052004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D599102517-07052004>Avi</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>
=00
------_=_NextPart_001_01C4346F.00FA4D9C--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 07 May 2004 20:00:24 +0000
From: "Ed Van Horne" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, <[email-masked]>
Subject: RE: Meeting at IETF 60
Date: Fri, 7 May 2004 12:59:55 -0700
Organization: Cisco Systems

This is a multi-part message in MIME format.

------=_NextPart_000_039D_01C43433.31FAC130
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I can be there, since I live in San Diego.
 
Ed
 
Ed Van Horne 
NMTG - San Diego 
Cisco Systems 
10935 Vista Sorrento Parkway 
San Diego, CA 92130 
858.526.1152 
 
P.S.: What's up with IETF? We meet in Minneapolis in November and San
Diego in August? I would have done it the other way around. ;-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Avi Lior
Sent: Friday, May 07, 2004 10:28 AM
To: [email-masked]
Subject: Meeting at IETF 60

Hi All,
 
I would like to propose that we have a meeting at IETF-60.
 
Avi

------=_NextPart_000_039D_01C43433.31FAC130
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D564595619-07052004><FONT face=3DArial color=3D#0000ff =
size=3D2>I can=20
be there, since I live in San Diego.</FONT></SPAN></DIV>
<DIV><SPAN class=3D564595619-07052004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D564595619-07052004><FONT face=3DArial color=3D#0000ff =

size=3D2>Ed</FONT></SPAN></DIV>
<DIV><SPAN class=3D564595619-07052004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D564595619-07052004>
<DIV align=3Dleft><FONT color=3D#0000ff><FONT face=3D"Comic Sans =
MS"><FONT size=3D-1>Ed=20
Van Horne</FONT></FONT> <BR><FONT face=3D"Comic Sans MS"><FONT =
size=3D-1>NMTG - San=20
Diego</FONT></FONT> <BR><FONT face=3D"Comic Sans MS"><FONT =
size=3D-1>Cisco=20
Systems</FONT></FONT> <BR><FONT face=3D"Comic Sans MS"><FONT =
size=3D-1>10935 Vista=20
Sorrento Parkway</FONT></FONT> <BR><FONT face=3D"Comic Sans MS"><FONT =
size=3D-1>San=20
Diego, CA 92130</FONT></FONT> <BR><FONT face=3D"Comic Sans MS"><FONT=20
size=3D-1>858.526.1152</FONT></FONT> </FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Comic Sans MS" color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft><SPAN class=3D564595619-07052004><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>P.S.: What's up with IETF? We meet in Minneapolis in November =
and San=20
Diego in August? I would have done it the other way around.=20
;-)</FONT></SPAN></DIV></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Avi Lior<BR><B>Sent:</B> Friday, May 07, 2004 10:28=20
  AM<BR><B>To:</B> [email-masked]<BR><B>Subject:</B> Meeting at =
IETF=20
  60<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D599102517-07052004>Hi=20
  All,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D599102517-07052004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D599102517-07052004>I=20
  would like to propose that we have a meeting at =
IETF-60.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D599102517-07052004></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D599102517-07052004>Avi</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_039D_01C43433.31FAC130--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 07 May 2004 17:28:21 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: Meeting at IETF 60
Date: Fri, 7 May 2004 13:27:53 -0400 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C43458.A0D0C760
Content-Type: text/plain

Hi All,
 
I would like to propose that we have a meeting at IETF-60.
 
Avi

------_=_NextPart_001_01C43458.A0D0C760
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=599102517-07052004>Hi 
All,</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=599102517-07052004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=599102517-07052004>I 
would like to propose that we have a meeting at IETF-60.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=599102517-07052004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=599102517-07052004>Avi</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C43458.A0D0C760--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 06 May 2004 08:30:19 +0000
Date: Thu, 06 May 2004 10:29:38 +0200
From: Nagi <[email-masked]>
Reply-To: [email-masked]
Organization: Alcatel Telecom
To: "Nelson, David" <[email-masked]>
CC: [email-masked]
Subject: Re: authorization of sub-sessions

--------------34BBBC19491C8CC0AF601F36
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Kuntal, David and all,

The base RFCs(RFC-2865 and RFC-2866) support a user having multiple
sessions. See the definition of "session" below.

Session:
             Each service provided by the NAS to a dial-in user
             constitutes a session, with the beginning of the session
             defined as the point where service is first provided and
             the end of the session defined as the point where service
             is ended.  *A user may have multiple sessions* in parallel
or
             series if the NAS supports that, with each session
             generating a separate start and stop accounting record with

             its own Acct-Session-Id.

Accounting seems to be OK:

It believe that handling multiple sessions accounting is clearly
supported by the RFC-2866. i.e., each susession will have its own
accounting session ID.  Also it appears to me that Acct-Multi-Session-Id
is also used in conjunction with Accounting session ID to group the same
user accounting.  Though I'm not sure of the real intention of
introducing Acct-Multi-Session-Id.

See the definition of Acct-Multi-Session-Id.

" This attribute is a unique Accounting ID to make it easy to link
      together multiple related sessions in a log file.  Each session
      linked together would have a unique Acct-Session-Id but the same
      Acct-Multi-Session-Id".

Authentication also is basically ok

After a user is authenticated, if the user wants to start a new
subsession, he needs a re-authorization but not re-authentication.
Though the RFC-2865 doesn't restrict having mutiple subsessions, it
doesn't describe either how to handle subsessions.

IMO, we need two things for re-authorization:

a. Sending an access-request that clearly say this is an
"Authorize-only" request but not a new authentication request.
b.  Attributes that describe what type of service is needed for the new
subsession.  Depending on the application
    new attributes can be added.

The solution for (a) could be to use the Access request with the Service
Type "Authorize-Only" which is defined in RFC-3576 already.

regards
Nagi.

"Nelson, David" wrote:

> Posted on behalf of Kuntal Chowdhury:
>
> >Hi all,
> >
> >During a recent 3GPP2-IETF co-ordination call the issue of
> >authorization of multiple auxiliary sub-sessions under a PPP
> >session came up. In 3GPP2 these sub sessions (termed auxiliary
> >service instance) are initiated to support applications that
> >need special treatments e.g. better than best effort QoS,
> >header compression etc. Today, these sub sessions are not
> >authorized using RADIUS messages (AR/AA). However, there are
> >special accounting needs for these sub sessions i.e. separate
> >accounting buckets are maintained for each of these sub
> >sessions in the NAS.
> >
> >The intent of posting this message here is to initiate some
> >discussion on sub sessions and possible RADIUS interaction.
> >
> >What would be the proper way to deal with these sub sessions?
> >Do we need to define RADIUS procedures to handle auth and
> >accounting of these sub sessions?
> >Is there a possible link between the sub sessions and the need
> >for sub types? Does the current (agreed) charter for RADEXT
> >cover such a thing?
> >
> >-Kuntal
> >
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--------------34BBBC19491C8CC0AF601F36
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Kuntal, David and all,
<p>The base RFCs(RFC-2865 and RFC-2866)&nbsp;support a user having multiple
sessions. See the definition of "session" below.
<br>&nbsp;
<p>Session:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Each service provided by the NAS to a dial-in user
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
constitutes a session, with the beginning of the session
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
defined as the point where service is first provided and
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
the end of the session defined as the point where service
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
is ended.&nbsp; *A user may have multiple sessions* in parallel or
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
series if the NAS supports that, with each session
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
generating a separate start and stop accounting record with
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
its own Acct-Session-Id.
<p><b><u>Accounting seems to be OK:</u></b>
<br>&nbsp;
<p>It believe that handling multiple sessions accounting is clearly supported
by the RFC-2866. i.e., each susession will have its own accounting session
ID.&nbsp; Also it appears to me that Acct-Multi-Session-Id is also used
in conjunction with Accounting session ID&nbsp;to group the same user accounting.&nbsp;
Though I'm not sure of the real intention of introducing Acct-Multi-Session-Id.
<p>See the definition of Acct-Multi-Session-Id.
<p>" This attribute is a unique Accounting ID to make it easy to link
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; together multiple related sessions in
a log file.&nbsp; Each session
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; linked together would have a unique
Acct-Session-Id but the same
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Acct-Multi-Session-Id".
<p><b><u>Authentication also is basically ok</u></b>
<br>&nbsp;
<p>After a user is authenticated, if the user wants to start a new subsession,
he needs a re-authorization but not re-authentication. Though the RFC-2865
doesn't restrict having mutiple subsessions, it doesn't describe either
how to handle subsessions.
<p>IMO, we need two things for re-authorization:
<p>a. Sending an access-request that clearly say this is an "Authorize-only"
request but not a new authentication request.
<br>b.&nbsp; Attributes that describe what type of service is needed for
the new subsession.&nbsp; Depending on the application
<br>&nbsp;&nbsp;&nbsp; new attributes can be added.
<br>&nbsp;
<p>The solution for (a) could be to use the Access request with the Service
Type "Authorize-Only" which is defined in RFC-3576 already.
<p>regards
<br>Nagi.
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<p>"Nelson, David" wrote:
<blockquote TYPE=CITE>Posted on behalf of Kuntal Chowdhury:
<p>>Hi all,
<br>>
<br>>During a recent 3GPP2-IETF co-ordination call the issue of
<br>>authorization of multiple auxiliary sub-sessions under a PPP
<br>>session came up. In 3GPP2 these sub sessions (termed auxiliary
<br>>service instance) are initiated to support applications that
<br>>need special treatments e.g. better than best effort QoS,
<br>>header compression etc. Today, these sub sessions are not
<br>>authorized using RADIUS messages (AR/AA). However, there are
<br>>special accounting needs for these sub sessions i.e. separate
<br>>accounting buckets are maintained for each of these sub
<br>>sessions in the NAS.
<br>>
<br>>The intent of posting this message here is to initiate some
<br>>discussion on sub sessions and possible RADIUS interaction.
<br>>
<br>>What would be the proper way to deal with these sub sessions?
<br>>Do we need to define RADIUS procedures to handle auth and
<br>>accounting of these sub sessions?
<br>>Is there a possible link between the sub sessions and the need
<br>>for sub types? Does the current (agreed) charter for RADEXT
<br>>cover such a thing?
<br>>
<br>>-Kuntal
<br>>
<p>--
<br>to unsubscribe send a message to [email-masked] with
<br>the word 'unsubscribe' in a single line as the message text body.
<br>archive: &lt;<a href="http://psg.com/lists/radiusext/">http://psg.com/lists/radiusext/</a>></blockquote>
</html>

--------------34BBBC19491C8CC0AF601F36--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 05 May 2004 17:59:13 +0000
Content-class: urn:content-classes:message
Subject: authorization of sub-sessions
Date: Wed, 5 May 2004 13:58:47 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Posted on behalf of Kuntal Chowdhury:

>Hi all,
>
>During a recent 3GPP2-IETF co-ordination call the issue of=20
>authorization of multiple auxiliary sub-sessions under a PPP=20
>session came up. In 3GPP2 these sub sessions (termed auxiliary=20
>service instance) are initiated to support applications that=20
>need special treatments e.g. better than best effort QoS,=20
>header compression etc. Today, these sub sessions are not=20
>authorized using RADIUS messages (AR/AA). However, there are=20
>special accounting needs for these sub sessions i.e. separate=20
>accounting buckets are maintained for each of these sub=20
>sessions in the NAS.
>
>The intent of posting this message here is to initiate some=20
>discussion on sub sessions and possible RADIUS interaction.=20
>
>What would be the proper way to deal with these sub sessions?=20
>Do we need to define RADIUS procedures to handle auth and=20
>accounting of these sub sessions?=20
>Is there a possible link between the sub sessions and the need=20
>for sub types? Does the current (agreed) charter for RADEXT=20
>cover such a thing?
>
>-Kuntal
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 05 May 2004 06:12:46 +0000
From: Greg Weber <[email-masked]>
Subject: RADIUS attribute design: some thoughts
To: [email-masked]
Date: Wed, 5 May 2004 02:10:59 -0400 (EDT)

In thinking about the RADIUS design guidelines work item 
from the current proposed charter, I thought it might provide
some insight to look at some specific ways in which the VSA 
space is evolving.  In part, it appears to be diverging from 
the data type encodings of the standard space due to simple
lack of recommended route.

Taking the SDOs as a microcosm of VSA usage, here are some
usages I see in IS-835 (3GPP2), TS-129.061 (3GPP), and 
PacketCable 1.0 (CableLabs).[*]

  * Grouping data for
     .Compactness
       As with bit flags, multiply valued attributes (e.g. a list of IP
       addresses), and various overloaded strings which need parsing.
     .Logical relationship
       Attributes which describe multiple aspects of a single entity.
       RADIUS provides tags for this, but I haven't seen much usage of
       that mechanism in VSAs; sub attributes seem more popular and
       are probably more extensible.
     .Shared information
       As with a group of attributes which share a common timestamp, or
       a group of counters related to a common remote IP address.

  * Per-attribute encryption
     Perhaps a reaction to the overhead of IPsec or maybe to satisfy
     regulatory requirements for particular data items. 

  * Fragmentation across VSAs
     For single VSA values exceeding the valid length of one attribute.
     These schemes seem to rely on the packet ordering/reordering
     restrictions on proxies- as does EAP.

Diameter seems to accommodate most of these expressed needs- except
perhaps compactness which may be an inappropriate goal for a protocol
that uses self-described data (vs. GTP' or IPFIX).

For RADIUS, I think the RADEXT attribute design guide should address
at least these areas.  

Greg

[*]
http://www.3gpp2.com/Public_html/specs/X.S0011-005-C_v1.0_110703.pdf
http://webapp.etsi.org/action%5CPU/20031007/ts_129061v050700p.pdf
http://www.packetcable.com/downloads/specs/PKT-SP-EM-I09-040402.pdf

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 20:17:17 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: redirection+prepaid
Date: Tue, 4 May 2004 16:16:58 -0400 

Hi Stefaan and all

As you point out, rhe problem with extending the text field for this
attribute is that we would break Diameter.  I borrowed heavily from
Diameter.

Having said that in the next version of Redirection Draft, for different
reasons, I had to change the syntax of that string.

Here is the reason:
If you want to remove a filter-rule or redirection-rule using COA push model
then you have to send an attribute that you want to change.  If you don't
then the NAS will keep the attribute. By sending an attribute the NAS will
replace all other attributes of the same type.  

BTW: The COA push model allows the RADIUS server to push attributes that it
wants to change to the NAS. The other model is what I call the COA pull
model which is a COA message that forces the NAS to reauthorize (send an
Access-Request Service-Type Authorize-Only) and receives all the attributes
in the Access-Accept message (hence "pull model").  The push model is not
supported by Diameter.

So two options:

a) Keep the syntax the same. Therefore I would have to send a benign rule
that will replace the other attributes; or

b) Change the syntax slightly eg. If the attribute is set to "flush" then
this flushes all the rules;

I like option b). 

Note a couple of things:

1) Option b) could be extended so that we can selectively remove
filter/redirection rules.

2) It does break the Diameter syntax but note that Diameter doesn't even
support the COA push model for changing attributes so we would have to have
some translation.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: May 4, 2004 3:50 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: redirection+prepaid
> 
> 
> 
> Hi Avi,
> 
> Ok, I see. In fact I was thinking about extending the text 
> field in for instance the NAS-Filter-Rule from "action dir 
> proto from src to dst [options]" to "action dir proto from 
> src to dst activation [options] " where activation can have 
> values "immediately", "quota_expired", ... this has the 
> problem that all possible cases has to be enumerated and that 
> it might not line up with diameter. Anyhow, the two options 
> below are also fine.
> 
> regards,
> Stefaan
> 
> 
> Avi Lior wrote:
> > 
> > Hi Stefaan and all,
> > 
> > Your question is very timely and right on.  We are 
> currently working 
> > on this in 3GPP2.
> > 
> > Putting an attribute to indicate when something applies may 
> not work.  
> > It is possible that even under normal circumstances the session may 
> > have a filter applied.  In the case where it's a prepaid session it 
> > could be that I have a filter/redirect attributes to be 
> applied when 
> > quota runs out and a filter id to be applied immediately.  Since we 
> > cannot guarantee the order of different attributes this 
> will be hard 
> > to do with an additional attribute.  If we could however group the 
> > redirection/filter attributes with the prepaid stuff then 
> this would 
> > do the trick.  That is the essence of Option 2 below.
> > 
> > I have identified two options (there could be others):
> > 
> > Option 1:
> > =========
> > 
> > When the quota reaches zero, in 3GPP2 the session is 
> terminated and an 
> > Access-Request Authorize-Only is sent back to report that 
> the session 
> > has terminated etc...
> > 
> > My suggestion is to not terminate the session but rather, 
> wait for the 
> > reply to the Access-Request (above).  That reply would be either:
> > 
> > an Access-Reject (no quota drop the user) or;
> > an Access-Accept with new quota (after all the user may have topped 
> > his
> > account) or;
> > an Access-Accept with redirection attributes.
> > 
> > Problem with Option 1 is that during the time when we wait for the 
> > response to the Access-Request there could be revenue leakage.  Any 
> > use could be applied to the new quota.  So we would only 
> have revenue 
> > leakage if the user doesn't top up.  Also it could be the case that 
> > the NAS will drop the session anyway after some (locally 
> configured) 
> > timeout period.
> > 
> > Option 2:
> > =========
> > 
> > For prepaid put the Redirection/Filter attributes in the PPAQ.  
> > Doesn't change the behavior of prepaid as specified by 
> 3GPP2. The NAS 
> > would apply any filter/redirection attributes it finds outside the 
> > PPAQ immediately.  Those in the PPAQ would be acted on when 
> the quota 
> > runs out.
> > 
> > This is what I have on the table in 3GPP2.
> > 
> > Note the following:
> > ===================
> > 
> > a) 3GPP2 folks have not given me a clear indication of what is the 
> > best option.  We are addressing this now so I will know 
> their opinions 
> > shortly.
> > 
> > b) I preffer option 1 but not sure about how operators will 
> feel about 
> > revenue leakage of several seconds.  Option 1 fixes the 
> problem of the 
> > subscriber toping off his account. Yes you have some potential for 
> > leakage but you may prevent a user from calling the call center to 
> > complain.  Not for me to decide which is better.
> > 
> > c) I have to check what Diameter-CC does about this.  I would very 
> > much like to have Diameter-CC, 3GPP2 and RADIUS converge on prepaid.
> > 
> > Finally, I would very much like to hear what other folks 
> have to say 
> > about this.
> > 
> > I really appreciate your comments.
> > 
> > Avi
> > 
> > > -----Original Message-----
> > > From: [email-masked] 
> > > [mailto:[email-masked]]
> > > Sent: May 4, 2004 12:43 PM
> > > To: [email-masked]
> > > Subject: redirection+prepaid
> > >
> > >
> > >
> > > Hi,
> > >
> > > I was wondering how the redirection in 
> > > draft-lior-radius-redirection-00 can be used for prepaid: the 
> > > filters/redirect is applied by the NAS as soon the attributes are 
> > > received by the NAS (either in access accept or CoA). How 
> can this 
> > > then be used for prepaid when the filters have to be applied when 
> > > there is no quota anymore? Would it not be better to add 
> something 
> > > to indicate when it has to be applied (e.g., immediately, when no 
> > > quota anymore, ...)?
> > >
> > > regards,
> > >
> > > Stefaan
> > >
> > > --
> > > to unsubscribe send a message to 
> [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 19:50:36 +0000
Date: Tue, 04 May 2004 21:50:19 +0200
From: [email-masked]
To: Avi Lior <[email-masked]>
CC: [email-masked]
Subject: Re: redirection+prepaid

Hi Avi,

Ok, I see. In fact I was thinking about extending the text field in
for instance the NAS-Filter-Rule from "action dir proto from src to
dst [options]" to "action dir proto from src to dst activation
[options] " where activation can have values "immediately",
"quota_expired", ... this has the problem that all possible cases
has to be enumerated and that it might not line up with diameter.
Anyhow, the two options below are also fine.

regards,
Stefaan

Avi Lior wrote:
> 
> Hi Stefaan and all,
> 
> Your question is very timely and right on.  We are currently working on this
> in 3GPP2.
> 
> Putting an attribute to indicate when something applies may not work.  It is
> possible that even under normal circumstances the session may have a filter
> applied.  In the case where it's a prepaid session it could be that I have a
> filter/redirect attributes to be applied when quota runs out and a filter id
> to be applied immediately.  Since we cannot guarantee the order of different
> attributes this will be hard to do with an additional attribute.  If we
> could however group the redirection/filter attributes with the prepaid stuff
> then this would do the trick.  That is the essence of Option 2 below.
> 
> I have identified two options (there could be others):
> 
> Option 1:
> =========
> 
> When the quota reaches zero, in 3GPP2 the session is terminated and an
> Access-Request Authorize-Only is sent back to report that the session has
> terminated etc...
> 
> My suggestion is to not terminate the session but rather, wait for the reply
> to the Access-Request (above).  That reply would be either:
> 
> an Access-Reject (no quota drop the user) or;
> an Access-Accept with new quota (after all the user may have topped his
> account) or;
> an Access-Accept with redirection attributes.
> 
> Problem with Option 1 is that during the time when we wait for the response
> to the Access-Request there could be revenue leakage.  Any use could be
> applied to the new quota.  So we would only have revenue leakage if the user
> doesn't top up.  Also it could be the case that the NAS will drop the
> session anyway after some (locally configured) timeout period.
> 
> Option 2:
> =========
> 
> For prepaid put the Redirection/Filter attributes in the PPAQ.  Doesn't
> change the behavior of prepaid as specified by 3GPP2.
> The NAS would apply any filter/redirection attributes it finds outside the
> PPAQ immediately.  Those in the PPAQ would be acted on when the quota runs
> out.
> 
> This is what I have on the table in 3GPP2.
> 
> Note the following:
> ===================
> 
> a) 3GPP2 folks have not given me a clear indication of what is the best
> option.  We are addressing this now so I will know their opinions shortly.
> 
> b) I preffer option 1 but not sure about how operators will feel about
> revenue leakage of several seconds.  Option 1 fixes the problem of the
> subscriber toping off his account. Yes you have some potential for leakage
> but you may prevent a user from calling the call center to complain.  Not
> for me to decide which is better.
> 
> c) I have to check what Diameter-CC does about this.  I would very much like
> to have Diameter-CC, 3GPP2 and RADIUS converge on prepaid.
> 
> Finally, I would very much like to hear what other folks have to say about
> this.
> 
> I really appreciate your comments.
> 
> Avi
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]
> > Sent: May 4, 2004 12:43 PM
> > To: [email-masked]
> > Subject: redirection+prepaid
> >
> >
> >
> > Hi,
> >
> > I was wondering how the redirection in
> > draft-lior-radius-redirection-00 can be used for prepaid: the
> > filters/redirect is applied by the NAS as soon the attributes
> > are received by the NAS (either in access accept or CoA). How
> > can this then be used for prepaid when the filters have to be
> > applied when there is no quota anymore? Would it not be
> > better to add something to indicate when it has to be applied
> > (e.g., immediately, when no quota anymore, ...)?
> >
> > regards,
> >
> > Stefaan
> >
> > --
> > to unsubscribe send a message to
> > [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 19:47:41 +0000
content-class: urn:content-classes:message
Subject: RE: redirection+prepaid
Date: Tue, 4 May 2004 12:43:47 -0700
From: "Blair T. Bullock" <[email-masked]>
To: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C43210.1E0CA55D
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C43210.1E0CA55D
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C43210.1E0CA55D--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 19:41:10 +0000
content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Tue, 4 May 2004 22:40:54 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Jari,

> This would make it be late from, say, 3GPP release 6 specifications
> which probably would like to refer to an IETF spec on this.
> Can you remind me why there is a dependency on the guidelines
> and WLAN attributes? I had been assuming that the guidelines
> are needed if you do something complicated, like subattributes
> or SDO-specific attributes. But I'm not sure we need them
> for the WLAN attrs draft. Or I would hope we can get by without
> them -- maybe I'm mistaken.

Well, as I understand, 3GPP is looking at having things wrapped-up
for Rel. 6 by September, so I doubt there is anyway to get anything
ready for that.

Perhaps it would be best to handle any 3GPP dependencies via the
3GPP liason.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 19:08:55 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked]
Subject: RE: redirection+prepaid
Date: Tue, 4 May 2004 15:08:35 -0400 

Hi Stefaan and all,

Your question is very timely and right on.  We are currently working on this
in 3GPP2.

Putting an attribute to indicate when something applies may not work.  It is
possible that even under normal circumstances the session may have a filter
applied.  In the case where it's a prepaid session it could be that I have a
filter/redirect attributes to be applied when quota runs out and a filter id
to be applied immediately.  Since we cannot guarantee the order of different
attributes this will be hard to do with an additional attribute.  If we
could however group the redirection/filter attributes with the prepaid stuff
then this would do the trick.  That is the essence of Option 2 below.

I have identified two options (there could be others):

Option 1:
=========

When the quota reaches zero, in 3GPP2 the session is terminated and an
Access-Request Authorize-Only is sent back to report that the session has
terminated etc...

My suggestion is to not terminate the session but rather, wait for the reply
to the Access-Request (above).  That reply would be either:

an Access-Reject (no quota drop the user) or;
an Access-Accept with new quota (after all the user may have topped his
account) or;
an Access-Accept with redirection attributes.

Problem with Option 1 is that during the time when we wait for the response
to the Access-Request there could be revenue leakage.  Any use could be
applied to the new quota.  So we would only have revenue leakage if the user
doesn't top up.  Also it could be the case that the NAS will drop the
session anyway after some (locally configured) timeout period.

Option 2:
=========

For prepaid put the Redirection/Filter attributes in the PPAQ.  Doesn't
change the behavior of prepaid as specified by 3GPP2.
The NAS would apply any filter/redirection attributes it finds outside the
PPAQ immediately.  Those in the PPAQ would be acted on when the quota runs
out.

This is what I have on the table in 3GPP2. 

Note the following:
===================

a) 3GPP2 folks have not given me a clear indication of what is the best
option.  We are addressing this now so I will know their opinions shortly.

b) I preffer option 1 but not sure about how operators will feel about
revenue leakage of several seconds.  Option 1 fixes the problem of the
subscriber toping off his account. Yes you have some potential for leakage
but you may prevent a user from calling the call center to complain.  Not
for me to decide which is better.

c) I have to check what Diameter-CC does about this.  I would very much like
to have Diameter-CC, 3GPP2 and RADIUS converge on prepaid.  

Finally, I would very much like to hear what other folks have to say about
this.

I really appreciate your comments.

Avi

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: May 4, 2004 12:43 PM
> To: [email-masked]
> Subject: redirection+prepaid
> 
> 
> 
> Hi,
> 
> I was wondering how the redirection in 
> draft-lior-radius-redirection-00 can be used for prepaid: the 
> filters/redirect is applied by the NAS as soon the attributes 
> are received by the NAS (either in access accept or CoA). How 
> can this then be used for prepaid when the filters have to be 
> applied when there is no quota anymore? Would it not be 
> better to add something to indicate when it has to be applied 
> (e.g., immediately, when no quota anymore, ...)?
> 
> regards,
> 
> Stefaan
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 18:08:51 +0000
Date: Tue, 04 May 2004 21:05:30 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADIUS drafts review -- LAN attributes

Nelson, David wrote:

> We did have an extended debate over subtypes.  We need to see if
> consensus has emerged, or if we've all simply grown weary of the debate.

;-)

My suggestion is to avoid this debate for the {,W}LAN
attributes work. Lets keep it simple.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 18:06:33 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Tue, 4 May 2004 14:06:24 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> [FA] I don't think we need design guidelines for LAN attributes
> (including WLAN) -- because as Jari said this is not a complicated
task.

Perhaps not.  There's certainly no issue with starting these work items
in parallel.  It should soon become obvious if there *is* a need to
apply the design guidelines.  Of course, *if* there is a need
identified, then finishing the design guidelines first would be the
proper procedure, much like completing the requirements document before
you design the protocol.

> Could you be more specific what you have in mind for design
guidelines?
> We spent over 6 month arguing about subtypes -- and if we spend
another
> 6 month arguing the design guidelines, for sure we will never get this
> done!

We did have an extended debate over subtypes.  We need to see if
consensus has emerged, or if we've all simply grown weary of the debate.
Once the consensus is determined we need to write it down in the design
guidelines, or run the risk of having the same 6-month debate at some
future time.  :-(

Creating the design guidelines is an important work item, and per our
milestones, it is one of the first deliverables.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 17:21:40 +0000
Content-Class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Tue, 4 May 2004 10:19:33 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>, <[email-masked]>
Cc: "Nelson, David" <[email-masked]>

Hi Dan,
Thanks.  In that case, Please allow me to post an update version in a
day or two for our discussion.
BR,
FArid

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email-masked]]=20
> Sent: Tuesday, May 04, 2004 7:03 AM
> To: Adrangi, Farid; [email-masked]
> Cc: Nelson, David
> Subject: RE: RADIUS drafts review -- LAN attributes
>=20
>=20
> Farid,
>=20
> draft-adrangi-radius-extension-for-pwlan-00.txt is expired=20
> and not available any longer in the IETF repository. I guess=20
> that you intent to re-submit it, as you are requiring=20
> comments. Do you have an alternative URL to access it meantime?
>=20
> Thanks and Regards,
>=20
> Dan
>=20
>=20
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Adrangi, Farid
> > Sent: 04 May, 2004 1:04 AM
> > To: [email-masked]
> > Cc: Nelson, David
> > Subject: RE: RADIUS drafts review -- LAN attributes
> >=20
> >=20
> > Hi David, all
> >=20
> > There are a number of drafts on LAN attributes:
> >=20
> > 1) http://www.ietf.org/internet-drafts/draft-lior-radius-redirect
> > ion-00.txt
> >=20
> > 2) http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandw
> > idth-capab
> > ility-00.txt
> >=20
> > 3) There were two original drafts on LAN attributes: black=20
> and adrangi
> > drafts:=20
> http://www.ietf.org/internet-drafts/draft-adrangi-radius-exten
> sion-for-p
> wlan-00.txt
>=20
> Note : Couldn't find the link for Black's draft.  Chuck please advise.
>=20
> There were a number of LAN attributes proposed in these two=20
> drafts. Some of the attributes were already taken into=20
> separate drafts like location information and network=20
> bandwidth authorization.  However, we need to scrub the=20
> remaining of attributes. =20
>=20
> 4) There were two drafts on location information (adrangi and jones
> drafts) -- these drafts were moved to the GeoPriv WG. We are=20
> currently working on a combined draft  -- plan to submit it=20
> in a few weeks.  For those folks who are interested, please=20
> subscribe to GeoPriv mailing list.
>=20
> Did I miss anything?
>=20
> BR,
> Farid
>=20
>=20
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Nelson, David
> > Sent: Monday, May 03, 2004 2:30 PM
> > To: [email-masked]
> > Subject: RE: RADIUS drafts review -- LAN attributes
> >=20
> >=20
> >=20
> > > In the last BoF, a number of people volunteered to be
> > reviewer for LAN
> > > attribute drafts.
> >=20
> > Farid, would you please remind us where the most current
> > version of this draft is posted?  Thanks!
> >=20
> > -- Dave
> >=20
> >=20
> >=20
> > --
> > to unsubscribe send a message to
> > [email-masked] with the word 'unsubscribe' in=20
> > a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 16:42:56 +0000
Date: Tue, 04 May 2004 18:42:37 +0200
From: [email-masked]
To: [email-masked]
Subject: redirection+prepaid

Hi,

I was wondering how the redirection in
draft-lior-radius-redirection-00 can be used for prepaid: the
filters/redirect is applied by the NAS as soon the attributes are
received by the NAS (either in access accept or CoA). How can this
then be used for prepaid when the filters have to be applied when
there is no quota anymore? Would it not be better to add something
to indicate when it has to be applied (e.g., immediately, when no
quota anymore, ...)?

regards,

Stefaan

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 16:15:48 +0000
Content-Class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Tue, 4 May 2004 09:15:23 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

> Jari writes...
>=20
>=20
> > Can you remind me why there is a dependency on the=20
> guidelines and WLAN=20
> > attributes?
>=20
> I think this thread is discussing the LAN attributes draft,=20
> although there may not be a significant distinction.
>=20
[FA]  There is no distinction at all.  I think there was a consensus to
put all attributes under a generic name, LAN attributes.
[/FA]

> > I had been assuming that the guidelines
> > are needed if you do something complicated, like subattributes or=20
> > SDO-specific attributes. But I'm not sure we need them for the WLAN=20
> > attrs draft.
>=20
> I'm not sure, either.  I guess that depends on how the draft=20
> shapes up. I simply hold that out as a possibility.  I would=20
> like to see work on the design guidelines begin immediately=20
> (in parallel with other work) and would be willing to assist=20
> with that draft myself.

[FA] I don't think we need design guidelines for LAN attributes
(including WLAN) -- because as Jari said this is not a complicated task.
Could you be more specific what you have in mind for design guidelines?
We spent over 6 month arguing about subtypes -- and if we spend another
6 month arguing the design guidelines, for sure we will never get this
done!

BR,
Farid

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 15:46:27 +0000
Date: Tue, 04 May 2004 17:46:00 +0200
From: Nagi <[email-masked]>
Reply-To: [email-masked]
Organization: Alcatel Telecom
To: "Nelson, David" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: RADIUS drafts review -- LAN attributes

> > I had been assuming that the guidelines
> > are needed if you do something complicated, like subattributes
> > or SDO-specific attributes. But I'm not sure we need them
> > for the WLAN attrs draft.
>
> I'm not sure, either.  I guess that depends on how the draft shapes up.
> I simply hold that out as a possibility.  I would like to see work on
> the design guidelines begin immediately (in parallel with other work)
> and would be willing to assist with that draft myself.

There seems to be a handful of LAN attributes and a few more might be
needed in future. Also I presume the guidelines draft documents the
structure of SubAttributes. It looks as if there is a dependency in case
the LAN attributes belong to SubAttributes category. This is debatable in
contrast with the *flat* LAN attributes.

regards
Nagi.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 14:48:08 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Tue, 4 May 2004 10:42:29 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Jari writes...

> This would make it be late from, say, 3GPP release 6 specifications
> which probably would like to refer to an IETF spec on this.

We should, of course, be sensitive to the timing requirements of other
SDOs.  I know that there have been co-coordinating conference calls with
3GGP2 (hosted by Thomas Narten).  Perhaps we need a similar coordination
effort with 3GPP.

> Can you remind me why there is a dependency on the guidelines
> and WLAN attributes?

I think this thread is discussing the LAN attributes draft, although
there may not be a significant distinction.

> I had been assuming that the guidelines
> are needed if you do something complicated, like subattributes
> or SDO-specific attributes. But I'm not sure we need them
> for the WLAN attrs draft.

I'm not sure, either.  I guess that depends on how the draft shapes up.
I simply hold that out as a possibility.  I would like to see work on
the design guidelines begin immediately (in parallel with other work)
and would be willing to assist with that draft myself.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 14:03:26 +0000
content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Tue, 4 May 2004 17:03:14 +0300
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>, <[email-masked]>
Cc: "Nelson, David" <[email-masked]>

Farid,

draft-adrangi-radius-extension-for-pwlan-00.txt is expired and not =
available any longer in the IETF repository. I guess that you intent to =
re-submit it, as you are requiring comments. Do you have an alternative =
URL to access it meantime?

Thanks and Regards,

Dan

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]On Behalf Of Adrangi, Farid
> Sent: 04 May, 2004 1:04 AM
> To: [email-masked]
> Cc: Nelson, David
> Subject: RE: RADIUS drafts review -- LAN attributes
>=20
>=20
> Hi David, all
>=20
> There are a number of drafts on LAN attributes:
>=20
> 1)
> http://www.ietf.org/internet-drafts/draft-lior-radius-redirect
> ion-00.txt
>=20
> 2)
> http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandw
> idth-capab
> ility-00.txt
>=20
> 3) There were two original drafts on LAN attributes: black and adrangi
> drafts:
> http://www.ietf.org/internet-drafts/draft-adrangi-radius-exten
sion-for-p
wlan-00.txt

Note : Couldn't find the link for Black's draft.  Chuck please advise.

There were a number of LAN attributes proposed in these two drafts.
Some of the attributes were already taken into separate drafts like
location information and network bandwidth authorization.  However, we
need to scrub the remaining of attributes. =20

4) There were two drafts on location information (adrangi and jones
drafts) -- these drafts were moved to the GeoPriv WG. We are currently
working on a combined draft  -- plan to submit it in a few weeks.  For
those folks who are interested, please subscribe to GeoPriv mailing
list.

Did I miss anything?

BR,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, May 03, 2004 2:30 PM
> To: [email-masked]
> Subject: RE: RADIUS drafts review -- LAN attributes
>=20
>=20
>=20
> > In the last BoF, a number of people volunteered to be=20
> reviewer for LAN=20
> > attribute drafts.
>=20
> Farid, would you please remind us where the most current=20
> version of this draft is posted?  Thanks!
>=20
> -- Dave
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 14:01:34 +0000
Date: Tue, 04 May 2004 16:57:57 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADIUS drafts review -- LAN attributes

Nelson, David wrote:
> Farid writes...
> 
> 
>>I think everyone should participate in scrubbing the LAN attributes,
> 
> and
> 
>>help finalize their definition, format/syntax ...  Whether or not we
>>need a single or multiple drafts to express these attributes, we can
>>discuss it in parallel.  I think our primary focus should be to
> 
> identify
> 
>>a list of LAN attributes that we need to standardize, and work on
> 
> their
> 
>>definition.  Your comment?
> 
> 
> That sounds fine.  If we can organize that effort to occur on the list,
> and we have some active participants, then let's start...   Actual
> editing of the drafts will still require an individual to act as editor,
> of course.
> 
> Keep in mind, however, the WG work items and milestones from the draft
> charter.
> 
> 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  RADIUS implementation issues and fixes submitted as an
>         Informational 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.
> 
> Before we can close on the LAN Attributes draft (or others) we need to
> complete the design guidelines draft.  Certainly, we can work in
> parallel, to the extent that resources permit.  The LAN Attributes draft
> is scheduled to be completed in December of 2005.

This would make it be late from, say, 3GPP release 6 specifications
which probably would like to refer to an IETF spec on this.
Can you remind me why there is a dependency on the guidelines
and WLAN attributes? I had been assuming that the guidelines
are needed if you do something complicated, like subattributes
or SDO-specific attributes. But I'm not sure we need them
for the WLAN attrs draft. Or I would hope we can get by without
them -- maybe I'm mistaken.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 May 2004 13:44:55 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Tue, 4 May 2004 09:44:08 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Farid writes...

> I think everyone should participate in scrubbing the LAN attributes,
and
> help finalize their definition, format/syntax ...  Whether or not we
> need a single or multiple drafts to express these attributes, we can
> discuss it in parallel.  I think our primary focus should be to
identify
> a list of LAN attributes that we need to standardize, and work on
their
> definition.  Your comment?

That sounds fine.  If we can organize that effort to occur on the list,
and we have some active participants, then let's start...   Actual
editing of the drafts will still require an individual to act as editor,
of course.

Keep in mind, however, the WG work items and milestones from the draft
charter.

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  RADIUS implementation issues and fixes submitted as an
        Informational 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.

Before we can close on the LAN Attributes draft (or others) we need to
complete the design guidelines draft.  Certainly, we can work in
parallel, to the extent that resources permit.  The LAN Attributes draft
is scheduled to be completed in December of 2005.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 03 May 2004 22:33:40 +0000
Content-Class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Mon, 3 May 2004 15:30:24 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Hi Dave, all
>=20
> Looking back in the mail archives, there was discussion of=20
> setting up a relatively small "design team" to work on=20
> scrubbing and merging these various LAN attributes drafts. =20
> Is that still a viable approach for us to take?
> =20

I think everyone should participate in scrubbing the LAN attributes, and
help finalize their definition, format/syntax ...  Whether or not we
need a single or multiple drafts to express these attributes, we can
discuss it in parallel.  I think our primary focus should be to identify
a list of LAN attributes that we need to standardize, and work on their
definition.  Your comment?

BR,
Farid

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 03 May 2004 22:16:24 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Mon, 3 May 2004 18:16:20 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> Note : Couldn't find the link for Black's draft.  Chuck please advise.

I couldn't find it either...
=20
> There were a number of LAN attributes proposed in these two drafts.
> Some of the attributes were already taken into separate drafts like
> location information and network bandwidth authorization.  However, we
> need to scrub the remaining of attributes.

Looking back in the mail archives, there was discussion of setting up a
relatively small "design team" to work on scrubbing and merging these
various LAN attributes drafts.  Is that still a viable approach for us
to take?
=20
> 4) There were two drafts on location information (adrangi and jones
> drafts) -- these drafts were moved to the GeoPriv WG. We are currently
> working on a combined draft  -- plan to submit it in a few weeks.  For
> those folks who are interested, please subscribe to GeoPriv mailing
> list.

Yes.  That's a good idea.  Some level of cross-review will be required.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 03 May 2004 22:13:55 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Mon, 3 May 2004 15:13:50 -0700
From: "Black, Chuck A" <[email-masked]>
To: <[email-masked]>

Here is the link to the original version of the 'black' draft for LAN
Edge attributes:
http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt. =20

As Farid mentions, since that time there has been some discussion
regarding having separate drafts for attributes such as bandwidth and
location.  This original draft still contains those attributes.

/chuck

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Adrangi, Farid
Sent: Monday, May 03, 2004 3:04 PM
To: [email-masked]
Cc: Nelson, David
Subject: RE: RADIUS drafts review -- LAN attributes

Hi David, all

There are a number of drafts on LAN attributes:

1)
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt

2)
http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capab
ility-00.txt

3) There were two original drafts on LAN attributes: black and adrangi
drafts:
http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-for-p
wlan-00.txt

Note : Couldn't find the link for Black's draft.  Chuck please advise.

There were a number of LAN attributes proposed in these two drafts.
Some of the attributes were already taken into separate drafts like
location information and network bandwidth authorization.  However, we
need to scrub the remaining of attributes. =20

4) There were two drafts on location information (adrangi and jones
drafts) -- these drafts were moved to the GeoPriv WG. We are currently
working on a combined draft  -- plan to submit it in a few weeks.  For
those folks who are interested, please subscribe to GeoPriv mailing
list.

Did I miss anything?

BR,
Farid

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, May 03, 2004 2:30 PM
> To: [email-masked]
> Subject: RE: RADIUS drafts review -- LAN attributes
>=20
>=20
>=20
> > In the last BoF, a number of people volunteered to be
> reviewer for LAN
> > attribute drafts.
>=20
> Farid, would you please remind us where the most current version of=20
> this draft is posted?  Thanks!
>=20
> -- Dave
>=20
>=20
>=20
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in a single

> line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 03 May 2004 22:13:04 +0000
Content-Class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Mon, 3 May 2004 15:12:28 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Yes, of course.  The more reviewers the better!  I mentioned a list of
people who already expressed interest and made a commitment -- i.e.,
they will review the drafts and post their comments to the list before
the specified deadline.  This does not preclude other people in the
mailing list.  BTW, I think I missed the following names in the
reviewers list: Chuck Black & Farooq Bari.

BR,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, May 03, 2004 2:42 PM
> To: [email-masked]
> Subject: RE: RADIUS drafts review -- LAN attributes
>=20
>=20
> > Hi Farid,
> >=20
> > I was missed the last IETF meeting but can you include me=20
> in the list
> of
> > reviewers ?
>=20
> At the risk of stating the obvious, it would seem to me that=20
> everyone subscribed to this mailing list is a reviewer, to=20
> one extent or another. Right?  Or am I missing some point?
>=20
> -- Dave
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 03 May 2004 22:04:56 +0000
Content-Class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Mon, 3 May 2004 15:04:24 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: "Nelson, David" <[email-masked]>

Hi David, all

There are a number of drafts on LAN attributes:

1)
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt

2)
http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capab
ility-00.txt

3) There were two original drafts on LAN attributes: black and adrangi
drafts:
http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-for-p
wlan-00.txt

Note : Couldn't find the link for Black's draft.  Chuck please advise.

There were a number of LAN attributes proposed in these two drafts.
Some of the attributes were already taken into separate drafts like
location information and network bandwidth authorization.  However, we
need to scrub the remaining of attributes. =20

4) There were two drafts on location information (adrangi and jones
drafts) -- these drafts were moved to the GeoPriv WG. We are currently
working on a combined draft  -- plan to submit it in a few weeks.  For
those folks who are interested, please subscribe to GeoPriv mailing
list.

Did I miss anything?

BR,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, May 03, 2004 2:30 PM
> To: [email-masked]
> Subject: RE: RADIUS drafts review -- LAN attributes
>=20
>=20
>=20
> > In the last BoF, a number of people volunteered to be=20
> reviewer for LAN=20
> > attribute drafts.
>=20
> Farid, would you please remind us where the most current=20
> version of this draft is posted?  Thanks!
>=20
> -- Dave
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 03 May 2004 21:56:17 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Mon, 3 May 2004 17:56:10 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> ...I was responding to Farid's email that had a list=20
> of volunteer reviewer names (did not exactly know what
> the list meant).

Nor did I.  I assume these are folks who volunteered to *actively*
review the draft(s) on this mailing list.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 03 May 2004 21:51:59 +0000
content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Mon, 3 May 2004 14:51:43 -0700
From: "Bari, Farooq" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

Completely agree with your statement - I was responding to Farid's email
that had a list of volunteer reviewer names (did not exactly know what
the list meant).

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nelson, David
Sent: Monday, May 03, 2004 2:42 PM
To: [email-masked]
Subject: RE: RADIUS drafts review -- LAN attributes

> Hi Farid,
>=20
> I was missed the last IETF meeting but can you include me in the list
of
> reviewers ?

At the risk of stating the obvious, it would seem to me that everyone
subscribed to this mailing list is a reviewer, to one extent or another.
Right?  Or am I missing some point?

-- Dave

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 03 May 2004 21:41:57 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Mon, 3 May 2004 17:41:47 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> Hi Farid,
>=20
> I was missed the last IETF meeting but can you include me in the list
of
> reviewers ?

At the risk of stating the obvious, it would seem to me that everyone
subscribed to this mailing list is a reviewer, to one extent or another.
Right?  Or am I missing some point?

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 03 May 2004 21:35:23 +0000
content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Mon, 3 May 2004 14:35:03 -0700
From: "Bari, Farooq" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>, <[email-masked]>

Hi Farid,

I was missed the last IETF meeting but can you include me in the list of
reviewers ?

BR,

Farooq

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Adrangi, Farid
Sent: Monday, May 03, 2004 2:19 PM
To: [email-masked]
Subject: RADIUS drafts review -- LAN attributes

Hi,

In the last BoF, a number of people volunteered to be reviewer for LAN
attribute drafts.  These people are:

Jari Arkko, Pasi Eronen, Osok Song, Parviz Yegani, David Mariblanca,
Farid Adrangi, and Avi  Lior, and lionel Morand

I think we should start this process ASAP - we can start with two more
drafts at a time and set a deadline for completing the review.  Is this
reasonable?  Do you have any suggestions how to proceed?

BR,
Farid

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 03 May 2004 21:30:56 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS drafts review -- LAN attributes
Date: Mon, 3 May 2004 17:30:02 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> In the last BoF, a number of people volunteered to be reviewer for LAN
> attribute drafts.

Farid, would you please remind us where the most current version of this
draft is posted?  Thanks!

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 03 May 2004 21:19:25 +0000
Content-Class: urn:content-classes:message
Subject: RADIUS drafts review -- LAN attributes
Date: Mon, 3 May 2004 14:18:52 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>

Hi,

In the last BoF, a number of people volunteered to be reviewer for LAN
attribute drafts.  These people are:

Jari Arkko, Pasi Eronen, Osok Song, Parviz Yegani, David Mariblanca,
Farid Adrangi, and Avi  Lior, and lionel Morand

I think we should start this process ASAP - we can start with two more
drafts at a time and set a deadline for completing the review.  Is this
reasonable?  Do you have any suggestions how to proceed?

BR,
Farid

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>