From owner-ietf-radius@livingston.com Fri Oct 1 11:54: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 LAA17650 for ; Fri, 1 Oct 1999 11:54:36 -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 IAA03450; Fri, 1 Oct 1999 08:51:43 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA27049 for ietf-radius-outgoing; Fri, 1 Oct 1999 08:48:56 -0700 (PDT) From: "Bernard Aboba" To: "'Carl Rigney'" Cc: Subject: (radius) Last call for RADIUS extensions draft? Date: Fri, 1 Oct 1999 08:44:16 -0700 Message-ID: <003c01bf0c23$d2020680$478939cc@internaut.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 CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.5400 In-Reply-To: <199909291424.HAA11521@hsmpka.eng.sun.com> Importance: Normal Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit Has the RADIUS extensions draft gone to last call? If not, when will this occur? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Oct 8 20:30: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 UAA02867 for ; Fri, 8 Oct 1999 20:30:21 -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 RAA14017; Fri, 8 Oct 1999 17:27:05 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA05066 for ietf-radius-outgoing; Fri, 8 Oct 1999 17:23:22 -0700 (PDT) Message-ID: <19991008172254.C11560@corp.earthlink.net> Date: Fri, 8 Oct 1999 17:22:54 -0700 From: Mark S Petrovic To: ietf-radius@livingston.com Subject: (radius) Extending the values of NAS-Port-Type 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 As high-speed access methods emerge and become commonplace, network providers become interested in denoting access methods not listed in draft-ietf-radius-radius-v2-01.txt. We wish to propose three new values of the NAS-Port-Type attribute: "xDSL", "cable", and "wireless". draft-ietf-radius-radius-v2-01.txt already includes specific DSL varieties, such as ADSL and SDSL. However, we envision situations where knowledge of the specific DSL variety is not available to the NAS, but where nonetheless "xDSL" might be indicated based on the NAS configuration and the physical circuit bearing the session. "cable" and "wireless" would be applied to users gaining network access through traditional CATV systems and wireless devices, respectively. -- Mark S. Petrovic EarthLink Network, Inc. Pasadena, CA - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Oct 8 20:32:01 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 UAA02933 for ; Fri, 8 Oct 1999 20:32:00 -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 RAA14095; Fri, 8 Oct 1999 17:29:02 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA05324 for ietf-radius-outgoing; Fri, 8 Oct 1999 17:29:56 -0700 (PDT) Date: Fri, 8 Oct 1999 17:29:54 -0700 (PDT) From: Carl Rigney Message-Id: <199910090029.RAA05317@server.livingston.com> To: petrovic@corp.earthlink.net Subject: Re: (radius) Extending the values of NAS-Port-Type Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Those make sense. Are there any specific forms of cable or wireless that should be added as well as the generic versions? -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Oct 9 14:31:34 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 OAA21748 for ; Sat, 9 Oct 1999 14:31:33 -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 LAA23609; Sat, 9 Oct 1999 11:28:30 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA28957 for ietf-radius-outgoing; Sat, 9 Oct 1999 11:27:37 -0700 (PDT) Message-ID: <19991009112710.B12729@corp.earthlink.net> Date: Sat, 9 Oct 1999 11:27:10 -0700 From: Mark S Petrovic To: Carl Rigney Cc: ietf-radius@livingston.com Subject: Re: (radius) Extending the values of NAS-Port-Type References: <199910090029.RAA05317@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2 In-Reply-To: <199910090029.RAA05317@server.livingston.com>; from Carl Rigney on Fri, Oct 08, 1999 at 05:29:54PM -0700 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Mark S Petrovic On 8Oct, Carl Rigney wrote: > Those make sense. Are there any specific forms of cable or wireless > that should be added as well as the generic versions? I cannot think of specific refinements for either one at this time. As technologies evolve, and our ability to discern when one of them obtains, perhaps they could be added. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Oct 12 02:34: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 CAA05850 for ; Tue, 12 Oct 1999 02:34:39 -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 XAA06642; Mon, 11 Oct 1999 23:31:41 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA18434 for ietf-radius-outgoing; Mon, 11 Oct 1999 23:29:18 -0700 (PDT) Date: Mon, 11 Oct 1999 23:29:15 -0700 (PDT) From: Carl Rigney Message-Id: <199910120629.XAA18427@server.livingston.com> To: Pat.Calhoun@eng.sun.com Subject: Re: (radius) RADIUS ver 2 Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney it having *some* intermediate nodes within a proxy chain perform their own retransmission, while others do not *will* cause problems in the network. Why? Either you pass things through as you get them, or you take responsibility and use your own retransmit policy because you know best (but keeping in mind that if its an access-request, you have a limited time budget to work with). It seems a very reasonable thing to have implementations experiment with, and if someone comes up with a method that is superior, they can publish it and people can adopt that. I would love to see people do some real testing and verification of retransmit strategies and publish ideas on the topic, the way Van Jacobson did with TCP windowing. In most cases Proxy shouldn't need more than 2 hops anyway (I can see three, but more than that strikes me as likely to be the result of poor network design). We have lots of people using Proxy with no reported problems. I'd be very interested in hearing from anyone who has operational experience with RADIUS proxy and is running into any problems. The whole premise behind RADIUS servers in the past was that they were largely stateless. And RADIUS servers in the past didn't do proxy. If you want a proxy-capable RADIUS server to be able to forward requests to older RADIUS servers that don't do Proxy (that is, that don't copy the Proxy-State attribute from request to response), then the forwarding server has to cache any existing Proxy-States and reattach them when the reply comes back. We may both agree that this is not an ideal thing to do, but if done properly it works very well, and allows interoperability with existing RADIUS implementations without requiring that everyone upgrade at once. Also, RADIUS accounting seems to require maintaining state when doing proxy, unless someone's come up with a stateless way of dealing with the Response Authenticator (if so, I'd love to hear about it!). And many implementers who are dealing with high volumes of RADIUS accounting packets may wish to cache them securely on an intermediate RADIUS server and ack them to the NAS, to free up the (typically very small) buffer memory on the NAS in the case of extended outages on the network or final accounting server. 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. Ah! I wasn't aware the EAP draft changed so that EAP-Start is no longer zero length. In that case I can change the RADIUS Extensions draft attribute 79 to replace > Length > >= 3 (EAP packet enclosed) > = 2 (EAP-Start message) With simply: Length >= 3 So that it's consistent with the draft-ietf-radius-radius-v2-01.txt requirement that all attribute lengths be 3 or greater. Excellent. If you see anywhere else in the 3 drafts where an empty attribute is permitted, please point it out to me; there are not supposed to be any. -- Carl Rigney 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 Tue Oct 12 02:40:55 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 CAA05914 for ; Tue, 12 Oct 1999 02:40:54 -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 XAA06778; Mon, 11 Oct 1999 23:37:58 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA18652 for ietf-radius-outgoing; Mon, 11 Oct 1999 23:38:57 -0700 (PDT) Date: Mon, 11 Oct 1999 23:38:55 -0700 (PDT) From: Carl Rigney Message-Id: <199910120638.XAA18645@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) 3 more values for NAS-Port-Type Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Mark Petrovic has suggested adding: > We wish to propose three new values of the NAS-Port-Type attribute: > "xDSL", "cable", and "wireless". > >draft-ietf-radius-radius-v2-01.txt already includes specific DSL >varieties, such as ADSL and SDSL. However, we envision situations >where knowledge of the specific DSL variety is not available to the >NAS, but where nonetheless "xDSL" might be indicated based on the NAS >configuration and the physical circuit bearing the session. > >"cable" and "wireless" would be applied to users gaining network access >through traditional CATV systems and wireless devices, respectively. I asked him if there were subcategories of cable or wireless but he thought not, so I propose adding the following values to NAS-Port-Type: 16 xDSL - Digital Subscriber Line of unknown type 17 Cable 18 Wireless (other than PIAFS) -- Carl Rigney RADIUS WG Editor - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Oct 12 08:56: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 IAA12465 for ; Tue, 12 Oct 1999 08:56: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 FAA12302; Tue, 12 Oct 1999 05:54:02 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA28317 for ietf-radius-outgoing; Tue, 12 Oct 1999 05:54:23 -0700 (PDT) From: "Bernard Aboba" To: "'Carl Rigney'" , Cc: Subject: RE: (radius) RADIUS ver 2 Date: Tue, 12 Oct 1999 05:47:17 -0700 Message-ID: <000401bf14af$eb40fb80$478939cc@internaut.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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <199910120629.XAA18427@server.livingston.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.5400 Importance: Normal Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit >Ah! I wasn't aware the EAP draft changed so that EAP-Start is no longer >zero length. It didn't change. The draft hasn't been updated since it was incorporated in RADIUS extensions. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 13 03:40: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 DAA15941 for ; Wed, 13 Oct 1999 03:40:21 -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 AAA15648; Wed, 13 Oct 1999 00:37:12 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id AAA29251 for ietf-radius-outgoing; Wed, 13 Oct 1999 00:36:27 -0700 (PDT) Message-Id: <4.1.19991012203709.00a7b720@omega.cisco.com> Message-Id: <4.1.19991012203709.00a7b720@omega.cisco.com> X-Sender: gdommety@omega.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 12 Oct 1999 20:44:17 -0700 To: Carl Rigney , Pat.Calhoun@eng.sun.com From: Gopal Dommety Subject: Re: (radius) RADIUS ver 2 Cc: ietf-radius@livingston.com In-Reply-To: <199910120629.XAA18427@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Gopal Dommety > 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 Is there any reason for not allowing empty attribute (length = 2)? There could be several benefits if we have this flexibility. Thanks Gopal Gopal Dommety Cisco Systems - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 13 10:27: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 KAA25308 for ; Wed, 13 Oct 1999 10:27: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 HAA19995; Wed, 13 Oct 1999 07:24:35 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA10360 for ietf-radius-outgoing; Wed, 13 Oct 1999 07:21:03 -0700 (PDT) Message-ID: <38049501.F5CF3635@karlnet.com> Date: Wed, 13 Oct 1999 10:19:45 -0400 From: Justin McCann X-Mailer: Mozilla 4.6 [en] (Win98; U) X-Accept-Language: en,pt-BR,es MIME-Version: 1.0 To: Mark S Petrovic CC: Carl Rigney , ietf-radius@livingston.com Subject: Re: (radius) Extending the values of NAS-Port-Type References: <199910090029.RAA05317@server.livingston.com> <19991009112710.B12729@corp.earthlink.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Justin McCann Content-Transfer-Encoding: 7bit Our company provides hardware and software for wireless LANs, MANs, and WANs, and we provide much of the access point software to Lucent for their WaveLAN product. We work closely with Lucent WCND (WaveLAN) in the Netherlands. KarlNet is testing Radius authentication and accounting support in our software, for authentication of the wireless devices themselves and/or with a username/password to gain access to the wireless network. The authentication mechanisms in the IEEE 802.11 wireless LAN standard don't support anything like this. We (KarlNet, not necessarily Lucent) would like to see the NAS-Port-Type attribute for wireless be broken into two subcategories: Wireless-- IEEE 802.11 Wireless-- Other If the phrasing needs changed, feel free to do so. The IEEE 802.11 standard is for wireless LAN's, and is used for laptops, handhelds, desktops, etc. The Apple Airport product uses this standard, in case you pay any attention to that. However, there are also other wireless network devices becoming readily available that use different schemes (such as the Palm Pilot VII or cellular phones). Wireless WAN vendors also are producing non-802.11 radios for high-speed connections for building-to-building and access point-to-access point connections. While these might have their own proprietary authentication schemes, we think it would be a good idea for Radius to support at least the wireless LAN standard as one type and all the rest as 'other'. There will certainly be situations in the future where you would want to allow someone wireless cellphone access but not 802.11 access, or vice-versa. There's my penny and a half. Justin McCann KarlNet, Inc. Mark S Petrovic wrote: > > On 8Oct, Carl Rigney wrote: > > Those make sense. Are there any specific forms of cable or wireless > > that should be added as well as the generic versions? > > I cannot think of specific refinements for either one at this time. As > technologies evolve, and our ability to discern when one of them > obtains, perhaps they could be added. > - > 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 Thu Oct 14 12: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 MAA06411 for ; Thu, 14 Oct 1999 12:35:35 -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 JAA18011; Thu, 14 Oct 1999 09:32:30 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA20434 for ietf-radius-outgoing; Thu, 14 Oct 1999 09:20:24 -0700 (PDT) Date: Thu, 14 Oct 1999 16:16:58 +0000 (GMT) From: Barry James X-Sender: bjames@sushi To: Carl Rigney cc: ietf-radius@livingston.com Subject: (radius) IETF Agenda In-Reply-To: <199910120638.XAA18645@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barry James Is there a set agenda for the RADIUS group at the IETF in November? If so, where would I find it? If not, how does the RADIUS people meet the other RADIUS people? Is there a RADIUS BOF? Thanks, Barry Barry L James | Never doubt that a small group of IP SWAT | thoughtful, committed citizens can Level 3 Communications | change the world. Indeed, it's finger bjames@sushi | the only thing that ever has. Member IEEE, AAAI | #include - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Oct 14 21:37:39 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 VAA16316 for ; Thu, 14 Oct 1999 21:37: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 SAA00627; Thu, 14 Oct 1999 18:34:39 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA24569 for ietf-radius-outgoing; Thu, 14 Oct 1999 18:35:13 -0700 (PDT) Date: Thu, 14 Oct 1999 18:35:10 -0700 (PDT) From: Carl Rigney Message-Id: <199910150135.SAA24563@server.livingston.com> To: bjames@Level3.net Subject: (radius) Re: IETF Agenda Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney The RADIUS group is mostly finished, so we're not planning to meet at the November IETF. I suspect there'll be a lot of RADIUS people at the AAA and NASREQ working group meetings, although those aren't directly discussing RADIUS. -- Carl Rigney - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Oct 15 10:28:32 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 KAA12635 for ; Fri, 15 Oct 1999 10:28: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 HAA09612; Fri, 15 Oct 1999 07:25:30 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA19462 for ietf-radius-outgoing; Fri, 15 Oct 1999 07:25:36 -0700 (PDT) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199910151425.HAA11273@hsmpka.eng.sun.com> Date: Fri, 15 Oct 1999 07:23:51 -0700 To: "Barry James" Cc: Subject: Re: (radius) IETF Agenda 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 >Is there a set agenda for the RADIUS group at the IETF in November? If >so, where would I find it? Is there a RADIUS BOF? no. >If not, how does the RADIUS people meet the other RADIUS people? Just look for a bunch of disgruntled engineers :) PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Oct 15 13:39: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 NAA18453 for ; Fri, 15 Oct 1999 13:39:04 -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 KAA14521; Fri, 15 Oct 1999 10:31:43 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA01187 for ietf-radius-outgoing; Fri, 15 Oct 1999 10:29:22 -0700 (PDT) Date: Fri, 15 Oct 1999 17:25:41 +0000 (GMT) From: Barry James X-Sender: bjames@sushi To: Patrice Calhoun cc: ietf-radius@livingston.com Subject: Re: (radius) IETF Agenda In-Reply-To: <199910151425.HAA11273@hsmpka.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barry James On Fri, 15 Oct 1999, Patrice Calhoun wrote: > Just look for a bunch of disgruntled engineers :) Hey, I don't have to go to IETF to find those. ;) Barry Barry L James | Never doubt that a small group of IP SWAT | thoughtful, committed citizens can Level 3 Communications | change the world. Indeed, it's finger bjames@sushi | the only thing that ever has. Member IEEE, AAAI | #include - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Oct 26 16:03:08 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 QAA23674 for ; Tue, 26 Oct 1999 16:03:07 -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 MAA14423; Tue, 26 Oct 1999 12:59:20 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA18569 for ietf-radius-outgoing; Tue, 26 Oct 1999 12:55:59 -0700 (PDT) Date: Tue, 26 Oct 1999 12:55:55 -0700 (PDT) From: Carl Rigney Message-Id: <199910261955.MAA18561@server.livingston.com> To: justin@karlnet.com Subject: Re: (radius) Extending the values of NAS-Port-Type Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney OK, anyone have any objections or suggestions for these assignments under NAS-Port-Type? 16 xDSL - Digital Subscriber Line of unknown type 17 Cable 18 Wireless - Other 19 Wireless - IEEE 802.11 -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Oct 26 17:45:32 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 RAA29805 for ; Tue, 26 Oct 1999 17:45:31 -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 OAA18648; Tue, 26 Oct 1999 14:41:56 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA26307 for ietf-radius-outgoing; Tue, 26 Oct 1999 14:42:27 -0700 (PDT) Date: Tue, 26 Oct 1999 21:39:09 +0000 (GMT) From: Barry James X-Sender: bjames@sushi To: ietf-radius@livingston.com Subject: (radius) Service-Type = Call Check, Auth-Type = Auth-CHAP In-Reply-To: <199910261955.MAA18561@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barry James Does it make any sense to have an attribute that will allow the specification of authentication types before modem negotiation via the call check mechanism? That is to say, one good use of the call check mechanism is to have the NAS send the Access-Request with Service-Type = Call Check and User-Name = and to have the RADIUS server send back and Auth-Type specifying what type of authentication mechanism should be used for this call. Most NAS gear support a default authentication type. For those users of RADIUS that resell ports to ISPs or other customers and need to support multiple customers dialing into a bank of NAS's it keeps us from having to dedicate NAS gear to specific customers (ie one customer uses PAP and another uses CHAP, etc). I think it would be very useful (we do it here now) to be able to send back in the Access-Accept something like Auth-Type = Auth-CHAP so that the NAS will initiate a CHAP negotiation with the customer, while sending back an Auth-PAP will cause the NAS to initiate a PAP negotiation. This model works well for port-resellers and others. A possible definition might include: Auth-None Auth-Any Auth-Default Auth-PAP Auth-CHAP Auth-MS-CHAP Thoughts? Regards, Barry Barry L James | Never doubt that a small group of IP SWAT | thoughtful, committed citizens can Level 3 Communications | change the world. Indeed, it's http://www.level3.com | the only thing that ever has. Member IEEE, AAAI | #include - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 27 14:29:26 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 OAA28761 for ; Wed, 27 Oct 1999 14:29:20 -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 LAA14123; Wed, 27 Oct 1999 11:25:38 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA19086 for ietf-radius-outgoing; Wed, 27 Oct 1999 11:24:25 -0700 (PDT) From: "Mark Anthony Beadles" To: "'Barry James'" , Subject: RE: (radius) Service-Type = Call Check, Auth-Type = Auth-CHAP Date: Wed, 27 Oct 1999 14:23:27 -0400 Message-ID: <001501bf20a8$5dc74c00$3e7e5d18@pavilion.columbus.rr.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 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mark Anthony Beadles" Content-Transfer-Encoding: 7bit This is in many ways similar to my proposal for "AAA referral". The main difference is that I did not propose a separate Service-Type. http://search.ietf.org/internet-drafts/draft-beadles-aaa-referral-00.txt. + Mark Anthony Beadles + + mark.beadles@columbus.rr.com + + Vox 614.565.1308 Pager 888.660.8427 + -----Original Message----- From: owner-ietf-radius@livingston.com [mailto:owner-ietf-radius@livingston.com]On Behalf Of Barry James Sent: Tuesday, 26 October 1999 17:39 To: ietf-radius@livingston.com Subject: (radius) Service-Type = Call Check, Auth-Type = Auth-CHAP Does it make any sense to have an attribute that will allow the specification of authentication types before modem negotiation via the call check mechanism? That is to say, one good use of the call check mechanism is to have the NAS send the Access-Request with Service-Type = Call Check and User-Name = and to have the RADIUS server send back and Auth-Type specifying what type of authentication mechanism should be used for this call. Most NAS gear support a default authentication type. For those users of RADIUS that resell ports to ISPs or other customers and need to support multiple customers dialing into a bank of NAS's it keeps us from having to dedicate NAS gear to specific customers (ie one customer uses PAP and another uses CHAP, etc). I think it would be very useful (we do it here now) to be able to send back in the Access-Accept something like Auth-Type = Auth-CHAP so that the NAS will initiate a CHAP negotiation with the customer, while sending back an Auth-PAP will cause the NAS to initiate a PAP negotiation. This model works well for port-resellers and others. A possible definition might include: Auth-None Auth-Any Auth-Default Auth-PAP Auth-CHAP Auth-MS-CHAP Thoughts? Regards, Barry Barry L James | Never doubt that a small group of IP SWAT | thoughtful, committed citizens can Level 3 Communications | change the world. Indeed, it's http://www.level3.com | the only thing that ever has. Member IEEE, AAAI | #include - 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.