From owner-ietf-radius@livingston.com Thu Sep 2 14:30:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26551 for ; Thu, 2 Sep 1999 14:30:15 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id LAA08418; Thu, 2 Sep 1999 11:27:34 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA17587 for ietf-radius-outgoing; Thu, 2 Sep 1999 11:24:50 -0700 (PDT) Message-ID: <6FFEC516CDF6D211AB7700805F65699E036E86@xwd.ih.lucent.com> From: "Varghese, Joe" To: ietf-radius@livingston.com Subject: (radius) Off-topic: Database vs textfile approach (Implementation Question ) Date: Thu, 2 Sep 1999 13:22:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Varghese, Joe" I apologize for the off-topic post, but couldnt find any other forum to get some answers (is there a newsgroup that deals with RADIUS questions?). Is the general norm to restart the Radius server whenver new users are added? I ask this because with a users textfile, the only way to add or delete users is to generate a new file and then restart the server. The alternative would be to have authentication requests go straight to whatever database you have running, but the disadvantage is that the Radius server is now tightly integrated with a database. Based on your experiences, do you recommend one way over another? Or, is there a middle ground (maybe a textfile that contains only the incremental changes in the database with primitives like add or delete)? Any comments would be appreciated. Thanks in advance! joe varghese -------------------------------- George (Joe) Varghese varghese@lucent.com (630) 713-9522 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Sep 10 04:23:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26164 for ; Fri, 10 Sep 1999 04:23:32 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id BAA28088; Fri, 10 Sep 1999 01:21:12 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA08346 for ietf-radius-outgoing; Fri, 10 Sep 1999 01:20:04 -0700 (PDT) Message-ID: <013a01befb65$5bc5a220$0201a8c0@nec.oleane.com> From: "Peter lewis" To: Subject: (radius) QoS Summit Date: Fri, 10 Sep 1999 10:20:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Peter lewis" Content-Transfer-Encoding: 7bit QoS Summit: key requirements for advanced applications running on future networks. Technologies (MPLS, ATM, IntSev/DiffServ, Frame Relay). Managing, policing, billing, charging QoS. The annual rendez-vous with top senior specialists. Paris, France, 16-19 November 1999 Please see details at the following web address: http://www.upperside.fr/baqos.htm Sorry to post this message on the list. Thanks - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Sep 15 03:56:53 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02790 for ; Wed, 15 Sep 1999 03:56:52 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id AAA22512; Wed, 15 Sep 1999 00:54:26 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id AAA07030 for ietf-radius-outgoing; Wed, 15 Sep 1999 00:49:50 -0700 (PDT) Message-ID: <37DF4E33.A1EC5DD9@rc.bel.alcatel.be> Date: Wed, 15 Sep 1999 09:43:47 +0200 From: Ronnie Ekstein X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Glen Zorn , roamops@tdmx.rutgers.edu, ietf-radius@livingston.com, MegaZone , nasreq@tdmx.rutgers.edu, "Yves T'joens" Subject: (radius) Re: nasreq draft-ekstein-roamops-protcomp-00.txt Content-Type: text/plain; charset=x-user-defined Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ronnie Ekstein Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA02790 Glen Zorn wrote: > On Tue, 31 Aug 1999, MegaZone wrote: > > > ---cut--- > >       Neither  RADIUS  nor  COPS  support  explicitly  vendor   specific > >       extensibility. > > ---cut--- > > > > That is an error.  RADIUS most certainly does - the attribute is called > > "Vendor-Specific". > > True (and it's even in RFC 2138! :-) ooops, indeed this is right, but still 2 remarks: 1. Eventhough the Vendor-Specific attribute exists, some vendors still (also) use the 'normal' space of attributes and create their own dictionary of attributes. 2. The use of Vendor-extensions in DIAMETER also allows for Vendor Specific messages. > > I think this document would be more effective if it > > took into account the drafts that enhance and extend RFCs 2138/2139 as > > there is a lot of capability not in those two RFCs but that does exist > > and is in common use today. > > Well...it might be more effective, but it wouldn't reflect the actual > status of the protocols in the IETF, right?  Given the length of time > those drafts have _been_ drafts, I'm not holding my breath till they are > RFCs! > agree > > > > > ---cut--- > >       A RADIUS client and server maintain between them a shared  secret. > >       A  RADIUS  server can authenticate the clients request only if the > >       shared secret has been used in the context of password  hiding.  A > >       User-Password  attribute  is  the plain-text user password encoded > >       with the MD5 digest of the octet stream consisting of  the  shared > >       secret  and  the  Authenticator. If the User-Password attribute is > >       not available, no other  explicit  authentication  information  is > >       available within the request. > > ---cut--- > > > > This is also no longer the case.  The more recent revisions to RADIUS > > talk to this point and there are other items to use in place of the > > User-Password.  You mention Signature later in your draft. > > > > True, but again, the Signature attribute isn't "official" RADIUS. > again, agree, we will see to put some more -draft- status information in the next version to show the fuller picture... > > > ---cut--- > >       RADIUS only provides for hiding of  the  User-Password  attribute. > >       Other attributes are send in cleartext > > ---cut--- > > > > ARAP-Password, CHAP-Password (this is off the top of my head, so I may > > be slightly off on the names), etc, are also protected if used. > > > > Actually, I don't think that either of these are actually protected _by > RADIUS_: they are scrambled up, but RADIUS doesn't do the scrambling, CHAP > and ARAP do.  So strictly speaking, I think that the draft is accurate in > saying that they are send (sic) in cleartext. > Agree again with Glenn on this. thanks a lot for the review, your input is appreciated, we'll update the draft soon... Regards, Ronnie, Yves - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Sep 15 14:41:18 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17676 for ; Wed, 15 Sep 1999 14:41:17 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id LAA03777; Wed, 15 Sep 1999 11:38:42 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA03587 for ietf-radius-outgoing; Wed, 15 Sep 1999 11:35:30 -0700 (PDT) Message-ID: <9A74C89D6696D2118E500008C7BA7C560C03B0AC@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Varghese, Joe'" , ietf-radius@livingston.com Subject: RE: (radius) Off-topic: Database vs textfile approach (Implementa tion Question ) Date: Wed, 15 Sep 1999 14:31:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Varghese, Joe [mailto:varghese@lucent.com]: >Is the general norm to restart the Radius server whenver new users are >added? I ask this because with a users textfile, the only way to add or >delete users is to generate a new file and then restart the server. > >The alternative would be to have authentication requests go straight to >whatever database you have running, but the disadvantage is that the Radius >server is now tightly integrated with a database. > >Based on your experiences, do you recommend one way over another? Or, is >there a middle ground (maybe a textfile that contains only the incremental >changes in the database with primitives like add or delete)? I hesitate to answer the question about what the "norm" is, because the norm may in fact be a bad thing to do. So... In a case where a RADIUS server is part of a mission-critical high-availability service, there probably is a requirement that the RADIUS server can run without interruption. That is, normal operations should not impact service availability. Adding users is certainly a normal operation. This requirement can be met in various ways, but IMO doing lookups to some type of back-end database is a good solution. I don't see why integration with a database is a disadvantage. Databases usually have well-documented public protocol interfaces and standard APIs. We have used RADIUS servers that talk to SQL databases and LDAP directories in order to achieve this level of service, with good results and performance. There is certainly a trend in the industry for commercial RADIUS servers to support various back-end databases and directories. + Mark Anthony Beadles + UUNET Product Development + + mbeadles@wcom.net + http://networking.us.uu.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Sep 17 09:25:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12870 for ; Fri, 17 Sep 1999 09:25:37 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id GAA12828; Fri, 17 Sep 1999 06:23:03 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA17100 for ietf-radius-outgoing; Fri, 17 Sep 1999 06:19:05 -0700 (PDT) Message-ID: <010b01bf010e$aef20610$0103a8c0@ds9> From: "Darran Potter" To: Subject: (radius) UTF-8 Strings Date: Fri, 17 Sep 1999 14:15:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit Are many vendors out there i) using UTF-8 today, or ii) planning on using UTF-8 in the near future Since all of the recent RFCs use terms like "should", "recomend" (eg tunnelling, extensions, v2 rfc's) Would you use it for all your strings? or just some? and would you expect an AAA server to return the same back? Thanks ______________________________ Darran Potter - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Sep 22 10:34:11 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04873 for ; Wed, 22 Sep 1999 10:34:10 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id HAA15799; Wed, 22 Sep 1999 07:31:33 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA11110 for ietf-radius-outgoing; Wed, 22 Sep 1999 07:27:11 -0700 (PDT) Message-Id: <4.2.0.58.19990922095523.00cd0610@zbl6c008.corpeast.baynetworks.com> X-Sender: dmitton@zbl6c008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 22 Sep 1999 10:25:29 -0400 To: ietf-radius From: "David Mitton" Subject: (radius) Bakeoff Interest? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David Mitton" Is there any interest in having a RADIUS interoperability testing event prior to IETF in November? Potential areas of testing would include: - Updates to specs (including Call-Check) - Tunnel drafts - Extentions - MS-CHAP Of course setting up some of the environments may be trickier given LNS servers and line simulators. Please indicate interest back to me directly. Thanks. Dave. --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Sep 26 04:13:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05626 for ; Sun, 26 Sep 1999 04:13:44 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id BAA19514; Sun, 26 Sep 1999 01:11:05 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA18510 for ietf-radius-outgoing; Sun, 26 Sep 1999 01:07:07 -0700 (PDT) Message-Id: <4.1.19990926011528.00a0e4a0@omega.cisco.com> X-Sender: gdommety@omega.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sun, 26 Sep 1999 01:17:29 -0700 To: randy@psg.com, ietf-radius@livingston.com From: Gopal Dommety Subject: (radius) RADIUS ver 2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Gopal Dommety Hello: Could someone tell me the status of the draft RADIUS version 2. Is it going to become an RFC? Thanks Gopal - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Sep 26 20:54:59 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09946 for ; Sun, 26 Sep 1999 20:54:58 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id RAA29660; Sun, 26 Sep 1999 17:52:12 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA07102 for ietf-radius-outgoing; Sun, 26 Sep 1999 17:45:52 -0700 (PDT) Message-Id: <199909270044.RAA29506@shell4.ba.best.com> Subject: Re: (radius) RADIUS ver 2 In-Reply-To: <4.1.19990926011528.00a0e4a0@omega.cisco.com> from Gopal Dommety at "Sep 26, 99 01:17:29 am" To: gdommety@cisco.com Date: Sun, 26 Sep 1999 17:44:26 -0700 (PDT) Cc: randy@psg.com, ietf-radius@livingston.com From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Content-Transfer-Encoding: 7bit Once upon a time Gopal Dommety shaped the electrons to say... > Could someone tell me the status of the draft RADIUS version 2. Is it >going to become an RFC? There is no "RADIUS Version 2" - there is just RADIUS. That name was (improperly) applied to some work done on what was eventually named DIAMETER. At this time there is a group working on DIAMETER, but, AFAIK, it is not under the aegis of any official IETF forum and there are other protocols being developed that could also be used for AAA. Whether DIAMETER will ever become an RFC remains to be seen. At this point in time I am not aware of any systems that use DIAMETER, aside for test systems used by the group working on it. -MZ, CISSP #3762 -- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Sep 26 23:06:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12266 for ; Sun, 26 Sep 1999 23:06:38 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id UAA17156; Sun, 26 Sep 1999 20:03:37 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA01647 for ietf-radius-outgoing; Sun, 26 Sep 1999 20:02:43 -0700 (PDT) Message-Id: <4.2.0.58.19990926200032.00973100@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 26 Sep 1999 20:02:02 -0700 To: MegaZone From: Matt Holdrege Subject: Re: (radius) RADIUS ver 2 Cc: gdommety@cisco.com, randy@psg.com, ietf-radius@livingston.com In-Reply-To: <199909270044.RAA29506@shell4.ba.best.com> References: <4.1.19990926011528.00a0e4a0@omega.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege At 05:44 PM 9/26/99 -0700, MegaZone wrote: >Once upon a time Gopal Dommety shaped the electrons to say... > > Could someone tell me the status of the draft RADIUS version 2. Is it > >going to become an RFC? > >There is no "RADIUS Version 2" - there is just RADIUS. > >That name was (improperly) applied to some work done on what was eventually >named DIAMETER. At this time there is a group working on DIAMETER, but, >AFAIK, it is not under the aegis of any official IETF forum and there are >other protocols being developed that could also be used for AAA. Whether >DIAMETER will ever become an RFC remains to be seen. At this point in time >I am not aware of any systems that use DIAMETER, aside for test systems >used by the group working on it. Actually there is a Radius 2 and it's documented at draft-ietf-radius-radius-v2-01.txt and it has nothing to do with Diameter. And it sure would be nice to get a status update. Has the IESG reviewed it? Will they? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Sep 26 23:27:45 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12319 for ; Sun, 26 Sep 1999 23:27:45 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id UAA17397; Sun, 26 Sep 1999 20:25:05 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA02127 for ietf-radius-outgoing; Sun, 26 Sep 1999 20:24:46 -0700 (PDT) From: Gopal Dommety Message-Id: <199909270320.UAA17366@omega.cisco.com> Subject: Re: (radius) RADIUS ver 2 To: matt@ascend.com Date: Sun, 26 Sep 1999 20:20:14 -0700 (PDT) Cc: megazone@megazone.org, gdommety@cisco.com, randy@psg.com, ietf-radius@livingston.com In-Reply-To: <4.2.0.58.19990926200032.00973100@porky> from "Matt Holdrege" at Sep 26, 99 08:02:02 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Gopal Dommety Content-Transfer-Encoding: 7bit > > Actually there is a Radius 2 and it's documented at > draft-ietf-radius-radius-v2-01.txt and it has nothing to do with Diameter. I was asking about the status of this draft. From the naming convention it looks like RADIUS working group draft. Could someone shed light on this? Thanks, -Gopal > > And it sure would be nice to get a status update. Has the IESG reviewed it? > Will they? > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Sep 26 23:28:41 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12330 for ; Sun, 26 Sep 1999 23:28:40 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id UAA17488; Sun, 26 Sep 1999 20:25:53 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA02153 for ietf-radius-outgoing; Sun, 26 Sep 1999 20:25:46 -0700 (PDT) Message-Id: <4.2.0.58.19990926202345.0096d3b0@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 26 Sep 1999 20:25:04 -0700 To: Gopal Dommety From: Matt Holdrege Subject: Re: (radius) RADIUS ver 2 Cc: randy@psg.com, ietf-radius@livingston.com In-Reply-To: <199909270320.UAA17366@omega.cisco.com> References: <4.2.0.58.19990926200032.00973100@porky> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege At 08:20 PM 9/26/99 -0700, Gopal Dommety wrote: > > > > Actually there is a Radius 2 and it's documented at > > draft-ietf-radius-radius-v2-01.txt and it has nothing to do with Diameter. > >I was asking about the status of this draft. From the naming >convention it looks like RADIUS working group draft. Could someone >shed light on this? It is a RADIUS WG draft and I seem to recall it went through WG last call which I why I wondered if the IESG had reviewed it. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Sep 27 07:42:54 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26579 for ; Mon, 27 Sep 1999 07:42:53 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id EAA21079; Mon, 27 Sep 1999 04:40:09 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA12625 for ietf-radius-outgoing; Mon, 27 Sep 1999 04:38:43 -0700 (PDT) From: Pat.Calhoun@eng.sun.com Message-ID: <525448625.938432311385.JavaMail.pcalhoun@hsmpka.Eng.Sun.COM> Date: Mon, 27 Sep 1999 04:38:31 -0700 (PDT) To: Gopal Dommety Subject: Re: (radius) RADIUS ver 2 Cc: ietf-radius@livingston.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Sun(TM) Web Access 1.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com Content-Transfer-Encoding: 7bit >> >> Actually there is a Radius 2 and it's documented at >> draft-ietf-radius-radius-v2-01.txt and it has nothing to do with Diameter. Correct. There are a few new attributes documented since some of these had become widely deployed. There is also support for Appletalk and EAP. This is not an attempt to fix the protocol. PatC > >I was asking about the status of this draft. From the naming >convention it looks like RADIUS working group draft. Could someone >shed light on this? > >Thanks, >-Gopal > > > >> >> And it sure would be nice to get a status update. Has the IESG reviewed it? >> Will they? >> >> - >> To unsubscribe, email 'majordomo@livingston.com' with >> 'unsubscribe ietf-radius' in the body of the message. >> > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Sep 27 08:34:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28727 for ; Mon, 27 Sep 1999 08:34:09 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id FAA21562; Mon, 27 Sep 1999 05:31:29 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA13701 for ietf-radius-outgoing; Mon, 27 Sep 1999 05:32:07 -0700 (PDT) Message-ID: <004b01bf08e3$bea29e30$0103a8c0@ds9> From: "Darran Potter" To: "Darran Potter" , References: <010b01bf010e$aef20610$0103a8c0@ds9> Subject: Re: (radius) UTF-8 Strings Date: Mon, 27 Sep 1999 13:27:57 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit So nobody has addressed this yet? ----- Original Message ----- From: Darran Potter To: Sent: 17 September 1999 14:15 Subject: (radius) UTF-8 Strings > Are many vendors out there > > i) using UTF-8 today, or > ii) planning on using UTF-8 in the near future > > Since all of the recent RFCs use terms like "should", "recomend" > (eg tunnelling, extensions, v2 rfc's) > > Would you use it for all your strings? or just some? and would you > expect an AAA server to return the same back? > > Thanks > > > ______________________________ > Darran Potter > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Sep 29 05:06:57 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21209 for ; Wed, 29 Sep 1999 05:06:56 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id CAA06552; Wed, 29 Sep 1999 02:04:25 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA09916 for ietf-radius-outgoing; Wed, 29 Sep 1999 02:00:46 -0700 (PDT) Date: Wed, 29 Sep 1999 02:00:43 -0700 (PDT) From: Carl Rigney Message-Id: <199909290900.CAA09910@server.livingston.com> To: gdommety@cisco.com Subject: Re: (radius) RADIUS ver 2 Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney There is no such thing as RADIUS version 2; the draft-ietf-radius-radius-v2-01.txt is for the advancement of RADIUS from Proposed Draft to Draft Standard. It's passed WG last call and is ready for IETF last call, but needs a couple more documents to be submitted along with it (the interoperability statement and some guidelines on allocating attributes), which I'm working on. The v2 is unfortunate, but that's how the Internet Drafts editor wanted to name it. -- Carl Rigney RADIUS WG Chair cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Sep 29 10:27:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01506 for ; Wed, 29 Sep 1999 10:27:12 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id HAA09895; Wed, 29 Sep 1999 07:24:34 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA18471 for ietf-radius-outgoing; Wed, 29 Sep 1999 07:24:47 -0700 (PDT) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199909291424.HAA11521@hsmpka.eng.sun.com> Date: Wed, 29 Sep 1999 07:25:16 -0700 To: "Carl Rigney" , Cc: Subject: Re: (radius) RADIUS ver 2 X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Content-Transfer-Encoding: 7bit Somehow I missed the WG last call, must have been in stasis or something. I became aware of the following text in the new document which I have objections with: A forwarding server may either perform its forwarding function in a pass through manner, where it sends retransmissions on as soon as it gets them, or it may take responsibility for retransmissions, for example in cases where the network link between forwarding and remote server has very different characteristics than the link between NAS and forwarding server. Extreme care should be used when implementing a proxy server that takes responsibility for retransmissions so that its retransmission policy is robust and scalable. The text above is about as vague as one can possibly imagine, and it having *some* intermediate nodes within a proxy chain perform their own retransmission, while others do not *will* cause problems in the network. My opinion is that either this document requires this functionality (where each node retransmits), or that only the NAS does (as is the current protocol). Furthermore, a RADIUS server will not be aware of the underlying links between the NAS and the forwarding servers, so I don't quite understand how a server would know that this needs to be turned on. Lastly, the last sentence makes it clear that the authors have issues with this new statement, and "robust and scalable" is left up to the developer's imagination. The whole premise behind RADIUS servers in the past was that they were largely stateless. I find it strange that moving the document to Draft Standard actually changes the whole concept of RADIUS servers. My understanding of moving to Draft Standard is that no major protocol change should be introduced. I consider this very major, and it has never been proven to work in a large network. One more comment. In the past it has been made very clear that an empty attribute (length = 2), is invalid and not supported in the RADIUS protocol. For this reason we had to change the EAP draft. The new draft now allows this. Is there a reason why this never before functionality is now allowed in the new draft? PatC >There is no such thing as RADIUS version 2; the >draft-ietf-radius-radius-v2-01.txt is for the advancement of RADIUS >from Proposed Draft to Draft Standard. It's passed WG last call and is >ready for IETF last call, but needs a couple more documents to be >submitted along with it (the interoperability statement and some >guidelines on allocating attributes), which I'm working on. > >The v2 is unfortunate, but that's how the Internet Drafts editor wanted >to name it. > >-- >Carl Rigney >RADIUS WG Chair >cdr@livingston.com >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message.