From owner-ietf-radius@livingston.com Mon May 3 05:27:31 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 FAA16743 for ; Mon, 3 May 1999 05:27:31 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id CAA10209; Mon, 3 May 1999 02:19:52 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA06546 for ietf-radius-outgoing; Mon, 3 May 1999 02:21:37 -0700 (PDT) Message-ID: <372D62B4.4DD57BFA@alcatel.be> Date: Mon, 03 May 1999 10:47:48 +0200 From: Marc De Vries X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius Subject: Re: (radius) NAS-Port-Id and Framed-Pool References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Marc De Vries Content-Transfer-Encoding: 7bit > > 5.18. Framed-Pool > > > > Description > > > > This Attribute contains the name of an assigned address pool that > > SHOULD be used to assign an address for the user. If a NAS does > > not support multiple address pools, the NAS should ignore this > > Attribute. Address pools are usually used for IP addresses, but > > can be used for other protocols if the NAS supports pools for > > those protocols. > > We need to more clearly define the behavior if named pools are supported > on the NAS, but this particular pool has not been configured. We also > need to specify what should happen if the specified pool is exhausted. > > I recommend something like, "If the particular pool requested is not > configured on the NAS, the NAS SHOULD ignore this Attribute. If the First, ignoring the pool attribute may result in the user getting any IP address he/she wants. Second, at least three NAS vendors already support a pool attribute and when they receive an unknown pool name, they attempt to download an updated pool configuration from a central server (hoping the pool with that particular name will be in there). So, IMO, the attribute should not be ignored, and the resulting action is implementation dependent. Regards, Marc. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon May 3 11:41:20 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 LAA20049 for ; Mon, 3 May 1999 11:41:20 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA15827; Mon, 3 May 1999 08:33:23 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA21472 for ietf-radius-outgoing; Mon, 3 May 1999 08:37:21 -0700 (PDT) Date: Mon, 3 May 1999 10:31:08 -0500 (CDT) From: Shreesha Ramanna Message-Id: <199905031531.KAA20706@allegreto.cig.mot.com> X-Mailer: Z-Mail (3.2.1 10oct95) To: ietf-radius@livingston.com Subject: (radius) RADIUS products Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Shreesha Ramanna Hi all, I am looking for some RADIUS product/software vendors information, who are willing to share/modify their VSAs. Regards, Shreesha - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon May 3 12:31:14 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 MAA21160 for ; Mon, 3 May 1999 12:31:14 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA18204; Mon, 3 May 1999 09:23:58 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA27097 for ietf-radius-outgoing; Mon, 3 May 1999 09:28:47 -0700 (PDT) Message-ID: <372DCE66.A2560428@merit.edu> Date: Mon, 03 May 1999 12:27:18 -0400 From: Wei Wang Organization: Merit Network, Inc. X-Mailer: Mozilla 4.51 [en] (X11; U; SunOS 5.5.1 sun4m) X-Accept-Language: en, zh-CN, zh-TW, zh MIME-Version: 1.0 To: Shreesha Ramanna CC: ietf-radius@livingston.com Subject: Re: (radius) RADIUS products References: <199905031531.KAA20706@allegreto.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Wei Wang Content-Transfer-Encoding: 7bit Shreesha Ramanna wrote: > > Hi all, > > I am looking for some RADIUS product/software vendors information, > who are willing to share/modify their VSAs. What's the reason for you to require that? Regards, -- Wei Wang weiwang@merit.edu Merit Network, Inc. http://www.merit.edu/~weiwang/ [Tel] 734-764-2874 [Fax] 734-647-3745 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon May 3 19:44:52 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 TAA12938 for ; Mon, 3 May 1999 19:44:52 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA04568; Mon, 3 May 1999 16:37:54 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA17346 for ietf-radius-outgoing; Mon, 3 May 1999 16:42:13 -0700 (PDT) Message-ID: <19990503234337.98679.qmail@hotmail.com> X-Originating-IP: [209.195.84.94] From: "Huw Davis" To: ietf-radius@livingston.com Subject: (radius) Proxy-State and Class attribute survey Date: Mon, 03 May 1999 23:43:33 GMT Mime-Version: 1.0 Content-type: text/plain; format=flowed; Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Huw Davis" Hi, Having spent too much time debugging interoperability problems in proxy chaining scenarios, I'd really appreciate RADIUS server and client (NAS etc) implementors helping me and others by answering the following questions about their Proxy-State and Class attribute support. I realize that this is not strictly related to the working group activities but I see that the designers of most the major RADIUS implementations are regular contributors. I've already learned the answer to some of these questions but instead of posting them and receiving lots of "That was a bug in version [x] and in version [x+1] we support...", I'd rather get the latest answer direct from the designers themselves. Thanks in advance. RADIUS Server ------------- Product: Version: 1) Does your server add the Class attribute to responses? If yes, how many and what is the maximum number of bytes in this attribute? 2) Does your server strip/truncate Class attributes if already present in responses before forwarding to the client? If yes, what are the strip/truncate rules e.g. discard all but first/last, discard more that [n] bytes etc? 3) Does your server strip/truncate Proxy-State attributes if already present in responses before forwarding to the client? If yes, what are the strip/truncate rules e.g. discard all but first/last, discard more that [n] bytes etc? If your RADIUS server supports proxying, please complete the next section too (RADIUS client is not just NAS since RADIUS 'servers' also act as clients in proxy chains). RADIUS Clients ------------- Product: Version: 1) Does your client add the Proxy-State attribute to requests? If yes, how many and what is the maximum number of bytes in this attribute? 2) Does your client strip/truncate Class attributes if already present in requests before forwarding to the server? If yes, what are the strip/truncate rules e.g. discard all but first/last, discard more that [n] bytes etc? 3) Does your client strip/truncate Proxy-State attributes if already present in requests before forwarding to the server? If yes, what are the strip/truncate rules e.g. discard all but first/last, discard more that [n] bytes etc? ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed May 5 10:32:07 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 KAA22996 for ; Wed, 5 May 1999 10:32:06 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA13960; Wed, 5 May 1999 07:25:02 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA11715 for ietf-radius-outgoing; Wed, 5 May 1999 07:26:07 -0700 (PDT) Message-Id: <3.0.5.32.19990505053416.00c0fb00@porky.ascend.com> X-Sender: mhold@porky.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 05 May 1999 05:34:16 -0700 To: ietf-radius@livingston.com From: Matt Holdrege Subject: (radius) update to tunnel draft Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege Folks, sorry for this late request to the tunneling draft. But recent deployments of L2TP have raised a very serious issue for large scale operations. I hope that everyone understands the value of these new attributes. I also hope you understand that they are optional and no implementation is required to add them. Note that the MUST's are only there if this new behavior is desired. =========================================================================== As operational experience is gained, it has become important for adminstrators to provide specific names to be used during tunnel authentication. The administration of a large network of tunnel clients (NAS) and tunnel servers becomes very onerous, difficult and error prone. This becomes even more difficult when an organization doesn't have full control over a subset of tunnel servers or clients, such as when they subcontract a portion of their network from third parties. Some providers are selling NAS ports to other parties which in turn buy NAS ports from multiple providers. In this situation, maintaining the authentication database for NAS<->tunnel servers becomes a time consuming and error prone task. These attributes provide the ability to specify a name to be used during tunnel authentication so that a smaller set of names needs to be maintained between any two such partners. These new attributes are intended to be used for authenticating the endpoints of the tunnel. They are not intended to be used for authenticating enduser sessions. Because multiple units within an administrative domain may use the same authentication name, these attributes are not globally unique and so they cannot be used to identify the tunnel for accounting and auditing purposes. Note that these attribute complement (and do not replace) the normal Tunnel-Server-Endpoint and Tunnel-Client-Endpoint attributes. 5.xx. Tunnel-Client-Auth-Id Description This attribute specifies the name used by the client end of the tunnel during the authentication phase of tunnel establishment. The Tunnel-Client-Auth-Id attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet and MUST be included in the Access-Accept packet if an authentication name different than the default is desired. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. A summary of the Tunnel-Client-Auth-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type xx for Tunnel-Client-Auth-Id. Length >= 3 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the value of the Tag field is less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains; otherwise, it SHOULD be interpreted as the first byte of the following String field. On Accounting-Request packets, the Tag field SHOULD be set to 0x00. String The String field contains the tunnel client authentication name in UTF-8 format. 5.xx. Tunnel-Server-Auth-Id Description This attribute specifies the name used by the server end of the tunnel during the authentication phase of tunnel establishment. The Tunnel-Server-Auth-Id attribute MAY be included (as a hint to the RADIUS server) in the Access-Request packet and MUST be included in the Access-Accept packet if an authentication name different than the default is desired. It SHOULD be included in Accounting-Request packets which contain Acct-Status-Type attributes with values of either Start or Stop and which pertain to a tunneled session. A summary of the Tunnel-Server-Auth-Id attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type xx for Tunnel-Server-Auth-Id. Length >= 3 Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the value of the Tag field is less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains; otherwise, it SHOULD be interpreted as the first byte of the following String field. On Accounting-Request packets, the Tag field SHOULD be set to 0x00. String The String field contains the tunnel server authentication name in UTF-8 format. Table of Attributes Access- Access- Access- Access- Acct- Request Accept Reject Challenge Request # Attribute 0-1 0-1 0 0 0-1 xx Tunnel-Client-Auth-Id 0-1 0-1 0 0 0-1 xx Tunnel-Server-Auth-Id Note: As for all tunneling attributes, a "1" occurance means "1-32" instances, each with different tag values. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu May 6 02:48:52 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 CAA19449 for ; Thu, 6 May 1999 02:48:52 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id XAA06100; Wed, 5 May 1999 23:42:25 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA05337 for ietf-radius-outgoing; Wed, 5 May 1999 23:46:45 -0700 (PDT) From: silvia_brown@usa.net Message-Id: <199905060641.XAA06092@bast.livingston.com> Subject: (radius) adv: Important Psychic Message For You... Date: Mon, 19 Apr 99 00:45:01 Pacific Daylight Time X-Mailer: Microsoft Outlook Express X-Priority: 3 X-MSMailPriority: Normal Importance: Normal Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: silvia_brown@usa.net LIVE PERSONAL PSYCHIC! (as seen on T.V.) LEARN TODAY WHAT YOUR FUTURE HOLDS FOR LOVE, MONEY, MARRIAGE, JOB, & HEALTH ASTROLOGY CLAIRVOYANCY NUMEROLOGY TAROT ALL QUESTIONS ANSWERED IMMEDIATELY! REALIZE YOUR DESTINY! CALL RIGHT NOW! 1-900-226-4140 or 1-800-372-3384 for VISA, MC, & AMEX (These are not sex lines!) This message is intended for Psychic Readers, Psychic Users and people who are involved in the $1 Billion a year Psychic Industry. If this message has reached you in error, please disregard it and accept our apoligies. To be removed from this list, please respond with the subject "remove". Thank You. LIVE PERSONAL PSYCHIC! (as seen on T.V.) LEARN TODAY WHAT YOUR FUTURE HOLDS FOR - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu May 6 12:26:24 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 MAA28606 for ; Thu, 6 May 1999 12:26:24 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA18641; Thu, 6 May 1999 09:19:28 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA02671 for ietf-radius-outgoing; Thu, 6 May 1999 09:18:18 -0700 (PDT) Message-ID: <19990506091747.B11045@corp.earthlink.net> Date: Thu, 6 May 1999 09:17:47 -0700 From: Mark S Petrovic To: ietf-radius@livingston.com Subject: (radius) The origin and use of NAS-Port-Type 11-14 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Mark S Petrovic draft-ietf-radius-radius-v2-00.txt lists 11 SDSL - Symmetric DSL 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 14 IDSL - ISDN Digital Subscriber Line among the values NAS-Port-Type may assume. I didn't see on the mailing list or minutes a discussion of these values and how a NAS (elegantly) comes to know one of them obtains. -- Mark S. Petrovic Earthlink Network - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu May 6 14:44:40 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 OAA01558 for ; Thu, 6 May 1999 14:44:36 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA26655; Thu, 6 May 1999 11:38:07 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA20000 for ietf-radius-outgoing; Thu, 6 May 1999 11:42:39 -0700 (PDT) Message-ID: <3731E258.DC28F302@globalone.net> Date: Thu, 06 May 1999 14:41:28 -0400 From: aleksey tolchinskiy Organization: Global One X-Sender: "aleksey tolchinskiy" X-Mailer: Mozilla 4.05 [en]C-G1.V2 (Win95; U) MIME-Version: 1.0 To: ietf-radius@livingston.com, leifer@del.com, acr@del.com, jas@shiva.com, glennz@microsoft.com Subject: (radius) tunnel password encryption Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: aleksey tolchinskiy Content-Transfer-Encoding: 7bit Gentlemen, My name is Aleksey Tolchinsky. I'm with Global One. I have a question regarding the section 5.5 of the draft-ietf-radius-tunnel-auth-06.txt. Is there a code doing the Tunnel Password encryption described in this section? Or do you have any information about existing versions of comercial Radius servers supporting it? Thanks in advance, Aleksey - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu May 6 15:49:15 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 PAA02547 for ; Thu, 6 May 1999 15:49:14 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA29608; Thu, 6 May 1999 12:42:01 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA26412 for ietf-radius-outgoing; Thu, 6 May 1999 12:46:22 -0700 (PDT) Message-Id: <3.0.5.32.19990506123954.00a7d4e0@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 06 May 1999 12:39:54 -0700 To: Matt Holdrege , Mike.Mun@BTNA.com From: Ignacio Goyret Subject: RE: (radius) update to tunnel draft Cc: ig@ascend.com, ietf-radius@livingston.com In-Reply-To: <3.0.5.32.19990505234825.00c10c20@porky.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ignacio Goyret At 11:48 PM 5/5/99 -0700, Matt Holdrege wrote: >What would happen in detail given the situation below? Hi Matt, In general, the Tunnel-*-Endpoint attributes are used to determine the address of the peer endpoint (eg, the IP address, PVC identifier, etc.), and potentially, the local address to be used. They are not intended to be used for tunnel authentication. The Tunnel-*-Auth-Id would be used by a tunnel endpoint as the identifier to the other tunnel endpoint during the authentication phase of tunnel establishment. Together with the Tunnel-Password, they provide the necessary details required for tunnel authentication. A NAS receiving an Access-Accept with a Tunnel-Client-Auth-Id could use that value as the identifier of the client endpoint when authenticating to the tunnel server endpoint (whose address may have been indicated on a Tunnel-Server-Endpoint attribute). A NAS could also use a Tunnel-Server-Auth-Id as the expected identifier from the tunnel server endpoint and potentially refuse the tunnel if the server responds with some other id. Hope this helps, -Ignacio >>From: "Mun, Mike" >>To: Matt Holdrege >>Subject: RE: (radius) update to tunnel draft >>Date: Wed, 5 May 1999 15:08:07 -0400 >>X-Mailer: Internet Mail Service (5.5.2448.0) >> >> >>Thank you for your reply. In that sense, I would assume that NAS and Tunnel >>Server use the AUTH-ID and Tunnel Password to do authentication. What would >>NAS and Tunnel server behave if both tunnel endpoints and tunnel-auth-ids >>attributes are presented in an access accept packet? >> >> >>Mike >> ---------- >> From: Matt Holdrege [SMTP:matt@ascend.com] >> Sent: Wednesday, May 05, 1999 2:44 PM >> To: Mun, Mike >> Subject: RE: (radius) update to tunnel draft >> >> Yes, they may be used for tunnel auth to complement the existing >> endpoints. >> >> >> At 11:44 AM 5/5/99 -0400, Mun, Mike wrote: >> >Hello, Matt, >> > >> >I think your message could be a very good point to ease the >> >administration burden of a ISP. Are you saying that these two >> >attribtues can be used in absence of the tunnel end points, >> >so the tunnul client and server authenticate each other using >> >these two attributes instead? >> > >> >Your reply will be appreciated. >> > >> >Mike - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri May 7 11:03: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 LAA02952 for ; Fri, 7 May 1999 11:03:12 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA03106; Fri, 7 May 1999 07:55:19 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA04256 for ietf-radius-outgoing; Fri, 7 May 1999 07:56:54 -0700 (PDT) Message-ID: <003301be9899$0092ee00$0103a8c0@ds9> From: "Darran Potter" To: Subject: (radius) Status of the tunnel draft? Date: Fri, 7 May 1999 15:50:41 +0100 Organization: Cisco Systems Inc MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 Whats the current status of the tunnel auth (6) acct (2) drafts? Are we due any updates soon? Thanks Darran - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 06:13: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 GAA23768 for ; Tue, 11 May 1999 06:13:12 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id DAA04918; Tue, 11 May 1999 03:06:25 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA15139 for ietf-radius-outgoing; Tue, 11 May 1999 03:09:02 -0700 (PDT) Message-Id: <199905110604.OAA17270@mail> From: "Penny" Subject: (radius) Before you go To: officeman20ik@claramail.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Mon, 10 May 1999 23:28:14 -0500 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Penny" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA23768 Office chairs and furniture at just above dealer cost it is now available to you. You won't find lower prices. All products shipped directly to you from the distributor with giant savings. Just reply to: mailto:hhbk@mailme.net?subject=WHOLESALE to receive our free information. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ If you wish to be removed reply to: mailto:nothanks@dbzmail.com?subject=remove /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 16:40:04 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 QAA04160 for ; Tue, 11 May 1999 16:40:02 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA25699; Tue, 11 May 1999 13:33:00 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA08331 for ietf-radius-outgoing; Tue, 11 May 1999 13:36:44 -0700 (PDT) From: Aydin Edguer Message-Id: <199905112034.QAA03125@harlequin.MorningStar.Com> Subject: RE: (radius) update to tunnel draft To: ietf-radius@livingston.com Date: Tue, 11 May 1999 16:34:07 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] 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: Aydin Edguer Content-Transfer-Encoding: 7bit > >>Thank you for your reply. In that sense, I would assume that NAS and Tunnel > >>Server use the AUTH-ID and Tunnel Password to do authentication. What would > >>NAS and Tunnel server behave if both tunnel endpoints and tunnel-auth-ids > >>attributes are presented in an access accept packet? If the NAS/Tunnel-Client received both the *-Server-Endpoint and the *-Client-Auth-Id then it would open a connection to the Endpoint and identify itself as the Auth-Id. If the NAS/Tunnel-Client received the *-Server-Endpoint and both the *-Auth-Ids then it would open a connection to the Endpoint and identify identify itself as the *-Client-Auth-Id and expect the Server to identify itself as the *-Server-Auth-Id. If the NAS/Tunnel-Client received all four attributes then (a) it would need some method external to RADIUS to determine that it was supposed to be the Tunnel-Client (if it supported both Client and Server modes) and then (b) it would open a connection to the *-Server-Endpoint using as the local address the *-Client-Endpoint and identify identify itself as the *-Client-Auth-Id and expect the Server to identify itself as the *-Server-Auth-Id. Note that the "external method" could be simply the context that caused the initial Access-Request to be sent. If the NAS sent an Access-Request, presumably it was due to an incoming call or some sort of outgoing call request. In either case, the decision will probably be obvious and will not need anything other information to decide. It might however be a configuration parameter on the NAS. > >> >I think your message could be a very good point to ease the > >> >administration burden of a ISP. Are you saying that these two > >> >attribtues can be used in absence of the tunnel end points, > >> >so the tunnul client and server authenticate each other using > >> >these two attributes instead? No, they cannot typically be used in the absence of the *-Endpoint information, because they are for use only for tunnel authentication and accounting. Without the appropriate *-Endpoint information, there is no way to know *where* (example: IP address) to connect. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 17:58:10 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 RAA04610 for ; Tue, 11 May 1999 17:58:09 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA28830; Tue, 11 May 1999 14:51:28 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA18720 for ietf-radius-outgoing; Tue, 11 May 1999 14:56:22 -0700 (PDT) Message-ID: <29752A74B6C5D211A4920090273CA3DC57970D@new-exc1.ctron.com> From: "Waters, Stephen" To: ietf-radius@livingston.com Subject: (radius) Tunnel-Private-Group-ID Date: Tue, 11 May 1999 22:52:46 +0100 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: "Waters, Stephen" Hi, I am looking to use the RADIUS database to hold information on which authentication method is needed for a tunnel client. I am thinking more for the 'Voluntary' tunnel mode. The idea is that I do a tunnel 'authentication' phase using : Access-Request / Tunnel-Client-Endpoint Access-Accept / Tunnel-Password + Tunnel-Private-Group-ID and I use the 'Tunnel-Private-Group-ID' string to indicate which class of user authentication is needed, e.g. CHAP, OTP, etc. Is this an acceptable use of Tunnel-Private-Group-ID? Thanks, Steve. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 19:00:16 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 TAA04900 for ; Tue, 11 May 1999 19:00:16 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA01666; Tue, 11 May 1999 15:53:47 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA25444 for ietf-radius-outgoing; Tue, 11 May 1999 15:58:26 -0700 (PDT) Date: Tue, 11 May 1999 15:58:25 -0700 (PDT) Message-Id: <199905112258.PAA25436@server.livingston.com> To: ietf-radius@livingston.com From: majordomo@livingston.com Subject: (radius) Welcome to bounces Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: majordomo@livingston.com -- Welcome to the bounces mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, send the following command in email to : unsubscribe Or you can send mail to with the following command in the body of your email message: unsubscribe bounces or from another account, besides ietf-radius (990511 portmaster-users): unsubscribe bounces ietf-radius (990511 portmaster-users) If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: For addresses bouncing from the majordomo@livingston.com list server - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 19:00:35 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 TAA04910 for ; Tue, 11 May 1999 19:00:35 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA01692; Tue, 11 May 1999 15:53:54 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA25469 for ietf-radius-outgoing; Tue, 11 May 1999 15:58:33 -0700 (PDT) Date: Tue, 11 May 1999 15:58:32 -0700 (PDT) Message-Id: <199905112258.PAA25463@server.livingston.com> To: ietf-radius-digest@livingston.com From: majordomo@livingston.com Subject: (radius) Welcome to bounces Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: majordomo@livingston.com -- Welcome to the bounces mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, send the following command in email to : unsubscribe Or you can send mail to with the following command in the body of your email message: unsubscribe bounces or from another account, besides ietf-radius-digest (990511 portmaster-users): unsubscribe bounces ietf-radius-digest (990511 portmaster-users) If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: For addresses bouncing from the majordomo@livingston.com list server - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 19:03:50 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 TAA04987 for ; Tue, 11 May 1999 19:03:49 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA02224; Tue, 11 May 1999 15:57:20 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA26223 for ietf-radius-outgoing; Tue, 11 May 1999 16:02:22 -0700 (PDT) Date: Tue, 11 May 1999 15:57:41 -0700 (PDT) Message-Id: <199905112257.PAA25314@server.livingston.com> To: bounces@livingston.com From: majordomo@livingston.com Subject: (radius) Welcome to bounces Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: majordomo@livingston.com -- Welcome to the bounces mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, send the following command in email to : unsubscribe Or you can send mail to with the following command in the body of your email message: unsubscribe bounces or from another account, besides bounces (990511 portmaster-users): unsubscribe bounces bounces (990511 portmaster-users) If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: For addresses bouncing from the majordomo@livingston.com list server - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 19:05:46 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 TAA05002 for ; Tue, 11 May 1999 19:05:45 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA02551; Tue, 11 May 1999 15:59:13 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA26564 for ietf-radius-outgoing; Tue, 11 May 1999 16:04:17 -0700 (PDT) Date: Tue, 11 May 1999 15:57:41 -0700 (PDT) Message-Id: <199905112257.PAA25314@server.livingston.com> To: bounces@livingston.com From: majordomo@livingston.com Subject: (radius) Welcome to bounces Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: majordomo@livingston.com -- Welcome to the bounces mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, send the following command in email to : unsubscribe Or you can send mail to with the following command in the body of your email message: unsubscribe bounces or from another account, besides bounces (990511 portmaster-users): unsubscribe bounces bounces (990511 portmaster-users) If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: For addresses bouncing from the majordomo@livingston.com list server - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 19:07: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 TAA05033 for ; Tue, 11 May 1999 19:07:40 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA03081; Tue, 11 May 1999 16:01:17 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA26995 for ietf-radius-outgoing; Tue, 11 May 1999 16:06:20 -0700 (PDT) Date: Tue, 11 May 1999 15:57:41 -0700 (PDT) Message-Id: <199905112257.PAA25314@server.livingston.com> To: bounces@livingston.com From: majordomo@livingston.com Subject: (radius) Welcome to bounces Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: majordomo@livingston.com -- Welcome to the bounces mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, send the following command in email to : unsubscribe Or you can send mail to with the following command in the body of your email message: unsubscribe bounces or from another account, besides bounces (990511 portmaster-users): unsubscribe bounces bounces (990511 portmaster-users) If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: For addresses bouncing from the majordomo@livingston.com list server - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 19:09:37 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 TAA05064 for ; Tue, 11 May 1999 19:09:37 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA03479; Tue, 11 May 1999 16:03:13 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA27347 for ietf-radius-outgoing; Tue, 11 May 1999 16:08:16 -0700 (PDT) Date: Tue, 11 May 1999 15:57:41 -0700 (PDT) Message-Id: <199905112257.PAA25314@server.livingston.com> To: bounces@livingston.com From: majordomo@livingston.com Subject: (radius) Welcome to bounces Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: majordomo@livingston.com -- Welcome to the bounces mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, send the following command in email to : unsubscribe Or you can send mail to with the following command in the body of your email message: unsubscribe bounces or from another account, besides bounces (990511 portmaster-users): unsubscribe bounces bounces (990511 portmaster-users) If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: For addresses bouncing from the majordomo@livingston.com list server - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 19:13:37 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 TAA05105 for ; Tue, 11 May 1999 19:13:36 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA04348; Tue, 11 May 1999 16:07:03 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA28091 for ietf-radius-outgoing; Tue, 11 May 1999 16:12:06 -0700 (PDT) Date: Tue, 11 May 1999 15:57:41 -0700 (PDT) Message-Id: <199905112257.PAA25314@server.livingston.com> To: bounces@livingston.com From: majordomo@livingston.com Subject: (radius) Welcome to bounces Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: majordomo@livingston.com -- Welcome to the bounces mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, send the following command in email to : unsubscribe Or you can send mail to with the following command in the body of your email message: unsubscribe bounces or from another account, besides bounces (990511 portmaster-users): unsubscribe bounces bounces (990511 portmaster-users) If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: For addresses bouncing from the majordomo@livingston.com list server - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 19:16:43 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 TAA05146 for ; Tue, 11 May 1999 19:16:42 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA03977; Tue, 11 May 1999 16:05:11 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA27772 for ietf-radius-outgoing; Tue, 11 May 1999 16:10:14 -0700 (PDT) Date: Tue, 11 May 1999 15:57:41 -0700 (PDT) Message-Id: <199905112257.PAA25314@server.livingston.com> To: bounces@livingston.com From: majordomo@livingston.com Subject: (radius) Welcome to bounces Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: majordomo@livingston.com -- Welcome to the bounces mailing list! Please save this message for future reference. Thank you. If you ever want to remove yourself from this mailing list, send the following command in email to : unsubscribe Or you can send mail to with the following command in the body of your email message: unsubscribe bounces or from another account, besides bounces (990511 portmaster-users): unsubscribe bounces bounces (990511 portmaster-users) If you ever need to get in contact with the owner of the list, (if you have trouble unsubscribing, or have questions about the list itself) send email to . This is the general rule for most mailing lists when you need to contact a human. Here's the general information for the list you've subscribed to, in case you don't already have it: For addresses bouncing from the majordomo@livingston.com list server - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 11 19:35:36 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 TAA05297 for ; Tue, 11 May 1999 19:35:35 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA06122; Tue, 11 May 1999 16:24:00 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA00389 for ietf-radius-outgoing; Tue, 11 May 1999 16:28:58 -0700 (PDT) Message-ID: <3738BDC4.E335ECE1@livingston.com> Date: Tue, 11 May 1999 16:31:16 -0700 From: Thomas C Kinnen Organization: Lucent RABU X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com, nat@livingston.com Subject: (radius) Bounces Messages Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Thomas C Kinnen Content-Transfer-Encoding: 7bit I'm looking into the cause of the bounces messages. Tom - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed May 12 06:22:44 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 GAA23065 for ; Wed, 12 May 1999 06:22:44 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id DAA16622; Wed, 12 May 1999 03:16:02 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA25231 for ietf-radius-outgoing; Wed, 12 May 1999 03:18:54 -0700 (PDT) Date: Wed, 12 May 1999 03:18:52 -0700 (PDT) From: Carl Rigney Message-Id: <199905121018.DAA25225@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) WG LAST CALL for RADIUS, Accounting, Extensions Cc: randy@psg.com, wijnen@VNET.IBM.COM Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney This is the IETF RADIUS Working Group Last Call for draft-ietf-radius-radius-v2-01.txt "RADIUS" to advance to Draft Standard, replacing RFC 2138 draft-ietf-radius-accounting-v2-01.txt "RADIUS Accounting" as Informational, replacing RFC 2139 draft-ietf-radius-ext-04.txt "RADIUS Extensions" as Informational These are available now in ftp://ftp.livingston.com/pub/radius/ and will be available in all the usual Internet-Drafts locations within a day or so. If you have any comments please submit them to the editor (cdr@livingston.com) or to the ietf-radius mailing list by 5pm EDT May 26, 1999. -- Carl Rigney IETF RADIUS Working Group Chair cdr@livingston.com "It doesn't have to finish but it has to stop." -- Mike O'Dell - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed May 12 06:58:14 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 GAA23258 for ; Wed, 12 May 1999 06:58:13 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id DAA17046; Wed, 12 May 1999 03:51:44 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA26334 for ietf-radius-outgoing; Wed, 12 May 1999 03:56:47 -0700 (PDT) Date: Wed, 12 May 1999 03:56:45 -0700 (PDT) From: Carl Rigney Message-Id: <199905121056.DAA26327@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Milestones Updated Cc: randy@psg.com, wijnen@VNET.IBM.COM Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Now that everything's in the pipeline, here's the updated milestones. An archive of recent mail to ietf-radius is available in ftp://ftp.livingston.com/pub/radius/archive/ The RADIUS Working Group has no further meetings scheduled. Subject: IETF RADIUS Working Group Charter Remote Authentication Dial-In User Service (RADIUS) Operational Requirements Directorate Working Group Charter (created 95/6/12, last update 99/5/12) It was decided at the RADIUS BOF held 4 April 1995 at the 32nd IETF in Danvers, Massachusetts that a RADIUS Working Group should be formed. Before taking an active role in the Working Group the Chair requests that anyone who has not recently read RFC 1718 "The Tao of IETF" and RFC 1602 "The Internet Standards Process -- Revision 2" please take a moment to do so. For your convenience copies of both are available from ftp://ftp.livingston.com/pub/radius/rfc1602 and rfc1718 for easy retrieval. Goals: The working group produced RFC 2138 "RADIUS" as a proposed standard and RFC 2139 "RADIUS Accounting" as informational in April 1997. The end purpose of this group is to produce the following documents: 1) A full standard RFC documenting the RADIUS protocol already deployed for use by a Network Access Server (NAS) to communicate with a remote Authentication & Authorization database server, with minor amendments reflecting field experience of several implementations over several years at thousands of sites. 2) An informational RFC describing RADIUS Accounting. 3) An informational RFC for RADIUS Extensions documenting extensions for additional functionality within the RADIUS framework, which will be interoperable with the base RADIUS defined in the document for goal 1. 4-5) Two standard RFCs documenting SNMP MIBs for RADIUS clients and servers. 6-7) Two informational RFCs documenting SNMP MIBs for RADIUS Accounting clients and servers. 8-9) Two standard RFCs documenting RADIUS use for Tunneling. 10) One informational RFC documenting RADIUS accounting use for Tunneling. 11) An informational memo documenting independent interoperable implementations in support of item 1's advancement to draft standard. 12) An informational memo providing guidance to the IANA in allocating numbers in the RADIUS attributes and values, in support of item 1's advancement to full standard. Current Status: All current drafts are available on ftp://ftp.livingston.com/pub/radius and the usual Internet-Drafts directories, as listed in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt These drafts went to working group last call 1999/5/12, due 5/26. draft-ietf-radius-accounting-v2-01.txt RADIUS Accounting draft-ietf-radius-ext-04.txt RADIUS Extensions draft-ietf-radius-radius-v2-01.txt RADIUS These drafts have already been through working group last call and are being edited to address IESG concerns, at which point they can go to IETF last call: draft-ietf-radius-tunnel-acct-03.txt draft-ietf-radius-tunnel-auth-06.txt draft-ietf-radius-tunnel-imp-04.txt These drafts have been through IETF last call and the IESG and are in the RFC Editor's queue. draft-ietf-radius-acc-clientmib-05.txt draft-ietf-radius-acc-servmib-05.txt draft-ietf-radius-auth-clientmib-05.txt draft-ietf-radius-auth-servmib-05.txt Milestones: 1999 June - All documents through last call and to the RFC Editor 1999 October - RADIUS submitted for Full Standard 1999 December - Documents that were proposed drafts in June submitted as draft standards 2000 April - Documents that were draft standards in December submitted as full standards. Working group concludes. Scope: The intent in goals 1 and 2 are to document the protocol as it exists and is used currently, in such a way as to allow interoperable implementations to be written from the RFC. Minor modifications to enhance interoperability or operation based on field experience are suitable, major overhauls are outside the scope of this working group's charter. Goals 3 through 10 are to provide a mechanism for additional features deemed widely useful to be added to the existing framework, for example to provide better support for EAP and L2TP. Clearly outside the scope of the charter are the following: 1) NAS Standardization is outside the scope. We're defining standard RADIUS, not a standard encompassing everything about network access servers. This effort does not require NASes to implement RADIUS; it just defines how the RADIUS Protocol works on NASes that do implement RADIUS. 2) RADIUS is not intended as a NAS management protocol, SNMP already exists for that. 3) Management of the Authentication/Authorization database itself is outside the scope. 4) Alternative transport protocols such as IPX or IPv6 appear straightforward, but will not be addressed in this effort. 5) The flexibility and generality of RADIUS have led to its use for other applications, but this Working Group is addressing only those uses involving user dial-in to Network Access Servers. Background: The original specification for and implementation of RADIUS was written by Steve Willens of Livingston Enterprises in response to a need outlined by the earlier NASREQ working group, and has been deployed by multiple vendors over the past 6 years. No other working group appears to be addressing the topic of communicating authentication and authorization information between a Network Access Server and a central authentication & authorization server, and general consensus is that standardization of such a protocol would be extremely useful. Mailing List: ietf-radius@livingston.com To join, send email to ietf-radius-request@livingston.com with "subscribe" in the body of the message. Archives and working documents directory (updated monthly): ftp://ftp.livingston.com/pub/radius/ Document Editor Carl Rigney Livingston Enterprises cdr@livingston.com For RADIUS MIBs contact: Bernard Aboba Internaut Books aboba@internaut.com Glen Zorn Microsoft Corporation glennz@microsoft.com For RADIUS Tunneling contact: Bernard Aboba Internaut Books aboba@internaut.com Dave Mitton Nortel Networks dmitton@nortelnetworks.com Glen Zorn Microsoft Corporation glennz@microsoft.com Working Group Chair: Carl Rigney Livingston Enterprises 4464 Willow Road; Pleasanton, CA 94588 cdr@livingston.com 925-737-2100 -- ietf-radius-request@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu May 13 12:51:46 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 MAA06535 for ; Thu, 13 May 1999 12:51:46 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA29790; Thu, 13 May 1999 09:44:12 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA29188 for ietf-radius-outgoing; Thu, 13 May 1999 09:45:05 -0700 (PDT) Message-Id: <199905131219.IAA29874@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-accounting-v2-01.txt Date: Thu, 13 May 1999 08:19:13 -0400 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Accounting Author(s) : C. Rigney Filename : draft-ietf-radius-accounting-v2-01.txt Pages : 28 Date : 12-May-99 This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-accounting-v2-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-accounting-v2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-accounting-v2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990512113835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-accounting-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-accounting-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990512113835.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu May 13 12:59: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 MAA06677 for ; Thu, 13 May 1999 12:59:40 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA00228; Thu, 13 May 1999 09:52:41 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA01119 for ietf-radius-outgoing; Thu, 13 May 1999 09:57:37 -0700 (PDT) Message-Id: <199905131249.IAA00564@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-radius-v2-01.txt Date: Thu, 13 May 1999 08:49:49 -0400 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : Remote Authentication Dial In User Service (RADIUS) Author(s) : A. Rubens, W. Simpson, S. Willens, C. Rigney Filename : draft-ietf-radius-radius-v2-01.txt Pages : 75 Date : 12-May-99 This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-radius-v2-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-radius-v2-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-radius-v2-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990512113915.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-radius-v2-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-radius-v2-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990512113915.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu May 13 13:00:22 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 NAA06705 for ; Thu, 13 May 1999 13:00:21 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA00253; Thu, 13 May 1999 09:52:47 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA01104 for ietf-radius-outgoing; Thu, 13 May 1999 09:57:34 -0700 (PDT) Message-Id: <199905131249.IAA00547@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-ext-04.txt Date: Thu, 13 May 1999 08:49:43 -0400 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Extensions Author(s) : C. Rigney, P. Calhoun, W. Willats Filename : draft-ietf-radius-ext-04.txt Pages : 47 Date : 12-May-99 This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2138 and RFC 2139. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-ext-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-ext-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-ext-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990512113854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-ext-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-ext-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990512113854.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu May 13 22:23:20 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 WAA12736 for ; Thu, 13 May 1999 22:23:19 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id TAA16811; Thu, 13 May 1999 19:03:53 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA25948 for ietf-radius-outgoing; Thu, 13 May 1999 19:08:33 -0700 (PDT) Message-Id: <3.0.5.32.19990513190335.00cdc330@porky.ascend.com> X-Sender: mhold@porky.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 13 May 1999 19:03:35 -0700 To: Carl Rigney From: Matt Holdrege Subject: Re: (radius) Milestones Updated Cc: ietf-radius@livingston.com, randy@psg.com, wijnen@VNET.IBM.COM In-Reply-To: <199905121056.DAA26327@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege At 03:56 AM 5/12/99 -0700, Carl Rigney wrote: >These drafts have already been through working group last call and >are being edited to address IESG concerns, at which point they can >go to IETF last call: > >draft-ietf-radius-tunnel-acct-03.txt >draft-ietf-radius-tunnel-auth-06.txt >draft-ietf-radius-tunnel-imp-04.txt Wait a minute! Didn't you see my email bringing up a significant problem with the tunnel attributes? And the solution too? I don't believe these drafts ever passed WG last call. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu May 13 22:28:21 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 WAA12752 for ; Thu, 13 May 1999 22:28:20 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id TAA16699; Thu, 13 May 1999 19:02:28 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA25838 for ietf-radius-outgoing; Thu, 13 May 1999 19:05:59 -0700 (PDT) Message-Id: <3.0.5.32.19990513190114.00c0c330@porky.ascend.com> X-Sender: mhold@porky.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 13 May 1999 19:01:14 -0700 To: ietf-ppp@merit.edu, ietf-radius@livingston.com From: Matt Holdrege Subject: (radius) AO/DI Radius attributes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege Hi, Not having any comments on AO/DI except to ask for Radius attributes, I'm inclined to ask the PPPEXT chair to take it to last call. But what about the RADIUS attributes? We've defined our own VSA's. But it certainly would be nice to have a standard set. What do people think? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon May 17 10:11:52 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 KAA25763 for ; Mon, 17 May 1999 10:11:51 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA18182; Mon, 17 May 1999 07:04:55 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA12025 for ietf-radius-outgoing; Mon, 17 May 1999 07:05:21 -0700 (PDT) Message-ID: <004501bea06d$ca679ce0$0103a8c0@ds9> From: "Darran Potter" To: Subject: (radius) Ascend-Send-Secret Date: Mon, 17 May 1999 15:01:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 Obviously this is highly vendor specific, but does anyone know how this attribute is encrypted/encoded.... the same as User-Password?? Offline replies are fine... Thanks Daz - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon May 17 13:27:50 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 NAA01984 for ; Mon, 17 May 1999 13:27:50 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA24936; Mon, 17 May 1999 10:20:55 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA02252 for ietf-radius-outgoing; Mon, 17 May 1999 10:24:39 -0700 (PDT) Message-Id: <3.0.5.32.19990517101747.00b53720@scamp.eng.ascend.com> X-Sender: igoyret@scamp.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 17 May 1999 10:17:47 -0700 To: "Darran Potter" From: Ignacio Goyret Subject: Re: (radius) Ascend-Send-Secret Cc: ietf-radius@livingston.com In-Reply-To: <004501bea06d$ca679ce0$0103a8c0@ds9> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ignacio Goyret At 03:01 PM 5/17/99 +0100, Darran Potter wrote: >Obviously this is highly vendor specific, but does anyone know how this >attribute is encrypted/encoded.... the same as User-Password?? Yes. An example can be found on the sample radius server in ftp://ftp.ascend.com/pub/Software-Releases/Radius/Current/radius-980618.tar.gz -Ignacio - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon May 17 13:52: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 NAA02309 for ; Mon, 17 May 1999 13:52:37 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA25799; Mon, 17 May 1999 10:46:00 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA05559 for ietf-radius-outgoing; Mon, 17 May 1999 10:50:52 -0700 (PDT) From: "Yong Li" To: "Ietf-Radius" Subject: (radius) Class attribute Date: Mon, 17 May 1999 13:46:48 -0400 Message-Id: <000201bea08d$3cbd3ba0$3396a8c0@bridgewatersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Yong Li" Content-Transfer-Encoding: 7bit In the latest draft: draft-ietf-radius-raidus-v2-01.txt The description for Class attribute: This Attribute is available to be sent by the server to the client in an Access-Accept and "SHOULD" be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported. The client MUST NOT interpret the attribute locally. Notice here the behavior of the NAS has been changed from MUST to SHOULD. Is there any reason for this? In a previous section (2.3): A forwarding server MUST not modify existing Proxy-State, State, or Class attributes present in the packet. What good will this do if the NAS does not send back the Class attribute? Yong Li Software Designer Bridgewater Systems Corp. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue May 18 16:47:43 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 QAA15781 for ; Tue, 18 May 1999 16:47:42 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA06145; Tue, 18 May 1999 13:39:38 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA23373 for ietf-radius-outgoing; Tue, 18 May 1999 13:41:26 -0700 (PDT) Message-ID: <783D93998201D311B0CF00805FEAA07B6B1762@RED-MSG-42> From: Ashwin Palekar To: Ietf-Radius Subject: (radius) NAS expects RADIUS server to return Hints sent in access request? Date: Tue, 18 May 1999 13:40:21 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ashwin Palekar I was told that some NASes actually expect that the attributes it sent to the RADIUS server as hint in the access request should be returned in the access accept. In this particular case, the NAS/VPN server (don't want to use the vendor's name) sends a Tunnel-Name "VSA" to the RADIUS server, and expects the RADIUS server to return it back in the response. This is not consistent with what the RFC says. The RADIUS RFC states that "An Access-Request MAY contain additional attributes as a hint to the server, but the server is not required to honor the hint.". What is the right behavior for a RADIUS server? and are there any other NASes around which expect the RADIUS server to always return back the hints in the access accept? Ashwin Palekar - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri May 28 10:50:19 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 KAA27399 for ; Fri, 28 May 1999 10:50:18 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA07637; Fri, 28 May 1999 07:42:44 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA16568 for ietf-radius-outgoing; Fri, 28 May 1999 07:45:28 -0700 (PDT) Message-Id: <4.1.19990528103146.01d36990@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 28 May 1999 10:35:44 -0400 To: ietf-radius@livingston.com From: Dave Mitton Subject: Re: (radius) NAS expects RADIUS server to return Hints sent in access request? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton I aggree with you on this. The RFC says nothing about it, and I'm pretty sure that Livingston's original "reference" server did no such thing. The Merit server, might due to how it internally handles attributes. Ours does not, but you can flag any attributes in a return list with "Echo" behavior. That is they will echo the Access-Accept value. That would prempt any ability to set the attribute value for that user. Dave. At 08:40 PM 5/18/99 +0000, you wrote: >I was told that some NASes actually expect that the attributes it sent to >the RADIUS server as hint in the access request should be returned in the >access accept. > >In this particular case, the NAS/VPN server (don't want to use the vendor's >name) sends a Tunnel-Name "VSA" to the RADIUS server, and expects the RADIUS >server to return it back in the response. This is not consistent with what >the RFC says. The RADIUS RFC states that "An Access-Request MAY contain >additional attributes as a hint to the server, but the server is not >required to honor the hint.". > >What is the right behavior for a RADIUS server? and are there any other >NASes around which expect the RADIUS server to always return back the hints >in the access accept? > >Ashwin Palekar > > > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > --------------------------------------------------------------- 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.