Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 27 Feb 2004 09:15:03 +0000 Message-Id: From: "Beck01, Wolfgang" To: avi@bridgewatersystems.com, radiusext@ops.ietf.org Subject: AW: RADIUS BAR BOF in Korea Date: Fri, 27 Feb 2004 10:13:55 +0100 MIME-Version: 1.0 Content-Type: text/plain >> I am Osok Song at Samsung Electronics, Korea. I am glad that you (and Farid) invited me to >> attend this BoF. >> I found that the social event is planed to be on Tuesday evening. Would it be OK for the all >> attendee? (Personally I will not attend the social event.) Also I want to know how many >> people are going to be at BoF. > I'll be at the BOF. Me too Wolfgang -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 27 Feb 2004 00:58:59 +0000 Message-Id: <4.3.2.7.2.20040226165656.02132228@franklin.cisco.com> Date: Thu, 26 Feb 2004 16:58:03 -0800 To: Osok Song , "'Avi Lior'" , radiusext@ops.ietf.org From: Parviz Yegani Subject: RE: RADIUS BAR BOF in Korea Cc: "'Adrangi, Farid'" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_107766349==_.ALT" --=====================_107766349==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:25 AM 2/27/2004 +0900, Osok Song wrote: >Hi all, > > > >I am Osok Song at Samsung Electronics, Korea. I am glad that you (and >Farid) invited me to attend this BoF. > >I found that the social event is planed to be on Tuesday evening. Would it >be OK for the all attendee? (Personally I will not attend the social >event.) Also I want to know how many people are going to be at BoF. I'll be at the BOF. Rgds, Parviz > > >Regards, > > > >Osok > > > >=========================== > >Osok Song > >Senior Engineer / Ph.D > >Global Standards & ResearchTeam > >Samsung Electronics Co., Ltd. > >=========================== > >-----Original Message----- >From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] >On Behalf Of Avi Lior >Sent: Friday, February 27, 2004 8:42 AM >To: radiusext@ops.ietf.org >Cc: Adrangi, Farid; 'Parviz Yegani' >Subject: RADIUS BAR BOF in Korea > > > >The best time for having a Bar BOF for RADIUS appears to be on Tuesday >evening after the last session of the Day. > > > >Tuesday at 18:30 location TBD. > > > >We dont know exactly where the best spot -- but we will post it to this list. > > > >Avi >-----Original Message----- >From: Avi Lior [mailto:avi@bridgewatersystems.com] >Sent: Tuesday, February 17, 2004 5:11 PM >To: radiusext@ops.ietf.org >Subject: Who is planning to be in Korea? >We would like to know who is planning to be in Korea. > > >Perhaps we can get together one night for some beer. > > > > >Avi. --=====================_107766349==_.ALT Content-Type: text/html; charset="us-ascii" At 09:25 AM 2/27/2004 +0900, Osok Song wrote:

Hi all,

 

I am Osok Song at Samsung Electronics, Korea. I am glad that you (and Farid) invited me to attend this BoF.

I found that the social event is planed to be on Tuesday evening. Would it be OK for the all attendee? (Personally I will not attend the social event.)  Also I want to know how many people are going to be at BoF.

I'll be at the BOF.

Rgds,
Parviz


 

Regards,

 

Osok

 

===========================  

Osok Song  

Senior Engineer / Ph.D  

Global Standards & ResearchTeam  

Samsung Electronics Co., Ltd.  

===========================

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior
Sent: Friday, February 27, 2004 8:42 AM
To: radiusext@ops.ietf.org
Cc: Adrangi, Farid; 'Parviz Yegani'
Subject: RADIUS BAR BOF in Korea

 

The best time for having a Bar BOF for RADIUS appears to be on Tuesday evening after the last session of the Day.

 

Tuesday at 18:30 location TBD.

 

We dont know exactly where the best spot -- but we will post it to this list.

 

Avi
-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, February 17, 2004 5:11 PM
To: radiusext@ops.ietf.org
Subject: Who is planning to be in Korea?
We would like to know who is planning to be in Korea.
 

Perhaps we can get together one night for some beer. 
 

 

Avi.
--=====================_107766349==_.ALT-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 27 Feb 2004 00:28:21 +0000 Date: Fri, 27 Feb 2004 09:25:11 +0900 From: Osok Song Subject: RE: RADIUS BAR BOF in Korea To: 'Avi Lior' , radiusext@ops.ietf.org Cc: "'Adrangi, Farid'" , 'Parviz Yegani' Message-id: <000b01c3fcc8$29b6cb10$6d87d5a5@LocalHost> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_LeleFyX++XdNbjVMcv3WCA)" This is a multi-part message in MIME format. --Boundary_(ID_LeleFyX++XdNbjVMcv3WCA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, I am Osok Song at Samsung Electronics, Korea. I am glad that you (and Farid) invited me to attend this BoF. I found that the social event is planed to be on Tuesday evening. Would it be OK for the all attendee? (Personally I will not attend the social event.) Also I want to know how many people are going to be at BoF. Regards, Osok =========================== Osok Song Senior Engineer / Ph.D Global Standards & ResearchTeam Samsung Electronics Co., Ltd. =========================== -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior Sent: Friday, February 27, 2004 8:42 AM To: radiusext@ops.ietf.org Cc: Adrangi, Farid; 'Parviz Yegani' Subject: RADIUS BAR BOF in Korea The best time for having a Bar BOF for RADIUS appears to be on Tuesday evening after the last session of the Day. Tuesday at 18:30 location TBD. We dont know exactly where the best spot -- but we will post it to this list. Avi -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com] Sent: Tuesday, February 17, 2004 5:11 PM To: radiusext@ops.ietf.org Subject: Who is planning to be in Korea? We would like to know who is planning to be in Korea. Perhaps we can get together one night for some beer. Avi. --Boundary_(ID_LeleFyX++XdNbjVMcv3WCA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Message

Hi all,

 

I am Osok Song at Samsung Electronics, Korea. I am glad that you (and Farid) invited me to attend this BoF.

I found that the social event is planed to be on Tuesday evening. Would it be OK for the all attendee? (Personally I will not attend the social event.)  Also I want to know how many people are going to be at BoF.

 

Regards,

 

Osok

 

===========================  

Osok Song  

Senior Engineer / Ph.D  

Global Standards & ResearchTeam  

Samsung Electronics Co., Ltd.  

===========================

-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior
Sent: Friday, February 27, 2004 8:42 AM
To: radiusext@ops.ietf.org
Cc: Adrangi, Farid; 'Parviz Yegani'
Subject: RADIUS BAR BOF in Korea

 

The best time for having a Bar BOF for RADIUS appears to be on Tuesday evening after the last session of the Day.

 

Tuesday at 18:30 location TBD.

 

We dont know exactly where the best spot -- but we will post it to this list.

 

Avi

-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, February 17, 2004 5:11 PM
To: radiusext@ops.ietf.org
Subject: Who is planning to be in Korea?

We would like to know who is planning to be in Korea.

 

Perhaps we can get together one night for some beer. 

 

 

Avi.

--Boundary_(ID_LeleFyX++XdNbjVMcv3WCA)-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 26 Feb 2004 23:43:40 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org Cc: "Adrangi, Farid" , 'Parviz Yegani' Subject: RADIUS BAR BOF in Korea Date: Thu, 26 Feb 2004 18:42:11 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FCC2.2767E0C0" 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_01C3FCC2.2767E0C0 Content-Type: text/plain The best time for having a Bar BOF for RADIUS appears to be on Tuesday evening after the last session of the Day. Tuesday at 18:30 location TBD. We dont know exactly where the best spot -- but we will post it to this list. Avi -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com] Sent: Tuesday, February 17, 2004 5:11 PM To: radiusext@ops.ietf.org Subject: Who is planning to be in Korea? We would like to know who is planning to be in Korea. Perhaps we can get together one night for some beer. Avi. ------_=_NextPart_001_01C3FCC2.2767E0C0 Content-Type: text/html Message
The best time for having a Bar BOF for RADIUS appears to be on Tuesday evening after the last session of the Day.
 
Tuesday at 18:30 location TBD.
 
We dont know exactly where the best spot -- but we will post it to this list.
 
Avi
-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, February 17, 2004 5:11 PM
To: radiusext@ops.ietf.org
Subject: Who is planning to be in Korea?

We would like to know who is planning to be in Korea.
 
Perhaps we can get together one night for some beer. 
 
 
Avi.
------_=_NextPart_001_01C3FCC2.2767E0C0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 23 Feb 2004 21:50:29 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org Subject: New RADIUS Redirection Draft Date: Mon, 23 Feb 2004 16:49:42 -0500 MIME-Version: 1.0 Content-Type: text/plain FYI: would appreciate comments on this work. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Remote Authentication Dial In User Service (RADIUS) Redirection Author(s) : A. Lior Filename : draft-lior-radius-redirection-00.txt Pages : 27 Date : 2004-2-9 In certain scenarios there needs to be a method to force the users traffic to a specific location. This document describes several methods that are available to be used with Remote Authentication Dial In User Service (RADIUS) Protocol and defines three new RADIUS attributes: NAS-Filter-Rule, Redirect-Id and Redirect-Rule. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt This work has been motivated by PWLAN. This draft introduces 3 new attributes and was written such that it compliments Diameter. NAS-Filter-Rule was introduced to make Filter-Id more roaming friendly (See commentary in NASREQ) Redirect-Id attribute is to be used like Filter-Id in those cases where there is a 'tight' relationship with the roaming partners. Like Filter-Id, Redirect-Id is not roaming friendly and hence we introduced Redirect-Rule. Redirect-Rule is based on IPFW syntax slightly modified to implement redirection. Again this approach is entirely consistant with Diameter's approach for IPFilterRule. However, IPFW does not support redirection. It does support (in some cases) Forwarding but forwarding is not the same as Redirection. Redirection has also been addressed by Diameter-Credit-Control Application. However, in credit control redirection is done as a subset of the method proposed here. ============================================ STATEMENT of Compliance to Proposed Charter ============================================ The draft is 100% compatible with the RADIUS EXT Proposed Charter Item 1: All work MUST be backward compatible with exiting RADIUS RFCs. This draft is 100% backwards compatible with existing RADIUS RFCs. Item 2: No new RADIUS transports No new transports were introdcued. Item 3: No changes will be considered to the RADIUS attribute format. No changes were made to any RADIUS attribute format. The new attriutes are of type STRING. Item 4: No new RADIUS data types will be defined. No new RADIUS data type was introduced. Item 5: The RADIUS maximum packet size (4K) will not be increaded. Packet size remains less the 4K. Item 6: No RADIUS attribute "sub-types" will be defined. No new attribute called "sub-types" was defined or introduced. All attributes are based on existing RADIUS types. Item 7: No new RADIUS secuirty mechanism will be defined. No new security mechanisms was introduced. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 20 Feb 2004 04:58:47 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org Subject: New Prepaid Draf version 3 is now available. Date: Thu, 19 Feb 2004 23:58:30 -0500 MIME-Version: 1.0 Content-Type: text/plain The draft is available http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-03. txt Whats new: Formalized the required set of attributes -- there are three attributes. Addes discussion on why the the prepaid approach in this document is more robust then doing prepaid using existing RADIUS attributes. There is already a version 4 in the works...... ============================================ STATEMENT of Compliance to Proposed Charter ============================================ The draft is 100% compatible with the RADIUS EXT Proposed Charter Item 1: All work MUST be backward compatible with exiting RADIUS RFCs. This draft is 100% backwards compatible with existing RADIUS RFCs. Item 2: No new RADIUS transports No new transports were introdcued. Item 3: No changes will be considered to the RADIUS attribute format. No changes were made to any RADIUS attribute format. The new attriutes are of type STRING. Item 4: No new RADIUS data types will be defined. No new RADIUS data type was introduced. Item 5: The RADIUS maximum packet size (4K) will not be increaded. Packet size remains less the 4K. Item 6: No RADIUS attribute "sub-types" will be defined. No new attribute called "sub-types" was defined or introduced. All attributes are based on RADIUS type STRING. Item 7: No new RADIUS secuirty mechanism will be defined. No new security mechanisms was introduced. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Feb 2004 18:49:00 +0000 Message-ID: <403504CD.4070609@cisco.com> Date: Thu, 19 Feb 2004 10:47:41 -0800 From: "Murtaza S. Chiba" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040118 MIME-Version: 1.0 To: Avi Lior CC: radiusext@ops.ietf.org Subject: Re: Query requests Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hey Avi, Great we are on the same wavelength! Location is one of the parameters, I was thinking more in terms of services enabled for the user. Regards, Murtaza Avi Lior wrote: > Hi Murtaza, > > It probably is out of charter. Two things: > > 1) Just yesterday while working on location I was wondering if we could use > AAA to pull position information from the NAS which perhaps can go to the > client as well. > > 2) In 3GPP2 we decided that Network Presence would be delivered to the > Presence Server via AAA (RADIUS). It is conceivable that the Presence > Server may want to query the AAA for Network Presence Information. > > So your "wondering" is intriguing me. > > Avi > > >>-----Original Message----- >>From: Murtaza S. Chiba [mailto:mchiba@cisco.com] >>Sent: February 18, 2004 7:18 PM >>To: radiusext@ops.ietf.org >>Subject: Query requests >> >> >>Probably out of the charter. But was wondering if any >>thought was given >>for Query requests that would return status of current session/s for >>self-care type applications. The dynamic-author interface could be >>extended. >> >> >>Thanks, >>Murtaza >> >>-- >>to unsubscribe send a message to >>radiusext-request@ops.ietf.org with the word 'unsubscribe' in >>a single line as the message text body. >>archive: >> > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Feb 2004 14:44:55 +0000 Message-ID: From: Avi Lior To: "'Murtaza S. Chiba'" , radiusext@ops.ietf.org Subject: RE: Query requests Date: Thu, 19 Feb 2004 09:44:34 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Murtaza, It probably is out of charter. Two things: 1) Just yesterday while working on location I was wondering if we could use AAA to pull position information from the NAS which perhaps can go to the client as well. 2) In 3GPP2 we decided that Network Presence would be delivered to the Presence Server via AAA (RADIUS). It is conceivable that the Presence Server may want to query the AAA for Network Presence Information. So your "wondering" is intriguing me. Avi > -----Original Message----- > From: Murtaza S. Chiba [mailto:mchiba@cisco.com] > Sent: February 18, 2004 7:18 PM > To: radiusext@ops.ietf.org > Subject: Query requests > > > Probably out of the charter. But was wondering if any > thought was given > for Query requests that would return status of current session/s for > self-care type applications. The dynamic-author interface could be > extended. > > > Thanks, > Murtaza > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 19 Feb 2004 00:19:07 +0000 Message-ID: <403400AF.1090201@cisco.com> Date: Wed, 18 Feb 2004 16:17:51 -0800 From: "Murtaza S. Chiba" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040118 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Query requests Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Probably out of the charter. But was wondering if any thought was given for Query requests that would return status of current session/s for self-care type applications. The dynamic-author interface could be extended. Thanks, Murtaza -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Feb 2004 15:51:18 +0000 Date: Wed, 18 Feb 2004 08:02:45 -0800 (PST) From: Bernard Aboba To: Avi Lior cc: radiusext@ops.ietf.org Subject: RE: RADIUS Location Drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Any draft involving location information is covered. This includes both the Jones and Adrangi drafts. On Wed, 18 Feb 2004, Avi Lior wrote: > Bernard, > > I need some clarification. Does that mean just the jones draft or both the > jones draft and the adrangi draft? > > Avi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Feb 2004 13:35:09 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: RE: RADIUS Location Drafts Date: Wed, 18 Feb 2004 08:34:51 -0500 MIME-Version: 1.0 Content-Type: text/plain Bernard, I need some clarification. Does that mean just the jones draft or both the jones draft and the adrangi draft? Avi > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: February 18, 2004 3:22 AM > To: radiusext@ops.ietf.org > Subject: RADIUS Location Drafts > > > We have discussed the issue of RADIUS location attributes > with the GEOPRIV WG chairs, and they have made a request that > this work be discussed with them, rather than being handled in RADEXT. > > Therefore at this point, the discussion on RADIUS location > attributes should move to the GEOPRIV mailing list. > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Feb 2004 11:11:45 +0000 Message-ID: <89F1B72D32F6D511BBD10002A55CBDE601CA8F2A@zfrac101.nortel-dasa.de> From: "Lothar Reith" To: "'Mark Grayson (mgrayson)'" , Avi Lior , radiusext@ops.ietf.org Subject: AW: "service-key" in Lior-Draft ( Radius-Prepaid-Extension) Date: Wed, 18 Feb 2004 11:11:15 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F60F.ED047802" 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_01C3F60F.ED047802 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Mark, =20 thanks for the link - unfortunately I could not locate any appearance = of the term "service-identifier" in the document.=20 Could you please be more specific or provide a link to the Diameter = document that contains the term "service-identifier" you are talking about. =20 Or do you mean the term "charging key" as being equivalent/analogous = to "service key" / "service identifier" ? =20 Many thanks in advance. =20 Lothar -----Urspr=FCngliche Nachricht----- Von: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]=20 Gesendet: Dienstag, 17. Februar 2004 18:33 An: Reith, Lothar [HAHN:ND:EXCH]; Avi Lior; radiusext@ops.ietf.org Betreff: RE: "service-key" in Lior-Draft ( Radius-Prepaid-Extension) Lothar =20 as I understand it, service key is analagous to the service-identifier = in Diameter Credit Control and is being specified by other standardzation bodies, e.g., 3GPP (http://www.3gpp.org/ftp/Specs/archive/23_series/23.825/23825-140.zip = ) which then assists in rating the pre-paid request. =20 Cheers, Mark =20 -----Original Message----- From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Lothar Reith Sent: 17 February 2004 16:07 To: 'Avi Lior'; radiusext@ops.ietf.org Subject: "service-key" in Lior-Draft ( Radius-Prepaid-Extension) Ladies and Gentlemen,=20 I would like to comment on the RADIUS-Prepaid-Extension Draft.=20 It contains the statement:=20 "The exact definition of these services is not the focus of this draft. This=20 definition MAY include a "service key" which can be used to=20 correlate prepaid requests for access to a service with the service=20 definition in the prepaid system."=20 Can someone please shed some light on why the concept of "service key" = is being introduced.=20 If I understand correctly, the whole draft is about some prepaid-server (sometimes also referred to as Quota-Server - or what is the difference between a Quota-Server and a Prepaid Server?) that MAY be part of a = RADIUS Server. Okay, if the prepaid server IS part of a RADIUS server, then = perhaps no issue, the Service-Key is just another Attribute but I do not = understand what it is good for in this case. In the more interesting case, where the Quota-Server (or Prepaid = Server) is not part of the AAA Server, the question arises to me, if the = Service-Key is not a trojan-horse that actually deprives the AAA Server from its = original task of service authorization. If I understand the draft correctly, = then the service-key identifies a bundle of a number of primitive services to = which the user has subscribed, hence it belongs into the AAA-Server and not = into the Quota Server. And by the way, watch out for the definiton of the = term "service" - it is not identical to the definition of "service" in the = base RADIUS RFC. Is this service subscription information not something which = architecturally belongs into the the AAA Server and not into the Prepaid-Server ?=20 If we start splitting user subscription data over 2 databases (RADIUS = Server and Prepaid Server) things become very messy. Is it design intend of = that draft that the RADIUS Server becomes "transparent" and the = Prepaid-Server takes over ? Put perhaps somebody can enlight me about the wisdom of introducing the "service key" concept into this draft (which does not seem to be = included in the related 3GPP2 work on PrePaid Data Service). I had thought, that the task of a Quota-Server is to manage Quotas, and = not authorize services.=20 my 2 Milli-Euro...=20 Lothar=20 ------_=_NextPart_001_01C3F60F.ED047802 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Nachricht
Mark,
 
thanks=20 for the link - unfortunately I could not locate any appearance of the = term=20 "service-identifier" in the document.
Could=20 you please be more specific or provide a link to the Diameter document = that=20 contains the term "service-identifier" you are talking=20 about.
 
Or do=20 you mean the term  "charging key" as being equivalent/analogous =  to=20 "service key"  / "service identifier" ?
 
Many=20 thanks in advance.
 
Lothar
-----Urspr=FCngliche Nachricht-----
Von: Mark = Grayson=20 (mgrayson) [mailto:mgrayson@cisco.com]
Gesendet: Dienstag, = 17.=20 Februar 2004 18:33
An: Reith, Lothar [HAHN:ND:EXCH]; Avi = Lior;=20 radiusext@ops.ietf.org
Betreff: RE: "service-key" in = Lior-Draft (=20 Radius-Prepaid-Extension)

Lothar
 
as I=20 understand it, service key is analagous to the service-identifier in = Diameter=20 Credit Control and is being specified by other standardzation bodies, = e.g.,=20 3GPP (http://www.3gpp.org/ftp/Specs/archive/23_series/23.825/23825-140.= zip)=20 which then assists in rating the pre-paid = request.
 
Cheers,
Mark
 
-----Original Message-----
From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Lothar Reith
Sent: 17 February 2004=20 16:07
To: 'Avi Lior'; = radiusext@ops.ietf.org
Subject:=20 "service-key" in Lior-Draft ( = Radius-Prepaid-Extension)

Ladies and Gentlemen,

I would like to comment on the = RADIUS-Prepaid-Extension=20 Draft.

It contains the statement:

"The exact definition of these services is not = the focus of=20 this draft.  This
   = definition MAY=20 include a "service key" which can be used to
   correlate prepaid requests for access to a = service with=20 the service
   definition in = the prepaid=20 system."

Can someone please shed some light on why the = concept of=20 "service key" is being introduced.

If I understand correctly, the whole draft is = about some=20 prepaid-server (sometimes also referred to as Quota-Server - or = what is the=20 difference between a Quota-Server and a Prepaid Server?) that MAY = be part of=20 a RADIUS Server. Okay, if the prepaid server IS part of a RADIUS = server,=20 then perhaps no issue, the Service-Key is just another Attribute = but I do=20 not understand what it is good for in this case.

In the more interesting case, where the = Quota-Server (or=20 Prepaid Server) is not part of the AAA Server, the question arises = to me, if=20 the Service-Key is not a trojan-horse that actually deprives the = AAA Server=20 from its original task of service authorization. If I understand = the draft=20 correctly, then the service-key identifies a bundle of a number of = primitive=20 services to which the user has subscribed, hence it belongs into = the=20 AAA-Server and not into the Quota Server. And by the way, watch out = for the=20 definiton of the term "service" - it is not identical to the = definition of=20 "service" in the base RADIUS RFC.

Is this service subscription information not = something which=20 architecturally belongs into the the AAA Server and not into the=20 Prepaid-Server ?

If we start splitting user subscription data over = 2=20 databases (RADIUS Server and Prepaid Server) things become very = messy. Is it=20 design intend of that draft that the RADIUS Server becomes = "transparent" and=20 the Prepaid-Server takes over ?

Put perhaps somebody can enlight me about the = wisdom of=20 introducing the "service key" concept into this draft (which does = not seem=20 to be included in the related 3GPP2 work on PrePaid Data=20 Service).

I had thought, that the task of a Quota-Server is = to manage=20 Quotas, and not authorize services.

my 2 Milli-Euro...

Lothar





------_=_NextPart_001_01C3F60F.ED047802-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 18 Feb 2004 08:10:17 +0000 Date: Wed, 18 Feb 2004 00:21:38 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADIUS Location Drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII We have discussed the issue of RADIUS location attributes with the GEOPRIV WG chairs, and they have made a request that this work be discussed with them, rather than being handled in RADEXT. Therefore at this point, the discussion on RADIUS location attributes should move to the GEOPRIV mailing list. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 22:39:34 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 14:38:03 -0800 Message-ID: <96D13222E704DC4D868F0009F0EE53E1017B3CFE@orsmsx410.jf.intel.com> Thread-Topic: RE: RE: RE: draft-jones-radius-geopriv Thread-Index: AcP1gHcBGAZWxGMjRsq2FR3qCiWs6QAAS6pgAANGkJAAAWsS8AABZIOQAAEfNQAAAcRcwA== From: "Adrangi, Farid" To: "Mark Grayson (mgrayson)" , , , , "John Schnizlein (jschnizl)" Cc: , Hi Mark, Not yet! As you know, we are trying to reach consensus whether UserName (1) rewrite will be sufficient or there is a need for the new attribute (currently discussed in GSMA). There has been couple of clarification-related questions posted on eap WG on RFC 3579 -- but we haven't got any answers from the authors yet.=20 BR, Farid > -----Original Message----- > From: Mark Grayson (mgrayson) [mailto:mgrayson@cisco.com]=20 > Sent: Tuesday, February 17, 2004 2:09 PM > To: Adrangi, Farid; john.loughney@nokia.com;=20 > avi@bridgewatersystems.com;=20 > mark.jones@bridgewatersystems.com; John Schnizlein (jschnizl) > Cc: radiusext@ops.ietf.org; geopriv@ietf.org > Subject: RE: RE: RE: RE: draft-jones-radius-geopriv >=20 >=20 > Farid >=20 > Is the chargeable identity draft available? >=20 > Cheers, > Mark >=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] > On Behalf Of Adrangi,=20 > Farid > Sent: 17 February 2004 21:11 > To: john.loughney@nokia.com; avi@bridgewatersystems.com; > mark.jones@bridgewatersystems.com; John Schnizlein (jschnizl) > Cc: radiusext@ops.ietf.org; geopriv@ietf.org > Subject: RE: RE: RE: RE: draft-jones-radius-geopriv >=20 >=20 >=20 > > Is there any chance that the GSMA could bring their requirements > > to the IETF, so that we can ensure we don't have too many > > conflicting requirements & also have a chance to understand > > what are the real requirements? I know the IETF has had=20 > > misunderstandings > > in the past with respect to 3GPP requirements. > >=20 >=20 > [FA] Yes. Actually, I believe Jouni K. has already sent an=20 > LS from GSMA > to IETF (Bernard / David Nelson) on this. =20 >=20 > BR, > Farid >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 22:11:30 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org Subject: Who is planning to be in Korea? Date: Tue, 17 Feb 2004 17:11:21 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F5A2.F94CE8A0" 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_01C3F5A2.F94CE8A0 Content-Type: text/plain We would like to know who is planning to be in Korea. Perhaps we can get together one night for some beer. Avi. ------_=_NextPart_001_01C3F5A2.F94CE8A0 Content-Type: text/html Message
We would like to know who is planning to be in Korea.
 
Perhaps we can get together one night for some beer. 
 
 
Avi.
------_=_NextPart_001_01C3F5A2.F94CE8A0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 22:09:33 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 23:08:47 +0100 Message-ID: Thread-Topic: RE: RE: RE: draft-jones-radius-geopriv Thread-Index: AcP1gHcBGAZWxGMjRsq2FR3qCiWs6QAAS6pgAANGkJAAAWsS8AABZIOQAAEfNQA= From: "Mark Grayson (mgrayson)" To: "Adrangi, Farid" , , , , "John Schnizlein (jschnizl)" Cc: , Farid Is the chargeable identity draft available? Cheers, Mark -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Adrangi, Farid Sent: 17 February 2004 21:11 To: john.loughney@nokia.com; avi@bridgewatersystems.com; mark.jones@bridgewatersystems.com; John Schnizlein (jschnizl) Cc: radiusext@ops.ietf.org; geopriv@ietf.org Subject: RE: RE: RE: RE: draft-jones-radius-geopriv > Is there any chance that the GSMA could bring their requirements > to the IETF, so that we can ensure we don't have too many > conflicting requirements & also have a chance to understand > what are the real requirements? I know the IETF has had=20 > misunderstandings > in the past with respect to 3GPP requirements. >=20 [FA] Yes. Actually, I believe Jouni K. has already sent an LS from GSMA to IETF (Bernard / David Nelson) on this. =20 BR, Farid -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 21:56:51 +0000 Date: Tue, 17 Feb 2004 14:07:46 -0800 (PST) From: Bernard Aboba To: "Adrangi, Farid" cc: john.loughney@nokia.com, avi@bridgewatersystems.com, mark.jones@bridgewatersystems.com, jschnizl@cisco.com, radiusext@ops.ietf.org, geopriv@ietf.org Subject: RE: RE: RE: draft-jones-radius-geopriv Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > [FA] Yes. We need to work with Mark Jones and others to make sure that we don't reinvent the wheels. Yes. A single draft that is parsimonious and compatible with existing work (such as the DHCP option) would be helpful. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 21:12:02 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 13:10:55 -0800 Message-ID: <96D13222E704DC4D868F0009F0EE53E1C4BD99@orsmsx410.jf.intel.com> Thread-Topic: RE: RE: RE: draft-jones-radius-geopriv Thread-Index: AcP1gHcBGAZWxGMjRsq2FR3qCiWs6QAAS6pgAANGkJAAAWsS8AABZIOQ From: "Adrangi, Farid" To: , , , Cc: , > Is there any chance that the GSMA could bring their requirements > to the IETF, so that we can ensure we don't have too many > conflicting requirements & also have a chance to understand > what are the real requirements? I know the IETF has had=20 > misunderstandings > in the past with respect to 3GPP requirements. >=20 [FA] Yes. Actually, I believe Jouni K. has already sent an LS from GSMA to IETF (Bernard / David Nelson) on this. =20 BR, Farid -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 20:41:58 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: GSMA requirements (was RE: draft-jones-radius-geopriv) Date: Tue, 17 Feb 2004 15:41:49 -0500 Message-ID: Thread-Topic: GSMA requirements (was RE: draft-jones-radius-geopriv) Thread-Index: AcP1gHcBGAZWxGMjRsq2FR3qCiWs6QAAS6pgAANGkJAAAWsS8AAAUXtg From: "Nelson, David" Cc: , John Loughney writes... > Is there any chance that the GSMA could bring their requirements > to the IETF, so that we can ensure we don't have too many > conflicting requirements & also have a chance to understand > what are the real requirements? GSAM has just yesterday sent a Liaison Letter to the chairs. It is not as explicit in terms of requirements as one might like, however it is a start. Since distribution of this document is open to the IETF community, I have reproduced the text of that letter here. -- Dave To: RADEXT Working Group Chairs,=20 Bernard Aboba, aboba@internaut.com David Nelson, dnelson@enterasys.com=20 From: GSMA WLAN Task Force, Chairman, Carlo Cassisa, Carlo.Cassisa@teliasonera.com Director, Graham Trickey, gtrickey@gsm.org CC: =09 Subject: RADEXT new attributes for global WLAN Roaming Date: 14-Feb-2004 =20 Response date due by: Latest 8-Mar-2004 Background: In recent developments of establishing a global SIM based inter-operator WLAN roaming within GSMA WLAN TF, we have faced several challenges with current RADIUS protocol. These challenges are mostly related to global inter-operator location based billing and taxation issues and user billing identities that are suitable for globally well established inter-operator billing systems. After careful studies and live tests we feel that there is room for enhancements in current RADIUS protocol to satisfy our requirements for global inter-operator SIM based WLAN roaming. These are needed to avoid fragmentation in inter-operator billing system interfaces and ease the integration to existing global inter-operator billing systems. GMSA WLAN Task Force would like to state their interest in the work done in IETF RADEXT Working Group identifying new RADIUS attributes and clarifying the usage of existing RADIUS attributes (such as the User-name attribute) that are usable for global SIM based WLAN roaming purposes. These attributes and clarifications include location information that is accurate enough for global billing and taxation purposes and billable user identities that are also usable for well established global inter-operator billing systems. We would like to point out few ongoing drafts that deal with the issues of our concern: draft-adrangi-radiusext-location-information and draft-adrangi-radius-chargeable-user-identity-attribute The following drafts have also been identified useful in a global roaming point of view: draft-adrangi-radius-bandwidth-capability and draft-lior-radius-redirection In the near future we also see RADIUS and DIAMETER migration and interworking as a challenge that should be solved in a proper way. Actions: GSMA WLAN TF is having their next meeting 11-Mar-2004 and we kindly ask for an input from RADEXT Working Group chairs on how they see the importance of adding attributes to the RADIUS protocol and/or clarifying the use of existing attributes in order to ease the deployment of global SIM based WLAN roaming. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 20:31:54 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 22:29:20 +0200 Message-ID: Thread-Topic: RE: RE: draft-jones-radius-geopriv Thread-Index: AcP1gHcBGAZWxGMjRsq2FR3qCiWs6QAAS6pgAANGkJAAAWsS8A== From: To: , , , Cc: , Hi Farid, > > Having been through a similar exercize before, I don't much like the = naming conventions > > in the above draft - section 2.2 for example.=20 >=20 > [FA] Can you be more specific. We would be more than happy=20 > to use your suggestions and advice in improving the naming=20 > convention and other things in the draft. I'll re-read the document tomorrow & send some coments. =20 > > Also, there are some editing nits, for example the '=C6'=20 > character in section 8. =20 >=20 > [FA] Good catch -- I thought I fixed that! >=20 >=20 > > I'd prefer re-use of the work done in GEOPRIV. >=20 > [FA] Yes. We need to work with Mark Jones and others to make=20 > sure that we don't reinvent the wheels. Good.=20 > > Would you be looking at only access, or service specific=20 > issues as well? > > How does it map to the GEOPRIV deliverables - for example=20 > the SIP & HTTP > > drafts?=20 >=20 > [FA] right now, GSMA requirements are for location-based=20 > access and accounting. We are also looking at location-based=20 > services, however we need to figure out how it maps to the=20 > GEOPPRIV deliverables as you pointed out. Is there any chance that the GSMA could bring their requirements to the IETF, so that we can ensure we don't have too many conflicting requirements & also have a chance to understand what are the real requirements? I know the IETF has had = misunderstandings in the past with respect to 3GPP requirements. thanks, John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 20:31:24 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 22:30:54 +0200 Message-ID: Thread-Topic: RE: RE: draft-jones-radius-geopriv Thread-Index: AcP1gHcBGAZWxGMjRsq2FR3qCiWs6QAAS6pgAABVTLAABHJDgA== From: To: Cc: , Dave, > John Loughney writes... > > > This type of location information needs to be transported to the = home > > > network and must only be used for that intention. > >=20 > > How does one guarantee that? >=20 > I wonder if it is ever possible to guarantee, in the > information-theoretic sense, that a trusted party does not misuse > information to which it has access? Its a sort of metapoint. How can an IETF specification guarantee things like the above. It seems much more like a legal issue, not a protocol issue. thanks, John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 20:11:32 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 12:10:18 -0800 Message-ID: <96D13222E704DC4D868F0009F0EE53E1017B3CFA@orsmsx410.jf.intel.com> Thread-Topic: RE: RE: draft-jones-radius-geopriv Thread-Index: AcP1gHcBGAZWxGMjRsq2FR3qCiWs6QAAS6pgAANGkJA= From: "Adrangi, Farid" To: , , , Cc: , Hi john,=20 Avi has answered your questions, however please couple of additional = points/comments inline. BR, Farid >=20 > > One reason for location information is as identified in this draft > >=20 > = http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-info= rmation-00.txt > Having been through a similar exercize before, I don't much like the = naming conventions > in the above draft - section 2.2 for example.=20 [FA] Can you be more specific. We would be more than happy to use your = suggestions and advice in improving the naming convention and other = things in the draft. > Also, there are some editing nits, for example the '=C6' character in = section 8. =20 [FA] Good catch -- I thought I fixed that! > I'd prefer re-use of the work done in GEOPRIV. [FA] Yes. We need to work with Mark Jones and others to make sure that = we don't reinvent the wheels. > Would you be looking at only access, or service specific issues as = well? > How does it map to the GEOPRIV deliverables - for example the SIP & = HTTP > drafts?=20 [FA] right now, GSMA requirements are for location-based access and = accounting. We are also looking at location-based services, however we = need to figure out how it maps to the GEOPPRIV deliverables as you = pointed out. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 19:14:41 +0000 Message-ID: From: Mark Jones To: "'Nelson, David'" Cc: "'radiusext@ops.ietf.org'" , "'geopriv@ietf.org'" Subject: RE: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 14:14:21 -0500 MIME-Version: 1.0 Content-Type: text/plain > I wonder if it is ever possible to guarantee, in the > information-theoretic sense, that a trusted party does not > misuse information to which it has access? > It's a good point, David. I see a parallel here with the privacy policies we read on web sites before surrendering our email, etc. There is no guarantee that my personal information will be misused. However, if the service provider does break the rules governing its use then presumably I have some legal recourse. Similarly, as a subscriber I would like to be able to specify a policy governing the use of my location information and this policy must be accessible and evaluated by anyone who determines my location. Depending on consumer sensitivity to this issue, we may even see network access locations (hotspots, etc) boasting 'GEOPRIV compliance' as a differentiator. Now I'm not suggesting RADIUS will be the only protocol involved in addressing this problem but it is proposed as a transport protocol for the location information so we should examine the security and privacy implications now rather than try to bolt something on later. Regards Mark -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 18:47:45 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , "'john.loughney@nokia.com'" Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: RE: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 13:47:30 -0500 MIME-Version: 1.0 Content-Type: text/plain John, I agree with Dave here. As a minimum you have to trust the various intermediaries. Even if we send a policy down the pipe saying what may or may not be done with the infromation. Ultimately you have to trust the various parties. In sending the information back to the home network you could encrypte it using radius encryption mechanism. But each party would still have to be trusted. So this is good against the Man-in-the-middle attack. You could also put the information in a secure tunnel (EAP-message) for end to end security. However, I will assert that the weakest link WRT to trust is the node furthest away from the home network. For example, in WLAN that access point would be in Joe-Hacker's dinner. So even using an EAP scheme would offer questionable protection. Unless of course the location information is coming from the users device (but we are not talking about that in our draft). Finally, we need to consider what we are truelly advertizing. Its not the user's location but the location of the NAS. As well, the identity of the user could be protected using EAP methods. So that while you may have access to the location information you don't really know who the user is. Avi > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: February 17, 2004 1:25 PM > Cc: radiusext@ops.ietf.org; geopriv@ietf.org > Subject: RE: RE: RE: draft-jones-radius-geopriv > > > > John Loughney writes... > > > This type of location information needs to be transported to the > home > > > network and must only be used for that intention. > > > > How does one guarentee that? > > I wonder if it is ever possible to guarantee, in the > information-theoretic sense, that a trusted party does not > misuse information to which it has access? > > -- Dave > > > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 18:25:27 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 13:25:23 -0500 Message-ID: Thread-Topic: RE: RE: draft-jones-radius-geopriv Thread-Index: AcP1gHcBGAZWxGMjRsq2FR3qCiWs6QAAS6pgAABVTLA= From: "Nelson, David" Cc: , John Loughney writes... > > This type of location information needs to be transported to the home > > network and must only be used for that intention. >=20 > How does one guarentee that? I wonder if it is ever possible to guarantee, in the information-theoretic sense, that a trusted party does not misuse information to which it has access? -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 18:17:23 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 20:16:38 +0200 Message-ID: Thread-Topic: RE: RE: draft-jones-radius-geopriv Thread-Index: AcP1gHcBGAZWxGMjRsq2FR3qCiWs6QAAS6pg From: To: , , Cc: , Hi Avi, > One reason for location information is as identified in this draft > = http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-info= rmation-00.txt Having been through a similar exercize before, I don't much like the = naming conventions in the above draft - section 2.2 for example. Also, there are some = editing nits, for example the '=C6' character in section 8. I'd prefer re-use of the work = done in GEOPRIV. >=20 > Location information can be used during Authorization to determine = whether > the subscriber is allowed access at a given location etc... Would you be looking at only access, or service specific issues as well? How does it map to the GEOPRIV deliverables - for example the SIP & HTTP drafts?=20 > Location information is also needed during billing. For example the = tax > rate may be based on the location where the user has accessed the = network as > opposed to the location of the home network. OK. > This type of location information needs to be transported to the home > network and must only be used for that intention. How does one guarentee that? John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 18:12:50 +0000 Message-ID: <4032598A.531CB843@alcatel.be> Date: Tue, 17 Feb 2004 19:12:26 +0100 From: Nagi Organization: Alcatel Telecom MIME-Version: 1.0 To: Lothar Reith CC: "'Avi Lior'" , radiusext@ops.ietf.org Subject: Re: "service-key" in Lior-Draft ( Radius-Prepaid-Extension) Content-Type: multipart/alternative; boundary="------------47CF8DBB6AD9D8297828DF1C" --------------47CF8DBB6AD9D8297828DF1C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lothar, > Can someone please shed some light on why the concept of "service key" > is being introduced. I think the name "service key" is a bit confusing when we compare with the Service-Type defined in base RFC. Service-Key identifies more *granular detail of service* that is offered to the user. Suppose, a prepaid PPP user can access to TV-on-demand, VoIP and vanilla internet access services. - Service Type attribute carries "framed" value. - Service Key can specify any or all of "TV-on-demand", "VoIP", "Internet access" values. > Is this service subscription information not something which > architecturally belongs into the the AAA Server and not into the > Prepaid-Server ? If the services are prepaid specific, then they should architecturally belong to Prepaid-server. For instance, prepaid user "X" has access to service "vanilla internet access" only and prepaid user "Y" has access to "TV-on-demand" and others. Then, these service keys have to be stored and communicated by the prepaid server. regards Nagi. --------------47CF8DBB6AD9D8297828DF1C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Lothar,
 
Can someone please shed some light on why the concept of "service key" is being introduced.


I think the name "service key" is a bit confusing when we compare with the Service-Type defined in base RFC.

Service-Key identifies more *granular detail of service* that is offered to the user. Suppose,  a prepaid PPP user can access to TV-on-demand, VoIP and vanilla internet access services.

- Service Type attribute carries "framed" value.
- Service Key can specify any or all of "TV-on-demand", "VoIP", "Internet access" values.
 

Is this service subscription information not something which architecturally belongs into the the AAA Server and not into the Prepaid-Server ?


If the services are prepaid specific, then they should architecturally belong to Prepaid-server. For instance, prepaid user "X" has access to service "vanilla internet access" only and prepaid user "Y" has access to "TV-on-demand" and others. Then, these service keys have to be stored and communicated by the prepaid server.

regards
Nagi.
  --------------47CF8DBB6AD9D8297828DF1C-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 18:04:12 +0000 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , Mark Jones , jschnizl@cisco.com Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 13:03:52 -0500 MIME-Version: 1.0 Content-Type: text/plain John, Perhaps I can jump in here. One reason for location information is as identified in this draft http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-informa tion-00.txt Location information can be used during Authorization to determine whether the subscriber is allowed access at a given location etc... Location information is also needed during billing. For example the tax rate may be based on the location where the user has accessed the network as opposed to the location of the home network. This type of location information needs to be transported to the home network and must only be used for that intention. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: February 17, 2004 12:40 PM > To: mark.jones@bridgewatersystems.com; jschnizl@cisco.com > Cc: radiusext@ops.ietf.org; geopriv@ietf.org > Subject: RE: RE: draft-jones-radius-geopriv > > > Hi Mark, > > > 1) Provide guidelines for RADIUS implementers needing to transport > > subscriber location information and remain compliant with > the GEOPRIV > > privacy and security requirements. We also wanted to examine the > > various roaming scenarios and provide recommendations on > how location > > information should be sent between AAA servers using RADIUS. > > Question on the second part. What are the use cases for > transporting location info? I've never really considered > RADIUS a transport protocol, so this seems like an odd usage > of RADIUS. > > thanks, > John > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 17:53:54 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 19:39:30 +0200 Message-ID: Thread-Topic: RE: draft-jones-radius-geopriv Thread-Index: AcP1eOmw7G07TQIaTdONQuklcAOlzwAA8GPA From: To: , Cc: , Hi Mark, > 1) Provide guidelines for RADIUS implementers needing to transport > subscriber location information and remain compliant with the GEOPRIV > privacy and security requirements. We also wanted to examine the = various > roaming scenarios and provide recommendations on how location = information > should be sent between AAA servers using RADIUS. Question on the second part. What are the use cases for transporting location info? I've never really considered RADIUS a transport = protocol, so this seems like an odd usage of RADIUS. thanks, John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 17:33:28 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F57C.17049AAC" Subject: RE: "service-key" in Lior-Draft ( Radius-Prepaid-Extension) Date: Tue, 17 Feb 2004 18:33:00 +0100 Message-ID: Thread-Topic: "service-key" in Lior-Draft ( Radius-Prepaid-Extension) Thread-Index: AcP1cDE/ruJ6nJ8WTqS1rsuQ49VVRwACnGmQ From: "Mark Grayson (mgrayson)" To: "Lothar Reith" , "Avi Lior" , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F57C.17049AAC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Lothar =20 as I understand it, service key is analagous to the service-identifier in Diameter Credit Control and is being specified by other standardzation bodies, e.g., 3GPP (http://www.3gpp.org/ftp/Specs/archive/23_series/23.825/23825-140.zip) which then assists in rating the pre-paid request. =20 Cheers, Mark =20 -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Lothar Reith Sent: 17 February 2004 16:07 To: 'Avi Lior'; radiusext@ops.ietf.org Subject: "service-key" in Lior-Draft ( Radius-Prepaid-Extension) Ladies and Gentlemen,=20 I would like to comment on the RADIUS-Prepaid-Extension Draft.=20 It contains the statement:=20 "The exact definition of these services is not the focus of this draft. This=20 definition MAY include a "service key" which can be used to=20 correlate prepaid requests for access to a service with the service=20 definition in the prepaid system."=20 Can someone please shed some light on why the concept of "service key" is being introduced.=20 If I understand correctly, the whole draft is about some prepaid-server (sometimes also referred to as Quota-Server - or what is the difference between a Quota-Server and a Prepaid Server?) that MAY be part of a RADIUS Server. Okay, if the prepaid server IS part of a RADIUS server, then perhaps no issue, the Service-Key is just another Attribute but I do not understand what it is good for in this case. In the more interesting case, where the Quota-Server (or Prepaid Server) is not part of the AAA Server, the question arises to me, if the Service-Key is not a trojan-horse that actually deprives the AAA Server from its original task of service authorization. If I understand the draft correctly, then the service-key identifies a bundle of a number of primitive services to which the user has subscribed, hence it belongs into the AAA-Server and not into the Quota Server. And by the way, watch out for the definiton of the term "service" - it is not identical to the definition of "service" in the base RADIUS RFC. Is this service subscription information not something which architecturally belongs into the the AAA Server and not into the Prepaid-Server ?=20 If we start splitting user subscription data over 2 databases (RADIUS Server and Prepaid Server) things become very messy. Is it design intend of that draft that the RADIUS Server becomes "transparent" and the Prepaid-Server takes over ? Put perhaps somebody can enlight me about the wisdom of introducing the "service key" concept into this draft (which does not seem to be included in the related 3GPP2 work on PrePaid Data Service). I had thought, that the task of a Quota-Server is to manage Quotas, and not authorize services.=20 my 2 Milli-Euro...=20 Lothar=20 ------_=_NextPart_001_01C3F57C.17049AAC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Lothar
 
as I=20 understand it, service key is analagous to the service-identifier in = Diameter=20 Credit Control and is being specified by other standardzation bodies, = e.g., 3GPP=20 (http://www.3gpp.org/ftp/Specs/archive/23_series/23.825/23825-140.zip= )=20 which then assists in rating the pre-paid request.
 
Cheers,
Mark
 
-----Original Message-----
From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Lothar Reith
Sent: 17 February 2004=20 16:07
To: 'Avi Lior'; = radiusext@ops.ietf.org
Subject:=20 "service-key" in Lior-Draft ( = Radius-Prepaid-Extension)

Ladies and Gentlemen,

I would like to comment on the = RADIUS-Prepaid-Extension=20 Draft.

It contains the statement:

"The exact definition of these services is not the = focus of=20 this draft.  This
   = definition MAY=20 include a "service key" which can be used to
   correlate prepaid requests for access to a = service with=20 the service
   definition in the = prepaid=20 system."

Can someone please shed some light on why the = concept of=20 "service key" is being introduced.

If I understand correctly, the whole draft is about = some=20 prepaid-server (sometimes also referred to as Quota-Server - or what = is the=20 difference between a Quota-Server and a Prepaid Server?) that MAY be = part of a=20 RADIUS Server. Okay, if the prepaid server IS part of a RADIUS server, = then=20 perhaps no issue, the Service-Key is just another Attribute but I do = not=20 understand what it is good for in this case.

In the more interesting case, where the Quota-Server = (or=20 Prepaid Server) is not part of the AAA Server, the question arises to = me, if=20 the Service-Key is not a trojan-horse that actually deprives the AAA = Server=20 from its original task of service authorization. If I understand the = draft=20 correctly, then the service-key identifies a bundle of a number of = primitive=20 services to which the user has subscribed, hence it belongs into the=20 AAA-Server and not into the Quota Server. And by the way, watch out = for the=20 definiton of the term "service" - it is not identical to the = definition of=20 "service" in the base RADIUS RFC.

Is this service subscription information not = something which=20 architecturally belongs into the the AAA Server and not into the=20 Prepaid-Server ?

If we start splitting user subscription data over 2 = databases=20 (RADIUS Server and Prepaid Server) things become very messy. Is it = design=20 intend of that draft that the RADIUS Server becomes "transparent" and = the=20 Prepaid-Server takes over ?

Put perhaps somebody can enlight me about the wisdom = of=20 introducing the "service key" concept into this draft (which does not = seem to=20 be included in the related 3GPP2 work on PrePaid Data = Service).

I had thought, that the task of a Quota-Server is to = manage=20 Quotas, and not authorize services.

my 2 Milli-Euro...

Lothar





------_=_NextPart_001_01C3F57C.17049AAC-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 17:08:56 +0000 Message-ID: From: Mark Jones To: 'John Schnizlein' Cc: "'radiusext@ops.ietf.org'" , "'geopriv@ietf.org'" Subject: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 12:08:39 -0500 MIME-Version: 1.0 Content-Type: text/plain > draft-jones-radius-geopriv specifies a way for a NAS to tell a > RADIUS server the location of the NAS. The location of the > NAS could be manually configured either in the NAS or in the > RADIUS server with which it shares a secret. The > radius-geopriv attribute might be added to the RADIUS > attributes that are forwarded to a different > (home) RADIUS server (in the global roaming situation). > (If this summary is incorrect, please clarify.) > John, We set out to write this draft with two main goals: 1) Provide guidelines for RADIUS implementers needing to transport subscriber location information and remain compliant with the GEOPRIV privacy and security requirements. We also wanted to examine the various roaming scenarios and provide recommendations on how location information should be sent between AAA servers using RADIUS. 2) Provide an access-independent representation of subscriber, device and network location information and specify how it is encoded in RADIUS. Rather than invent a new encoding, we would investigate the applicable areas of the GMLv3 efforts. Regards Mark -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 16:58:38 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685DA1@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Bernard Aboba'" Cc: radiusext@ops.ietf.org Subject: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 17:58:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" dhcp: distributes its own location information and has control over it. aaa: network distributes location information about the user for authorization, charging,.... (and maybe for other applications once the infrastructure is setup). > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, February 17, 2004 5:56 PM > To: Tschofenig Hannes > Cc: radiusext@ops.ietf.org > Subject: RE: draft-jones-radius-geopriv > > > > regarding your dhcp example: the dhcp scenario is a little bit > >different to the radius/diameter example since the location > information > >which is distributed is not only about the visited network but rather > >about the user (and also used in this sense). > > I'm not sure there really is a difference this way. > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 16:43:51 +0000 Date: Tue, 17 Feb 2004 08:55:34 -0800 (PST) From: Bernard Aboba To: Tschofenig Hannes cc: radiusext@ops.ietf.org Subject: RE: draft-jones-radius-geopriv Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > regarding your dhcp example: the dhcp scenario is a little bit >different to the radius/diameter example since the location information >which is distributed is not only about the visited network but rather >about the user (and also used in this sense). I'm not sure there really is a difference this way. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 16:36:37 +0000 Date: Tue, 17 Feb 2004 08:47:03 -0800 (PST) From: Bernard Aboba To: Henning Schulzrinne cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: draft-jones-radius-geopriv Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Why not re-use the encoding used in the civil version for DHCP? > Compression will not help significantly unless you use a SIGCOMP > approach and your dictionary is exactly right. The complexity of doing > that boggles the mind. Yes, that is the simplest thing that comes to mind. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 16:07:36 +0000 Message-ID: <89F1B72D32F6D511BBD10002A55CBDE601CA8F28@zfrac101.nortel-dasa.de> From: "Lothar Reith" To: "'Avi Lior'" , radiusext@ops.ietf.org Subject: "service-key" in Lior-Draft ( Radius-Prepaid-Extension) Date: Tue, 17 Feb 2004 16:07:09 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F570.18BC411E" 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_01C3F570.18BC411E Content-Type: text/plain Ladies and Gentlemen, I would like to comment on the RADIUS-Prepaid-Extension Draft. It contains the statement: "The exact definition of these services is not the focus of this draft. This definition MAY include a "service key" which can be used to correlate prepaid requests for access to a service with the service definition in the prepaid system." Can someone please shed some light on why the concept of "service key" is being introduced. If I understand correctly, the whole draft is about some prepaid-server (sometimes also referred to as Quota-Server - or what is the difference between a Quota-Server and a Prepaid Server?) that MAY be part of a RADIUS Server. Okay, if the prepaid server IS part of a RADIUS server, then perhaps no issue, the Service-Key is just another Attribute but I do not understand what it is good for in this case. In the more interesting case, where the Quota-Server (or Prepaid Server) is not part of the AAA Server, the question arises to me, if the Service-Key is not a trojan-horse that actually deprives the AAA Server from its original task of service authorization. If I understand the draft correctly, then the service-key identifies a bundle of a number of primitive services to which the user has subscribed, hence it belongs into the AAA-Server and not into the Quota Server. And by the way, watch out for the definiton of the term "service" - it is not identical to the definition of "service" in the base RADIUS RFC. Is this service subscription information not something which architecturally belongs into the the AAA Server and not into the Prepaid-Server ? If we start splitting user subscription data over 2 databases (RADIUS Server and Prepaid Server) things become very messy. Is it design intend of that draft that the RADIUS Server becomes "transparent" and the Prepaid-Server takes over ? Put perhaps somebody can enlight me about the wisdom of introducing the "service key" concept into this draft (which does not seem to be included in the related 3GPP2 work on PrePaid Data Service). I had thought, that the task of a Quota-Server is to manage Quotas, and not authorize services. my 2 Milli-Euro... Lothar ------_=_NextPart_001_01C3F570.18BC411E Content-Type: text/html Content-Transfer-Encoding: quoted-printable "service-key" in Lior-Draft ( = Radius-Prepaid-Extension)

Ladies and Gentlemen,

I would like to comment on the = RADIUS-Prepaid-Extension Draft.

It contains the statement:

"The exact definition of these services is not = the focus of this draft.  This
   definition MAY include a "service key" = which can be used to
   correlate prepaid requests for access = to a service with the service
   definition in the prepaid = system."

Can someone please shed some light on why the concept = of "service key" is being introduced.

If I understand correctly, the whole draft is about = some prepaid-server (sometimes also referred to as Quota-Server - or = what is the difference between a Quota-Server and a Prepaid Server?) = that MAY be part of a RADIUS Server. Okay, if the prepaid server IS = part of a RADIUS server, then perhaps no issue, the Service-Key is just = another Attribute but I do not understand what it is good for in this = case.

In the more interesting case, where the Quota-Server = (or Prepaid Server) is not part of the AAA Server, the question arises = to me, if the Service-Key is not a trojan-horse that actually deprives = the AAA Server from its original task of service authorization. If I = understand the draft correctly, then the service-key identifies a = bundle of a number of primitive services to which the user has = subscribed, hence it belongs into the AAA-Server and not into the Quota = Server. And by the way, watch out for the definiton of the term = "service" - it is not identical to the definition of = "service" in the base RADIUS RFC.

Is this service subscription information not = something which architecturally belongs into the the AAA Server and not = into the Prepaid-Server ?

If we start splitting user subscription data over 2 = databases (RADIUS Server and Prepaid Server) things become very messy. = Is it design intend of that draft that the RADIUS Server becomes = "transparent" and the Prepaid-Server takes over ?

Put perhaps somebody can enlight me about the wisdom = of introducing the "service key" concept into this draft = (which does not seem to be included in the related 3GPP2 work on = PrePaid Data Service).

I had thought, that the task of a Quota-Server is to = manage Quotas, and not authorize services.

my 2 Milli-Euro...

Lothar



 



------_=_NextPart_001_01C3F570.18BC411E-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 15:46:03 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D9D@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Henning Schulzrinne'" , radiusext@ops.ietf.org, "'geopriv@ietf.org'" Subject: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 16:45:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" hi henning, thanks for you quick response. > schofenig Hannes wrote: > > > hi henning, > > do you remember our discussions in the washington interim meeting? > there we > > considered the http proposals for distributing location > information. > andrew > > daviels proposed a custom location information format. there we > argued that > > we have to consider privacy issues (and therefore our > results of the > geopriv > > working group). the geopriv working group decided to build > their location > > objects based on xml (and also the policies). some size > considerations go > > along with it (also with the usage of s/mime). > > > That's putting it rather mildly... Given the trivial > structure for the > basic PIDF privacy information, I'm not convinced that we always need > the full generality of a GML object. I'd like to hear a technical, > rather than procedural, argument for disallowing that. (In HTTP, the > size argument was largely a non-issue.) i have not objections against adding privacy issues to other drafts. as you know i was not a big fan of gml at the beginning (which motivated jorge and christian to come up with their own location object draft) but looking deeper in it it turns out to contain useful stuff. looking at the features provided by it would not hurt. > > There might be more general value in a restricted format, as > it could be > applicable to other limited-functionality and > bandwidth/size-constrained > cases. There is clearly precedent for coding information in multiple > formats; the DHCP drafts are examples of that. > > The other alternative is http://www.w3.org/TR/wbxml/, but that 'note' > comes with warning labels that indicate that this is not exactly a > future-proof effort. true. i also saw this link. another alternative is to switch to diameter. > > > > > regarding your dhcp example: the dhcp scenario is a little bit > different to the radius/diameter example > > since the location information which is distributed is not > only about the > > visited network but rather about the user (and also used > in this sense). > > > It would be a trivial exercise to embed the privacy flags into a TLV > encoding. i agree with you. it wouldn't be a drawback to merge some other aspects as well. > > I have nothing against XML, but I'm worried about declaring it a > religion .. which i wouldn't do. > where any questioning of its universal applicability is > considered sacrilege. our draft and our intention does not go that far. it raises some issues (privacy, what location information could be useful,security,...), shows scenarios and points to work done in other places in the ietf. i think is fair todo that. ciao hannes > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 15:44:43 +0000 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 07:43:43 -0800 Message-ID: <96D13222E704DC4D868F0009F0EE53E1017B3CF9@orsmsx410.jf.intel.com> Thread-Topic: draft-jones-radius-geopriv Thread-Index: AcPwDxDANamcM/rJQDSHUqkLrlBsDgFXNsgw From: "Adrangi, Farid" To: "John Schnizlein" , "Bernard Aboba" Cc: "Hannes Tschofenig" , , > A summary of the various intersections might be useful here: > (for others - I know Bernard knows this background) >=20 > draft-ietf-geopriv-dhcp-lci-option-03.txt specifies a way for a=20 > DHCP server to give a host the host's location, using (circuit-ID) > information from the relay-agent and knowledge of the wiring plant. >=20 > draft-ietf-dhc-agentopt-radius-03.txt specifies a way for a DHCP > relay agent to relay RADIUS information to the DHCP server for its > use in allocating configuration options. >=20 > draft-jones-radius-geopriv specifies a way for a NAS to tell a=20 > RADIUS server the location of the NAS. The location of the NAS could > be manually configured either in the NAS or in the RADIUS server > with which it shares a secret. The radius-geopriv attribute might > be added to the RADIUS attributes that are forwarded to a different > (home) RADIUS server (in the global roaming situation). > (If this summary is incorrect, please clarify.) >=20 > Before combining these ideas in a creative way, one would need to > have a clear understanding of whose location information is needed > where, and which provider of the information has the best=20 > access to it. > Since this analysis is already too difficult for some of us to want > to attempt, making it worse with different information formats seems > like over-kill. >=20 > John >=20 >=20 Thanks for the summary Johh. There is also another related draft (draft-adrangi-radius-location-information-attribute-00.txt) that specifies a way for an Access Network (NAS) to convey the Access Network operational ownership and location information to the home RADIUS server. This draft is based on the requirements defined by GSMA operators and Wifi PA3 (public access) to enable location-based authentication, location-based services, and location-based billing and accounting use-scenarios. =20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 15:25:35 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Bof at next IETF? Date: Tue, 17 Feb 2004 10:28:03 -0500 Message-Id: <20040217152815.6E70C170D9@mail.nitros9.org> "Nelson, David" wrote: > Those drafts that call for extensions to RADIUS that are outside the > RADEXT proposed charter, and would break backwards compatibility with > the existing RADIUS RFCs and RADIUS implementations, should never, IMHO, > be published as Standards Track RFCs, and I have some serious doubts as > to whether they should be published as Informational RFCs. The client kickstart at least has zero impact on existing implementations. If your server doesn't support dynamic registration of clients, then the current methods (or lack thereof) are OK. If your server does support it, then if the clients support it, you get an incremental piece of security in your network. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 15:24:25 +0000 Message-ID: <4032321F.8090201@cs.columbia.edu> Date: Tue, 17 Feb 2004 10:24:15 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: radiusext@ops.ietf.org, "'geopriv@ietf.org'" Subject: Re: draft-jones-radius-geopriv Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit schofenig Hannes wrote: > hi henning, > do you remember our discussions in the washington interim meeting? there we > considered the http proposals for distributing location information. andrew > daviels proposed a custom location information format. there we argued that > we have to consider privacy issues (and therefore our results of the geopriv > working group). the geopriv working group decided to build their location > objects based on xml (and also the policies). some size considerations go > along with it (also with the usage of s/mime). That's putting it rather mildly... Given the trivial structure for the basic PIDF privacy information, I'm not convinced that we always need the full generality of a GML object. I'd like to hear a technical, rather than procedural, argument for disallowing that. (In HTTP, the size argument was largely a non-issue.) There might be more general value in a restricted format, as it could be applicable to other limited-functionality and bandwidth/size-constrained cases. There is clearly precedent for coding information in multiple formats; the DHCP drafts are examples of that. The other alternative is http://www.w3.org/TR/wbxml/, but that 'note' comes with warning labels that indicate that this is not exactly a future-proof effort. > > regarding your dhcp example: the dhcp scenario is a little bit different to the radius/diameter example > since the location information which is distributed is not only about the > visited network but rather about the user (and also used in this sense). It would be a trivial exercise to embed the privacy flags into a TLV encoding. I have nothing against XML, but I'm worried about declaring it a religion where any questioning of its universal applicability is considered sacrilege. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 15:08:02 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D99@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Henning Schulzrinne'" Cc: "'John Schnizlein'" , radiusext@ops.ietf.org, geopriv@ietf.org Subject: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 16:07:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" hi henning, do you remember our discussions in the washington interim meeting? there we considered the http proposals for distributing location information. andrew daviels proposed a custom location information format. there we argued that we have to consider privacy issues (and therefore our results of the geopriv working group). the geopriv working group decided to build their location objects based on xml (and also the policies). some size considerations go along with it (also with the usage of s/mime). regarding your dhcp example: the dhcp scenario is a little bit different to the radius/diameter example since the location information which is distributed is not only about the visited network but rather about the user (and also used in this sense). ciao hannes > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Tuesday, February 17, 2004 3:44 PM > To: Tschofenig Hannes > Cc: 'John Schnizlein'; radiusext@ops.ietf.org; geopriv@ietf.org > Subject: Re: draft-jones-radius-geopriv > > > Why not re-use the encoding used in the civil version for DHCP? > Compression will not help significantly unless you use a SIGCOMP > approach and your dictionary is exactly right. The complexity > of doing > that boggles the mind. > > Tschofenig Hannes wrote: > > > hi john, > > > > thanks for your observation. > > > > i see the following ways to tackle this problem: > > - forget xml and use a different encoding which is more "lighweight" > > - switch to diameter > > - compress xml objects > > > > i personally think that the privacy issues are worth > thinking about these > > options. > > > > ciao > > hannes > > > > > >>-----Original Message----- > >>From: John Schnizlein [mailto:jschnizl@cisco.com] > >>Sent: Monday, February 16, 2004 1:53 AM > >>To: Tschofenig Hannes > >>Cc: radiusext@ops.ietf.org; geopriv@ietf.org > >>Subject: Re: draft-jones-radius-geopriv > >> > >> > >>I am sorry I quoted the wrong part of RFC 2865. > >>The length of an attribute is at most 255, one octet [page 25]. > >>It seems unlikely that GML, or any XML, would be efficient > >>enough to be carried in a RADIUS attribute. > >> > >>At 01:12 PM 2/10/2004, John Schnizlein wrote: > >> > >>>>One concern, if this location configuration information (LCI) > >>>>is to be carried over RADIUS, is that the example in section 6 > >>>>seems to be 993 characters long. This one attribute seems to be > >>>>taking a large share of the maximum RADIUS packet size of 4096. > >>>>[RFC 2865, p 15] Is there enough room for everything else that > >>>>would be expected with this attribute? > >> > > > > -- > > to unsubscribe send a message to radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 14:44:57 +0000 Message-ID: <403228BE.6090205@cs.columbia.edu> Date: Tue, 17 Feb 2004 09:44:14 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Tschofenig Hannes CC: "'John Schnizlein'" , radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: draft-jones-radius-geopriv Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Why not re-use the encoding used in the civil version for DHCP? Compression will not help significantly unless you use a SIGCOMP approach and your dictionary is exactly right. The complexity of doing that boggles the mind. Tschofenig Hannes wrote: > hi john, > > thanks for your observation. > > i see the following ways to tackle this problem: > - forget xml and use a different encoding which is more "lighweight" > - switch to diameter > - compress xml objects > > i personally think that the privacy issues are worth thinking about these > options. > > ciao > hannes > > >>-----Original Message----- >>From: John Schnizlein [mailto:jschnizl@cisco.com] >>Sent: Monday, February 16, 2004 1:53 AM >>To: Tschofenig Hannes >>Cc: radiusext@ops.ietf.org; geopriv@ietf.org >>Subject: Re: draft-jones-radius-geopriv >> >> >>I am sorry I quoted the wrong part of RFC 2865. >>The length of an attribute is at most 255, one octet [page 25]. >>It seems unlikely that GML, or any XML, would be efficient >>enough to be carried in a RADIUS attribute. >> >>At 01:12 PM 2/10/2004, John Schnizlein wrote: >> >>>>One concern, if this location configuration information (LCI) >>>>is to be carried over RADIUS, is that the example in section 6 >>>>seems to be 993 characters long. This one attribute seems to be >>>>taking a large share of the maximum RADIUS packet size of 4096. >>>>[RFC 2865, p 15] Is there enough room for everything else that >>>>would be expected with this attribute? >> > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 12:40:12 +0000 Message-ID: <40320B7B.1020308@lipetsk.ru> Date: Tue, 17 Feb 2004 15:39:23 +0300 From: Victor Gamov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040126 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: subtypes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit My two cents (again :-) )about possible attribute format to carry subattributes. When I say "subattribute" I speak about service or application specific attributes which must be sended to specific hardware or software. Type -- Attribute type. may be 226 for example SoA ID -- Service or Application ID. We can assign standard numbers to services (SIP, WiFi, LAN etc) and applications (Prepaid etc). So all vendors can use it in their products. SoA Type -- Service or Application Type. This is SoA attribute type. Tag -- tag to allow attribute assemble/disassemle (like EAP) +---------------------------------------------------------------+ |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 (226) | Length | SoA ID | +---------------+---------------+-------------------------------+ | SoA Type | Tag | SoA length | +---------------+---------------+---------------+---------------+ | Value... +---------------+--- I hope it maybe really help to solve our "subtype problem". -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 09:38:03 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F04685D85@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'John Schnizlein'" Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: RE: draft-jones-radius-geopriv Date: Tue, 17 Feb 2004 10:37:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" hi john, thanks for your observation. i see the following ways to tackle this problem: - forget xml and use a different encoding which is more "lighweight" - switch to diameter - compress xml objects i personally think that the privacy issues are worth thinking about these options. ciao hannes > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Monday, February 16, 2004 1:53 AM > To: Tschofenig Hannes > Cc: radiusext@ops.ietf.org; geopriv@ietf.org > Subject: Re: draft-jones-radius-geopriv > > > I am sorry I quoted the wrong part of RFC 2865. > The length of an attribute is at most 255, one octet [page 25]. > It seems unlikely that GML, or any XML, would be efficient > enough to be carried in a RADIUS attribute. > > At 01:12 PM 2/10/2004, John Schnizlein wrote: > >> One concern, if this location configuration information (LCI) > >> is to be carried over RADIUS, is that the example in section 6 > >> seems to be 993 characters long. This one attribute seems to be > >> taking a large share of the maximum RADIUS packet size of 4096. > >> [RFC 2865, p 15] Is there enough room for everything else that > >> would be expected with this attribute? > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 09:25:10 +0000 Message-Id: From: "Beck01, Wolfgang" To: john.loughney@nokia.com, radiusext@ops.ietf.org Subject: AW: Formatting problem with draft-sterman-aaa-sip-01.txt Date: Tue, 17 Feb 2004 10:25:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" John Loughney wrote: > Is it just me, or does: > http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt > seem to have 2 versions of the text appended to each other? Urgh, you are right. I've just checked my Sent-Box, the error must have occurred at internet-drafts@ietf.org. The mail I've sent to them contained the xml2rfc source and the txt version generated from it. To be on the safe side, I included the txt version as text and as attachment. Maybe some script cat'ed them together. Wolfgang -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 08:43:26 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Formatting problem with draft-sterman-aaa-sip-01.txt Date: Tue, 17 Feb 2004 10:43:10 +0200 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcP1JX5l2hoj+oStS0GHNF88OMbiZwADHj3Q From: To: Hi all, Is it just me, or does: http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt seem to have 2 versions of the text appended to each other? John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 07:13:16 +0000 Message-Id: <4.3.2.7.2.20040216220417.025b8a18@franklin.cisco.com> Date: Mon, 16 Feb 2004 23:12:50 -0800 To: , From: Parviz Yegani Subject: RE: Bof at next IETF? Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hello, Greg, John, Comments inline ... At 02:10 PM 2/16/2004 +0200, john.loughney@nokia.com wrote: >Hi Greg, > > > This does seem like a good thing to discuss. Seems to me that > > it would be beneficial to have some way of enforcing forward > > compatibility from RADIUS to Diameter. A working group with > > both protocols in its purview might provide that venue for > > enforcement- or at least awareness. Also, most of the work > > item areas are solution oriented, not protocol specific. > > > > I believe ITU-T is looking favorably at applying 3GPP's IMS > > architecture to DSL & Cable. That leads me to believe that > > more Diameter applications will be on the way. If AAA-WG is > > going to shutdown, we need an area for these new AAA applications > > to develop. > >I agree with you on this point. A question to the chairs - >should we send text on the proposed charter with this in mind? Good point. We should go ahead and propose text for the charter if there is no objection. We can perhaps use the following list for items to be included in the charter (thanks to Avi for posting this list): http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-for-pwlan -00.txt This will be updated by deadline http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-informa tion-00.txt This is new work. http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capabilit y-00.txt This is new work http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt Updates previous one http://www.ietf.org/internet-drafts/draft-lonvick-sobgp-radius-03.txt http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-port-0 1.txt http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickstart- 01.txt http://www.ietf.org/internet-drafts/draft-heinanen-radius-l2tp-vpls-00.txt http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-handoff-04.txt http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-02. txt This will be updated. http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapping- 00.txt This will be updated http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extensi on-00.txt This is new work but outside scope of charter. http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt This is new work >From IETF 58: http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapping- 00.txt http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickstart- 01.txt http://www.ietf.org/internet-drafts/draft-moskowitz-sspp-snmp-01.txt http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-02. txt http://www.watersprings.org/pub/id/draft-schulzrinne-sipping-radius-accounti ng-00.txt http://www.watersprings.org/pub/id/draft-sterman-aaa-sip-00.txt http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt http://www.ietf.org/internet-drafts/draft-aboba-context-802-00.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt http://www.ietf.org/internet-drafts/draft-adrangi-radius-issues-in-pwlan-roa ming-01.txt http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-extensio n-for-pwlan-00.txt http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-port-0 1.txt http://www.ietf.org/internet-drafts/draft-heinanen-radius-pe-discovery-04.tx t Please post any additional drafts if not included in the above list. Thanks, Parviz >thanks, >John > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 17 Feb 2004 04:59:40 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft) Date: Tue, 17 Feb 2004 06:59:15 +0200 Message-ID: Thread-Topic: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft) Thread-Index: AcP0mFJSXIa6RJuARDe5TLKU+7Z2gQAekLrA From: To: , Hi Wolfgang, > > I think that if Extension X provides the exact same functionality as = VSA y, > > what is the need to support Extension X? > If VSA is identical to Extension X, you are right. But what if VSA y = does not > care about DIAMETER interopability and Extension X does? When I = submitted > draft-sterman-aaa-sip, one of the first question was about DIAMETER > interopability. There was a problem that could be settled after some > discussion. In this particular case, we found that a change in the > DIAMETER SIP application draft was the best solution. With a VSA, this = > valuable discussion wouldn't have happened. I do think your update is an improvement, and that is a good thing. = Getting the Diamatere SIP application to be RADIUS friendly is important as = well. We are probably moving foward on all of this, somewhat slowly ... John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 22:45:17 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' Cc: radiusext@ops.ietf.org Subject: If not BOF then WG? Date: Mon, 16 Feb 2004 17:44:49 -0500 MIME-Version: 1.0 Content-Type: text/plain Bernard, Based on this email(below) then are we to conclude that there is still a move to progress towards a RADIUS working group? > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, February 16, 2004 2:42 PM > To: Greg Weber > Cc: Joel M. Halpern; radiusext@ops.ietf.org > Subject: Re: RADIUS and complex attributes > > > > I think it would be very helpful to produce some more modern > > recommendations on how to > format/tag/concatenate/encrypt/etc VSAs and > > when to pursue IETF space use vs. vendor (SDO) specific. > Perhaps this > > is worthy of charter work-item inclusion. > > I think it is. There has been some discussion about one of > the following types of documents: > > a. RADIUS Implementation Issues and Fixes > b. RADIUS attribute design guidelines > > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 22:16:49 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , Avi Lior , radiusext@ops.ietf.org Subject: RE: Extending a RADIUS attribute (was subtypes....) Date: Mon, 16 Feb 2004 17:16:30 -0500 MIME-Version: 1.0 Content-Type: text/plain David, So I agree that perhaps the unreliable was not the correct word to use (as you suggest). But nevertheless it has problems. If I actually need to have multiple values of the attribute then simply repeating the attribute is not workable. It would be difficult if not impossible for the RADIUS server to tell whether the next attribute is a continuation of the previous one or a new one. Strangely someone asked me just this question about my redirection draft. There the REDIRECTION rule can get lengthy and I need to be able to send more than one. Therefore I replied as follows: I can extend the content of the REDIRECT-RULE attribute over back to back attributes. But this method is not good if we want more then one REDIRECT attribute and we do. Therefore the correct way to do this is to include the length of the overall data and then split it over back-to-back attributes. Another method is to reserve a key word such as "more". If "more" is found at the end of the first chunk then the next attribute is an extension of the first. Both method s would work in my case because the value type of the attribute is TEXT. But this does highlight the fact that there is no standard way to extend attributes in RADIUS that works across the board. Hence my discussion many moons ago about extending attributes. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Monday, February 16, 2004 4:36 PM > To: Avi Lior; radiusext@ops.ietf.org > Subject: RE: subtypes (was: HTTP digest and RADIUS; new > version of the Stermandraft) > > > Avi Lior writes... > > > Today if I have a string attribute that is longer than 253 octets > > -- I could extend it by putting the contents in back-to-back > > attributes. This however is not a very reliable way of extending > > an attribute. > > My understanding, from the context of early RADIUS WG > discussions, is that this is exactly what is intended. The > RFCs are less that crystal clear on this issue, however. The > only RADIUS attributes that have ordering requirements (e.g. > in proxy handling) are those string types that can contain a > continuation of a string value from one attribute to another. > The requirement to preserve order makes the re-assembly possible. > > As to reliability, I see no reason that this method is any > more unreliable than the underlying RADIUS transport > mechanism. It may be slightly cumbersome, but I would not > characterize it as unreliable. > > -- Dave > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 21:35:47 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the Stermandraft) Date: Mon, 16 Feb 2004 16:35:32 -0500 Message-ID: Thread-Topic: subtypes (was: HTTP digest and RADIUS; new version of the Stermandraft) Thread-Index: AcP00Y6ysaklKqK0SJCKsbtdMTY3FwAAmgeQ From: "Nelson, David" To: "Avi Lior" , Avi Lior writes... > Today if I have a string attribute that is longer than 253 octets > -- I could extend it by putting the contents in back-to-back=20 > attributes. This however is not a very reliable way of extending=20 > an attribute. My understanding, from the context of early RADIUS WG discussions, is that this is exactly what is intended. The RFCs are less that crystal clear on this issue, however. The only RADIUS attributes that have ordering requirements (e.g. in proxy handling) are those string types that can contain a continuation of a string value from one attribute to another. The requirement to preserve order makes the re-assembly possible. As to reliability, I see no reason that this method is any more unreliable than the underlying RADIUS transport mechanism. It may be slightly cumbersome, but I would not characterize it as unreliable. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 21:11:55 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , Victor Gamov , radiusext@ops.ietf.org Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the St ermandraft) Date: Mon, 16 Feb 2004 16:11:44 -0500 MIME-Version: 1.0 Content-Type: text/plain See inline. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Monday, February 16, 2004 11:17 AM > To: Victor Gamov; radiusext@ops.ietf.org > Subject: RE: subtypes (was: HTTP digest and RADIUS; new > version of the Stermandraft) > > > Victor Gamov writes... > > > Yes, but I don't say that we must increase attribute > length. We must > > propose method to join attribute values placed in different > attributes > > with some "tag". Like EAP for example. > > Application layer fragmentation and reassembly of attributes > already exists in RADIUS. It is used for string attributes, > such as Filter-ID or Framed-Route, in addition to EAP-Message. RADIUS has no way of addressing fragmentation and reassembly of attributes for "string" attributes. If you are talking about the fact the Filter-Id and Framed-Route can appear more then once in a packet , the intent of that is not to function as a fragmentation and reassembly mechanism. EAP-Message is entirely different story. Its really a transport within a tranpsort and does address this issue within the EAP-Message. Today if I have a string attribute that is longer than 253 octets -- I could extend it by putting the contents in back-to-back attributes. This however is not a very reliable way of extending an attribute. Also recall, that we have many discussion on this topic when I put forward the radius attribute extension drafts. During that discussion I proposed a method of doing this (but that is entirely a different story) Avi > -- Dave > > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 19:30:55 +0000 Date: Mon, 16 Feb 2004 11:42:26 -0800 (PST) From: Bernard Aboba To: Greg Weber cc: "Joel M. Halpern" , radiusext@ops.ietf.org Subject: Re: RADIUS and complex attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I think it would be very helpful to produce some more modern > recommendations on how to format/tag/concatenate/encrypt/etc VSAs > and when to pursue IETF space use vs. vendor (SDO) specific. > Perhaps this is worthy of charter work-item inclusion. I think it is. There has been some discussion about one of the following types of documents: a. RADIUS Implementation Issues and Fixes b. RADIUS attribute design guidelines -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 17:22:48 +0000 From: Greg Weber Message-Id: <200402161722.MAA18993@cisco.com> Subject: Re: RADIUS and complex attributes To: aboba@internaut.com (Bernard Aboba) Date: Mon, 16 Feb 2004 12:22:12 -0500 (EST) Cc: joel@stevecrocker.com (Joel M. Halpern), radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > > For many environments, there are very good reasons to prefer and move to > > standards. > > VSAs were never intended for general purpose use, which is what I think > the problem is here. But protocols such as SNMP can be used by SDOs to > create SDO-specific MIBs, and it does seem reasonable to enable SDOs to > create SDO-specific attributes. So far, they have not done a good job of > this partly because they have chosen the VSA format suggested in RFC 2865 > (how silly of them!) which only supports an 8 bit type code field. But > perhaps with some help and guidelines from the IETF this situation might > be improved. I think it would be very helpful to produce some more modern recommendations on how to format/tag/concatenate/encrypt/etc VSAs and when to pursue IETF space use vs. vendor (SDO) specific. Perhaps this is worthy of charter work-item inclusion. > > Sticking with VSAs for widely need features is simply a mistake. > > I'd agree for features that are not specific to a particular access > technology. However, it's worth noting that Enterprise MIBs are very > widely implemented today; many of the IEEE 802 MIBs fit in this category, > and interoperability has not been harmed by this. In the long term it is > not reasonable to force all AAA work to go through the IETF since this > does not scale. We need a mechanism akin to "MIB Doctors" for review, > "Enterprise MIBs" for legitimate extensions by SDOs (e.g. no new commands > or data types), and "Design guidelines" to provide advice on how to go > about it. > > > > Allow complex attributes. Call them subtypes if you like > > There is quite a difference between support of "complex attributes" and > "grouped AVPs" (e.g. sub-types). The former typically requires a data > definition language, while the latter does not. It is also worth noting > that the Diameter definition of "grouped AVPs" only allows one level of > grouping, That is not my understanding based on Section 4.4 of RFC 3588: "It is possible to include an AVP with a Grouped type within a Grouped type, that is, to nest them." I thought they could be recursive; please correct me if I'm wrong. Greg > so more than this cannot be allowed in RADIUS without breaking > DIAMETER/RADIUS compatibility. > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 16:49:33 +0000 Message-ID: <4030F48E.1080904@lipetsk.ru> Date: Mon, 16 Feb 2004 19:49:18 +0300 From: Victor Gamov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040126 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: subtypes Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: >>So, we can propose new extension with new attribute where we can join >>large attribute values or propose new RADIUS behaviour for VSA with >>VendorId=0 > > > It's hard to see how VSAs can address the length issue since > all RADIUS attributes are defined in RFC 2865 to have a Length field of 8 > bits. > > However, this approach could allow for grouping and possibly attribute > extension since RFC 2865 does allow for grouping of attributes within a > VSA. > > Some questions: > > a) Would single-level grouping (e.g. no groups within groups) within a > VSA with vendorid = 0 address the issues? Or do we need new data types or > even complex data types (with a datatype definition language)? > > b) Since VSAs are ignorable by the RADIUS client, are all contemplated > "grouped" attributes optional? How do we distinguish between mandatory > and optional attributes? I think that we must use new attribute with format like VSA (26) and with special behavior for attribute asseble/disassemble. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 16:46:33 +0000 Message-ID: <4030F3C4.30003@lipetsk.ru> Date: Mon, 16 Feb 2004 19:45:56 +0300 From: Victor Gamov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040126 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: subtypes (was: HTTP digest and RADIUS; new version of the Stermandraft) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nelson, David wrote: > Victor Gamov writes... > > >>Yes, but I don't say that we must increase attribute length. We must >>propose method to join attribute values placed in different attributes >>with some "tag". Like EAP for example. > > > Application layer fragmentation and reassembly of attributes already > exists in RADIUS. It is used for string attributes, such as Filter-ID > or Framed-Route, in addition to EAP-Message. Yes. But I still think that we must propose: 1) standard service-specific attributes for many services (SIP, WiFi etc) 2) standard way for fragmentation and assembly of this attributes (attribute assemble/disassemble, AAD) If we do it we will have mechanism to carry (possibly) large attributes and all vendors will be use service-specific attributes and AAD. Is it solve our "subtype" problem? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 16:45:52 +0000 Date: Mon, 16 Feb 2004 08:57:32 -0800 (PST) From: Bernard Aboba To: "Joel M. Halpern" cc: radiusext@ops.ietf.org Subject: Re: RADIUS and complex attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > For many environments, there are very good reasons to prefer and move to > standards. VSAs were never intended for general purpose use, which is what I think the problem is here. But protocols such as SNMP can be used by SDOs to create SDO-specific MIBs, and it does seem reasonable to enable SDOs to create SDO-specific attributes. So far, they have not done a good job of this partly because they have chosen the VSA format suggested in RFC 2865 (how silly of them!) which only supports an 8 bit type code field. But perhaps with some help and guidelines from the IETF this situation might be improved. > Sticking with VSAs for widely need features is simply a mistake. I'd agree for features that are not specific to a particular access technology. However, it's worth noting that Enterprise MIBs are very widely implemented today; many of the IEEE 802 MIBs fit in this category, and interoperability has not been harmed by this. In the long term it is not reasonable to force all AAA work to go through the IETF since this does not scale. We need a mechanism akin to "MIB Doctors" for review, "Enterprise MIBs" for legitimate extensions by SDOs (e.g. no new commands or data types), and "Design guidelines" to provide advice on how to go about it. > Allow complex attributes. Call them subtypes if you like There is quite a difference between support of "complex attributes" and "grouped AVPs" (e.g. sub-types). The former typically requires a data definition language, while the latter does not. It is also worth noting that the Diameter definition of "grouped AVPs" only allows one level of grouping, so more than this cannot be allowed in RADIUS without breaking DIAMETER/RADIUS compatibility. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 16:31:59 +0000 Date: Mon, 16 Feb 2004 08:43:32 -0800 (PST) From: Bernard Aboba To: Victor Gamov cc: radiusext@ops.ietf.org Subject: Re: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > So, we can propose new extension with new attribute where we can join > large attribute values or propose new RADIUS behaviour for VSA with > VendorId=0 It's hard to see how VSAs can address the length issue since all RADIUS attributes are defined in RFC 2865 to have a Length field of 8 bits. However, this approach could allow for grouping and possibly attribute extension since RFC 2865 does allow for grouping of attributes within a VSA. Some questions: a) Would single-level grouping (e.g. no groups within groups) within a VSA with vendorid = 0 address the issues? Or do we need new data types or even complex data types (with a datatype definition language)? b) Since VSAs are ignorable by the RADIUS client, are all contemplated "grouped" attributes optional? How do we distinguish between mandatory and optional attributes? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 16:17:32 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the Stermandraft) Date: Mon, 16 Feb 2004 11:17:21 -0500 Message-ID: Thread-Topic: subtypes (was: HTTP digest and RADIUS; new version of the Stermandraft) Thread-Index: AcP0oq2mzYOmPGqaRHOdEAfUUs065AABUy4g From: "Nelson, David" To: "Victor Gamov" , Victor Gamov writes... > Yes, but I don't say that we must increase attribute length. We must > propose method to join attribute values placed in different attributes > with some "tag". Like EAP for example. Application layer fragmentation and reassembly of attributes already exists in RADIUS. It is used for string attributes, such as Filter-ID or Framed-Route, in addition to EAP-Message. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 15:36:10 +0000 Message-ID: <4030E33F.3080104@lipetsk.ru> Date: Mon, 16 Feb 2004 18:35:27 +0300 From: Victor Gamov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040126 MIME-Version: 1.0 To: Nagi , radiusext@ops.ietf.org Subject: Re: subtypes (was: HTTP digest and RADIUS; new version of the Stermandraft) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Nagi wrote: > Victor, > > >>So, we can propose new extension with new attribute where we can join >>large attribute values or propose new RADIUS behaviour for VSA with >>VendorId=0 > > > Having a large attribute ( > 255) will break all existing Radius implementations. > Who ever sees this attribute ( be it Radius client, server or proxy) will need > recoding which is bad. > > Nagi. Yes, but I don't say that we must increase attribute length. We must propose method to join attribute values placed in different attributes with some "tag". Like EAP for example. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 15:17:48 +0000 Message-ID: <4030DEFE.8010409@lipetsk.ru> Date: Mon, 16 Feb 2004 18:17:18 +0300 From: Victor Gamov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040126 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit john.loughney@nokia.com wrote: > This is exactly why we need to ensure interoperability. If we extend RADIUS in > ways which would require RADIUS servers to be recoded, what is gained? I think > that if Extension X provides the exact same functionality as VSA y, what is > the need to support Extension X? At in the GSMA, 3GPP, 3GPP2 and enterprise > sphere, many vendors are implementing VSAs - even VSAs not specified by > themselves. I know in the enterprise sphere, vendors implement VSAs which > are specified by competitors all of the time. I think that we must propose extensions for some service-specific areas to vendors may implemet it in their products. So, SIP or WiFi specific attributes must be equal for all products from all vendors. And because we have VSA and VendorId=0 treat as standard RADIUS we can use this to extend attribute space. But current VSA has only 255 byte length attribute value. But new services require large attribute value sometimes. So, we can propose new extension with new attribute where we can join large attribute values or propose new RADIUS behaviour for VSA with VendorId=0 IMHO -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 15:08:12 +0000 Message-Id: <5.1.0.14.0.20040216095631.01a24c40@localhost> Date: Mon, 16 Feb 2004 10:07:47 -0500 To: radiusext@ops.ietf.org From: "Joel M. Halpern" Subject: RADIUS and complex attributes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed For some of the mechanisms that we need to support, we are going to have complex attributes with internal structure. A good example is prepaid. Given the complexities in prepaid, and the relationships among the information, flattening the full set of information into top level RADIUS attributes makes very little sense. So what are the alternatives for problems that need to be carried in RADIUS, and require complex information. I have seen the following suggested: Flatten the attributes, use "tags" to tie the together. While this works for some simple cases, it gets pretty hairy pretty quickly. Let folks use VSAs. One participant indicated that he did not see vendors saying that they would move from VSAs to standard attributes. For many environments, there are very good reasons to prefer and move to standards. The fact that we have to work with each RADIUS server vendor individually at each customer to get support for the VSAs we need for prepaid is NOT an advantage. It would be worth the small amount of work to switch to switch our client to use standard attributes. And I presume that the RADIUS server vendors would much prefer not to need a different implementation for each client that they have to work with. Sticking with VSAs for widely need features is simply a mistake. Allow complex attributes. Call them subtypes if you like (or dislike) the point is that the information to be carried has internal structure and meaning. It is very helpful if this structure can be standardized and described. It seems highly desirable to do that at the IETF rather than separately at IEEE, 3GPP, 3GPP2, the DSL Forum, ... And if we are going to do it at the IETF, this working group seems the right place to do this. In trying to follow the argument against complex attribute values, it seems that the argument is that such things should not be allowed within RADIUS, but only when they are a "carried application". It is understandable (and I support) that such attributes should not be mandatory for all clients or all servers, and that in general relays that are not adding value in the space of the complex attribute should be able to treat the attribute as a string. Once that much is said, the discussion seems to devolve into an assertion that if it is a carried application than it must be some other working group, and that the RADIUSEXT working group should not be defining such applications. Given that each of the applications is relatively small, and that unfortunately working groups carry a lot of overhead, it would simply seem more practical to define the extensions in the RADIUSEXT working group rather than trying to define a "prepaid" services WG and a "bandwidth allowance" working group, and... Yours, Joel M. Halpern -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 14:22:22 +0000 Message-Id: From: "Beck01, Wolfgang" To: john.loughney@nokia.com, radiusext@ops.ietf.org Subject: AW: subtypes (was: HTTP digest and RADIUS; new version of the Ste rman draft) Date: Mon, 16 Feb 2004 15:22:17 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" John Loughney wrote: > This is exactly why we need to ensure interoperability. If we extend RADIUS in > ways which would require RADIUS servers to be recoded, what is gained? Vendors keep adding minor extensions and fixes to their products all the time. We have processes for sytem updates. Replacing a AAA platform is a different category. > I think that if Extension X provides the exact same functionality as VSA y, > what is the need to support Extension X? If VSA is identical to Extension X, you are right. But what if VSA y does not care about DIAMETER interopability and Extension X does? When I submitted draft-sterman-aaa-sip, one of the first question was about DIAMETER interopability. There was a problem that could be settled after some discussion. In this particular case, we found that a change in the DIAMETER SIP application draft was the best solution. With a VSA, this valuable discussion wouldn't have happened. Wolfgang -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 14:19:42 +0000 Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C0476A5E0@eestqnt105.es.eu.ericsson.se> From: "David Mariblanca (ML/EEM)" To: "'radiusext@ops.ietf.org'" , "Adrangi, Farid" Subject: some comments on RADIUS Extension for Public Wireless LAN draft Date: Mon, 16 Feb 2004 15:18:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi all, I would like to give some comments on the paper draft-adrangi-radius-extension-for-pwlan-00.txt - General comment is that the list of attributes could be applicable for both Diameter and RADIUS (probably this has already been given). - In chapter 2.1 one of the fields is Operator-name, and it is proposed to have a prefix with the operator type. If the Operator-name must be globally known and unique, why is it needed this prefix ? I guess the HSN will check the correctness of this Operator-name with some list it will have, so it will be easy to know of the operator is GSM, WISP, or whatever. This comment comes because if some operator has more than one type (GSM and WISP, for example), I guess its PWLAN ANs will always advertise the prefix WISP to the HSN (if not the same GSM operator, of course), since a reasonable roaming rule in an HSN could be to choose preferably PWLAN ANs not owned by other GSM operators (which are their competitors). Other question about this attribute: how does this fit with the SSID ? Is it supposed to be copied into one of the fields ? - Other attribute which may be interesting is the intermediate network identity. If the user is roaming in other country (or network) and there is an intermediate network which the traffic is traversing, the identity of such network would be interesting to have in the home network, for example for roaming restrictions control. Note that the roaming restrictions can be applied not only to the WLAN ANs but also to the intermediate networks. A AAA in the intermediate network would be in charge of inserting this parameter. The reason to have this parameter on purpose (and not use existing parameters) is that it avoids RADIUS/Diameter (or vice versa) conversion problems. - For roaming restrictions control, it would be interesting to have something (if it does not exist) to indicate to the PWLAN client that roaming is not allowed in certain PWLAN ANs. For example, after a user has chosen one PWLAN AN (using the SSID or EAP methods currently being discussed), the PWLAN AN sends to the HSN the Operator-name and in the lists in the HSN that operator appears as "barred". The HSN has to send an access-reject so that a new PWLAN AN is chosen. Is it enough for this with the Reply-message attribute ? I think no, since a new network advertisement process has to be initiated. - Other important aspect is to indicate to the WLAN AN from the HSN to allow/block certain services in the WLAN AN, for example direct internet access. If the HSN wants to charge the user for internet access, this can be done directly from the WLAN AN (but in that case the WLAN AN gets some revenues) or the HSN operator can force the user to access internet through the HSN (in that case the WLAN AN does not charge for it). So the HSN could indicate to the WLAN AN that direct internet access is not allowed for that user. Is it needed a new attribute for this, or an existing one can be used ? Best regards, David. This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 13:30:40 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft) Date: Mon, 16 Feb 2004 15:30:34 +0200 Message-ID: Thread-Topic: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft) Thread-Index: AcP0hni3gb//Z08FS5mOE2IgZCEYmwACTd3Q From: To: , Hi Wolfgang, > Agreed. Can you give an example where the extension drafts would break > your product? As I haven't seen the need for the extensions, I haven't considered them in any great detail. > > Talking to other vendors, I haven't heard a lot of vendors saying = that > > they would move from VSAs to standard extensions if available. On = top > > of that, several folks on this list have stated that other SDOs need > > some extentions - if that is so, I think it would be good if those > > SDOs would make it known to the IESG / this list via the liasons = that > > already exist. >=20 > Providers (your customers) like standardized extensions better than > vendor-specific ones. Else we have the choice between maintenance = nightmare > or vendors handcuffing us. As far as I understand, many providers specify which VSAs they need = supported. Very rarely are they handcuffed to a particular supplier. > > I think the IESG is looking for clear proof that RADIUS extensions = are needed, > > so I'd be interested in seeing some reasoning (perhaps even in draft > > format) for this. Otherwise, I doubt the IESG will be really excited = about > > chartering this WG. In otherwords, the burden of proof is upon = those > > who want to extend RADIUS. > > Like IPV6 migration, replacing RADIUS means replacing a platform, not = just > updating some systems. Many providers can't afford to replace their = AAA > platform, just because it handles some error conditions nicer and is = more > extensible. The margins are pretty low in this business (not to = mention the > cash drain for buying Finnish 3G equipment). This is exactly why we need to ensure interoperability. If we extend = RADIUS in ways which would require RADIUS servers to be recoded, what is gained? = I think that if Extension X provides the exact same functionality as VSA y, what = is=20 the need to support Extension X? At in the GSMA, 3GPP, 3GPP2 and = enterprise sphere, many vendors are implementing VSAs - even VSAs not specified by themselves. I know in the enterprise sphere, vendors implement VSAs = which=20 are specified by competitors all of the time. =20 > We still develop IPV4 protocols within the IETF. And we also make sure that they are not IPv4 specific. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 13:20:52 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft) Date: Mon, 16 Feb 2004 15:20:34 +0200 Message-ID: Thread-Topic: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft) Thread-Index: AcP0jw0Qg8csS4E3RGiRoaTulaxkOAAAFkOQ From: To: Cc: , Hi Nagi, > > My company has implemented both, including some VSAs & we're = concerned > > about extensions that > > would cause us to implement more stuff without a clear benefit for = doing > > so. >=20 > Having a standard type doesn't necessarily mean to implement that. = Right? A > particular functionality like prepaid may not be supported by a box = and still > it can be a standard type. My meta-point is really that if we are going to extend RADIUS, we should = try to extend RADIUS in such a way that doesn't break interoperability. = Additionally, we need to sort out what are the extensions that are really needed. I = personally don't have a sense of that yet. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 13:16:33 +0000 Message-ID: <4030C29A.B6528B26@alcatel.be> Date: Mon, 16 Feb 2004 14:16:10 +0100 From: Nagi Organization: Alcatel Telecom MIME-Version: 1.0 To: john.loughney@nokia.com CC: wolfgang.beck01@t-online.de, radiusext@ops.ietf.org Subject: Re: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi John, > My company has implemented both, including some VSAs & we're concerned > about extensions that > would cause us to implement more stuff without a clear benefit for doing > so. Having a standard type doesn't necessarily mean to implement that. Right? A particular functionality like prepaid may not be supported by a box and still it can be a standard type. Nagi. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 12:14:31 +0000 Message-Id: From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: AW: subtypes (was: HTTP digest and RADIUS; new version of the Ste rman draft) Date: Mon, 16 Feb 2004 13:14:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" > My two cents are that I hope extensions to RADIUS to not break current > implementations of RADIUS and/or Diameter. My company has implemented > both, including some VSAs & we're concerned about extensions that > would cause us to implement more stuff without a clear benefit > for doing so. Agreed. Can you give an example where the extension drafts would break your product? > Talking to other vendors, I haven't heard a lot of vendors saying that > they would move from VSAs to standard extensions if available. On top > of that, several folks on this list have stated that other SDOs need > some extentions - if that is so, I think it would be good if those > SDOs would make it known to the IESG / this list via the liasons that > already exist. Providers (your customers) like standardized extensions better than vendor-specific ones. Else we have the choice between maintenance nightmare or vendors handcuffing us. > I think we are between a rock & a hard place on this topic. A few years > ago, the IETF undertook a process to define the AAA infrastructure. At > the time, extending RADIUS seemed to be a messier job (and not guarenteed > for success) than to standardize Diameter. I think that the IETF did > a poor job in getting Diameter completed in a timely manner (which > is another source of the current mess we find ourselves in). True. During that period we paid vendors to mitigate RADIUS deficiencies using proprietary extensions. Which makes now DIAMETER migration even harder to justify (not technically, but commercially). > I think the IESG is looking for clear proof that RADIUS extensions are needed, > so I'd be interested in seeing some reasoning (perhaps even in draft > format) for this. Otherwise, I doubt the IESG will be really excited about > chartering this WG. In otherwords, the burden of proof is upon those > who want to extend RADIUS. Like IPV6 migration, replacing RADIUS means replacing a platform, not just updating some systems. Many providers can't afford to replace their AAA platform, just because it handles some error conditions nicer and is more extensible. The margins are pretty low in this business (not to mention the cash drain for buying Finnish 3G equipment). We still develop IPV4 protocols within the IETF. Wolfgang -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 12:10:35 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Mon, 16 Feb 2004 14:10:20 +0200 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPyVjz+A+cWwJh9R0qa3mmrOBhYzQCL4INw From: To: Cc: Hi Greg, > This does seem like a good thing to discuss. Seems to me that > it would be beneficial to have some way of enforcing forward > compatibility from RADIUS to Diameter. A working group with > both protocols in its purview might provide that venue for > enforcement- or at least awareness. Also, most of the work > item areas are solution oriented, not protocol specific.=20 >=20 > I believe ITU-T is looking favorably at applying 3GPP's IMS > architecture to DSL & Cable. That leads me to believe that > more Diameter applications will be on the way. If AAA-WG is > going to shutdown, we need an area for these new AAA applications > to develop. I agree with you on this point. A question to the chairs -=20 should we send text on the proposed charter with this in mind? thanks, John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 10:48:34 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: subtypes (was: HTTP digest and RADIUS; new version of the Sterman draft) Date: Mon, 16 Feb 2004 12:48:29 +0200 Message-ID: Thread-Topic: HTTP digest and RADIUS; new version of the Sterman draft Thread-Index: AcPz/Zw3Xhly9QigSaCHfav8leXEFwAe5sJQ From: To: , Hi Wolfgang, > We seem to have two main positions on the list on the purpose > of RADIUSEXT. Correct me if I misunderstood the discussion. >=20 > a) Only allow new attributes that can be introduced by just > adding them to the dictionary and the user database. No > recompilation of the RADIUS server is allowed. >=20 > b) Add new attributes, even if they require some special server > behaviour. The RADIUS protocol itself remains untouched. RADIUS server > may need additional code to handle the new attributes. >=20 > My suspicion is that our discussion is more about a) vs. b) than > about attribute syntax. >=20 > A charter only allowing a) is not really worth the effort, but seems > to be preferred by people who want DIAMETER to be deployed.=20 My two cents are that I hope extensions to RADIUS to not break current implementations of RADIUS and/or Diameter. My company has implemented both, including some VSAs & we're concerned about extensions that would cause us to implement more stuff without a clear benefit for doing so. Talking to other vendors, I haven't heard a lot of vendors saying that they would move from VSAs to standard extensions if available. On top of that, several folks on this list have stated that other SDOs need some extentions - if that is so, I think it would be good if those SDOs would make it known to the IESG / this list via the liasons that already exist. I think we are between a rock & a hard place on this topic. A few years ago, the IETF undertook a process to define the AAA infrastructure. At the time, extending RADIUS seemed to be a messier job (and not = guarenteed for success) than to standardize Diameter. I think that the IETF did a poor job in getting Diameter completed in a timely manner (which is another source of the current mess we find ourselves in). I think the IESG is looking for clear proof that RADIUS extensions are needed, so I'd be interested in seeing some reasoning (perhaps even in draft format) for this. Otherwise, I doubt the IESG will be really excited = about chartering this WG. In otherwords, the burden of proof is upon those who want to extend RADIUS. I'm not adverse to some extensions, I think some of the roaming situations would be good places to create standards. However, my sense of the room is that folks are saying we should extend RADIUS because we can, which doesn't seem like a good argument. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 10:38:47 +0000 Message-ID: <40309D9D.91EA0810@alcatel.be> Date: Mon, 16 Feb 2004 11:38:22 +0100 From: Nagi Organization: Alcatel Telecom MIME-Version: 1.0 To: "Nelson, David" CC: radiusext@ops.ietf.org Subject: Subtypes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Chnaged the subject line from: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft > So are you saying that it's OK to treat a sub-class of RADIUS standard > attributes as if they were VSAs, in that only RADIUS product from > certain vendors who choose to support this functionality need to be able > to parse the attributes? It is OK to treat a sub-class of stabdard attributes as if they are not relevant for this implementation. There are plenty of standard attributes and one can't expect each and every implementation to support all of them. Take for example, a Radius client implementation which doesn't understand EAP messages. Let us say for instance, a malfunctioned Radius server sending a EAP message to the non-EAP compliant Radius client as part of Access-Accept. What do we expect from a Radius client? - Just ignore the attribute and continue with the access-accept. - Since it doesn't understand a standard attribute, it has to treat it as a access-reject. Ofcourse I vote for the first. > I think an attribute is either of limited scope of application (a VSA), > or it is of general applicability and all > RADIUS implementations SHOULD understand it. If it is not relevant for the implementation, it may ignore. regards Nagi. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 00:53:35 +0000 Message-Id: <4.3.2.7.2.20040215194345.00c33760@wells.cisco.com> Date: Sun, 15 Feb 2004 19:53:25 -0500 To: Hannes Tschofenig From: John Schnizlein Subject: Re: draft-jones-radius-geopriv Cc: radiusext@ops.ietf.org, geopriv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" I am sorry I quoted the wrong part of RFC 2865. The length of an attribute is at most 255, one octet [page 25]. It seems unlikely that GML, or any XML, would be efficient enough to be carried in a RADIUS attribute. At 01:12 PM 2/10/2004, John Schnizlein wrote: >> One concern, if this location configuration information (LCI) >> is to be carried over RADIUS, is that the example in section 6 >> seems to be 993 characters long. This one attribute seems to be >> taking a large share of the maximum RADIUS packet size of 4096. >> [RFC 2865, p 15] Is there enough room for everything else that >> would be expected with this attribute? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 16 Feb 2004 00:23:12 +0000 Message-ID: <40300CE9.7020601@piuha.net> Date: Mon, 16 Feb 2004 02:20:57 +0200 From: Jari Arkko Reply-To: jarkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Wolfgang Beck CC: radiusext@ops.ietf.org Subject: Re: HTTP digest and RADIUS; new version of the Sterman draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Can we have a new subject line for the subtype debate? Right now, I don't have time to follow that but I would like to follow what is happening to the digest thing. Thanks, --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Feb 2004 21:26:33 +0000 To: radiusext@ops.ietf.org Subject: Re: HTTP digest and RADIUS; new version of the Sterman draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5431.1076880378.1@localhost> Date: Sun, 15 Feb 2004 22:26:18 +0100 From: wolfgang.beck01@t-online.de (Wolfgang Beck) Message-ID: <1AsTmN-1FlXXc0@fwd00.sul.t-online.com> Dave Nelosn wrote: > Wolfgang wrote: >> A charter only allowing a) is not really worth the effort, but seems >> to be preferred by people who want DIAMETER to be deployed. > [DBN] In my case, I have no vested interest in the deployment of > Diameter, so your inference here is debatable. Sorry. [DBN] I would turn your challenge around. You have challenged us to convince you that sub-types are "bad" for RADIUS. I would challenge you to demonstrate that sub-types do not alter the architectural intent of standard RADIUS as it is documented. A question of who bears the "burden of proof". OK, I'll try: RADIUS already uses already structured string attributes. Some attributes (like CHAP-Password) simply group components without delimiters. Some attributes use delimiters (like NAI). Some attributes use a TLV syntax, like Vendor-Specific or EAP. draft-lior and draft-sterman just followed existing examples. Nobody had the intent to violate RADIUS principles. Many principles of RADIUS have been questioned and replaced, though. > As to how to distinguish a sub-type from a compound, but > opaque-to-RADIUS, data type, I think we have delineated that as closely > as one can in general terms. If a RADIUS client, proxy or server needs > to parse the individual sub-fields of sub-types, then the sub-types > ought to be flattened to the status of full attributes (or potentially > flattened to the status of single-layer attributes under a VSA or SSA). > The one counter-example is NAI parsing in proxies to determine the next > hop server. So, why don't you ask Jari to define a new Request-Destination attribute? > I would argue that QoS attributes, SIP attributes, pre-paid attributes, > and the like are simply attributes. The desire to "group" them can > likely be handled by existing tagging methods. Location attributes, if > defined in some well-known format such as X.500 syntax, probably qualify > as a single attribute, with multiple parts, similar to NAI in User-Names > or FQDN in NAS-Identifiers. The question is, whether an attribute can be used individually. User-Name makes sense in more than on combination. An HTTP digest nonce attribute is useless if there aren't Method-, URI- etc attributes available. HTTP groups them, why shouldn't RADIUS do the same? And for your tunneling argument: how does flattening out attributes change that? Would it be ok for you if we defined IP-Version, IP-Header-Length, IP-Type-Of-Service etc attributes? I guess not. Wolfgang -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Feb 2004 21:25:56 +0000 Message-ID: From: Avi Lior To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Sun, 15 Feb 2004 16:25:42 -0500 MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Monday, February 16, 2004 2:47 AM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: RE: FW: HTTP digest and RADIUS; new version of the > Sterman draft > > > Avi Lior writes... > > > Why is that any different then encoding a string with AVP > as in X.500 > > encoding "a=1 b=3". If that type of encoding is acceptable > so should > the > > other. > > [DBN] It IS different, and I don't know if I can come up with > any additional or different explanations of why, beyond what > I have already written on this topic. But let me try: You > could, given the length constraints of attributes, create an > attribute of base-type undistinguished octets (String) and > include within the attribute value field an entire IPv4 > packet. We are talking about RADIUS here right? RADIUS attributes are limited to 253 Octets. I don't see the relevance of your comment at all. > We have one explicit example of an > encapsulated protocol -- the EAP-Message attribute -- and > that's fine because it is reasonable, necessary and explicit. > It is also fine because EAP messages are clearly out-of-scope > for RADIUS. No RADIUS product would want to attempt to parse > them -- they are "foreign" entities. This is the exact case for Prepaid application and for Sterman draft. As you correctly point out, just like the EAP case the internal attributes in both the sterman draft and the prepaid draft are there exclusively for the endpoint application. As I suggested a million emails ago on this topic -- this should be the test. If the internal attributes are of use solely by the endpoint applications (EAP for example) then there is no need to expose them. Infact there are advantages to be gained in performance gains in the proxy chains. > The example you give in support of what I still call > sub-types is X.500 addresses. I have previously used a > similar example of DNS FQDNs. Each of these is a multi-part > data type. The distinction is that they are NOT a compendium > of attributes that are within the scope of AAA, grouped > together. They are, to a large extent, an opaque data type > that the RADIUS protocol engine itself does not attempt to > parse. They are forwarded to external entities, such as name > resolution engines, that process them, and potentially return > some useful result. Exactly correct. Once again this passes the above test. Note that like in EAP endpoint application or foreign entities, or external entities may be colocated with the RADIUS server or external to the RADIUS server. They are not part of the base RADIUS engine. In past emails what I said was: If the protocol designer is allowed a choice, it would be preferable that they use TLV encoding inside STRINGS as opposed to "a=1 b=2" encoding scheme because of the obvious benefits of being more compact and easier to parse. >The only exception to this, that I'm > aware of, is the NAI usages, in which a RADIUS proxy may > parse the "realm" portion of an NAI to determine the next hop > server address. This is the minimum routing requirement and much more complex then you indicate but I get your point and I agree. > > The point which is made over and over is that the attribute > is to be > > interrperted only by endpoints and these would have code beyond the > > dictionary anyway to parse further. > > [DBN] I fully understand that point, however I reject it. > This is not quite the same situation as the EAPOL messages we > encapsulate in EAP-Message attributes. The items being > debated are clearly, IMHO, AAA attributes fully within the > scope of RADIUS and Diameter. Therefore any attempt to > "group" them in a fashion opaque to the majority of RADIUS > product simply fragments the multi-vendor interoperability of > RADIUS. The argument that only the RADIUS clients and servers > from companies that are promoting these proposals need to be > able to "play", i.e. to be able to parse the attributes if > they wish, is antithetical to the architecture of RADIUS. > Any such "limited scope" attributes MUST, IMHO, be VSAs. > Otherwise we no longer have a single, interoperable RADIUS standard. I couldn't disagree with you more. First of all, the above argument has nothing to do with with grouping attributes (or the creation of stealthy protocols as you call it). Its equally valid for ordinary RADIUS attributes. If I flatten out my "stealthy" attributes that doesn't mean that everyone will implment them and should implment them!!! And it's too late. RADIUS already has the concept of extensions that are not globally available or implemted by all RADIUS servers. First there a groups of applications that are optionally supported: EAP, CHIBA 3576, TUNNELS (2868), IPv6, WLAN extensions (RFC 3580) Second there are many attributes that are optionally supported: Look at all the Appletalk attributes..... Not every deployment needs Appletalk 'stuff' and not every RADIUS client supports these attributes. The same is true of EAP and the same could be said of HTTP Digest. You develop these extensions to that RADIUS can serve a purpose in an ever evolving landscape. You do this at the IETF for the obvious reasons. Mr Nelson, I am looking forward to you standing up at the next AAA-WG meeting and objecting to having Diameter based Applications on the same grounds. > -- Dave > > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Feb 2004 20:29:06 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: HTTP digest and RADIUS; new version of the Sterman draft Date: Sun, 15 Feb 2004 15:28:57 -0500 Message-ID: Thread-Topic: HTTP digest and RADIUS; new version of the Sterman draft Thread-Index: AcPz/Z3HnD9KmJlMQMeHSWCcqLOoHgAAoHKg From: "Nelson, David" To: "Wolfgang Beck" , Wolfgang Beck writes... > A charter only allowing a) is not really worth the effort, but seems > to be preferred by people who want DIAMETER to be deployed. [DBN] In my case, I have no vested interest in the deployment of Diameter, so your inference here is debatable.=20 > I will remove structured strings immediately from draft-sterman-aaa-sip > if somebody can show me a concrete real world example why they are so > horrible. The debate on "tunneling" and secondary issues like attribute > syntax is somewhat philosophical and leads nowhere. Every protocol tunnels > higher layer protocols. Jari's 'user@realm' tunnels request-routing > information in a User-Name attribute. The Digest-Attributes attribute > of draft-sterman-aaa-sip tunnels HTTP digest information, using a TLV > syntax instead of '@' for separating optional components. Where do you > draw the line and why? [DBN] I would turn your challenge around. You have challenged us to convince you that sub-types are "bad" for RADIUS. I would challenge you to demonstrate that sub-types do not alter the architectural intent of standard RADIUS as it is documented. A question of who bears the "burden of proof". As to how to distinguish a sub-type from a compound, but opaque-to-RADIUS, data type, I think we have delineated that as closely as one can in general terms. If a RADIUS client, proxy or server needs to parse the individual sub-fields of sub-types, then the sub-types ought to be flattened to the status of full attributes (or potentially flattened to the status of single-layer attributes under a VSA or SSA). The one counter-example is NAI parsing in proxies to determine the next hop server. I would argue that QoS attributes, SIP attributes, pre-paid attributes, and the like are simply attributes. The desire to "group" them can likely be handled by existing tagging methods. Location attributes, if defined in some well-known format such as X.500 syntax, probably qualify as a single attribute, with multiple parts, similar to NAI in User-Names or FQDN in NAS-Identifiers. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Feb 2004 19:54:47 +0000 To: radiusext@ops.ietf.org Subject: Re: HTTP digest and RADIUS; new version of the Sterman draft MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5236.1076874844.1@localhost> Date: Sun, 15 Feb 2004 20:54:04 +0100 From: wolfgang.beck01@t-online.de (Wolfgang Beck) Message-ID: <1AsSL7-0VYDvU0@fwd01.sul.t-online.com> We seem to have two main positions on the list on the purpose of RADIUSEXT. Correct me if I misunderstood the discussion. a) Only allow new attributes that can be introduced by just adding them to the dictionary and the user database. No recompilation of the RADIUS server is allowed. b) Add new attributes, even if they require some special server behaviour. The RADIUS protocol itself remains untouched. RADIUS server may need additional code to handle the new attributes. My suspicion is that our discussion is more about a) vs. b) than about attribute syntax. A charter only allowing a) is not really worth the effort, but seems to be preferred by people who want DIAMETER to be deployed. I'd prefer a charter that allows b) and so do some other draft authors. To those who support a), would your vote be the same if we were discussing a AAAEXT charter and were talking about DIAMETER AVPs? Dave Nelson wrote: > My further opinion is that much of the argument in favor of sub-types is > seeking to protect existing implementations from IETF WG change control. I will remove structured strings immediately from draft-sterman-aaa-sip if somebody can show me a concrete real world example why they are so horrible. The debate on "tunneling" and secondary issues like attribute syntax is somewhat philosophical and leads nowhere. Every protocol tunnels higher layer protocols. Jari's 'user@realm' tunnels request-routing information in a User-Name attribute. The Digest-Attributes attribute of draft-sterman-aaa-sip tunnels HTTP digest information, using a TLV syntax instead of '@' for separating optional components. Where do you draw the line and why? Wolfgang -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Feb 2004 18:04:10 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Sun, 15 Feb 2004 13:04:03 -0500 Message-ID: Thread-Topic: FW: HTTP digest and RADIUS; new version of the Sterman draft Thread-Index: AcPy6lnRZONiH2wWQWGeOEf80iS+gwBAftrQ From: "Nelson, David" To: "Alan DeKok" , Alan DeKok writes... > One of the reasons for writing standards in the IETF is so that > other people don't. As we've seen in a number of cases, non-IETF > extensions to RADIUS involve *terrible* protocol design. [DBN] Agreed.=20 > I'm sure many people will agree that defining sub-types in RADIUS is > ugly. But it's significantly less ugly than the choices made by > non-IETF groups. [DBN] Hmmm. That may amount to damnation by means of faint praise. :-) > The single largest reason for defining sub-types is not to make our > life easier when writing new I-D's for RADIUS. It's to give other > people a standard way of extending RADIUS, and thus to make our life > easier when we have to implement their modifications to the protocol. [DBN] My personal opinion on this is that the sub-types are not in any technical way necessary in any of these current proposals. The authors, working outside of IETF supervision, have created, implemented, and in some cases deployed, these extensions using sub-types. My further opinion is that much of the argument in favor of sub-types is seeking to protect existing implementations from IETF WG change control. There may, in fact, be some merit to a variation of your suggestion. I have thought about the notion of SDO-Specific RADIUS Attributes (SSAs). These would be structured similarly to the VSAs, but with the requirement of a single layer of sub-attributes, reflecting standard RADIUS attribute format within the value field of an SSA, promoted to a MUST. This would allow SDOs to create RADIUS attributes within their "vendor ID" space. In addition, there should be some formal protocol quality review process, similar to the "MIB Doctors" used to review new MIBs. All of this would not help the current debate, however, as "grouped" sub-types would still be prohibited. But it might be of great utility for future discussions. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Feb 2004 17:46:46 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Sun, 15 Feb 2004 12:46:35 -0500 Message-ID: Thread-Topic: FW: HTTP digest and RADIUS; new version of the Sterman draft Thread-Index: AcPy3RjztKaiKaHQSxGTj8uOjcX9ZQBC597A From: "Nelson, David" To: "Avi Lior" Cc: Avi Lior writes... > Why is that any different then encoding a string with AVP as in X.500 > encoding "a=3D1 b=3D3". If that type of encoding is acceptable so = should the > other. [DBN] It IS different, and I don't know if I can come up with any additional or different explanations of why, beyond what I have already written on this topic. But let me try: You could, given the length constraints of attributes, create an attribute of base-type undistinguished octets (String) and include within the attribute value field an entire IPv4 packet. I think it is clear, in this somewhat extreme example, that a string is not a simple string but a "stealth protocol". I am opposed to hiding "stealth protocols" in RADIUS attributes. We have one explicit example of an encapsulated protocol -- the EAP-Message attribute -- and that's fine because it is reasonable, necessary and explicit. It is also fine because EAP messages are clearly out-of-scope for RADIUS. No RADIUS product would want to attempt to parse them -- they are "foreign" entities. The example you give in support of what I still call sub-types is X.500 addresses. I have previously used a similar example of DNS FQDNs. Each of these is a multi-part data type. The distinction is that they are NOT a compendium of attributes that are within the scope of AAA, grouped together. They are, to a large extent, an opaque data type that the RADIUS protocol engine itself does not attempt to parse. They are forwarded to external entities, such as name resolution engines, that process them, and potentially return some useful result. The only exception to this, that I'm aware of, is the NAI usages, in which a RADIUS proxy may parse the "realm" portion of an NAI to determine the next hop server address. > The point which is made over and over is that the attribute is to be > interrperted only by endpoints and these would have code beyond the > dictionary anyway to parse further. [DBN] I fully understand that point, however I reject it. This is not quite the same situation as the EAPOL messages we encapsulate in EAP-Message attributes. The items being debated are clearly, IMHO, AAA attributes fully within the scope of RADIUS and Diameter. Therefore any attempt to "group" them in a fashion opaque to the majority of RADIUS product simply fragments the multi-vendor interoperability of RADIUS. The argument that only the RADIUS clients and servers from companies that are promoting these proposals need to be able to "play", i.e. to be able to parse the attributes if they wish, is antithetical to the architecture of RADIUS. Any such "limited scope" attributes MUST, IMHO, be VSAs. Otherwise we no longer have a single, interoperable RADIUS standard. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 15 Feb 2004 17:14:11 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Sun, 15 Feb 2004 12:16:22 -0500 Message-Id: <20040215171622.95AB316CCA@mail.nitros9.org> Bernard Aboba wrote: > In general, the server does not need to understand attributes that it > sends, although the NAS does need to understand those it receives. > If the server is sending an attribute it doesn't understand, why should > the server require code changes? For attributes like IP addresses, text strings, or integers, I agree. For attributes which require some kind of calculation (e.g. md5, or authentication calculations), the server *must* be upgraded. > While one could argue that the server could just create a "String" type, > the reality is that many RADIUS implementations don't support entering > arbitrary binary data into "String" attribute types. Which is an implementation limitation, in *addition* to those imposed by the RFC's. Many attributes are defined or suggested to be "undistinguished octets". If a server does not support that, I don't see why it would be fully RFC compliant. And I don't see why we would handcuff ourselves for new attributes, just because of non-compliant implementations. There's a simple solution: upgrade. > Do we have concrete examples of where this will *not* work? My previous post mentioned IP addresses. They also won't work (or will be difficult) when the encapsulated data is undistinguished octets. If the first octet is 0x01, is it a tag, or part of the atribute data? I've always thought that the design of tagged attributes was problematic. The tags may, or may not, exist. The value in the first octet may, or may not, be a tag. You can't have tagged IP addresses. Tagged integers can only be 24 bits, etc. All of these limitations and different ways of doing the same thing make implementation more difficult. I'm not a party to any draft which proposes new attributes, but I will be implementing support for them. Being lazy, I'd rather see an attribute design which has a simple implementation, than one which gives me 2-4 ways of doing the same thing, and also prevents me from doing other things which are currently possible. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Feb 2004 17:56:29 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Avi Lior Cc: Alan DeKok , radiusext@ops.ietf.org Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Sat, 14 Feb 2004 12:56:25 -0500 MIME-Version: 1.0 Content-Type: text/plain Thank you for the reply. Here is my follow up. Can you show me in either sterman or lior where we are adding a new type to RADIUS? The encoding used for the string attributes may be functinally equivalent to a Grouped attribute but its not the same because we are not seeking to create a new attribute. If we were creating a grouped type then code would have to change because RADIUS dictionaries know about string and don't know about Grouped AVPs. So specifically, sterman/lior do not break RADIUS dictionaries. Right? Passing this attributes over a proxy chain today will not create a problem right? No new code would have to be introduced to handle these attributes. I wish to debate the pros and cons of introducing an Grouped AVPs but I don't want that debate to get in the way of the specific case. (At least in this email). > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: February 14, 2004 12:19 PM > To: Avi Lior > Cc: Alan DeKok; radiusext@ops.ietf.org > Subject: RE: FW: HTTP digest and RADIUS; new version of the > Sterman draft > > > > While this debate is interesting its not addressing the > issue. We are > > not trying to create a new fundemental type! We agree That > this would > > break RADIUS. > > > > Sterman draft and my prepaid draft are not introducing any new > > fundemental type. We are introducing a new Attribute of Type String. > > > > Given that, that this is only to be decoded at the RADIUS > server for > > which the Attribute is intended (and not by proxies) then how does > > this break existing RADIUS Server? > > This is the equivalent to Diameter's Grouped AVPs. Note that > grouping is allowed within RFC 2865 only for attributes of > Type 26 (Vendor Specific). In Section 5.26, it states: > > " Multiple subattributes MAY be encoded within a single Vendor- > Specific attribute, although they do not have to be." > > Grouped AVPs do not violate the fundamental design principle > of Diameter, since a Diameter server is assumed to be able to > handle the addition of a Grouped AVP without code changes. > > However, some constraints are required to limit the resulting > complexity. Diameter Grouped AVPs prohibit nesting within > sub-types (e.g. no Grouped AVP within a Grouped AVP), and > permit sub-AVPs only to utilize one of the Types defined in Diameter. > > That said, there are some additional constraints that appear > in RADIUS. > > a. Efficiency. The "tagged" approach taken in RFC 2867 and > 2868 is more efficient than Grouped AVPs, and therefore is > probably to be preferred, everything else being equal. Do we > have examples where the "tagged" approach would not work? > > b. Length constraints. Unlike Diameter, RADIUS attributes > can only be 253 octets in length. If Grouped AVPs are in > aggregate longer than this, then it will be necessary to > support fragmentation and reassembly of Grouped AVPs which > increases complexity. > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Feb 2004 17:51:02 +0000 Date: Sat, 14 Feb 2004 10:02:48 -0800 (PST) From: Bernard Aboba To: Alan DeKok cc: radiusext@ops.ietf.org Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > ... new VSA-style attributes with sub-types can be ignored by > servers that don't understand them. Provisions for this behaviour are > already in the RFC's. This makes adding new attributes easy, whatever > their internal format. The issue isn't just for receivers. It is also for servers *sending* the attributes. > attributes is irrelevant to anyone not implementing support for them. In general, the server does not need to understand attributes that it sends, although the NAS does need to understand those it receives. If the server is sending an attribute it doesn't understand, why should the server require code changes? While one could argue that the server could just create a "String" type, the reality is that many RADIUS implementations don't support entering arbitrary binary data into "String" attribute types. > I don't see anyone here trying to create a data definition language > for RADIUS. That's a bit much. The only debate I've seen so far is > about the ability to have VSA-style sub-types in new attributes. In Diameter, grouped AVPs are not allowed except where the AVPs being grouped have some relationship to each other. So is the issue really grouping, or is it the need for new types (such as a 128-bit IPv6 address type). If the former, do we understand why the tagging approach proposed in RFC 2867 and 2868 won't work? > I agree that this will be sufficient for many situations. Do we have concrete examples of where this will *not* work? BTW, it's important in this discussion to distinguish between "tagging", grouped AVPs and additional datatype proposals. Each of these approaches has quite different implications. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Feb 2004 17:30:42 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Sat, 14 Feb 2004 12:33:14 -0500 Message-Id: <20040214173314.8E6CF16CCA@mail.nitros9.org> Bernard Aboba wrote: > a. Efficiency. The "tagged" approach taken in RFC 2867 and 2868 is > more efficient than Grouped AVPs, and therefore is probably to be > preferred, everything else being equal. Do we have examples where the > "tagged" approach would not work? Anywhere an IP address is required to be a member of a group. Even RFC 2868 hides this problem: --- Type 66 for Tunnel-Client-Endpoint. ... String The format of the address represented by the String field depends upon the value of the Tunnel-Medium-Type attribute. If Tunnel-Medium-Type is IPv4 (1), then this string is either the fully qualified domain name (FQDN) of the tunnel client machine, or it is a "dotted-decimal" IP address. --- My only response is "yuck". I understand why that was done, but RADIUS already has an "IP address" fundamental data type. It would have been cleaner to define a "Tunnel-Client-Endpoint-IP-Address" attribute, but that's impossible with the "tag" method of grouping attributes. In this case, the goal for backwards compatibility resulted in the addition of a *new* base type to RADIUS: IP addresses represented in text as dotted quads, rather than as 32-bit entities. It would have arguable been cleaner to group the attributes into a new "Tunnel-Message" attribute, like EAP-Message, but with VSA-style sub-types. But I don't want to get into re-designing those RFC's now. > b. Length constraints. Unlike Diameter, RADIUS attributes can only be 253 > octets in length. If Grouped AVPs are in aggregate longer than this, then > it will be necessary to support fragmentation and reassembly of > Grouped AVPs which increases complexity. That is an issue. But People have dealt with it for EAP-Message, so I don't see any real difficulties with it. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Feb 2004 17:19:12 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Sat, 14 Feb 2004 12:21:46 -0500 Message-Id: <20040214172146.5251F16CCA@mail.nitros9.org> Bernard Aboba wrote: > One of the basic design principles of RADIUS is that adding a new > attributes does not require code changes on the server. To maintain this > principle while adding sub-types is extremely difficult because: ... new VSA-style attributes with sub-types can be ignored by servers that don't understand them. Provisions for this behaviour are already in the RFC's. This makes adding new attributes easy, whatever their internal format. I just don't see concrete reasons to oppose the idea that new attributes may be interpreted in certain limited ways by servers which have support for those attributes. Whatever goes into those attributes is irrelevant to anyone not implementing support for them. > a. RADIUS attributes are of limited length. In Diameter, attributes can > be much larger, which allowed us to introduce "Grouped" AVPs. However, > "Grouped" attributes are permitted in RFC 2865 only within attribute > 26, Vendor-Specific, but they are of limited utility since in RADIUS > an attribute can only be 253 octets in length. There's nothing to stop us from treating sequential instances of the same attribute in the same way as we now deal with EAP-Message. The only limit on encapsulated data is RADIUS packet size. Existing implementations don't need to change. > b. AAA protocols have chosen not to introduce a data definition language > such as the SMI. This was debated in the AAA WG, but it was decided that > this would introduce a level of complexity that was not warranted. In any > case, now that Diameter has chosen grouped AVPs, introduction of a data > type definition language in RADIUS would introduce compatibility issues. I don't see anyone here trying to create a data definition language for RADIUS. That's a bit much. The only debate I've seen so far is about the ability to have VSA-style sub-types in new attributes. > Given the constraints implied by a) and b), the traditional approach in > RADIUS has been to introduce "tagged" attributes that fit within existing > data types. For example, RFC 2867 and 2868 utilize tags within 4-octet > integers, so that no new data types are required. I agree that this will be sufficient for many situations. If there is huge opposition to sub-types, then draft authors may trivially work around the problem by defining "tagged" attributes, where the "tag" is interpreted as a sub-type. There will be no changes to existing implementations, and the attributes will fit into the current requirements. Would that solution be more, or less, acceptable than defining VSA-style sub-types in a new attribute? Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Feb 2004 17:07:22 +0000 Date: Sat, 14 Feb 2004 09:19:20 -0800 (PST) From: Bernard Aboba To: Avi Lior cc: Alan DeKok , radiusext@ops.ietf.org Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > While this debate is interesting its not addressing the issue. > We are not trying to create a new fundemental type! We agree > That this would break RADIUS. > > Sterman draft and my prepaid draft are not introducing any new > fundemental type. We are introducing a new Attribute of > Type String. > > Given that, that this is only to be decoded at the RADIUS > server for which the Attribute is intended (and not by proxies) > then how does this break existing RADIUS Server? This is the equivalent to Diameter's Grouped AVPs. Note that grouping is allowed within RFC 2865 only for attributes of Type 26 (Vendor Specific). In Section 5.26, it states: " Multiple subattributes MAY be encoded within a single Vendor- Specific attribute, although they do not have to be." Grouped AVPs do not violate the fundamental design principle of Diameter, since a Diameter server is assumed to be able to handle the addition of a Grouped AVP without code changes. However, some constraints are required to limit the resulting complexity. Diameter Grouped AVPs prohibit nesting within sub-types (e.g. no Grouped AVP within a Grouped AVP), and permit sub-AVPs only to utilize one of the Types defined in Diameter. That said, there are some additional constraints that appear in RADIUS. a. Efficiency. The "tagged" approach taken in RFC 2867 and 2868 is more efficient than Grouped AVPs, and therefore is probably to be preferred, everything else being equal. Do we have examples where the "tagged" approach would not work? b. Length constraints. Unlike Diameter, RADIUS attributes can only be 253 octets in length. If Grouped AVPs are in aggregate longer than this, then it will be necessary to support fragmentation and reassembly of Grouped AVPs which increases complexity. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Feb 2004 16:33:57 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Alan DeKok Cc: radiusext@ops.ietf.org Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Sat, 14 Feb 2004 11:33:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bernard, While this debate is interesting its not addressing the issue. We are not trying to create a new fundemental type! We agree That this would break RADIUS. Sterman draft and my prepaid draft are not introducing any new=20 fundemental type. We are introducing a new Attribute of Type String. Given that, that this is only to be decoded at the RADIUS=20 server for which the Attribute is intended (and not by proxies)=20 then how does this break existing RADIUS Server? =20 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD for Digest-Attributes. Length >=3D 5 String The String field is 3 or more octets and contains one or more subattributes. Format of a subattribute is shown be=A1 low. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Sub-Type | Sub-Length | Sub-Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ......................... > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: February 14, 2004 10:27 AM > To: Alan DeKok > Cc: radiusext@ops.ietf.org > Subject: Re: FW: HTTP digest and RADIUS; new version of the=20 > Sterman draft=20 >=20 >=20 > > The single largest reason for defining sub-types is not to make our = > > life easier when writing new I-D's for RADIUS. It's to give other=20 > > people a standard way of extending RADIUS, and thus to make=20 > our life=20 > > easier when we have to implement their modifications to the=20 > protocol. >=20 > One of the basic design principles of RADIUS is that adding a=20 > new attributes does not require code changes on the server. =20 > To maintain this principle while adding sub-types is=20 > extremely difficult because: >=20 > a. RADIUS attributes are of limited length. In Diameter,=20 > attributes can be much larger, which allowed us to introduce=20 > "Grouped" AVPs. However, "Grouped" attributes are permitted=20 > in RFC 2865 only within attribute 26, Vendor-Specific, but=20 > they are of limited utility since in RADIUS an attribute can=20 > only be 253 octets in length. >=20 > b. AAA protocols have chosen not to introduce a data=20 > definition language such as the SMI. This was debated in the=20 > AAA WG, but it was decided that this would introduce a level=20 > of complexity that was not warranted. In any case, now that=20 > Diameter has chosen grouped AVPs, introduction of a data type=20 > definition language in RADIUS would introduce compatibility issues. >=20 > Given the constraints implied by a) and b), the traditional=20 > approach in RADIUS has been to introduce "tagged" attributes=20 > that fit within existing data types. For example, RFC 2867=20 > and 2868 utilize tags within 4-octet integers, so that no new=20 > data types are required. >=20 > Another potential approach would be to add additional=20 > fundamental types, such as 128-bit IPv6 addresses. While=20 > code changes would be required, they would presumably only=20 > need to be done once, and the basic RADIUS design principle=20 > would be upheld. >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Feb 2004 15:15:13 +0000 Date: Sat, 14 Feb 2004 07:26:55 -0800 (PST) From: Bernard Aboba To: Alan DeKok cc: radiusext@ops.ietf.org Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The single largest reason for defining sub-types is not to make our > life easier when writing new I-D's for RADIUS. It's to give other > people a standard way of extending RADIUS, and thus to make our life > easier when we have to implement their modifications to the protocol. One of the basic design principles of RADIUS is that adding a new attributes does not require code changes on the server. To maintain this principle while adding sub-types is extremely difficult because: a. RADIUS attributes are of limited length. In Diameter, attributes can be much larger, which allowed us to introduce "Grouped" AVPs. However, "Grouped" attributes are permitted in RFC 2865 only within attribute 26, Vendor-Specific, but they are of limited utility since in RADIUS an attribute can only be 253 octets in length. b. AAA protocols have chosen not to introduce a data definition language such as the SMI. This was debated in the AAA WG, but it was decided that this would introduce a level of complexity that was not warranted. In any case, now that Diameter has chosen grouped AVPs, introduction of a data type definition language in RADIUS would introduce compatibility issues. Given the constraints implied by a) and b), the traditional approach in RADIUS has been to introduce "tagged" attributes that fit within existing data types. For example, RFC 2867 and 2868 utilize tags within 4-octet integers, so that no new data types are required. Another potential approach would be to add additional fundamental types, such as 128-bit IPv6 addresses. While code changes would be required, they would presumably only need to be done once, and the basic RADIUS design principle would be upheld. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Feb 2004 11:04:14 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Sat, 14 Feb 2004 06:06:31 -0500 Message-Id: <20040214110631.2F89A16CCA@mail.nitros9.org> Greg Weber wrote: > One advantage of formalizing sub-typed data might be to imposing > or strongly encouraging that same structured framework on VSAs. > I'm fearful of heading towards lots of different VSA structures, > e.g. IS-835 has at least a couple different VSA-specific ways > of sub-typing data. Similarly for the 3gpp2 attributes. One of the reasons for writing standards in the IETF is so that other people don't. As we've seen in a number of cases, non-IETF extensions to RADIUS involve *terrible* protocol design. I'm sure many people will agree that defining sub-types in RADIUS is ugly. But it's significantly less ugly than the choices made by non-IETF groups. The single largest reason for defining sub-types is not to make our life easier when writing new I-D's for RADIUS. It's to give other people a standard way of extending RADIUS, and thus to make our life easier when we have to implement their modifications to the protocol. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 14 Feb 2004 09:31:39 +0000 Message-ID: From: Avi Lior To: 'Nagi' , "Nelson, David" Cc: Alan DeKok , radiusext@ops.ietf.org Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Sat, 14 Feb 2004 04:31:06 -0500 MIME-Version: 1.0 Content-Type: text/plain Thanx NAGI, With one comment which I think is important. Its not a single unknown TLV. The attribute is of type String. The proxy would not see an unknown attribute. It would see an attribute of type string which it wouldn't know how to generally parse further. > -----Original Message----- > From: Nagi [mailto:Nagi_Reddy.Jonnala@alcatel.be] > Sent: February 13, 2004 11:57 AM > To: Nelson, David > Cc: Alan DeKok; radiusext@ops.ietf.org > Subject: Re: FW: HTTP digest and RADIUS; new version of the > Sterman draft > > > > I argue that adding sub-types means changing the parsing code. > > *only* the end points who wish to understand the sub-types > need to implement the parsing code ( almost similar to VSA > parsing). Radius proxies > treat these sub-types as a single unknown TLV. That is > acceptable, IMO. > > -Nagi. > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 19:09:46 +0000 Date: Fri, 13 Feb 2004 11:21:45 -0800 (PST) From: Bernard Aboba To: "Nelson, David" cc: Alan DeKok , radiusext@ops.ietf.org Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > If tagged attributes are sufficient, then I see no reason to add new > sub-types. Note that RFC 2867 and 2868 make use of "tagged" attributes. These RFCs do *not* define sub-types because the attributes are designed to fit within an existing data type - 4-octet Integer. Having said that, new code typically *was* required to implement RFC 2867 and 2868, so as to allow the creation of UI to enable entering of Tunnel attributes in an easy-to-use way. However, existing products could have been used without code changes, by manually entering appropriate Integer values. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 19:05:02 +0000 Date: Fri, 13 Feb 2004 11:15:13 -0800 (PST) From: Bernard Aboba To: "Nelson, David" cc: Nagi , radiusext@ops.ietf.org Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Recall that RADIUS clients MAY handle an unknown > attribute by treating the packet as if it were an Access-Reject. RFC 2865 Section 1.1 says: A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead. At the same time, Section 5 says: A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type. My interpretation of this is that RFC 2865 defines attributes authorizing a service as "mandatory", whereas other attributes are optional. The next question is "which attributes advertise a service?" The definition of a service in RFC 2865 is: service The NAS provides a service to the dial-in user, such as PPP or Telnet. This example seems to correspond to the definition of the Service-Type attribute (which can authorize Framed or Login services, among others). So at least the Service-Type attribute needs to be considered Mandatory. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 18:27:16 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Fri, 13 Feb 2004 13:26:53 -0500 Message-ID: Thread-Topic: FW: HTTP digest and RADIUS; new version of the Sterman draft Thread-Index: AcPyUnmCtrQBC6waTbS3Ahx/D41idwACwRnA From: "Nelson, David" To: "Nagi" Cc: Nagi writes... > *only* the end points who wish to understand the sub-types need to > implement the parsing code ( almost similar to VSA parsing). Radius > proxies treat these sub-types as a single unknown TLV. That is > acceptable, IMO. I guess as long as the policy is to blithely ignore unknown attributes. That might be an acceptable policy for a proxy, under certain circumstances. Recall that RADIUS clients MAY handle an unknown attribute by treating the packet as if it were an Access-Reject. There is almost always a policy decision to be made between the interests of transparent plug and play and the interests of strict security. So are you saying that it's OK to treat a sub-class of RADIUS standard attributes as if they were VSAs, in that only RADIUS product from certain vendors who choose to support this functionality need to be able to parse the attributes? I think an attribute is either of limited scope of application (a VSA), or it is of general applicability and all RADIUS implementations SHOULD understand it. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 17:24:30 +0000 From: Greg Weber Message-Id: <200402131724.MAA29752@cisco.com> Subject: Re: Bof at next IETF? To: john.loughney@nokia.com Date: Fri, 13 Feb 2004 12:24:03 -0500 (EST) Cc: avi@bridgewatersystems.com, pyegani@cisco.com, dromasca@avaya.com, dnelson@enterasys.com, radiusext@ops.ietf.org, aboba@internaut.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > >But at the last meeting, I remember > > > that a significant number of people thought it would be best > > > for the WG to be AAA Extensions, not just RADIUS extensions, > > > but we haven't discussed that on the mailing list. This does seem like a good thing to discuss. Seems to me that it would be beneficial to have some way of enforcing forward compatibility from RADIUS to Diameter. A working group with both protocols in its purview might provide that venue for enforcement- or at least awareness. Also, most of the work item areas are solution oriented, not protocol specific. I believe ITU-T is looking favorably at applying 3GPP's IMS architecture to DSL & Cable. That leads me to believe that more Diameter applications will be on the way. If AAA-WG is going to shutdown, we need an area for these new AAA applications to develop. Greg -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 16:57:37 +0000 Message-ID: <402D01F1.2901DE6A@alcatel.be> Date: Fri, 13 Feb 2004 17:57:21 +0100 From: Nagi Organization: Alcatel Telecom MIME-Version: 1.0 To: "Nelson, David" CC: Alan DeKok , radiusext@ops.ietf.org Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > I argue that adding sub-types means changing the parsing code. *only* the end points who wish to understand the sub-types need to implement the parsing code ( almost similar to VSA parsing). Radius proxies treat these sub-types as a single unknown TLV. That is acceptable, IMO. -Nagi. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 16:31:32 +0000 From: Greg Weber Message-Id: <200402131631.LAA27456@cisco.com> Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft To: dnelson@enterasys.com (Nelson, David) Date: Fri, 13 Feb 2004 11:31:09 -0500 (EST) Cc: aland@ox.org (Alan DeKok), radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > Alan DeKok writes... > > > > The technical arguments that I have heard (and advanced) against > > > sub-types are that it changes the RADIUS architecture (simple TLV > > > structures), requires changes to the RADIUS dictionary, and breaks > > > backwards compatibility with a large deployed base of RADIUS > products. > > > > ... which we already know won't understand the new attributes. > > Yes, but they could by updating their dictionary file (or equivalent > dictionary implementation). I guess that was the point of my admittedly > imperfect analogy with SNMP -- data dictionary driven protocol parsing, > as opposed to code driven parsing. I argue that adding sub-types means > changing the parsing code. Catching up on this discussion... Would the code changes you mention be necessary for all RADIUS endpoints or only those that wish to understand sub-typed attributes? I would think that sub-typed data (as in Diameter) could be structured to look like a regular attribute at the highest level. And at that level these attributes would be ignored by endpoints that don't have definitions for them. That would seem to indicate that sub-typed data could be compatible with existing devices, but code changes would be necessary to take advantage of the new attributes. As to the code changes, I would imagine that most RADIUS client/servers already have code to parse structured values as many VSA values have structured data. One advantage of formalizing sub-typed data might be to imposing or strongly encouraging that same structured framework on VSAs. I'm fearful of heading towards lots of different VSA structures, e.g. IS-835 has at least a couple different VSA-specific ways of sub-typing data. Greg > RADIUS implementations have been designed > from day-one to deal with new attributes, in the standard single-layer > TLV format. > > I do understand that a NAS or RADIUS server that actually wants to do > something useful with the semantics of a new attribute will need added > or changed code somewhere, even if not in the core RADIUS protocol > engine. > > > The only hard requirement I can see for backwards compatibility is > > that old servers MUST be able to act as proxies for requests with new > > attributes. We've seen this behaviour with EAP-Message, so we know it > > works. > > I suppose I draw a distinction that not everyone will agree with. EAPOL > frames are not RADIUS attributes in the classic sense of the definition. > I see tunneling EAP in RADIUS as a natural thing to do. Many of the > other proposed new attributes seem like any other RADIUS attribute to > me, and thus I resist the notion of tunneling, or sub-typing. > > > If tagged attributes are sufficient, then I see no reason to add new > > sub-types. > > That works for me. Let's see if it works for others. > > -- Dave > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 16:06:25 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Fri, 13 Feb 2004 11:05:41 -0500 Message-ID: Thread-Topic: FW: HTTP digest and RADIUS; new version of the Sterman draft Thread-Index: AcPyQuQNIcumD0JBTMymc6yVEaJL+gABl67w From: "Nelson, David" To: "Alan DeKok" , Alan DeKok writes... > > The technical arguments that I have heard (and advanced) against > > sub-types are that it changes the RADIUS architecture (simple TLV > > structures), requires changes to the RADIUS dictionary, and breaks > > backwards compatibility with a large deployed base of RADIUS products. >=20 > ... which we already know won't understand the new attributes. Yes, but they could by updating their dictionary file (or equivalent dictionary implementation). I guess that was the point of my admittedly imperfect analogy with SNMP -- data dictionary driven protocol parsing, as opposed to code driven parsing. I argue that adding sub-types means changing the parsing code. RADIUS implementations have been designed from day-one to deal with new attributes, in the standard single-layer TLV format. I do understand that a NAS or RADIUS server that actually wants to do something useful with the semantics of a new attribute will need added or changed code somewhere, even if not in the core RADIUS protocol engine. > The only hard requirement I can see for backwards compatibility is > that old servers MUST be able to act as proxies for requests with new > attributes. We've seen this behaviour with EAP-Message, so we know it > works. I suppose I draw a distinction that not everyone will agree with. EAPOL frames are not RADIUS attributes in the classic sense of the definition. I see tunneling EAP in RADIUS as a natural thing to do. Many of the other proposed new attributes seem like any other RADIUS attribute to me, and thus I resist the notion of tunneling, or sub-typing. > If tagged attributes are sufficient, then I see no reason to add new > sub-types. That works for me. Let's see if it works for others. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 15:05:24 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Fri, 13 Feb 2004 10:07:43 -0500 Message-Id: <20040213150743.3EB71170CD@mail.nitros9.org> "Nelson, David" wrote: > The technical arguments that I have heard (and advanced) against > sub-types are that it changes the RADIUS architecture (simple TLV > structures), requires changes to the RADIUS dictionary, and breaks > backwards compatibility with a large deployed base of RADIUS products. ... which we already know won't understand the new attributes. The only hard requirement I can see for backwards compatibility is that old servers MUST be able to act as proxies for requests with new attributes. We've seen this behaviour with EAP-Message, so we know it works. > With SNMP, MIBs can be enrolled in SNMP management stations by a > mechanical process because you can't re-define the ASN.1/BER data > formats used in SNMP. Should we settle for any less in RADIUS? No, but RADIUS does more. The vast majority of use of SNMP is for monitoring. The SNMP servers don't *do* anything with the data they manage. That is, we generally don't expect to do an SNMP write in one place, and then read back data elsewhere which is calculated by some algorithm from the updates. If that does happen, that data is usually calculated by something outside of SNMP, like another application. RADIUS is an "active" protocol, in that it changes its responses based on different inputs. In contrast, SNMP is much more "passive". This difference means that analogies to SNMP are less than perfect. > However the sub-type attributes are not in any fundamental way different > from "normal" RADIUS attributes. So what are the reasons offered for > treating them differently? One reason seems to be "the convenience of > grouping". RADIUS already has a recognized method of grouping > attributes. Using tunnel-type "tags" for grouping attributes is reasonable. > A second reason seems to be "we will run out of attribute > number space". Let's take a head count of new attributes that fall > within the scope of the charter before we deiced that, shall we? The rouch count posted to the list was what, 40-80 attributes? That's at least approaching the boundary. > While I do find the backwards compatibility reasons for NOT allowing > sub-types to be compelling, I don't find the two reasons I have listed > for allowing them to be compelling. If tagged attributes are sufficient, then I see no reason to add new sub-types. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 13:48:47 +0000 Message-Id: From: "Beck01, Wolfgang" To: dnelson@enterasys.com, radiusext@ops.ietf.org Subject: AW: new revision of the NAI RFC Date: Fri, 13 Feb 2004 14:48:26 +0100 MIME-Version: 1.0 Content-Type: text/plain > > Wolfgang wrote: > > nai = username / ( username "@" realm ) / ( "@" realm" ) > [..] > > NAIs are often transported in the User-Name attribute of RADIUS[10]. > > ..another example of a sub-attribute :-) Dave wrote: > Well, here's an even sillier "example"... > Integer :== millions-part "," thousands-part "," hundreds-part "," > units-part > e.g. 1,000,000,000 > That makes integers sub-attributes, right? :-) In a way, yes. You are just using a positional syntax instead of TLV. Your syntax has the same difficulties as sub-attributes. You can't associate only a 'millions-part' with a user in the RADIUS database. You have to specify the whole Integer. You are "tunneling" an un-interpreted integer through RADIUS to some higher layer protocol (eg. an accounting application). Wolfgang -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 13:25:46 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: new revision of the NAI RFC Date: Fri, 13 Feb 2004 08:25:16 -0500 Message-ID: Thread-Topic: new revision of the NAI RFC Thread-Index: AcPyFRcYnFV8yAOlQLS8hyr8YmK0mAAHwQwg From: "Nelson, David" To: "Beck01, Wolfgang" , Wolfgang Beck writes... > > nai =3D username / ( username "@" realm ) / ( "@" realm" ) > [..] > > NAIs are often transported in the User-Name attribute of RADIUS[10]. >=20 > ..another example of a sub-attribute :-) Well, here's an even sillier "example"... Integer :=3D=3D millions-part "," thousands-part "," hundreds-part "," units-part e.g. 1,000,000,000 That makes integers sub-attributes, right? :-) -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 09:36:27 +0000 Message-Id: From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: AW: new revision of the NAI RFC Date: Fri, 13 Feb 2004 10:36:09 +0100 MIME-Version: 1.0 Content-Type: text/plain > nai = username / ( username "@" realm ) / ( "@" realm" ) [..] > NAIs are often transported in the User-Name attribute of RADIUS[10]. ..another example of a sub-attribute :-) Wolfgang -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 09:16:48 +0000 Message-ID: <402C957F.5030102@piuha.net> Date: Fri, 13 Feb 2004 11:14:39 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "eap@frascone.com" , "'radiusext@ops.ietf.org'" Cc: Pasi Eronen , Bernard Aboba Subject: new revision of the NAI RFC Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit For your information: Pasi, Bernard, and myself published a new draft, draft-arkko-roamops-rfc2486bis-00.txt which is an update of the original NAI specification. It provides a few corrections, clarifications, and support for a couple of new features such as privacy and international character sets. It even touches upon network selection feature discussed in EAP WG by talking about the bang syntax. Feedback appreciated. Do folks think a bis version makes sense? Comments on content? Missed corrections? New functions make sense? Note that strictly speaking, there is no official home at the IETF for this discussion, so if we generate lengthy discussions based on this I'll promise to create a new list for the purpose and not disturb the AAA, AAAEXT or EAP WGs. Full list of modifications: o International character set support has been added for both usernames and realms. o Username privacy support has been added. o A requirement to support NAI length of at least 253 octets has been added, and compatibility considerations among NAI lengths in this specification and various AAA protocols are discussed. o The mediating network syntax and its implications have been fully described and not given only as an example. Note that this syntax is not intended to be a full solution to network discovery and selection needs as defined in [draft-ietf-eap-netsel-problem]. Rather, it is intended as a clarification of RFC 2486. It could also be used as a component in approaches such as [draft-adrangi]. o The realm BNF entry definition has been changed to avoid an error (infinite recursion) in the original specification. o The x and special BNF entries have been clarified. For more information, see the following URLs: http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt http://www.arkko.com/publications/nai/naibis.html --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 13 Feb 2004 01:37:58 +0000 Date: Thu, 12 Feb 2004 17:49:48 -0800 (PST) From: Bernard Aboba To: Korhonen Jouni cc: radiusext@ops.ietf.org Subject: RE: Bof at next IETF? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I would second that there is interest for the work done in RADIUSEXT. > For example GSMA would most probably like to see several of these worked > on drafts progress get eventually done. For > example draft-adrangi-radius-extension-for-pwlan, > draft-adrangi-radiusext-location-information and > draft-adrangi-radius-chargeable-user-identity-attribute (which is worked > on in background at the moment) are such to name few. Has there been any official communication from the GSMA to the IETF on this subject? We are trying to understand to what extend drafts under consideration in RADEXT have ended up on the dependency list of an SDO, including 3GPP, 3GPP2, or IEEE 802. This is an important issue, since one of the principles of governing AAA work in the IETF is that there needs to be a demonstrated need, as evidenced by SDO dependencies, requirements documents authored by existing IETF WGs, etc. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 20:50:35 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: FW: HTTP digest and RADIUS; new version of the Sterman draft Date: Thu, 12 Feb 2004 15:49:53 -0500 Message-ID: Thread-Topic: HTTP digest and RADIUS; new version of the Sterman draft Thread-Index: AcPxPSDSkwOOSYXLQ+WmIW1s9QD9QgASyyVAAAhTdLA= From: "Nelson, David" To: Wolfgang Beck writes... > I could live without sub-attributes but I haven't heard a really > convincing technical argument against them. Well, I guess that begs the question of what constitutes "convincing"? The technical arguments that I have heard (and advanced) against sub-types are that it changes the RADIUS architecture (simple TLV structures), requires changes to the RADIUS dictionary, and breaks backwards compatibility with a large deployed base of RADIUS products. I would offer an analogy. Adding sub-types to RADIUS would be similar to adding some sub-types (protocol-encoded information) as the data value of an ASN.1 varbind in SNMP. It is "tunneling" one protocol in another. In the case of SNMP, as in the case of RADIUS, we have a simple and limited set of data types, and single level of TLV structure. With SNMP, MIBs can be enrolled in SNMP management stations by a mechanical process because you can't re-define the ASN.1/BER data formats used in SNMP. Should we settle for any less in RADIUS? The one explicit case where we do tunnel a protocol in RADIUS is the EAP-Message attribute. If the information contained in the proposed sub-types were as disparate from other RADIUS attributes as EAP frames from RADIUS attributes, following this precedent would be reasonable. However the sub-type attributes are not in any fundamental way different from "normal" RADIUS attributes. So what are the reasons offered for treating them differently? One reason seems to be "the convenience of grouping". RADIUS already has a recognized method of grouping attributes. A second reason seems to be "we will run out of attribute number space". Let's take a head count of new attributes that fall within the scope of the charter before we deiced that, shall we? While I do find the backwards compatibility reasons for NOT allowing sub-types to be compelling, I don't find the two reasons I have listed for allowing them to be compelling. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 12:59:14 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Thu, 12 Feb 2004 07:58:54 -0500 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPw/vThWM1/ugd8RY2eUW3I2LZhqQAaGoSg From: "Nelson, David" To: "Avi Lior" , "Parviz Yegani" , Avi Lior writes... =20 > So this is great Dave. So when is the BOF going to happen? [DBN] I guess my point is that another BOF does not seem to be required. What is required is active review of, and comment upon, the drafts on the mailing list. Those drafts that have been (or will be) revised to fall within scope of the charter can progress. After all, all official actions and decisions of the IETF are taken by consensus of a WG on its mailing list, not by "hums" taken at meetings. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 12:26:52 +0000 Message-Id: From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com, radiusext@ops.ietf.org Subject: AW: HTTP digest and RADIUS; new version of the Sterman draft Date: Thu, 12 Feb 2004 13:26:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Miguel, you wrote: > Wolfgang is proposing a third solution, let's call it "the hybrid solution". I said > it is hybrid because the SIP server calculates the MD5 of the entity-body, but the > Diameter (or Radius in your case) server authenticates the user. I wonder if the > delegation of authentication to the SIP server would not solve your problem. Correct me if have misunderstood your DIAMETER draft: authentication delegation means, that the DIAMETER server knows a SIP server that knows how to authenticate a user. This is sort of a routing function, that could be done by a redirecting SIP proxy without using AAA protocol at all. > I believe this hybrid solution would work also in the Diameter > SIP application, we simply didn't have a requirement to > implement it, so we didn't. As you are already supporting both scenarios, I see two solutions. 1. You define the SIP-Authentication-Context content as body-digest instead of the whole SIP message body when using HTTP Digest and qop=auth-int 2. You define an additional AVP eg. SIP-Authentication-Digest that can be used for transportation of digest values. It contains the body-digest and is only used in environments using RADIUS translators. I'd prefer option 1, because it would make DIAMETER messages shorter and would not introduce separate RADIUS-related variations for a single function. Wolfgang Beck -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 12:25:10 +0000 Message-ID: <402B7034.5080401@piuha.net> Date: Thu, 12 Feb 2004 14:23:16 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Miguel.An.Garcia@nokia.com Cc: BeckW@t-systems.com, radiusext@ops.ietf.org Subject: Re: HTTP digest and RADIUS; new version of the Sterman draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Miguel.An.Garcia@nokia.com wrote: > At least I don't have a problem to add this hybrid scenario to the Diameter SIP application. However, I wouldn't be able to compromise on removing any of the existing two scenarions, since I am aware of interests in deployments that will use any of the other two. > > Will that help? If so, I will add some text to the Diameter SIP application, some motivation, and will send to this WG for review (just the relevant paragraph). I think this would be useful. Thanks! --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 12:08:25 +0000 Message-ID: <402B6C32.7070100@piuha.net> Date: Thu, 12 Feb 2004 14:06:10 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: Miguel.An.Garcia@nokia.com Cc: BeckW@t-systems.com, radiusext@ops.ietf.org Subject: Re: HTTP digest and RADIUS; new version of the Sterman draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I understand that there are different possible scenarios. But as you can imagine (no matter what the minor protocol encoding differences are) its hard to interoperate if the models underlying the protocols are different. As I would not like to see market fragmentation, is there something that you Wolfgang and Miguel could do to move towards a similar model, or at least provide an ability to support one common model? --Jari Miguel.An.Garcia@nokia.com wrote: >>>>My second significant comment at some point was the interoperation >>>>with Diameter-based SIP AAA. I think this is a requirement. Can >>>>you provide a section that explains how and under what limitations >>>>this and draft-ietf-aaa-diameter-sip-app can work together? >>> >>>Sure. For example, draft-ietf-aaa-diameter-sip-app defines a >>>SIP-Authentication-Context AVP which holds the SIP message body >>>for qop=auth-int. draft-sterman-aaa-sip-01 saves space by >> >>calculating >> >>>the body digest in the RADIUS client. As the maximum length >> >>of RADIUS >> >>>messages is limited to 4096, I see no way around some kind >> >>of compression. >> >>>DIAMETER allows much larger messages, but pre-computation >> >>of the body >> >>>digest might be a good idea for this protocol, too. >> >>Ok. I'd prefer to see those considerations written down >>somewhere. I believe that Miguel Garcia, who is working on >>the Diameter SIp application, would be willing to listen >>for feedback, if it turns out that interoperation is hard >>for some specific reason. >> > > > Hi: > > Wolfgang is correct in the sense that the Diameter SIP Application provides a SIP-Authentication-Context AVP which is intended to carry the whole entity-body in the case of SIP. > > I must warn you that the Diameter SIP application supports two authentication scenarios, one where the Diameter server is authenticating the user, in which case the SIP-Authentication-Contxt AVP may have significance. The other scenario we support takes place when the Diameter server delegates authentication to the SIP server (the Diameter client). In this case there is no need to transfer the entity-body accross the network. This is the solution that we offer in the Diameter SIP application. > > Wolfgang is proposing a third solution, let's call it "the hybrid solution". I said it is hybrid because the SIP server calculates the MD5 of the entity-body, but the Diameter (or Radius in your case) server authenticates the user. I wonder if the delegation of authentication to the SIP server would not solve your problem. > > I believe this hybrid solution would work also in the Diameter SIP application, we simply didn't have a requirement to implement it, so we didn't. > > My 0,02 EUR > > /Miguel > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 10:33:33 +0000 Message-ID: <402B560B.3070609@piuha.net> Date: Thu, 12 Feb 2004 12:31:39 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: radiusext@ops.ietf.org, Miguel.An.Garcia@nokia.com Subject: Re: AW: AW: HTTP digest and RADIUS; new version of the Sterman draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Beck01, Wolfgang wrote: > > -----Ursprungliche Nachricht----- > Von: Jari Arkko [mailto:jari.arkko@piuha.net] > Gesendet: Donnerstag, 12. Februar 2004 09:29 > An: Beck, Wolfgang > Cc: john.loughney@nokia.com; radiusext@ops.ietf.org > Betreff: Re: AW: HTTP digest and RADIUS; new version of the Sterman > draft > > Jari Arkko wrote: > >>>Beck01, Wolfgang wrote: > > >>>Open issues: I hope that I have addressed all the issues that were >>>raised in Minneapolis. > > >>What about support for other algorithms than MD5? This was one >>of my comments in Minneapolis. I took a new look at the draft. >>It does not say anything about this, but on the other hand my >>quick look did not reveal anything which would prevent them from >>being supported. Can you say if you support them or not? Say, RFC >>3310 support is included? > > Other algorithms are supported as long as they don't define additional > parameters. RfC 3310 defines a new 'auths' parameter, which would > require an additional RADIUS (sub-)attribute. I am not sure if a > general procedure can be valid for all possible algorithms. Ah, I see. But I would think that any additional parameter could be transported easily, as long as it fits the RFC 2617 section 2.1 syntax for "auth-param". Of course, this requires that the parameters are indeed part of the HTTP authentication header, but this appears to be the case in variations that I know of. Could you accommodate this is in a general way? If not, perhaps you could add support for "auts" from RFC 3310 specifically. But that does not appear to be necessary. >>My second significant comment at some point was the interoperation >>with Diameter-based SIP AAA. I think this is a requirement. Can >>you provide a section that explains how and under what limitations >>this and draft-ietf-aaa-diameter-sip-app can work together? > > Sure. For example, draft-ietf-aaa-diameter-sip-app defines a > SIP-Authentication-Context AVP which holds the SIP message body > for qop=auth-int. draft-sterman-aaa-sip-01 saves space by calculating > the body digest in the RADIUS client. As the maximum length of RADIUS > messages is limited to 4096, I see no way around some kind of compression. > DIAMETER allows much larger messages, but pre-computation of the body > digest might be a good idea for this protocol, too. Ok. I'd prefer to see those considerations written down somewhere. I believe that Miguel Garcia, who is working on the Diameter SIp application, would be willing to listen for feedback, if it turns out that interoperation is hard for some specific reason. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 09:40:50 +0000 Message-Id: From: "Beck01, Wolfgang" To: jari.arkko@piuha.net Cc: radiusext@ops.ietf.org Subject: AW: AW: HTTP digest and RADIUS; new version of the Sterman draft Date: Thu, 12 Feb 2004 10:40:25 +0100 MIME-Version: 1.0 Content-Type: text/plain -----Ursprungliche Nachricht----- Von: Jari Arkko [mailto:jari.arkko@piuha.net] Gesendet: Donnerstag, 12. Februar 2004 09:29 An: Beck, Wolfgang Cc: john.loughney@nokia.com; radiusext@ops.ietf.org Betreff: Re: AW: HTTP digest and RADIUS; new version of the Sterman draft Jari Arkko wrote: >> Beck01, Wolfgang wrote: >> Open issues: I hope that I have addressed all the issues that were >> raised in Minneapolis. > What about support for other algorithms than MD5? This was one > of my comments in Minneapolis. I took a new look at the draft. > It does not say anything about this, but on the other hand my > quick look did not reveal anything which would prevent them from > being supported. Can you say if you support them or not? Say, RFC > 3310 support is included? Other algorithms are supported as long as they don't define additional parameters. RfC 3310 defines a new 'auths' parameter, which would require an additional RADIUS (sub-)attribute. I am not sure if a general procedure can be valid for all possible algorithms. > My second significant comment at some point was the interoperation > with Diameter-based SIP AAA. I think this is a requirement. Can > you provide a section that explains how and under what limitations > this and draft-ietf-aaa-diameter-sip-app can work together? Sure. For example, draft-ietf-aaa-diameter-sip-app defines a SIP-Authentication-Context AVP which holds the SIP message body for qop=auth-int. draft-sterman-aaa-sip-01 saves space by calculating the body digest in the RADIUS client. As the maximum length of RADIUS messages is limited to 4096, I see no way around some kind of compression. DIAMETER allows much larger messages, but pre-computation of the body digest might be a good idea for this protocol, too. Wolfgang Thanks, --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 08:43:23 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: HTTP digest and RADIUS; new version of the Sterman draft Date: Thu, 12 Feb 2004 10:42:52 +0200 Message-ID: Thread-Topic: AW: HTTP digest and RADIUS; new version of the Sterman draft Thread-Index: AcPxQql73DdbV0jHTyGnX+yhm119cwAAXGRw From: To: , Cc: Hi Jari, > What about support for other algorithms than MD5? This was one > of my comments in Minneapolis. I took a new look at the draft. > It does not say anything about this, but on the other hand my > quick look did not reveal anything which would prevent them from > being supported. Can you say if you support them or not? Say, RFC > 3310 support is included? This would be nice to have. > My second significant comment at some point was the interoperation > with Diameter-based SIP AAA. I think this is a requirement. Can > you provide a section that explains how and under what limitations > this and draft-ietf-aaa-diameter-sip-app can work together? That would be important to capture, in my opinion. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 08:31:19 +0000 Message-ID: <402B3966.6040407@piuha.net> Date: Thu, 12 Feb 2004 10:29:26 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 MIME-Version: 1.0 To: "Beck01, Wolfgang" Cc: john.loughney@nokia.com, radiusext@ops.ietf.org Subject: Re: AW: HTTP digest and RADIUS; new version of the Sterman draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Beck01, Wolfgang wrote: > Open issues: I hope that I have addressed all the issues that were > raised in Minneapolis. What about support for other algorithms than MD5? This was one of my comments in Minneapolis. I took a new look at the draft. It does not say anything about this, but on the other hand my quick look did not reveal anything which would prevent them from being supported. Can you say if you support them or not? Say, RFC 3310 support is included? My second significant comment at some point was the interoperation with Diameter-based SIP AAA. I think this is a requirement. Can you provide a section that explains how and under what limitations this and draft-ietf-aaa-diameter-sip-app can work together? Thanks, --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 08:19:20 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Thu, 12 Feb 2004 10:18:37 +0200 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPw/pZeRm5wT7myTR6Ikq1tlIZPxgAQSLgQ From: "Korhonen Jouni" To: "Avi Lior" , "Bernard Aboba" , Cc: Hi all, I would second that there is interest for the work done in RADIUSEXT. For example GSMA would most probably like to see several of these worked on drafts progress get eventually done. Some of the next steps in global interoperator WLAN roaming standardization work would benefit (and is actually waiting for) on RADIUS extensions being drafted in RADIUSEXT. For example draft-adrangi-radius-extension-for-pwlan, draft-adrangi-radiusext-location-information and draft-adrangi-radius-chargeable-user-identity-attribute (which is worked on in background at the moment) are such to name few. Best regards, Jouni --=20 Jouni Korhonen - Senior Researcher Emerging Technologies and Innovations TeliaSonera Finland =20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: 12. helmikuuta 2004 2:22 > To: 'Bernard Aboba'; john.loughney@nokia.com > Cc: radiusext@ops.ietf.org > Subject: RE: Bof at next IETF? >=20 > 80 People showed up and the vast majority expressed an=20 > interest in forming a > WG. >=20 > Work has progressed in the meanwhile. There is plenty of=20 > evidence that > there is interest. >=20 > There are a number of new drafts, and there are a number of=20 > revised draft. >=20 > Avi. >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > > Sent: Wednesday, February 11, 2004 4:22 PM > > To: john.loughney@nokia.com > > Cc: radiusext@ops.ietf.org > > Subject: RE: Bof at next IETF? > >=20 > >=20 > > > I would have expected people to make more progress on some of the=20 > > > relevant drafts that were discussed in Minneapolis. Having=20 > > a charter=20 > > > or WG shouldn't affect that work. I've been somewhat=20 > > suprised by the=20 > > > lack of progress. > >=20 > > Having an IETF WG doesn't make work happen. The IETF can=20 > > merely bring together people interested in doing work. The=20 > > first test of whether a WG makes sense is whether the group,=20 > > when brought together, actually does work. > >=20 > >=20 > > -- > > to unsubscribe send a message to=20 > > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > > a single line as the message text body. > > archive: > >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 07:51:51 +0000 Message-Id: From: "Beck01, Wolfgang" To: john.loughney@nokia.com, radiusext@ops.ietf.org Subject: AW: HTTP digest and RADIUS; new version of the Sterman draft Date: Thu, 12 Feb 2004 08:51:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" John Loughney wrote: >> After re-checking the announcement list, I found that >> http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt >> is already available. It now has a Security Considerations section >> and I've added support for Authentication-Info. > Could you send a more detailed mail on what changes you have made, > and what are the open issues which need further discussion? Well, I have added some motivational paragraphs why HTTP digest support for RADIUS is required in some environments. And when to choose DIAMETER instead. There is a comparison of the SIP AAA options an operator has today. I've added a step-by-step description of the RADIUS client and RADIUS server behaviour. As the original draft was quite old, I had to update most of the references and the authors' addresses. To improve security, RADIUS clients that accept secured connections from their SIP / HTTP clients are now required to have a secured connection to the RADIUS server. RADIUS servers must return a Authentication-Info digest. Open issues: I hope that I have addressed all the issues that were raised in Minneapolis. There is the sub-attribute discussion, of course. The draft needs official IANA assigned attribute types instead of the experimental ones mentioned in -00. I could live without sub-attributes but I haven't heard a really convincing technical argument against them. Wolfgang Beck -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 07:48:53 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Thu, 12 Feb 2004 09:48:31 +0200 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPxO6GerXLH3LloQE2rVQOmd5qQQQAAGGPg From: To: , , , , , Hi Avi, > So how is *not* having a BOF going to help progress this further? Well, that is something I don't have any control over. However,=20 I guess people should have been asking about the bof a bit earlier ... > > Revision of drafts well before the draft cut-off date is > > a good indicator. >=20 > Well, I can live with that but why hold us to a higher mark then say = other > WGs. Well, I have the same problem as you. Some WGs seem to be created = without much effort and others are heavily scrutinized. My feelings is that = there should be some standard criteria here. =20 > > Should it make a difference? What extra does a WG do to make=20 > > the work happen? >=20 > In my opinion tons of difference. For one it creates an open place = where > people can talk/comment about related topics. But I guess some folks = behave > around here as if this is a closed community. Well, we have the mailing list, so there is no closed community, imo. > > My understanding was that progress on the drafts was expected=20 > > and discussion on the charter was to take place so that a=20 > > draft charter could be sent to the IESG. We really haven't=20 > > discussed the charter. =20 >=20 > Regarding the Charter. There were discussions. And a tone of = discussion on > subtypes and other related issues. I didn't see a lot of text suggestions about how to improve the charter. = That is more what I meant. > >But at the last meeting, I remember=20 > > that a significant number of people thought it would be best=20 > > for the WG to be AAA Extensions, not just RADIUS extensions,=20 > > but we haven't discussed that on the mailing list. >=20 > Not exactly my recollection at all. First and foremost it was a = RADIUS > gathering. We did agree to consider whether this should also be a = Diameter > extension group. I wouldn't characterise it as a significant number = of > people. I think more than 15 supported the idea, out of 80 is still a = significant number (1 or 2 would be insignificant). =20 =20 > But who cares. Why should this minor point stall us? I think we'd just need to update the charter accordingly, if this was = OK. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 07:41:03 +0000 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , Avi Lior , pyegani@cisco.com, dromasca@avaya.com, dnelson@enterasys.com, radiusext@ops.ietf.org, aboba@internaut.com Subject: RE: Bof at next IETF? Date: Thu, 12 Feb 2004 02:40:55 -0500 MIME-Version: 1.0 Content-Type: text/plain John, Thanx for the reply. First I will highlight this: You said: > And how do all of these related to the proposed charter and > what is the current support for including this work in the > WG? These are the kind of discussions which are needed, imo. So how is *not* having a BOF going to help progress this further? Other comments are inline. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Thursday, February 12, 2004 2:41 PM > To: avi@bridgewatersystems.com; pyegani@cisco.com; > dromasca@avaya.com; dnelson@enterasys.com; > radiusext@ops.ietf.org; aboba@internaut.com > Subject: RE: Bof at next IETF? > > > Hi Avi, > > > John can you share with us what standard do you use to > > measure progress. > > Revision of drafts well before the draft cut-off date is > a good indicator. Well, I can live with that but why hold us to a higher mark then say other WGs. > > And can you please comment on how much work will be done if there > > wasn't a working group vs. how much work will be done if > there was a > > working group? > > Should it make a difference? What extra does a WG do to make > the work happen? In my opinion tons of difference. For one it creates an open place where people can talk/comment about related topics. But I guess some folks behave around here as if this is a closed community. > > As well, in 58 8 to 10 people have agreed to do the majority of the > > work. Is this not enough? > > My understanding was that progress on the drafts was expected > and discussion on the charter was to take place so that a > draft charter could be sent to the IESG. We really haven't > discussed the charter. Regarding the Charter. There were discussions. And a tone of discussion on subtypes and other related issues. >But at the last meeting, I remember > that a significant number of people thought it would be best > for the WG to be AAA Extensions, not just RADIUS extensions, > but we haven't discussed that on the mailing list. Not exactly my recollection at all. First and foremost it was a RADIUS gathering. We did agree to consider whether this should also be a Diameter extension group. I wouldn't characterise it as a significant number of people. But who cares. Why should this minor point stall us? > > Current partial listing(as obtained from the list) > > John > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 07:15:23 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: HTTP digest and RADIUS; new version of the Sterman draft Date: Thu, 12 Feb 2004 09:15:03 +0200 Message-ID: Thread-Topic: HTTP digest and RADIUS; new version of the Sterman draft Thread-Index: AcPxN2GsxbmH8LZrRtGeAdxvCu/q2AAAHeXA From: To: , Hi Wolfgang, > After re-checking the announcement list, I found that > http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt > is already available. It now has a Security Considerations section > and I've added support for Authentication-Info. Could you send a more detailed mail on what changes you have made, and what are the open issues which need further discussion? thanks, John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 07:10:49 +0000 Message-Id: From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: HTTP digest and RADIUS; new version of the Sterman draft Date: Thu, 12 Feb 2004 08:10:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" After re-checking the announcement list, I found that http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt is already available. It now has a Security Considerations section and I've added support for Authentication-Info. Wolfgang Beck -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 05:41:16 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Thu, 12 Feb 2004 07:40:53 +0200 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPxBeAXK7TTZ/8nSOKVJ+UBlDbrRQAI7XQA From: To: , , , , , Hi Avi, > John can you share with us what standard do you use to=20 > measure progress. Revision of drafts well before the draft cut-off date is a good indicator. =20 > And can you please comment on how much work will be done if there = wasn't a > working group vs. how much work will be done if there was a working = group? Should it make a difference? What extra does a WG do to make the work = happen? =20 > As well, in 58 8 to 10 people have agreed to do the majority of the = work. > Is this not enough? My understanding was that progress on the drafts was expected and = discussion on the charter was to take place so that a draft charter could be sent = to the IESG. We really haven't discussed the charter. But at the last = meeting, I remember that a significant number of people thought it would be best for the WG to be AAA Extensions, not just RADIUS extensions, but we = haven't discussed that on the mailing list. > Current partial listing(as obtained from the list) And how do all of these related to the proposed charter and what is the current support for including this work in the WG? These are the kind of discussions which are needed, imo. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 01:16:23 +0000 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , pyegani@cisco.com, dromasca@avaya.com, dnelson@enterasys.com, Avi Lior , radiusext@ops.ietf.org, Bernard Aboba Subject: RE: Bof at next IETF? Date: Wed, 11 Feb 2004 20:16:12 -0500 MIME-Version: 1.0 Content-Type: text/plain John can you share with us what standard do you use to measure progress. And can you please comment on how much work will be done if there wasn't a working group vs. how much work will be done if there was a working group? As well, in 58 8 to 10 people have agreed to do the majority of the work. Is this not enough? FYI: Current partial listing(as obtained from the list) http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-for-pwlan -00.txt This will be updated by deadline http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-informa tion-00.txt This is new work. http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capabilit y-00.txt This is new work http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt Updates previous one http://www.ietf.org/internet-drafts/draft-lonvick-sobgp-radius-03.txt http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-port-0 1.txt http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickstart- 01.txt http://www.ietf.org/internet-drafts/draft-heinanen-radius-l2tp-vpls-00.txt http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-handoff-04.txt http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-02. txt This will be updated. http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapping- 00.txt This will be updated http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extensi on-00.txt This is new work but outside scope of charter. http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt This is new work >From IETF 58: http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapping- 00.txt http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickstart- 01.txt http://www.ietf.org/internet-drafts/draft-moskowitz-sspp-snmp-01.txt http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-02. txt http://www.watersprings.org/pub/id/draft-schulzrinne-sipping-radius-accounti ng-00.txt http://www.watersprings.org/pub/id/draft-sterman-aaa-sip-00.txt http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt http://www.ietf.org/internet-drafts/draft-aboba-context-802-00.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt http://www.ietf.org/internet-drafts/draft-adrangi-radius-issues-in-pwlan-roa ming-01.txt http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-extensio n-for-pwlan-00.txt http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-port-0 1.txt http://www.ietf.org/internet-drafts/draft-heinanen-radius-pe-discovery-04.tx t > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, February 11, 2004 1:12 PM > To: pyegani@cisco.com; dromasca@avaya.com; > dnelson@enterasys.com; avi@bridgewatersystems.com; > radiusext@ops.ietf.org > Subject: RE: Bof at next IETF? > > > Hi Yegani, > > > A number of drafts on Radius Extensions have been submitted > for quite > > sometime that need to be addressed in IETF soon. I'm not > sure how this > > could be done if the creation of the Radiusext WG is > delayed further. > > I thought we agreed at IETF58 in Minneapolis that RADIUSEXT was the > > only home for these drafts, no? > > I would have expected people to make more progress on some of > the relevant > drafts that were discussed in Minneapolis. Having a charter > or WG shouldn't affect that work. I've been somewhat suprised > by the lack of progress. > > John > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 00:27:07 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , Parviz Yegani , Avi Lior , radiusext@ops.ietf.org Subject: RE: Bof at next IETF? Date: Wed, 11 Feb 2004 19:27:03 -0500 MIME-Version: 1.0 Content-Type: text/plain Dave Nelson said: >While there was substantial support for moving forward with > RADIUS Extensions, there was equally substantial support for > the limited scope of changes to RADIUS as presented in the > draft charter. I think we are making progress toward meeting > but we have a ways to go yet. So this is great Dave. So when is the BOF going to happen? > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Wednesday, February 11, 2004 12:28 AM > To: Parviz Yegani; Avi Lior; radiusext@ops.ietf.org > Subject: RE: Bof at next IETF? > > > Parviz Yegani writes... > > > Given the strong support from the last IETF I thought > RADIUSEXT was on > > its way to become a new WG. What are we waiting for? > > We are waiting for Internet Drafts, of suitable quality, that > fit within the proposed Charter, and volunteers to review > those drafts. > > I have noticed a flurry of drafts coming out just prior to > the cutoff date for IEEE 59. I would encourage all > interested parties to review these drafts, for protocol > quality, and also for compliance to the charter. Please > review the drafts and submit commentary on this list. > > While there was substantial support for moving forward with > RADIUS Extensions, there was equally substantial support for > the limited scope of changes to RADIUS as presented in the > draft charter. I think we are making progress toward meeting > the requirement for suitable drafts, but we have a ways to go yet. > > -- Dave > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 12 Feb 2004 00:22:28 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , john.loughney@nokia.com Cc: radiusext@ops.ietf.org Subject: RE: Bof at next IETF? Date: Wed, 11 Feb 2004 19:22:11 -0500 MIME-Version: 1.0 Content-Type: text/plain 80 People showed up and the vast majority expressed an interest in forming a WG. Work has progressed in the meanwhile. There is plenty of evidence that there is interest. There are a number of new drafts, and there are a number of revised draft. Avi. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Wednesday, February 11, 2004 4:22 PM > To: john.loughney@nokia.com > Cc: radiusext@ops.ietf.org > Subject: RE: Bof at next IETF? > > > > I would have expected people to make more progress on some of the > > relevant drafts that were discussed in Minneapolis. Having > a charter > > or WG shouldn't affect that work. I've been somewhat > suprised by the > > lack of progress. > > Having an IETF WG doesn't make work happen. The IETF can > merely bring together people interested in doing work. The > first test of whether a WG makes sense is whether the group, > when brought together, actually does work. > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Feb 2004 17:42:22 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Wed, 11 Feb 2004 09:40:58 -0800 Message-ID: <96D13222E704DC4D868F0009F0EE53E1C4BD57@orsmsx410.jf.intel.com> Thread-Topic: Bof at next IETF? Thread-Index: AcPwbh3YzLOS/73STGqRD27R2dn2KAAUigxw From: "Adrangi, Farid" To: "Bernard Aboba" , Cc: I *totally* agree with John. Since the last meeting, the group has continued working on a number of drafts (that are within the scope of the charter) based on the discussion/feedbacks on the mailing list. So, I don't understand why should not move forward with these drafts and make progress. =20 BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Tuesday, February 10, 2004 11:22 PM > To: john.loughney@nokia.com > Cc: radiusext@ops.ietf.org > Subject: RE: Bof at next IETF? >=20 >=20 > > I would have expected people to make more progress on some of the=20 > > relevant drafts that were discussed in Minneapolis. Having=20 > a charter=20 > > or WG shouldn't affect that work. I've been somewhat=20 > suprised by the=20 > > lack of progress. >=20 > Having an IETF WG doesn't make work happen. The IETF can=20 > merely bring together people interested in doing work. The=20 > first test of whether a WG makes sense is whether the group,=20 > when brought together, actually does work. >=20 >=20 > -- > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Feb 2004 09:41:42 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC06F3@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'John Schnizlein'" , Bernard Aboba Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: RE: draft-jones-radius-geopriv Date: Wed, 11 Feb 2004 10:41:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" hi john, thanks for your summary. please see a small comment below: > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Tuesday, February 10, 2004 8:49 PM > To: Bernard Aboba > Cc: Tschofenig Hannes; radiusext@ops.ietf.org; geopriv@ietf.org > Subject: Re: draft-jones-radius-geopriv > > > Comments embedded in context: > > At 02:06 PM 2/10/2004, Bernard Aboba wrote: > > >I'm curious as to the contrast in approach taken by this draft > >versus the DHCP option. Given the recent activity on encapsulation > >of RADIUS attributes in DHCP, isn't it important for the DHCP > >option and the RADIUS attribute to take similar approaches? > > I would be surprised to see anyone determine the host's location > through the RADIUS server, and pass that location through the > relay-agent sub-option to the DHCP server, in order for the DHCP > server to configure it at the host. However, similar approaches > to encoding the information would match the similar constraints > that both DHCP and RADIUS are carried in a single UDP datagram. > > >For example, if the goal is to make both the client and RADIUS > >server aware of their location, then the NAS might pass a location > >attribute to the RADIUS server, as well as passing this to the > >DHCP server in a relay option. Encoding the information two very > >different ways seems like it results in unnecessary overhead. > > A summary of the various intersections might be useful here: > (for others - I know Bernard knows this background) > > draft-ietf-geopriv-dhcp-lci-option-03.txt specifies a way for a > DHCP server to give a host the host's location, using (circuit-ID) > information from the relay-agent and knowledge of the wiring plant. > > draft-ietf-dhc-agentopt-radius-03.txt specifies a way for a DHCP > relay agent to relay RADIUS information to the DHCP server for its > use in allocating configuration options. > > draft-jones-radius-geopriv specifies a way for a NAS to tell a > RADIUS server the location of the NAS. The location of the NAS could > be manually configured either in the NAS or in the RADIUS server > with which it shares a secret. The radius-geopriv attribute might > be added to the RADIUS attributes that are forwarded to a different > (home) RADIUS server (in the global roaming situation). > (If this summary is incorrect, please clarify.) i guess there are two issues here: a) encoding of location information b) who is authorized to distribute location information for (a) the draft suggests to take a look at the results of the geopriv working. initially i was a little bit skeptic about gmlv3 but when i looked at the details i saw that these guys did good work. for (b) there are different scenarios. we tried to describe them in detail to make an analysis easier. first, the visited network might distribute its own location information to other networks - fairly simple stuff. second, the visited network makes the location information of the end host accessible. call me strange but i think that there are some privacy considerations. once such infrastructure is deployed people tend to use it for other applications as well. > > Before combining these ideas in a creative way, one would need to > have a clear understanding of whose location information is needed > where, and which provider of the information has the best > access to it. certainly. > Since this analysis is already too difficult for some of us to want > to attempt, making it worse with different information formats seems > like over-kill. ciao hannes > > John > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Feb 2004 09:30:10 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC06F1@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Bernard Aboba'" , John Schnizlein Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: RE: draft-jones-radius-geopriv Date: Wed, 11 Feb 2004 10:29:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" hi bernard, > > One concern, if this location configuration information (LCI) > > is to be carried over RADIUS, is that the example in section 6 > > seems to be 993 characters long. This one attribute seems to be > > taking a large share of the maximum RADIUS packet size of 4096. > > [RFC 2865, p 15] Is there enough room for everything else that > > would be expected with this attribute? > > I'm curious as to the contrast in approach taken by this > draft versus the > DHCP option. Given the recent activity on encapsulation of RADIUS > attributes in DHCP, isn't it important for the DHCP option > and the RADIUS > attribute to take similar approaches? > > For example, if the goal is to make both the client and RADIUS server > aware of their location, then the NAS might pass a location > attribute to > the RADIUS server, as well as passing this to the DHCP server > in a relay > option. Encoding the information two very different ways > seems like it > results in unnecessary overhead. that's certainly a good view. having many different ways of encoding things is not the best approach. ciao hannes > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Feb 2004 09:28:48 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BC06F0@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'John Schnizlein'" Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: RE: draft-jones-radius-geopriv Date: Wed, 11 Feb 2004 10:28:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" hi john, you are fully right. we have also identified this as an issue. i think we should also think about size considerations in the geopriv working group. ciao hannes > -----Original Message----- > From: John Schnizlein [mailto:jschnizl@cisco.com] > Sent: Tuesday, February 10, 2004 7:12 PM > To: Tschofenig Hannes > Cc: radiusext@ops.ietf.org; geopriv@ietf.org > Subject: draft-jones-radius-geopriv > > > Including the GeoPriv WG.. > > One concern, if this location configuration information (LCI) > is to be carried over RADIUS, is that the example in section 6 > seems to be 993 characters long. This one attribute seems to be > taking a large share of the maximum RADIUS packet size of 4096. > [RFC 2865, p 15] Is there enough room for everything else that > would be expected with this attribute? > > John > > At 12:05 PM 2/10/2004, Hannes Tschofenig wrote: > > >you can find the geogriv/radius draft at: > >http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.html > >http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.txt > > > >the draft tries awareness for privacy and reuses results of > the geopriv > >working group. > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Feb 2004 08:05:07 +0000 Message-Id: From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: charter vs drafts, sub-types Date: Wed, 11 Feb 2004 09:04:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Dave Nelson wrote: > I think that the "charter issue", as you call it, is that some of the > proposed drafts fall outside the scope of the proposed charter, for > which there is fairly broad support. We had some discussion on the list about the sub-type issue. I did not get the impression that we have rough consensus over this part of the charter. > The operative question is whether the charter should be revised or > those particular drafts revised. I am suggesting that the charter > is fine and that the drafts that fall out of scope should be revised. I chose to retain sub-attributes in my draft (which is still in the queue of internet-drafts@ietf.org), as I felt the topic was still undecided. And there are existing implementations that I did not want to break without reason. If the list decides, that 'thou shalt not use sub-attributes' I will submit an updated version in a couple of days. Wolfgang Beck -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Feb 2004 07:10:16 +0000 Date: Tue, 10 Feb 2004 23:22:08 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com cc: radiusext@ops.ietf.org Subject: RE: Bof at next IETF? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I would have expected people to make more progress on some of the relevant > drafts that were discussed in Minneapolis. Having a charter or WG shouldn't > affect that work. I've been somewhat suprised by the lack of progress. Having an IETF WG doesn't make work happen. The IETF can merely bring together people interested in doing work. The first test of whether a WG makes sense is whether the group, when brought together, actually does work. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 11 Feb 2004 04:12:32 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Wed, 11 Feb 2004 06:12:01 +0200 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPwHTtNcBRGe7YkQuuMUM5YIa+UvgAN7tVA From: To: , , , , Hi Yegani, > A number of drafts on Radius Extensions have been submitted for quite = sometime > that need to be addressed in IETF soon. I'm not sure how this could be = done if > the creation of the Radiusext WG is delayed further. I thought we = agreed at=20 > IETF58 in Minneapolis that RADIUSEXT was the only home for these = drafts, no? I would have expected people to make more progress on some of the = relevant=20 drafts that were discussed in Minneapolis. Having a charter or WG = shouldn't affect that work. I've been somewhat suprised by the lack of progress. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 22:28:37 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Tue, 10 Feb 2004 17:28:34 -0500 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPwINXeFn5ppOb9Q0qA/gmPGHAujwAA75Fg From: "Nelson, David" To: "Parviz Yegani" , > Having a RADEXT BOF at IETF 59 would certainly help resolve the charter > issue. Is it too late to have a BOF at IETF next month in Seoul? I think that the "charter issue", as you call it, is that some of the proposed drafts fall outside the scope of the proposed charter, for which there is fairly broad support. The operative question is whether the charter should be revised or those particular drafts revised. I am suggesting that the charter is fine and that the drafts that fall out of scope should be revised. Having another BOF will not make progress on reviewing and revising the drafts. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 22:23:30 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Tue, 10 Feb 2004 17:23:16 -0500 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPwHT3wPkw6xO13R6+cZPnoIfgyAgABdV8g From: "Nelson, David" To: "Parviz Yegani" , Parviz Yegani writes... > A number of drafts on Radius Extensions have been submitted for quite > sometime ... Well, to be tongue-in-cheek, unlike fine wines, Internet Drafts do not always improve with age. =20 Those drafts that call for extensions to RADIUS that are outside the RADEXT proposed charter, and would break backwards compatibility with the existing RADIUS RFCs and RADIUS implementations, should never, IMHO, be published as Standards Track RFCs, and I have some serious doubts as to whether they should be published as Informational RFCs.=20 The "need" for drafts to be acted upon quickly must be tempered by the "need" for them to fall within the proposed charter and achieve broad Internet Community consensus. > I thought we agreed at IETF58 in Minneapolis that RADIUSEXT was the > only home for these drafts, no? We decided that drafts that fell within the scope of the proposed charter would best find a home in an RADEXT WG. There are other drafts that might be handled in another (existing) IETF WG. And there are some drafts that require rework and revision to fit within the proposed RADEXT WG charter. So it depends on which subset of drafts you are referring to... -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 21:57:15 +0000 Message-Id: <4.3.2.7.2.20040210133212.01784820@franklin.cisco.com> Date: Tue, 10 Feb 2004 13:56:57 -0800 To: "Nelson, David" , From: Parviz Yegani Subject: RE: Bof at next IETF? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed David, Comments inline... At 11:42 AM 2/10/2004 -0500, Nelson, David wrote: >I have had some off-list discussions about the timing and progress of >the nascent RADEXT WG, and have summarized my comments on this issue for >the list, as I'm sure others have the same questions. > >While not have a RADEXT BOF at IETF 59 may be seen to create unfortunate >timing, having a formal WG is not a prerequisite to doing work on the >drafts. At RADEXT BOF at IETF 58 we discussed this issue and there was substantial support for creating a new WG, an attempt to find a home for the drafts on Radius extensions. I'm a bit puzzled now that how your statement above "having a formal WG is not a prerequisite to doing work on the drafts" would support what we discussed and generally agreed at that meeting. >Having volunteers to act as document editors, volunteers to do >careful reviews, and a reflector list over which to communicate is all >that is needed... for now. Some of the submitted drafts, IMHO, are >still out of scope for our charter. I'd like to see more progress in >that area before we formally ask the IESG to charter the WG. Formally >starting the WG, before the charter and scope issues are generally >agreed upon will not, IMHO, accelerate the desired end product. Having a RADEXT BOF at IETF 59 would certainly help resolve the charter issue. Is it too late to have a BOF at IETF next month in Seoul? Thanks, Parviz >-- Dave > > > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 21:31:29 +0000 Message-Id: <4.3.2.7.2.20040210131707.0178a250@franklin.cisco.com> Date: Tue, 10 Feb 2004 13:31:12 -0800 To: john.loughney@nokia.com, , , , From: Parviz Yegani Subject: RE: Bof at next IETF? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Hello, John, A number of drafts on Radius Extensions have been submitted for quite sometime that need to be addressed in IETF soon. I'm not sure how this could be done if the creation of the Radiusext WG is delayed further. I thought we agreed at IETF58 in Minneapolis that RADIUSEXT was the only home for these drafts, no? Rgds, Parviz At 05:37 PM 2/10/2004 +0200, john.loughney@nokia.com wrote: >Hi Dan, > > > I was not aware about a call for volunteers. I am > > volunteering to review the drafts. As they are individual > > submissions at this point in time, I would be grateful to be > > pointed to these drafts, as they are submitted and become available. > >It would be good if authors of individual documents would send email >to this list, with pointers to their documents. Also, it would >help to have the authors give a short explaination of what they >are trying to do, what things need discussion, etc. I think the >chairs & area directors are waiting for some discussion and interest >level in this work. The IETF generally doesn't have extra resources >to do any work or reviews if there aren't people voluneering to do >the work. > >br, >John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 19:49:34 +0000 Message-Id: <4.3.2.7.2.20040210140759.02d8be20@wells.cisco.com> Date: Tue, 10 Feb 2004 14:49:10 -0500 To: Bernard Aboba From: John Schnizlein Subject: Re: draft-jones-radius-geopriv Cc: Hannes Tschofenig , radiusext@ops.ietf.org, geopriv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Comments embedded in context: At 02:06 PM 2/10/2004, Bernard Aboba wrote: >I'm curious as to the contrast in approach taken by this draft >versus the DHCP option. Given the recent activity on encapsulation >of RADIUS attributes in DHCP, isn't it important for the DHCP >option and the RADIUS attribute to take similar approaches? I would be surprised to see anyone determine the host's location through the RADIUS server, and pass that location through the relay-agent sub-option to the DHCP server, in order for the DHCP server to configure it at the host. However, similar approaches to encoding the information would match the similar constraints that both DHCP and RADIUS are carried in a single UDP datagram. >For example, if the goal is to make both the client and RADIUS >server aware of their location, then the NAS might pass a location >attribute to the RADIUS server, as well as passing this to the >DHCP server in a relay option. Encoding the information two very >different ways seems like it results in unnecessary overhead. A summary of the various intersections might be useful here: (for others - I know Bernard knows this background) draft-ietf-geopriv-dhcp-lci-option-03.txt specifies a way for a DHCP server to give a host the host's location, using (circuit-ID) information from the relay-agent and knowledge of the wiring plant. draft-ietf-dhc-agentopt-radius-03.txt specifies a way for a DHCP relay agent to relay RADIUS information to the DHCP server for its use in allocating configuration options. draft-jones-radius-geopriv specifies a way for a NAS to tell a RADIUS server the location of the NAS. The location of the NAS could be manually configured either in the NAS or in the RADIUS server with which it shares a secret. The radius-geopriv attribute might be added to the RADIUS attributes that are forwarded to a different (home) RADIUS server (in the global roaming situation). (If this summary is incorrect, please clarify.) Before combining these ideas in a creative way, one would need to have a clear understanding of whose location information is needed where, and which provider of the information has the best access to it. Since this analysis is already too difficult for some of us to want to attempt, making it worse with different information formats seems like over-kill. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 19:16:31 +0000 Date: Tue, 10 Feb 2004 11:28:42 -0800 (PST) From: Bernard Aboba To: John Schnizlein cc: Hannes Tschofenig , radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: draft-jones-radius-geopriv Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > One concern, if this location configuration information (LCI) > is to be carried over RADIUS, is that the example in section 6 > seems to be 993 characters long. This one attribute seems to be > taking a large share of the maximum RADIUS packet size of 4096. > [RFC 2865, p 15] Is there enough room for everything else that > would be expected with this attribute? Even if a RADIUS packet can be up to 4096 octets in length, it's still not a good idea to cause fragmentation if it can be avoided. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 18:54:29 +0000 Date: Tue, 10 Feb 2004 11:06:13 -0800 (PST) From: Bernard Aboba To: John Schnizlein cc: Hannes Tschofenig , radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: draft-jones-radius-geopriv Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > One concern, if this location configuration information (LCI) > is to be carried over RADIUS, is that the example in section 6 > seems to be 993 characters long. This one attribute seems to be > taking a large share of the maximum RADIUS packet size of 4096. > [RFC 2865, p 15] Is there enough room for everything else that > would be expected with this attribute? I'm curious as to the contrast in approach taken by this draft versus the DHCP option. Given the recent activity on encapsulation of RADIUS attributes in DHCP, isn't it important for the DHCP option and the RADIUS attribute to take similar approaches? For example, if the goal is to make both the client and RADIUS server aware of their location, then the NAS might pass a location attribute to the RADIUS server, as well as passing this to the DHCP server in a relay option. Encoding the information two very different ways seems like it results in unnecessary overhead. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 18:12:23 +0000 Message-Id: <4.3.2.7.2.20040210125857.02f46a18@wells.cisco.com> Date: Tue, 10 Feb 2004 13:12:11 -0500 To: "Hannes Tschofenig" From: John Schnizlein Subject: draft-jones-radius-geopriv Cc: , geopriv@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Including the GeoPriv WG.. One concern, if this location configuration information (LCI) is to be carried over RADIUS, is that the example in section 6 seems to be 993 characters long. This one attribute seems to be taking a large share of the maximum RADIUS packet size of 4096. [RFC 2865, p 15] Is there enough room for everything else that would be expected with this attribute? John At 12:05 PM 2/10/2004, Hannes Tschofenig wrote: >you can find the geogriv/radius draft at: >http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.html >http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.txt > >the draft tries awareness for privacy and reuses results of the geopriv >working group. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 17:30:33 +0000 From: "Hannes Tschofenig" To: "'Bernard Aboba'" Cc: "'Nelson, David'" , Subject: RE: [Partial] listing of RADIUS related Internet Drafts Date: Tue, 10 Feb 2004 18:30:33 +0100 Message-ID: <000f01c3effb$96b28ee0$0100a8c0@verena> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit hi bernard, the geopriv-dhcp draft distributes its own location information as a location generator. as such it is not directly related. it was written in the early days of the geopriv working group. the draft is targeted at the geopriv working group. ciao hannes > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Dienstag, 10. Februar 2004 18:31 > To: Tschofenig Hannes > Cc: 'Nelson, David'; radiusext@ops.ietf.org > Subject: RE: [Partial] listing of RADIUS related Internet Drafts > > > > you can find the geogriv/radius draft at: > > http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.html > > http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.txt > > > > the draft tries awareness for privacy and reuses results of the > geopriv > > working group. > > Question: How does this draft relate to the DHCP location > option, proposed below? Is this draft intended for the GEOPRIV WG? > http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lci-option-0 3.txt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 17:18:40 +0000 Date: Tue, 10 Feb 2004 09:30:58 -0800 (PST) From: Bernard Aboba To: Hannes Tschofenig cc: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: [Partial] listing of RADIUS related Internet Drafts Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > you can find the geogriv/radius draft at: > http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.html > http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.txt > > the draft tries awareness for privacy and reuses results of the geopriv > working group. Question: How does this draft relate to the DHCP location option, proposed below? Is this draft intended for the GEOPRIV WG? http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lci-option-03.txt -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 17:05:49 +0000 From: "Hannes Tschofenig" To: "'Nelson, David'" , Subject: RE: [Partial] listing of RADIUS related Internet Drafts Date: Tue, 10 Feb 2004 18:05:32 +0100 Message-ID: <000a01c3eff8$17d886e0$0100a8c0@verena> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit hi nelson, hi all, you can find the geogriv/radius draft at: http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.html http://www.tschofenig.com/drafts/draft-jones-radius-geopriv-00.txt the draft tries awareness for privacy and reuses results of the geopriv working group. ciao hannes > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Dienstag, 10. Februar 2004 17:23 > To: radiusext@ops.ietf.org > Subject: [Partial] listing of RADIUS related Internet Drafts > > > This list of RADIUS related Internet Drafts is taken from the > IETF Individual Submission ID web page. Note that not all of > the IDs listed below are under active consideration for > RADEXT WG work at this time. Please add to this list as > appropriate. Thanks. > > > > http://www.ietf.org/internet-drafts/draft-adrangi-radius-exten sion-for-p wlan-00.txt http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-inf ormation-00.txt http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capab ility-00.txt http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt http://www.ietf.org/internet-drafts/draft-lonvick-sobgp-radius-03.txt http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-po rt-01.txt http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickst art-01.txt http://www.ietf.org/internet-drafts/draft-heinanen-radius-l2tp-vpls-00.t xt http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-handoff-04.txt http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions -02.txt http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapp ing-00.txt http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext ension-00.txt http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt There is also a new draft on "GEOPRIV support for RADIUS" that has not been posted to the IETF ID page yet. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 16:49:15 +0000 Date: Tue, 10 Feb 2004 09:01:28 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com cc: radiusext@ops.ietf.org Subject: RE: Bof at next IETF? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Thanks, John. One of the pre-requisities for formation of an IETF WG is the demonstration that a community of interest exists relating to the work items included in the charter. That means that we not only need individual submissions fitting within the charter, but active discussion on those items to demonstrate that there is interest in advancing them. > It would be good if authors of individual documents would send email > to this list, with pointers to their documents. Also, it would > help to have the authors give a short explaination of what they > are trying to do, what things need discussion, etc. I think the > chairs & area directors are waiting for some discussion and interest > level in this work. The IETF generally doesn't have extra resources > to do any work or reviews if there aren't people voluneering to do > the work. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 16:42:24 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Tue, 10 Feb 2004 11:42:08 -0500 Message-ID: Thread-Topic: RE: Bof at next IETF? Thread-Index: AcPvqmDZsDhjlJr7QTu9C2FyRu2EUwAPw4ggAAA1sqAAABI6sAAAJTKwAAA2L6AAAfey4A== From: "Nelson, David" To: I have had some off-list discussions about the timing and progress of the nascent RADEXT WG, and have summarized my comments on this issue for the list, as I'm sure others have the same questions. While not have a RADEXT BOF at IETF 59 may be seen to create unfortunate timing, having a formal WG is not a prerequisite to doing work on the drafts. Having volunteers to act as document editors, volunteers to do careful reviews, and a reflector list over which to communicate is all that is needed... for now. Some of the submitted drafts, IMHO, are still out of scope for our charter. I'd like to see more progress in that area before we formally ask the IESG to charter the WG. Formally starting the WG, before the charter and scope issues are generally agreed upon will not, IMHO, accelerate the desired end product. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 16:23:41 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [Partial] listing of RADIUS related Internet Drafts Date: Tue, 10 Feb 2004 11:22:47 -0500 Message-ID: Thread-Topic: [Partial] listing of RADIUS related Internet Drafts Thread-Index: AcPv8idRAQE7p1EeTgWZr14RQn1U4A== From: "Nelson, David" To: This list of RADIUS related Internet Drafts is taken from the IETF Individual Submission ID web page. Note that not all of the IDs listed below are under active consideration for RADEXT WG work at this time. Please add to this list as appropriate. Thanks. http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-for-p wlan-00.txt http://www.ietf.org/internet-drafts/draft-adrangi-radiusext-location-inf ormation-00.txt http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capab ility-00.txt http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-01.txt http://www.ietf.org/internet-drafts/draft-lonvick-sobgp-radius-03.txt http://www.ietf.org/internet-drafts/draft-nmcgill-l2tp-radius-ext-nas-po rt-01.txt http://www.ietf.org/internet-drafts/draft-moskowitz-radius-client-kickst art-01.txt http://www.ietf.org/internet-drafts/draft-heinanen-radius-l2tp-vpls-00.t xt http://www.ietf.org/internet-drafts/draft-irtf-aaaarch-handoff-04.txt http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions -02.txt http://www.ietf.org/internet-drafts/draft-lior-radius-udp-transport-mapp ing-00.txt http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-ext ension-00.txt http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-00.txt There is also a new draft on "GEOPRIV support for RADIUS" that has not been posted to the IETF ID page yet.=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 15:37:43 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Tue, 10 Feb 2004 17:37:28 +0200 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPvrZE5vMQ8263TQO2chW7mAc+iSgAPDHogAABHj5AAAByTYA== From: To: , , , , Hi Dan, > I was not aware about a call for volunteers. I am=20 > volunteering to review the drafts. As they are individual=20 > submissions at this point in time, I would be grateful to be=20 > pointed to these drafts, as they are submitted and become available. It would be good if authors of individual documents would send email to this list, with pointers to their documents. Also, it would help to have the authors give a short explaination of what they are trying to do, what things need discussion, etc. I think the chairs & area directors are waiting for some discussion and interest level in this work. The IETF generally doesn't have extra resources to do any work or reviews if there aren't people voluneering to do the work. br, John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 15:35:20 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Tue, 10 Feb 2004 10:35:02 -0500 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPvrZE5vMQ8263TQO2chW7mAc+iSgAPDHogAABHj5AAABVHYA== From: "Nelson, David" To: "Romascanu, Dan (Dan)" , > I was not aware about a call for volunteers. I am volunteering to review > the drafts. As they are individual submissions at this point in time, I > would be grateful to be pointed to these drafts, as they are submitted and > become available. Dan, I'll review the list of those that I am aware of, and post a pointer on this reflector to any that haven't been announced here. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 15:33:31 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Tue, 10 Feb 2004 10:32:31 -0500 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPvqmDZsDhjlJr7QTu9C2FyRu2EUwAPw4ggAAA1sqAAADOV4A== From: "Nelson, David" To: Dan Romascanu writes... =20 > Why? Please see my reply to Parviz's message. If that explanation is not sufficient, please reply, and I'll attempt to elaborate. Thanks. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 15:33:10 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Tue, 10 Feb 2004 17:32:33 +0200 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPvrZE5vMQ8263TQO2chW7mAc+iSgAPDHogAABHj5A= From: "Romascanu, Dan (Dan)" To: "Nelson, David" , "Parviz Yegani" , "Avi Lior" , I was not aware about a call for volunteers. I am volunteering to review = the drafts. As they are individual submissions at this point in time, I = would be grateful to be pointed to these drafts, as they are submitted = and become available. Regards, Dan > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Nelson, David > Sent: 10 February, 2004 5:28 PM > To: Parviz Yegani; Avi Lior; radiusext@ops.ietf.org > Subject: RE: Bof at next IETF? >=20 >=20 > Parviz Yegani writes... > =20 > > Given the strong support from the last IETF I thought=20 > RADIUSEXT was on > > its way to become a new WG. What are we waiting for? >=20 > We are waiting for Internet Drafts, of suitable quality, that=20 > fit within > the proposed Charter, and volunteers to review those drafts. >=20 > I have noticed a flurry of drafts coming out just prior to the cutoff > date for IEEE 59. I would encourage all interested parties to review > these drafts, for protocol quality, and also for compliance to the > charter. Please review the drafts and submit commentary on this list. >=20 > While there was substantial support for moving forward with RADIUS > Extensions, there was equally substantial support for the=20 > limited scope > of changes to RADIUS as presented in the draft charter. I=20 > think we are > making progress toward meeting the requirement for suitable=20 > drafts, but > we have a ways to go yet. >=20 > -- Dave >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 15:28:29 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Tue, 10 Feb 2004 10:28:13 -0500 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPvrZE5vMQ8263TQO2chW7mAc+iSgAPDHog From: "Nelson, David" To: "Parviz Yegani" , "Avi Lior" , Parviz Yegani writes... =20 > Given the strong support from the last IETF I thought RADIUSEXT was on > its way to become a new WG. What are we waiting for? We are waiting for Internet Drafts, of suitable quality, that fit within the proposed Charter, and volunteers to review those drafts. I have noticed a flurry of drafts coming out just prior to the cutoff date for IEEE 59. I would encourage all interested parties to review these drafts, for protocol quality, and also for compliance to the charter. Please review the drafts and submit commentary on this list. While there was substantial support for moving forward with RADIUS Extensions, there was equally substantial support for the limited scope of changes to RADIUS as presented in the draft charter. I think we are making progress toward meeting the requirement for suitable drafts, but we have a ways to go yet. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 15:27:32 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Tue, 10 Feb 2004 17:27:16 +0200 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPvqmDZsDhjlJr7QTu9C2FyRu2EUwAPw4ggAAA1sqA= From: "Romascanu, Dan (Dan)" To: "Nelson, David" , "Avi Lior" , Why? Regards, Dan > Avi Lior writes... >=20 > > Is there going to be a BOF at the IETF 59. >=20 > No. > =20 > > Also did we post minutes from the last BOF. >=20 > Yes. Here's the link: http://www.ietf.org/proceedings/03nov/177.htm >=20 > -- Dave >=20 >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 15:23:24 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Bof at next IETF? Date: Tue, 10 Feb 2004 10:22:44 -0500 Message-ID: Thread-Topic: Bof at next IETF? Thread-Index: AcPvqmDZsDhjlJr7QTu9C2FyRu2EUwAPw4gg From: "Nelson, David" To: "Avi Lior" , Avi Lior writes... > Is there going to be a BOF at the IETF 59. No. =20 > Also did we post minutes from the last BOF. Yes. Here's the link: http://www.ietf.org/proceedings/03nov/177.htm -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 08:11:36 +0000 Message-Id: <4.3.2.7.2.20040210000719.01d6b910@franklin.cisco.com> Date: Tue, 10 Feb 2004 00:10:56 -0800 To: Avi Lior , radiusext@ops.ietf.org From: Parviz Yegani Subject: Re: Bof at next IETF? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Given the strong support from the last IETF I thought RADIUSEXT was on its way to become a new WG. What are we waiting for? -Parviz At 02:48 AM 2/10/2004 -0500, Avi Lior wrote: >Is there going to be a BOF at the IETF 59. If so when so we can plan our >travels. > >Also did we post minutes from the last BOF. > > >-- >to unsubscribe send a message to radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 10 Feb 2004 07:48:40 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org Subject: Bof at next IETF? Date: Tue, 10 Feb 2004 02:48:15 -0500 MIME-Version: 1.0 Content-Type: text/plain Is there going to be a BOF at the IETF 59. If so when so we can plan our travels. Also did we post minutes from the last BOF. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 09 Feb 2004 15:28:59 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Subtypes (again) and other ideas Date: Mon, 9 Feb 2004 10:28:32 -0500 Message-ID: Thread-Topic: Subtypes (again) and other ideas Thread-Index: AcPvC4UJcc17pBiuQXSRZWa/GrURVAAFIAsA From: "Nelson, David" To: "Victor Gamov" , Victor Gamov writes... > I red this pecifications and now I have new ideas about our problem. >=20 > 1. I think that we need to use VSA with Vendor-Id=3D0 (standard = RADIUS) to > extend standard RADIUS attributes space. It's very possible that > current attribute space will be exceed in future. DBN: I don't think there is any credible evidence that the Standard RADIUS attribute space, for attributes that would pass "IETF standards action" review, will be exhausted anytime in the near future. If, in fact, that does come to pass during the lifetime of RADIUS, then it should be addressed at that point in time. At this juncture, it is mere speculation. > 2. New attribute type from still unassigned attribute space with > following format to extend Service-specific attributes: DBN: "Service-Specific" as opposed to "Vendor-Specific"? What distinguishes a Service-Specific attribute from a RADIUS Standards Track attribute? =20 > 3. When different applications need to share some attribute we can add > it in RADIUS VSA (with Vendor-ID 0) attribute space after some > discussions. So item 1 is very useful for this. DBN: When multiple applications have a shared need for a RADIUS attribute, it belongs in the Standards Track attribute number space. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 09 Feb 2004 12:51:32 +0000 Message-ID: <40278221.1040308@lipetsk.ru> Date: Mon, 09 Feb 2004 15:50:41 +0300 From: Victor Gamov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040126 MIME-Version: 1.0 To: radiusext@ops.ietf.org CC: Avi Lior , "'Nakhjiri Madjid-MNAKHJI1'" Subject: Re: Subtypes (again) and other ideas Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Avi Lior wrote: > >>-----Original Message----- >>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >>Sent: Tuesday, January 27, 2004 3:32 PM >>To: 'Avi Lior'; 'Victor Gamov'; radiusext@ops.ietf.org >>Subject: RE: Subtypes (again) and other ideas >> >> >>Hi Avi, >> >>I am not sure, if I understand the problem you are raising >>below. Are you saying that a sub attribute out of for >>instance WLAN attribute (which is treated as a vendor >>specific) needs security, then that piece of data cannot be a >>subattribute anymore? If true, although I agree that is a >>problem, but isn't that already a >>problem for vendor specific attributes? > > > It is. Hi gentlemen! I'm really sorry, that I was absent for a long time >>The suggested idea seems to be the best way to handle all the >>new applications that are popping up with the limited >>attribute space. Furthermore, this approach won't tie the >>hand of application designers to have to map all their data >>into existing attributes. > > But don't forget my other reason. Not using application space allows us to > reuse attributes. > > I think that there is a better approach to handling the limited attribute > space for RADIUS. I already posted an internet draft for that. See > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-lior-radius-attribut > e-type-extension-00.txt I red this pecifications and now I have new ideas about our problem. 1. I think that we need to use VSA with Vendor-Id=0 (standard RADIUS) to extend standard RADIUS attributes space. It's very possible that current attribute space will be exceed in future. 2. New attribute type from still unassigned attribute space with following format to extend Service-specific attributes: 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 (241) | Length | Service-Type | +---------------+---------------+-------------------------------+ | Service-Type (cont) | String... +---------------+---------------+---------------+---------------+ Type 241 for Service-Specific Length >= 7 Service-Type = value of Service-Type attribute. (We need to propose new Service-Type values for different services (Wi-Fi, LAN, PPPoE etc)) String may be in following format: +---------------+---------------+---------------+---------------+ | Extended-Type | ID |Extended-Length| +---------------+---------------+---------------+---------------+ | Extended-Value... +---------------+---------------+---------------+---------------+ Extended-Type -- type of service-specific attribute ID -- random value from 0 to 255 to identify different service-specific attributes with equal Extended-Type in one packet Extended-Length >= 5 Extended-Value -- Service-Type and Extended-Type specific value Attributes with equal Service-Type, Extended-Type and ID MUST be concatenated. This allows Extended-Value longer than 245 bytes 3. When different applications need to share some attribute we can add it in RADIUS VSA (with Vendor-ID 0) attribute space after some discussions. So item 1 is very useful for this. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: