From owner-ietf-radius@livingston.com Thu Oct 1 18:22:11 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA17078 for ; Thu, 1 Oct 1998 18:22:10 -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 PAA21194; Thu, 1 Oct 1998 15:17:07 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA04634 for ietf-radius-outgoing; Thu, 1 Oct 1998 15:11:57 -0700 (PDT) X-Authentication-Warning: empire.scs.unr.edu: jana owned process doing -bs Date: Thu, 1 Oct 1998 15:10:42 -0700 (PDT) From: Jana Dunn To: ietf-radius@livingston.com Subject: (radius) Firewalls with RADIUS-based authentication? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jana Dunn Greetings, We're working on a project to provide authentication for outgoing/Internet-bound connections from (TCP/IP-connected) student computer labs. Ideally, we'd like a student to be able to walk into a lab, fire up a web browser, telnet, ftp, or a similar application, be challenged for login/password authentication, and then, providing he is able to authenticate, be allowed to connect to the target server and go about his business on the Internet. We have fairly extensive RADIUS authentication databases already in use for our modem banks, and so we'd like to use RADIUS for the lab authentication as well. We've looked at Firewall-1 from Sun, and are looking at PIX from Cisco. For various reasons, we're not entirely happy with either product. Are there other firewall or firewall-type products we could use to provide RADIUS-based authentication for our project? --------------------------- Here's what we'd like to see: The machines in the lab may or may not be connected to a fileserver, so we don't want a solution that's dependent on the existence of a fileserver. If the lab is the "inside" and the rest of the Internet (including the rest of our campus network) is "outside", we need the RADIUS servers to be on the outside of the firewall. We have more than one RADIUS server and so require RADIUS-to-RADIUS proxy. We very much prefer the "user@realm" syntax. We would like the user to be able to authenticate for a reasonable session. For example, re-authenticating for connecting to each http server he accesses during a surfing session seems inconvenient to us. We'd like the authentication challenge/method to be relatively intuitive. We would like to be able to do URL filtering with a subscription-based product. The server for the product needs to reside on the "outside" of the firewall. URL filtering is not an absolute requirement. We would prefer a UNIX-based server/firewall or a standalone/special purpose firewall (like PIX.) --------------------------- If you know of a product we should look at, please email me with the relevant info. Thank you. Jana Dunn Telecom Analyst University of Nevada System jana@scs.unr.edu - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Oct 2 20:03:50 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA12078 for ; Fri, 2 Oct 1998 20: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 QAA09621; Fri, 2 Oct 1998 16:58:37 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA28735 for ietf-radius-outgoing; Fri, 2 Oct 1998 16:55:53 -0700 (PDT) Message-ID: <008701bdee5b$e6cef780$86f61fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Carl Rigney" , Cc: "RADIUS" Subject: (radius) ARAP-Challenge-Response? Date: Fri, 2 Oct 1998 16:21:09 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_006E_01BDEE20.A9FF7FE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_006E_01BDEE20.A9FF7FE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In the extensions draft, there is mention of an ARAP-Challenge-Response attribute but the attribute is never formally defined. Is this going to be in the next rev? __ A society, most of whose members spend a great deal of their time not on the spot, not here and now in the calculable future, but somwhere else, in the irrelevant other worlds of sport and soap opera, of mythology and metaphysical fantasy, will find it hard to resist the encroachments of those who would manipulate and control it. -- Aldous Huxley, Foreword to "Brave New World", 1946 ------=_NextPart_000_006E_01BDEE20.A9FF7FE0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19981002T232108Z END:VCARD ------=_NextPart_000_006E_01BDEE20.A9FF7FE0-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Oct 2 20:25:20 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA12180 for ; Fri, 2 Oct 1998 20:25: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 RAA10468; Fri, 2 Oct 1998 17:20:27 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA00852 for ietf-radius-outgoing; Fri, 2 Oct 1998 17:19:44 -0700 (PDT) Date: Fri, 2 Oct 1998 17:19:42 -0700 (PDT) From: Carl Rigney Message-Id: <199810030019.RAA00845@server.livingston.com> To: gwz@pinky.microsoft.com Subject: (radius) Re: ARAP-Challenge-Response? Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Yes, ARAP-Challenge-Response is attribute 84. 5.15. ARAP-Challenge-Response Description This attribute is sent in an Access-Accept packet with Framed- Protocol of ARAP, and contains the response to the dial-in client's challenge. A summary of the ARAP-Challenge-Response 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 | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 84 for ARAP-Challenge-Response. Length 10 Value The Value field contains an 8 octet response to the dial-in client's challenge. The RADIUS server calculates this value by taking the dial-in client's challenge from the high order 8 octets of the ARAP-Password attribute and performing DES encryption on this value with the authenticating user's password as the key. If the user's password is less than 8 octets in length, the password is padded at the end with NULL octets to a length of 8 before using it as a key. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Oct 2 20:51:26 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA12320 for ; Fri, 2 Oct 1998 20:51:25 -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 RAA11699; Fri, 2 Oct 1998 17:46:36 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA03004 for ietf-radius-outgoing; Fri, 2 Oct 1998 17:46:17 -0700 (PDT) Message-ID: <00c601bdee66$b2ca01e0$86f61fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Carl Rigney" Cc: Subject: Re: (radius) Re: ARAP-Challenge-Response? Date: Fri, 2 Oct 1998 17:42:15 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B9_01BDEE2B.FE2B58E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_00B9_01BDEE2B.FE2B58E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thanks! -----Original Message----- From: Carl Rigney To: gwz@pinky.microsoft.com Cc: ietf-radius@livingston.com Date: Friday, October 02, 1998 5:19 PM Subject: (radius) Re: ARAP-Challenge-Response? >Yes, ARAP-Challenge-Response is attribute 84. > >5.15. ARAP-Challenge-Response > > Description > > This attribute is sent in an Access-Accept packet with Framed- > Protocol of ARAP, and contains the response to the dial-in > client's challenge. > > A summary of the ARAP-Challenge-Response 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 | Value... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Type > > 84 for ARAP-Challenge-Response. > > Length > > 10 > > Value > > The Value field contains an 8 octet response to the dial-in > client's challenge. The RADIUS server calculates this value by > taking the dial-in client's challenge from the high order 8 octets > of the ARAP-Password attribute and performing DES encryption on > this value with the authenticating user's password as the key. If > the user's password is less than 8 octets in length, the password > is padded at the end with NULL octets to a length of 8 before > using it as a key. > > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > ------=_NextPart_000_00B9_01BDEE2B.FE2B58E0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19981003T004214Z END:VCARD ------=_NextPart_000_00B9_01BDEE2B.FE2B58E0-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Oct 5 11:41:16 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA22022 for ; Mon, 5 Oct 1998 11:41:15 -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 IAA26357; Mon, 5 Oct 1998 08:35:55 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA09636 for ietf-radius-outgoing; Mon, 5 Oct 1998 08:27:36 -0700 (PDT) From: "Bob Bosen" To: Subject: (radius) RADIUS "bakeoff" compatibility exercises Date: Mon, 5 Oct 1998 08:27:52 -0700 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <98Oct5.082633pdt.26881@bohica.con.securecomputing.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bob Bosen" Folks: Have we had any RADIUS "bakeoff" compatibility exercises lately? Any scheduled for the near future? Regards, Bob Bosen Authentication Division Router/Commserver Interface Department Secure Computing Corporation bob_bosen@securecomputing.com http://www.safeword.com/safeword/welcome.htm ********************** It wasn't me! Somebody must have captured my username/password! ********************** - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Oct 5 16:28:11 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA27508 for ; Mon, 5 Oct 1998 16:28:11 -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 NAA08798; Mon, 5 Oct 1998 13:23:07 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA14852 for ietf-radius-outgoing; Mon, 5 Oct 1998 13:22:24 -0700 (PDT) Message-ID: <001d01bdf09d$4ddcf560$0137a8c0@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Bob Bosen" , Subject: Re: (radius) RADIUS "bakeoff" compatibility exercises Date: Mon, 5 Oct 1998 13:18:19 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001A_01BDF062.9E7A0520" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_001A_01BDF062.9E7A0520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Bob Bosen writes: >Folks: Have we had any RADIUS "bakeoff" compatibility exercises >lately? Any scheduled for the near future? Nope and nope (but you're more than welcome to organize one :-). > > >Regards, > > >Bob Bosen >Authentication Division >Router/Commserver Interface Department >Secure Computing Corporation > >bob_bosen@securecomputing.com >http://www.safeword.com/safeword/welcome.htm > >********************** >It wasn't me! Somebody must have captured my username/password! >********************** >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > ------=_NextPart_000_001A_01BDF062.9E7A0520 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19981005T201817Z END:VCARD ------=_NextPart_000_001A_01BDF062.9E7A0520-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Oct 5 19:14:04 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA29354 for ; Mon, 5 Oct 1998 19:14:03 -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 QAA19778; Mon, 5 Oct 1998 16:09:06 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA07811 for ietf-radius-outgoing; Mon, 5 Oct 1998 16:08:14 -0700 (PDT) Message-ID: <361952D5.18089E07@iea-software.com> Date: Mon, 05 Oct 1998 16:14:29 -0700 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: Glen Zorn CC: Bob Bosen , ietf-radius@livingston.com Subject: Re: (radius) RADIUS "bakeoff" compatibility exercises References: <001d01bdf09d$4ddcf560$0137a8c0@glennz-2.dns.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Script: \\FilterScript.mml X-DomainScript: pinky.microsoft.com\\script.mml X-UserScript: livingston.com\ietf-radius\script.mml Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Glen Zorn wrote: > > Bob Bosen writes: > > >Folks: Have we had any RADIUS "bakeoff" compatibility exercises > >lately? Any scheduled for the near future? > > Nope and nope (but you're more than welcome to organize one :-). We have the ability to test on-line with anyone who wants to. Although the RadiusNT site/server isn't up right now because we moved to a new server and I didn't move all the sites. Basically we have a permiscuous mode that allows anyone to make requests and tests. The web page allows you to define domains to proxy to for testing proxy from RadiusNT to another server as well. If anyone wants to do some testing, just send me some email, and I can throw the site (that has all the information in it) back up. I also still have (I think) the old web site and database schema that we used for the DC Bakeoff that we could use to do some testing in the same sense as the bakeoff, but over the net rather than on the LAN. Any one interested in that? -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 7 01:10:41 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA07072 for ; Wed, 7 Oct 1998 01:10:41 -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 WAA06489; Tue, 6 Oct 1998 22:04:53 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA01732 for ietf-radius-outgoing; Tue, 6 Oct 1998 22:02:47 -0700 (PDT) Date: Tue, 6 Oct 1998 22:02:45 -0700 (PDT) From: Carl Rigney Message-Id: <199810070502.WAA01726@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) International RADIUS Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Does anyone object if in the upcoming revised draft for RADIUS I specify Unicode UTF-8 instead of ASCII in the places where it talks about contents of printable strings? My understanding is that UTF-8 is a superset of ASCII so we have backwards compatibility, but it includes additional characters that non-US sites may find useful. I'm out of town 10/8-14 but will catch up on email when I return, so please email me your thoughts (cc ietf-radius if you want to share them with everyone else). Does anyone know an online reference for UTF-8? RFC 1641 has a reference to [UTF-8] X/Open Company Ltd., "File System Safe UCS Transformation Format (FSS_UTF)", X/Open Preliminary Specification, Document Number: P316. This information also appears in Unicode Technical Report #4, and in a forthcoming annex to ISO/IEC 10646. -- 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 Wed Oct 7 01:35:11 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA07229 for ; Wed, 7 Oct 1998 01:35:10 -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 WAA06876; Tue, 6 Oct 1998 22:30:08 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA02578 for ietf-radius-outgoing; Tue, 6 Oct 1998 22:29:03 -0700 (PDT) Date: Tue, 6 Oct 1998 22:29:02 -0700 (PDT) From: Carl Rigney Message-Id: <199810070529.WAA02570@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) draft-ietf-radius-ext-02.txt ready for review Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney With extreme apologies for the very long delay, I'm pleased to announce that the RADIUS Extensions draft is ready for review. I've placed a copy at ftp://ftp.livingston.com/pub/radius/draft-ietf-radius-ext-02.txt and it should be appearing in the usual Internet-Draft locations soon. This draft includes the renumbering of attributes to avoid conflict with the tunneling attributes, and incorporates the Acct-Interim-Interval draft and EAP draft. There may still be rough edges but I wanted to get it out to the list for review before going out of town 10/8-15; email me any corrections or suggestions or improvement by 10/16 and I'll update it when I'm back and get it out (finally) to last call. I think ARAP's use of the Request Authenticator on page 5 in section 2.2 needs to be clarified with regard to byte order, and there's still a place or two where EAP needs to be smoothed; in particular 1) how to deal with EAP-Message in Access-Requests with no User-Name, and 2) the EAP-Message with an EAP-Start can have a length of 2, which no other string in RADIUS permits. Will having a string with no data in it cause grief for anyone's implementation? When I get back I'll send out the RADIUS and RADIUS Accounting updates; the changes to those are mostly minor so I wanted to get Extensions out first. I should have them ready for last call by the end of October. -- Carl Rigney cdr@livingston.com "October 1998. Thanks for asking." - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 7 08:37:26 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA09925 for ; Wed, 7 Oct 1998 08:37:25 -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 FAA12987; Wed, 7 Oct 1998 05:31:23 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA14994 for ietf-radius-outgoing; Wed, 7 Oct 1998 05:30:27 -0700 (PDT) Date: Wed, 7 Oct 1998 05:27:16 -0700 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199810071227.FAA25704@hsmpka.eng.sun.com> To: "Carl Rigney" , ietf-radius@livingston.com X-Mailer: Sun NetMail 2.1.6 Subject: Re: (radius) International RADIUS Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) That is fine with me. I am actually surprised that we got away with it in RFC2138,2139. The IESG (or rather certain members) are sensitive to this. PatC >Does anyone object if in the upcoming revised draft for RADIUS I specify >Unicode UTF-8 instead of ASCII in the places where it talks about contents >of printable strings? My understanding is that UTF-8 is a superset of ASCII >so we have backwards compatibility, but it includes additional characters that >non-US sites may find useful. > >I'm out of town 10/8-14 but will catch up on email when I return, so >please email me your thoughts (cc ietf-radius if you want to share them >with everyone else). > >Does anyone know an online reference for UTF-8? RFC 1641 has a reference to >[UTF-8] X/Open Company Ltd., "File System Safe UCS Transformation > Format (FSS_UTF)", X/Open Preliminary Specification, > Document Number: P316. This information also appears in > Unicode Technical Report #4, and in a forthcoming annex to > ISO/IEC 10646. > >-- >Carl Rigney >cdr@livingston.com >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 7 09:48:32 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA10893 for ; Wed, 7 Oct 1998 09:48:32 -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 GAA14199; Wed, 7 Oct 1998 06:41:36 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA17321 for ietf-radius-outgoing; Wed, 7 Oct 1998 06:40:51 -0700 (PDT) Message-Id: <3.0.5.32.19981007094301.03037c10@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 07 Oct 1998 09:43:01 -0400 To: Carl Rigney , ietf-radius@livingston.com From: Dave Mitton Subject: Re: (radius) International RADIUS In-Reply-To: <199810070502.WAA01726@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton Just scanning RFC2138 for "ASCII" I only find places where the "printable ASCII characters" are recommended or MAY occur. In which case, changing ASCII to UTF-8 doesn't make much difference. Just a different sort of "printable". In no place do I find any sort of character set encoding Required or MUST. (hmm... scan for characters revels that User-Password talks about characters in length) Did I miss anything? BTW: I do think that this is a good thing. Dave. At 10:02 PM 10/6/98 -0700, Carl Rigney wrote: >Does anyone object if in the upcoming revised draft for RADIUS I specify >Unicode UTF-8 instead of ASCII in the places where it talks about contents >of printable strings? My understanding is that UTF-8 is a superset of ASCII >so we have backwards compatibility, but it includes additional characters that >non-US sites may find useful. > >I'm out of town 10/8-14 but will catch up on email when I return, so >please email me your thoughts (cc ietf-radius if you want to share them >with everyone else). > >Does anyone know an online reference for UTF-8? RFC 1641 has a reference to >[UTF-8] X/Open Company Ltd., "File System Safe UCS Transformation > Format (FSS_UTF)", X/Open Preliminary Specification, > Document Number: P316. This information also appears in > Unicode Technical Report #4, and in a forthcoming annex to > ISO/IEC 10646. > >-- >Carl Rigney >cdr@livingston.com >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton 978-670-8888 Main Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Networks, I&SP Group 978-916-4789 FAX Billerica, MA 01821 dmitton@baynetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 7 12:19:09 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA14052 for ; Wed, 7 Oct 1998 12:19:08 -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 JAA21226; Wed, 7 Oct 1998 09:10:54 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA01817 for ietf-radius-outgoing; Wed, 7 Oct 1998 09:09:52 -0700 (PDT) From: "Bernard Aboba" To: "Carl Rigney" , Subject: Re: (radius) draft-ietf-radius-ext-02.txt ready for review Date: Wed, 7 Oct 1998 08:49:28 -0700 Message-Id: <01bdf20a$1139d740$0f8939cc@e1kj2.internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" >1) how to deal with EAP-Message in Access-Requests with no User-Name, I think that it is reasonable to require the Access-Request to contain a User-name attribute. Logic follows below. If the NAS sends the EAP-Request/Identity message and receives an EAP-Response/Identity prior to sending a RADIUS Access-Request with an EAP-Message attribute, then the User-Name will be known and can be included in the Access-Request. This guarantees compatibility with RADIUS proxies, and is the only mode which our implementation supports. However, when the NAS sends a RADIUS Access-Request prior to initiating the EAP conversation, then the userID is not known and the EAP-Start is used. This was intended for use in circumstances where the EAP-Request/Identity might not be sent, since this is not mandatory in RFC 2284. There are only a few examples in which an identity exchange appears to not be necessary. One is identification based on called or calling phone numbers. For example, a smart card authentication could be required if the user calls from a given number. This case can be handled by requiring the User-Name attribute and allowing the NAS to populate it with the other identification information. Another case is of some form of authentication that can determine the identity of the user without a claim of identity. Smartcard authentication is one example of this; the user's identity can be included on the smartcard. However, even though the identity exchange is not strictly necessary, it is still desirable since this allows the NAS and proxies to remain ignorant of the details of individual EAP modules. This is not a hardship on the client since the client can respond to the EAP-Request/Identity with the User-Name taken from the smartcard. Biometric authentication methods could also conceivably fit into this category, although the case is hard to make. Typically, the computation involved in comparing the measured biometric against a personal's profile is substantial so that it makes more sense to have the individual claim an identity and test the claim rather than matching the metric against *everyone* in the database. Even in this case, one could argue that requiring a User-Name attribute would not be a hardship; the NAS could fill it in with a value implying "to be determined." - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 7 12:32:09 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA14485 for ; Wed, 7 Oct 1998 12:32:08 -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 JAA22120; Wed, 7 Oct 1998 09:26:10 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA03799 for ietf-radius-outgoing; Wed, 7 Oct 1998 09:25:48 -0700 (PDT) Date: Wed, 7 Oct 1998 09:18:40 -0700 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199810071618.JAA05873@hsmpka.eng.sun.com> To: "Bernard Aboba" , "Carl Rigney" , ietf-radius@livingston.com X-Mailer: Sun NetMail 2.1.6 Subject: Re: (radius) draft-ietf-radius-ext-02.txt ready for review Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) >>1) how to deal with EAP-Message in Access-Requests with no User-Name, > >I think that it is reasonable to require the Access-Request to contain a >User-name attribute. Logic follows below. > >If the NAS sends the EAP-Request/Identity message and receives >an EAP-Response/Identity prior to sending a RADIUS Access-Request >with an EAP-Message attribute, then the User-Name will be known and >can be included in the Access-Request. This guarantees compatibility >with RADIUS proxies, and is the only mode which our implementation >supports. > >However, when the NAS sends a RADIUS Access-Request prior to >initiating the EAP conversation, then the userID is not known and >the EAP-Start is used. This was intended for use in circumstances >where the EAP-Request/Identity might not be sent, since this is >not mandatory in RFC 2284. > >There are only a few examples in which an identity exchange >appears to not be necessary. One is identification based on called or >calling phone numbers. For example, a smart card authentication could be >required if the user calls from a given number. This case can be >handled by requiring the User-Name attribute and allowing the >NAS to populate it with the other identification information. >Another case is of some form of authentication that can determine >the identity of the user without a claim of identity. Smartcard >authentication is one example of this; the user's identity can be >included on the smartcard. However, even though the identity >exchange is not strictly necessary, it is still desirable since this >allows the NAS and proxies to remain ignorant of the details of >individual EAP modules. This is not a hardship on the client since >the client can respond to the EAP-Request/Identity with the >User-Name taken from the smartcard. > >Biometric authentication methods could also conceivably fit >into this category, although the case is hard to make. >Typically, the computation involved in comparing the measured >biometric against a personal's profile is substantial so that >it makes more sense to have the individual claim an identity and >test the claim rather than matching the metric against *everyone* >in the database. Even in this case, one could argue that requiring >a User-Name attribute would not be a hardship; the NAS could >fill it in with a value implying "to be determined." If this is to be the case, I would like the "to be determined" to be pre-defined. Otherwise each NAS manufacturer will include its own proprietary value, and this makes it harder to support in multi-vendor environments. Perhaps a User-Name of "EAP" ? PatC > > > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 7 16:14:55 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA18784 for ; Wed, 7 Oct 1998 16:14:54 -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 NAA03604; Wed, 7 Oct 1998 13:03:44 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA02756 for ietf-radius-outgoing; Wed, 7 Oct 1998 13:02:34 -0700 (PDT) From: stock-pick@stock-pick.net Message-Id: <199810072346.TAA05741@mars.your-mail.com> To: user@the.internet Date: Wed, 07 Oct 98 08:11:21 EST Subject: (radius) AD: Stock-Pick Discovers Media Goldmine!! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: stock-pick@stock-pick.net This message is sent in compliance of the new e-mail bill: SECTION 301, Paragraph (a)(2)(C) of s. 1618 Sender : Stock-Pick, P.O. Box 130544, St Paul, MN 55113 Phone : 1-612-646-8174 E-mail : stock-pick@stock-pick.net To be removed from our mailing list, simply reply with "REMOVE" in the subject. Visit http://www.stock-pick.net for full details. Financial Highlights: Triangle Broadcasting, Inc. (OTC BB : GAAY) Shares Outstanding (Aug 31, 1998) : 19.4 Million Shares Current Market Capitalization (Current Stock Price of $0.05) - $970,000 Stockholders’ Equity (June 30, 1998) - $2,233,470 - Equity per Share : $0.115 At current stock price of $0.05 we feel this stock to be tremendous BUY at these levels. Currently there are 19.4 million shares outstanding, this gives a market capitalization of only $970,000 - a modest investment could yield enormous rewards for the investors who entered on the ground floor. At current price levels $1000 would purchase 20,000 shares. "Mark Twain said: "The secret to success is - find out where the people are going and get there first". We feel that Triangle Broadcasting, Inc. (OTC BB : GAAY) has followed that adage to a T. Triangle Broadcasting Company, Inc. (OTC BB : GAAY) is launching itself to a right future. They are the first mass media company to target gays and lesbians on a national level. Successful companies always take one step at a time so that they never skip over something important that will haunt them in the future. First, Triangle Broadcasting Company, Inc. did extensive surveys. They found out what were the people's preferences. They also figured out what would be the most strategic way to market their product and what programs would be received well by both the gay and lesbian communities and the mass market. They set up their programming and found what cities they should target first. Triangle Broadcasting Company, Inc. is going to start in 15 cities. They have chosen 15 cities with large gay and lesbian populations. After they have gained acceptance in these markets, they will expand to a national level. They can already be received by over 10,000 stations in the United States and Canada. Triangle Broadcasting Company, Inc. will not expand until they have made a presence in the markets that they are focusing on. Triangle Broadcast Company, Inc. hand-picked it's management infrastructure. They took broadcast executives who had extensive knowledge about the industry. Gay and lesbian nightclub owners were brought in to help formulate the programming. Business advisors help with the complexities of running a business. And last but not least real estate people help with the planning of which communities would be their first targets. After all this was set up they contacted advertising executives of major companies throughout the United States and Canada. The response was overwhelming. With all the above factors, and the fact that advertisers are already lining up, success is almost inevitable. This is truly an amazing company with nothing but positive opportunities in front of it. Once again visit http://www.stock-pick.net for full details. ****** DISCLAIMER ****** This material is being provided by Stock-Pick, a paid public relations company, and is for informational purposes only and is not to be construed as an offer or solicitation of an offer to sell or buy any security. Stock-Pick is an independent electronic publication providing both information and factual analysis on selected companies that in the opinion of Stock-Pick have investment potential. Companies featured by Stock-Pick or company affiliates pay consideration to Stock-Pick for the electronic dissemination of company information. Triangle Broadcasting Company, Inc. has paid a consideration of 100,000 common shares of Triangle Broadcasting Company, Inc. stock to Stock-Pick in conjunction with this company profile. All statements and expressions are the opinion of Stock-Pick. Stock-Pick is not a registered investment advisor or a broker dealer. While it is our goal to locate and research equity investments in micro or small capitalization companies that have the potential for long-term appreciation, investment in the companies reviewed are considered to be high risk and may result in loss of some or all of the investment. The information that Stock-Pick relies on is generally provided by the featured companies and also may include information from outside sources and interviews conducted by Stock-Pick. While Stock-Pick believes all sources of the information to be reliable, Stock-Pick makes no representation or warranty as to the accuracy of the information provided. Investors should not rely solely on the information contained in this publication. Rather, investors should use the information contained in this publication as a starting point for doing additional independent research on the featured companies in order to allow the investor to form his or her own opinion regarding investing in featured companies. This publication contains forward looking statements that are subject to risk and uncertainties that could cause results to differ materially from those set forth in the forward-looking statements. These forward-looking statements represent Triangle Broadcasting Inc., judgement as of the date of this release. The company disclaims any intent or obligation to update these forward-looking statements. Factual statements in this publication are made as of the date stated and are subject to change without notice. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 7 16:32:00 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA19136 for ; Wed, 7 Oct 1998 16:31:59 -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 NAA05335; Wed, 7 Oct 1998 13:26:25 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA05901 for ietf-radius-outgoing; Wed, 7 Oct 1998 13:25:58 -0700 (PDT) Message-ID: <361BCD8E.5FDD@ascend.com> Date: Wed, 07 Oct 1998 13:22:38 -0700 From: Bill Webb Organization: Ascend Engineering X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5.1 i86pc) MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: (radius) ietf-radius mailing list SPAM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Bill Webb Re: AD: Stock-Pick Discovers Media Goldmine!! Enough already! Can't we close this list so that we don't get SPAMMED as much or at least filter out email with "AD:" in the subject line? Bill Webb (Ascend Communications) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 7 21:13:37 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA21371 for ; Wed, 7 Oct 1998 21: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 SAA16345; Wed, 7 Oct 1998 18:08:35 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA05192 for ietf-radius-outgoing; Wed, 7 Oct 1998 18:07:48 -0700 (PDT) Message-ID: <008f01bdf257$76ea8740$86f61fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Carl Rigney" , Subject: Re: (radius) International RADIUS Date: Wed, 7 Oct 1998 18:03:17 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_008C_01BDF21C.C28760A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_008C_01BDF21C.C28760A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Carl Rigney writes: >Does anyone object if in the upcoming revised draft for RADIUS I specify >Unicode UTF-8 instead of ASCII in the places where it talks about contents >of printable strings? My understanding is that UTF-8 is a superset of ASCII >so we have backwards compatibility, but it includes additional characters that >non-US sites may find useful. It's a good start, but I don't think that it satisfies the requirements of RFC 2277 (which I think we should be shooting for). There is a draft in last call in the pppext WG (draft-ietf-pppext-lcp-charset-04.txt) that defines an LCP config option for negotiating charset and language in PPP. While this approach works well for PPP, in runs into problems with RADIUS. Even if there were RADIUS attributes that the NAS could use to request a message in a given charset/language pair, there is no way for the NAS to know before the LCP negotiations complete if a given RADIUS server supports the option it has negotiated. This could be handled with NAS configuration in a small network, but if RADIUS proxies are involved (or multiple RADIUS servers not contolled by the same people who administer the NASs) things get more interesting. Of course, the NAS could tell the RADIUS server what option was negotiated, then drop back to LCP and renegotiate if the server didn't support it, but that seems a bit inelegant. > >I'm out of town 10/8-14 but will catch up on email when I return, so >please email me your thoughts (cc ietf-radius if you want to share them >with everyone else). > >Does anyone know an online reference for UTF-8? RFC 1641 has a reference to >[UTF-8] X/Open Company Ltd., "File System Safe UCS Transformation > Format (FSS_UTF)", X/Open Preliminary Specification, > Document Number: P316. This information also appears in > Unicode Technical Report #4, and in a forthcoming annex to > ISO/IEC 10646. RFC 2279 > >-- >Carl Rigney >cdr@livingston.com >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > ------=_NextPart_000_008C_01BDF21C.C28760A0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19981008T010315Z END:VCARD ------=_NextPart_000_008C_01BDF21C.C28760A0-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 7 21:26:09 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA21421 for ; Wed, 7 Oct 1998 21:26: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 SAA16760; Wed, 7 Oct 1998 18:21:14 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA06032 for ietf-radius-outgoing; Wed, 7 Oct 1998 18:21:07 -0700 (PDT) Message-ID: <009c01bdf259$550f0220$86f61fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Carl Rigney" , Subject: Re: (radius) draft-ietf-radius-ext-02.txt ready for review Date: Wed, 7 Oct 1998 18:15:41 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0099_01BDF21E.7E109AC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_0099_01BDF21E.7E109AC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit One thing that leaps out: since the sections on EAP and interim accounting appear to be basically cut-and-pasted from draft-ietf-radius-eap-05.txt and draft-ietf-radius-acct-interim-01.txt respectively, I think that you need to incorporate the authors of those drafts as authors of this one as well. -----Original Message----- From: Carl Rigney To: ietf-radius@livingston.com Date: Tuesday, October 06, 1998 10:23 PM Subject: (radius) draft-ietf-radius-ext-02.txt ready for review >With extreme apologies for the very long delay, I'm pleased to >announce that the RADIUS Extensions draft is ready for review. >I've placed a copy at >ftp://ftp.livingston.com/pub/radius/draft-ietf-radius-ext-02.txt >and it should be appearing in the usual Internet-Draft locations >soon. > >This draft includes the renumbering of attributes to avoid conflict >with the tunneling attributes, and incorporates the >Acct-Interim-Interval draft and EAP draft. There may still be rough >edges but I wanted to get it out to the list for review before going >out of town 10/8-15; email me any corrections or suggestions or >improvement by 10/16 and I'll update it when I'm back and get it out >(finally) to last call. > >I think ARAP's use of the Request Authenticator on page 5 in section >2.2 needs to be clarified with regard to byte order, and there's still >a place or two where EAP needs to be smoothed; in particular 1) how to >deal with EAP-Message in Access-Requests with no User-Name, and 2) >the EAP-Message with an EAP-Start can have a length of 2, which no other >string in RADIUS permits. Will having a string with no data in it >cause grief for anyone's implementation? > >When I get back I'll send out the RADIUS and RADIUS Accounting updates; >the changes to those are mostly minor so I wanted to get Extensions out >first. I should have them ready for last call by the end of October. > >-- >Carl Rigney >cdr@livingston.com > >"October 1998. Thanks for asking." >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > ------=_NextPart_000_0099_01BDF21E.7E109AC0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19981008T011540Z END:VCARD ------=_NextPart_000_0099_01BDF21E.7E109AC0-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Oct 8 10:21:23 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA05585 for ; Thu, 8 Oct 1998 10:21:22 -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 HAA01187; Thu, 8 Oct 1998 07:15:42 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA03815 for ietf-radius-outgoing; Thu, 8 Oct 1998 07:12:45 -0700 (PDT) Message-Id: <199810081410.KAA05275@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-ext-02.txt Date: Thu, 08 Oct 1998 10:10:54 -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, W. Willats Filename : draft-ietf-radius-ext-02.txt Pages : 42 Date : 07-Oct-98 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. Internet-Drafts are 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-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-ext-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-ext-02.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: <19981007125826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-ext-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-ext-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981007125826.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 Fri Oct 9 10:00:05 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA27385 for ; Fri, 9 Oct 1998 10:00:04 -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 GAA22578; Fri, 9 Oct 1998 06:54:21 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA25407 for ietf-radius-outgoing; Fri, 9 Oct 1998 06:52:24 -0700 (PDT) From: William Bulley Message-Id: <199810091349.JAA28258@ohm.merit.edu> Subject: (radius) omission(s) from Extensions Draft -02 To: cdr@livingston.com Date: Fri, 9 Oct 1998 09:49:30 -0400 (EDT) Cc: ietf-radius@livingston.com X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William Bulley I see extension attributes [52 through 53] on page 19 listed along with all the other extension attributes, and I see their description on pages 20 through 24, but I do NOT see them being included in the "Table of Attributes" on pages 35 and 36. Am I missing something? Regards, web... -- William Bulley Senior Systems Research Programmer Merit Network, Inc. Email: web@merit.edu 4251 Plymouth Road, Suite C Phone: (734) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (734) 647-3185 [ Reuters, London, February 29, 1998: Scientists have announced discovering ] [ a meteorite which will strike the earth in March, 2028. Millions of UNIX ] [ coders expressed relief for being spared the UNIX epoch "crisis" of 2038. ] - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Oct 10 15:51:08 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA22156 for ; Sat, 10 Oct 1998 15:51:07 -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 MAA00402; Sat, 10 Oct 1998 12:46:02 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA28045 for ietf-radius-outgoing; Sat, 10 Oct 1998 12:42:29 -0700 (PDT) Message-Id: <199810101941.MAA11590@shell4.ba.best.com> Subject: (radius) Extensions draft To: ietf-radius@livingston.com Date: Sat, 10 Oct 1998 12:41:46 -0700 (PDT) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-SHOW-1: ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. X-SHOW-2: Three days of clues, news, and views from the industry's best and X-SHOW-3: brightest. http://www.ispf.com/ for information and registration. X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Perhaps this is a nit, however: --- String The String field is encoded as ASCII characters. The connection speed SHOULD be included at the beginning of the first Connect- Info attribute in the packet. If the Transmit and Receive connection speeds differ, they may both be included in the first attribute with the receive speed first (the speed the NAS modem receives at), a slash (/), the transmit speed, then optionally other information. For example, "28800 V42BIS/LAPM" or "52000/33600 V90" --- This struck me as confusing. If it is RECEIVE/TRANSMIT from the POV of the NAS, wouldn't the example be more appropriate as "31200/52000 V90"? Since nearly every use with a NAS is going to have the NAS as the digital end of the PCM connection, it will have the high transmit, low receive. (I believe the 33.6 symbol table is disabled in V.90 in case you're wondering why I changed that speed.) -MZ -- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ==================================================================== - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Oct 11 21:08:58 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA06158 for ; Sun, 11 Oct 1998 21:08:58 -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 SAA13958; Sun, 11 Oct 1998 18:03:27 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA04980 for ietf-radius-outgoing; Sun, 11 Oct 1998 18:00:11 -0700 (PDT) From: Outpost18@ibm.net Message-Id: <199810120050.AAA28646@vtx-sdp.worldaccess.nl> Date: Sun, 11 Oct 98 17:37:43 EST To: Recipients@globalwest.com Subject: (radius) Express mail Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Outpost18@ibm.net Regardless of your present career or position, I have something that can LIGHT YOUR FIRE and help you achieve the income, wealth and life style that you so richly deserve. Hello, My name is Michael and I was a practicing physician for many years, before I retired to do this ! Now I enjoy a life of unparalled freedom with my family and associates, never worried or fearful of POVERTY or rejection ! Through this UNIQUE business venture that a friend shared with me two years ago, I have learned the secrets of success, and I am willing to do the same with a limited number of achievers. This is NOT MLM or network marketing ! You can work from home OR office. Most of my associates are earning $1- $5,000 per week in less than 30 days ! Some associates have earned over $50,000 in one month ! The greatest mistake I have found to achieving wealth is not having the blueprint or plans to get there. People need a TURNKEY MASTERMARKETING SYSTEM that takes all the guess work out of success. Your participation into our business venture is by invitation only. At the very least, you must be at least 18 years of age and have the ability to make a moderate ONE TIME INVESTMENT into starting your own company. Either myself or one of my associates will get back to you within 24 to 48 hours. I look forward to our conversation and wish you and your loved ones the very best. Regards, Dr. Michael ************ Call 1- 800- 498 -4753 ************ * If the line is busy, our system will automatically pick up your number and we will call you back. Thank you for your patience. ** To be removed from further mailings, simply put a remove in the subject and forward to remove-me.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Oct 12 11:04:16 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA21376 for ; Mon, 12 Oct 1998 11:04:15 -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 HAA23804; Mon, 12 Oct 1998 07:57:42 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA01914 for ietf-radius-outgoing; Mon, 12 Oct 1998 07:42:25 -0700 (PDT) Message-Id: <199810121440.KAA20646@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-tunnel-imp-04.txt Date: Mon, 12 Oct 1998 10:40:33 -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 : Implementation of L2TP Compulsory Tunneling via RADIUS Author(s) : B. Aboba, G. Zorn Filename : draft-ietf-radius-tunnel-imp-04.txt Pages : 18 Date : 09-Oct-98 This document discusses implementation issues arising in the provi- sioning of compulsory tunneling in dial-up networks using the L2TP protocol. This provisioning can be accomplished via the integration of RADIUS and tunneling protocols. Implementation issues encountered with other tunneling protocols are left to separate documents. Internet-Drafts are 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-tunnel-imp-04.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-tunnel-imp-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-tunnel-imp-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: <19981009163821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-tunnel-imp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-tunnel-imp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981009163821.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 Mon Oct 12 11:20:08 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA21969 for ; Mon, 12 Oct 1998 11:20:07 -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 IAA24158; Mon, 12 Oct 1998 08:13:11 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA03068 for ietf-radius-outgoing; Mon, 12 Oct 1998 08:00:52 -0700 (PDT) Message-ID: From: "Nelson, David" To: "'ietf-radius@livingston.com'" Subject: FW: (radius) Extensions draft Date: Mon, 12 Oct 1998 10:57:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2217.0) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" MegaZone brings up a question regarding the following: > String > > The String field is encoded as ASCII characters. The connection > speed SHOULD be included at the beginning of the first Connect- > Info attribute in the packet. If the Transmit and Receive > connection speeds differ, they may both be included in the first > attribute with the receive speed first (the speed the NAS modem > receives at), a slash (/), the transmit speed, then optionally > other information. > > For example, "28800 V42BIS/LAPM" or "52000/33600 V90" > That set me to pondering. I don't recall the details of the original discussion of this feature, as I think it started a couple of years ago. But I seem to recall that the intent was for the NAS to pass along connection information from the "modem", and to do so without much, if any, processing or string manipulation. In some cases the "modem" may be tightly integrated to the NAS, and the "modem" software/firmware may be under the control or authorship of the NAS vendor. In other cases the "modem" may be an external device or a standard chip set, in which case the connect messages are not customizable. Is it the intent of this section of the ID that the NAS be responsible for conforming the connection information to a standardized ASCII format, or is it the intent that the NAS simply pass along the ASCII connect string verbatim as provided by the modem? I would argue for the latter, to preserve generality of application and the notion that the NAS is "simple". Parsing and reformatting connect strings from various kinds of modems does seem to stretch the notion of "simple". Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Oct 12 17:11:38 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA04967 for ; Mon, 12 Oct 1998 17:11: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 OAA11087; Mon, 12 Oct 1998 14:06:31 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA19290 for ietf-radius-outgoing; Mon, 12 Oct 1998 14:04:49 -0700 (PDT) Message-Id: <199810122103.RAA18741@clipper.hq.tis.com> X-Sender: balenson@pop.hq.tis.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Mon, 12 Oct 1998 17:04:30 -0400 To: ietf-radius@livingston.com From: "David M. Balenson" Subject: (radius) NDSS '99 Registration Now Taking Place! Cc: balenson@tis.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David M. Balenson" R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 1999 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 3-5, 1999 Catamaran Resort Hotel San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Steve Kent, BBN Technologies Gene Tsudik, USC/Information Sciences Institute ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss99 EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 1999 The 6th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. KEYNOTE SPEAKER: Whitfield Diffie, Sun Microsystems. Co-author of "Privacy on the Line: The Politics of Wiretapping and Encryption." THIS YEAR'S TOPICS INCLUDE: - Secure Password-Based Protocol for Downloading a Private Key - A Real-World Analysis of Kerberos Password Security - Secure Remote Access to an Internal Web Server - Security and the User - Experimenting with Shared Generation of RSA Keys - Addressing the Problem of Undetected Signature Key Compromise - Practical Approach to Anonymity in Large Scale Electronic Voting Schemes - New Approaches to BGP Security - Distributed Policy Management for Java 1.2 - Distributed Execution with Remote Audit - Trust-Based Authentication in Open Networks - A Network Security Research Agenda - PGRIP: PNNI Global Routing Infrastructure Protection - A Cryptographic Countermeasure Against Connection Depletion Attacks - IPSec: Friend or Foe? EXPANDED PRE-CONFERENCE TECHNICAL TUTORIALS: - Principles of Network Security (Dr. Stephen T. Kent, BBN Technologies) - Optical Network Security (Jeff Ingle and Dr. Eric Harder, NSA) - Electronic Payment Systems (Dr. B. Clifford Neuman, USC/ISI) - Windows NT Security - Cryptography - Web Security and Beyond (Dr. B. Clifford Neuman, USC/ISI) - JAVA Security FOR MORE INFORMATION contact the Internet Society: Internet Society, 12020 Sunrise Valley Drive, Reston, VA, 20191 USA Phone: +1-703-648-9888 Fax: +1-703-648-9887 E-mail: ndss99reg@isoc.org URL: http://www.isoc.org/ndss99/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-648-9888 or send e-mail to carla@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. ---------------------------------------------------------------------------- David M. Balenson, Publicity Chair, NDSS '99 TIS Labs at Network Associates, Inc. 3060 Washington Road, Glenwood, MD 21738 USA balenson@tis.com; 301-854-5358; fax 301-854-5363 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Oct 12 18:39:35 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA06230 for ; Mon, 12 Oct 1998 18:39:34 -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 PAA15665; Mon, 12 Oct 1998 15:23:59 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA29143 for ietf-radius-outgoing; Mon, 12 Oct 1998 15:23:23 -0700 (PDT) Message-ID: <001d01bdf62e$5429dc80$86f61fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Carl Rigney" , Subject: Re: (radius) draft-ietf-radius-ext-02.txt ready for review Date: Mon, 12 Oct 1998 15:17:34 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_001A_01BDF5F3.70657FC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_001A_01BDF5F3.70657FC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Carl Rigney writes: >With extreme apologies for the very long delay, I'm pleased to >announce that the RADIUS Extensions draft is ready for review. >I've placed a copy at >ftp://ftp.livingston.com/pub/radius/draft-ietf-radius-ext-02.txt >and it should be appearing in the usual Internet-Draft locations >soon. > >This draft includes the renumbering of attributes to avoid conflict >with the tunneling attributes, and incorporates the >Acct-Interim-Interval draft and EAP draft. There may still be rough >edges but I wanted to get it out to the list for review before going >out of town 10/8-15; email me any corrections or suggestions or >improvement by 10/16 and I'll update it when I'm back and get it out >(finally) to last call. > >I think ARAP's use of the Request Authenticator on page 5 in section >2.2 needs to be clarified with regard to byte order, Also, I notice that you specify what should be done if the ARAP user is _not_ a guest, but not what should be done if (s)he _is_ a guest. What happens? It would make the most sense to me to send an Access-Request w/o extraneous attributes like username and password, but that seems to be against the law. >and there's still >a place or two where EAP needs to be smoothed; in particular 1) how to >deal with EAP-Message in Access-Requests with no User-Name, and 2) >the EAP-Message with an EAP-Start can have a length of 2, which no other >string in RADIUS permits. Will having a string with no data in it >cause grief for anyone's implementation? > >When I get back I'll send out the RADIUS and RADIUS Accounting updates; >the changes to those are mostly minor so I wanted to get Extensions out >first. I should have them ready for last call by the end of October. > >-- >Carl Rigney >cdr@livingston.com > >"October 1998. Thanks for asking." >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > ------=_NextPart_000_001A_01BDF5F3.70657FC0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19981012T221734Z END:VCARD ------=_NextPart_000_001A_01BDF5F3.70657FC0-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 14 00:36:29 1998 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA01702 for ; Wed, 14 Oct 1998 00:36:29 -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 VAA05824; Tue, 13 Oct 1998 21:31:08 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA00577 for ietf-radius-outgoing; Tue, 13 Oct 1998 21:28:55 -0700 (PDT) From: liquid_32@hotmail.com Date: Wed, 14 Oct 1998 00:45:24 -0500 (CDT) Message-Id: <199810140545.AAA24203@mail.hic.net> To: liquid_32@hotmail.com Subject: (radius) We Buy Anything! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: liquid_32@hotmail.com We buy anything!!!!! DISTRESSED MERCHANDISE----CLOSE-OUTS------FACTORY RETURNS We pay top dollar for your merchandise!! GUARANTEED! Representatives Nationwide ready to pay immediate cash! PHONE: 818-506-7885 FAX: 818-980-8033 E-MAIL: liquidator@hotmail.com http://www.ieleads.com/liquidator - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Oct 15 10:58:15 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA09798 for ; Thu, 15 Oct 1998 10:58:14 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id HAA17057; Thu, 15 Oct 1998 07:50:37 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA00948 for ietf-radius-outgoing; Thu, 15 Oct 1998 07:41:25 -0700 (PDT) Message-Id: <199810151439.KAA09362@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-ms-vsa-00.txt Date: Thu, 15 Oct 1998 10:39:21 -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 : Microsoft Vendor-specific RADIUS Attributes Author(s) : G. Zorn Filename : draft-ietf-radius-ms-vsa-00.txt Pages : 40 Date : 14-Oct-98 This document describes the set of Microsoft vendor-specific RADIUS attributes. These attributes are designed to support Microsoft propri- etary dial-up protocols and/or provide support for features which is not provided by the standard RADIUS attribute set [3]. It is expected that this memo will be updated whenever Microsoft defines a new vendor-spe- cific attribute, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. Internet-Drafts are 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-ms-vsa-00.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-ms-vsa-00.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-ms-vsa-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart 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: <19981014141850.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-ms-vsa-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-ms-vsa-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981014141850.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 Fri Oct 16 11:24:57 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA13985 for ; Fri, 16 Oct 1998 11:24:56 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id IAA25058; Fri, 16 Oct 1998 08:19:21 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA22132 for ietf-radius-outgoing; Fri, 16 Oct 1998 08:11:15 -0700 (PDT) From: info@cyber-host.net Message-Id: <199810161855.OAA06112@mars.your-mail.com> To: user@the.internet Date: Fri, 16 Oct 98 06:00:57 EST Subject: (radius) AD: Discover Your Family History - Rated "Cool Site of the Week" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: info@cyber-host.net This message is sent in compliance of the new e-mail bill: SECTION 301, Paragraph (a)(2)(C) of s. 1618 Sender : Hoek Industries, P.O. Box 130544, St Paul, MN 55113 Phone : 1-612-646-8174 E-mail : info@cyber-host.net To be removed from our mailing list, simply reply with "REMOVE" in the subject. Come visit our website at http://www.cyber-host.net/history/trace.html Free Search Do you know WHO your ancestors are and WHAT they did? Do you know WHEN your surname first appeared? Are you curious about WHERE your family roots originate? Now you can fill in the missing pieces of this puzzle. Join the satisfied multitudes who have discovered their complete Family Surname History. All Nationalities. It's easy. Just key your last name into our online index, and in seconds we will tell you it's origin and much MORE. See if we've researched your complete family name history during our 25 years of professional research. Read a sample history, plus - FREE Coat of Arms keychain with your family's most ancient coat of arms & crest. All in full color. Your family name history parchment is 11 x 17", approximately 1700 words. It is beautifully ILLUMINATED by your most ancient Coat of Arms in full authentic Heraldic Colors. Over 500 URLs on family and heraldic history. Please come visit our website at http://www.cyber-host.net/history/trace.html Free Search Hall of Names International Inc. 1-888-My-Roots (1-888-697-6687) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Oct 18 22:17:40 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA06077 for ; Sun, 18 Oct 1998 22:17:39 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id TAA04585; Sun, 18 Oct 1998 19:12:15 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA12144 for ietf-radius-outgoing; Sun, 18 Oct 1998 19:06:01 -0700 (PDT) From: motzartk626@hotmail.com Date: Sun, 18 Oct 1998 22:10:00 -0400 (EDT) Message-Id: <199810190210.WAA11088@mars.ezenet.com> To: motzartk626@hotmail.com Subject: (radius) FREE Equipment Buyers Guide Catalog... Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: motzartk626@hotmail.com ----------------------------------------------------------- "The Equipment Buyers Guide". Mpls. MN.55438. This message is sent in compliance of the new e-mail bill: SECTION301 Sender:EBG S.Wyoming#157 Mpls. MN .55438 Hours M-F 9-5 612.914.0494email:<> Section 301,Paragraph (a)(2)(C) of s. 618 ------------------------------------------------------------ Just released......... We invite you to try out the new "Equipment Buyers Guide Catalog" absolutely free! ================================================ This catalog is a beta version of the new buyers guide .It contains literally hundreds of business related products and services. We are distributing this free beta copy to test market the new format before we put it into mass production. We would simply appreciate your feedback on how you like it. To keep the test results as valid as possible, we are sending this only to people we believe have an interest in items such as rack, conveyor shelving, forklifts, office equipment and other kinds of material handling equipment.. ============================================= PLUS....A BONUS! . A special free gift for helping us test market the catalog. We'll send you a special URL to the hottest "Insiders Monthly Liquidation Web Site" on the net! This is insider information that will amaze co-workers. You'll find and buy deals that will have your competitors green with envy. It's really cool. ============================================= Here's all you need to do.. #1) Print out this registration form. #2) Fill in the appropriate mailing information #3) Fax to EBG test promo offer OC2-90K 10-17 at 1-320-485-4860. That's it! You're done. It only takes 30 seconds of your time. You'll receive your free info pack in 3 to 5 days. COMPANY:_______________________________________ NAME:__________________________________________ TITLE:__________________________________________ ADDRESS:_______________________________________ CITY:_______________STATE:________ZIP:____________ PHONE:______________________FAX:________________ E-MAIL ADDRESS:_________________________________________ MAIN BIZ ITEMS OF INTEREST? ________________________________________ Remove instructions: We have made every attempt to avoid mailing to those who do not qualify for or have interest in this offer. To be permanently removed from this and any future lists, send a reply to <> with REMOVE in the subject line. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Oct 23 18:51:31 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA07838 for ; Fri, 23 Oct 1998 18:51:31 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id PAA21501; Fri, 23 Oct 1998 15:45:52 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA25355 for ietf-radius-outgoing; Fri, 23 Oct 1998 15:38:59 -0700 (PDT) Message-ID: <001301bdfed5$4126e880$86f61fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "'ietf-radius'" Subject: (radius) Username/User-Password attributes Date: Fri, 23 Oct 1998 15:33:48 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_000E_01BDFE9A.875BC900" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_000E_01BDFE9A.875BC900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Trying to figure out how to support DNIS/CLNI authentication, as well as "guest" accounts, it appears that the Username and *-Password attributes are pretty much superfluous in these cases. Does anyone else support these? How many servers will break if they get an Access-Request w/o them? Is there any interest in making Username a "0-1" attribute instead of "1"? -- A society, most of whose members spend a great deal of their time not on the spot, not here and now in the calculable future, but somwhere else, in the irrelevant other worlds of sport and soap opera, of mythology and metaphysical fantasy, will find it hard to resist the encroachments of those who would manipulate and control it. -- Aldous Huxley, Foreword to "Brave New World", 1946 ------=_NextPart_000_000E_01BDFE9A.875BC900 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19981023T223346Z END:VCARD ------=_NextPart_000_000E_01BDFE9A.875BC900-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Oct 23 19:12:26 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA08075 for ; Fri, 23 Oct 1998 19:12:25 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id QAA22347; Fri, 23 Oct 1998 16:06:55 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA27286 for ietf-radius-outgoing; Fri, 23 Oct 1998 16:03:57 -0700 (PDT) From: Aydin Edguer Message-Id: <199810232302.TAA02090@harlequin.MorningStar.Com> Subject: Re: (radius) Username/User-Password attributes To: gwz@pinky.microsoft.com Date: Fri, 23 Oct 1998 19:02:38 -0400 (EDT) Cc: ietf-radius@livingston.com In-Reply-To: <001301bdfed5$4126e880$86f61fac@glennz-2.dns.microsoft.com> from "Glen Zorn" at Oct 23, 98 03:33:48 pm 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 > Trying to figure out how to support DNIS/CLNI authentication, as well as > "guest" accounts, it appears that the Username and *-Password attributes > are pretty much superfluous in these cases. > Does anyone else support these? Yes. Ascend supports DNIS and CLID authentication (and has for at least three years). Ascend sends the DNIS or CLID information in the Access-Request as the User-Name attribute along with a standard User-Password. For example, if the NAS is configured to use DNIS to pre-authenticate a call, the number that was dialed would be placed in the User-Name. If the number was 5551212, then the User-Name would be "5551212" and the Password would be "Ascend-DNIS". The use of User-Name could be fairly generic between all NAS vendors and is very easy to implement. The use of "Ascend-*" as a User-Password is not generic and most vendors would probably not agree to such a value. The option on the RADIUS server side would be to ignore the password if other NAS vendors use a different password. > How many servers will break if they get an Access-Request w/o them? Most. The typical index into the RADIUS user database is the User-Name attribute. It is a requirement for Livingston 1.x and Merit 2/3/4.x RADIUS servers at least. > Is there any interest in making Username a "0-1" attribute instead of "1"? I do not have any interest at this stage of the RADIUS standards game. I could understand relaxing the requirement to include a User-Password or CHAP-Password, but there are other ways around the problem. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Oct 23 19:20:51 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA08177 for ; Fri, 23 Oct 1998 19:20:50 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id QAA22625; Fri, 23 Oct 1998 16:15:16 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA28030 for ietf-radius-outgoing; Fri, 23 Oct 1998 16:11:36 -0700 (PDT) From: William Bulley Message-Id: <199810232312.TAA01071@ohm.merit.edu> Subject: Re: (radius) Username/User-Password attributes To: gwz@pinky.microsoft.com Date: Fri, 23 Oct 1998 19:12:30 -0400 (EDT) Cc: ietf-radius@livingston.com In-Reply-To: <001301bdfed5$4126e880$86f61fac@glennz-2.dns.microsoft.com> from "Glen Zorn" at Oct 23, 98 03:33:48 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William Bulley According to Glen Zorn: > > Trying to figure out how to support DNIS/CLNI authentication, as well as > "guest" accounts, it appears that the Username and *-Password attributes are > pretty much superfluous in these cases. Does anyone else support these? > How many servers will break if they get an Access-Request w/o them? Is > there any interest in making Username a "0-1" attribute instead of "1"? I am pretty sure that we should keep User-Name and *-Password present: 1) for if we abandon *-Password we lose the security of MD-5 and RADIUS 2) lots of stuff depends upon User-Name being present (at a minimum) I would not object to setting User-Name to "MaBell" when using DNIS/CLNI authentication, but I would think eliminating it altogether would be a radical change. Maybe we could discuss this elsewhere? (e.g., ietf-aaa)? Regards, web... -- William Bulley Senior Systems Research Programmer Merit Network, Inc. Email: web@merit.edu 4251 Plymouth Road, Suite C Phone: (734) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (734) 647-3185 [ Reuters, London, February 29, 1998: Scientists have announced discovering ] [ a meteorite which will strike the earth in March, 2028. Millions of UNIX ] [ coders expressed relief for being spared the UNIX epoch "crisis" of 2038. ] - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Oct 23 20:52:30 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA09183 for ; Fri, 23 Oct 1998 20:52:30 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id RAA24630; Fri, 23 Oct 1998 17:47:05 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA03673 for ietf-radius-outgoing; Fri, 23 Oct 1998 17:46:36 -0700 (PDT) Message-ID: <3631250F.1EB7DC04@iea-software.com> Date: Fri, 23 Oct 1998 17:53:35 -0700 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 To: gwz@pinky.microsoft.com CC: ietf-radius@livingston.com Subject: Re: (radius) Username/User-Password attributes References: <199810232302.TAA02090@harlequin.MorningStar.Com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Script: \\FilterScript.mml X-DomainScript: pinky.microsoft.com\\script.mml X-UserScript: livingston.com\ietf-radius\script.mml Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Aydin Edguer wrote: > > Yes. Ascend supports DNIS and CLID authentication (and has for at least > three years). > > Ascend sends the DNIS or CLID information in the Access-Request as the > User-Name attribute along with a standard User-Password. > > For example, if the NAS is configured to use DNIS to pre-authenticate > a call, the number that was dialed would be placed in the User-Name. > > If the number was 5551212, then the User-Name would be "5551212" and > the Password would be "Ascend-DNIS". This is what I prefer to see. It makes life REALLY easy to diagnose and interpret this. Just set the username to the same as the > The use of User-Name could be fairly generic between all NAS vendors and > is very easy to implement. The use of "Ascend-*" as a User-Password is > not generic and most vendors would probably not agree to such a value. > The option on the RADIUS server side would be to ignore the password if > other NAS vendors use a different password. The password really isn't relevant and in most cases is ignored. It COULD be definable on the NAS for added security, though. > > How many servers will break if they get an Access-Request w/o them? > > Most. The typical index into the RADIUS user database is the User-Name > attribute. It is a requirement for Livingston 1.x and Merit 2/3/4.x > RADIUS servers at least. RadiusNT does require it unless Caller-ID Authentication is enabled. -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Oct 25 10:41:15 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA02754 for ; Sun, 25 Oct 1998 10:41:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id HAA16105; Sun, 25 Oct 1998 07:35:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA22917 for ietf-radius-outgoing; Sun, 25 Oct 1998 07:32:33 -0800 (PST) Message-Id: <199810251538.KAA14185@beowulf.cryptocard.com> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) Username/User-Password attributes In-reply-to: Your message of "Fri, 23 Oct 1998 19:12:30 EDT." <199810232312.TAA01071@ohm.merit.edu> Date: Sun, 25 Oct 1998 10:38:05 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok William Bulley wrote: > I am pretty sure that we should keep User-Name and *-Password present: > > 1) for if we abandon *-Password we lose the security of MD-5 and RADIUS > > 2) lots of stuff depends upon User-Name being present (at a minimum) I agree with most of this. However, I'm all for making the *-Password attributes '0-1', instead of '1' in Access-Request packets. We're a token card vendor, and the current radius spec forces customers to type in a password *prior* to performing challenge-response authentication. This is annoying. I'd like to see a NAS configured so that it can query a RADIUS server as to which prompt to use when asking for a password. This will can each NAS multi-lingual support, and will allow us to send an X9.9 challenge as part of the password prompt. Right now we can hack around this problem, but it's a continual source of frustration. It would also be useful to not require a User-Name, and define new explicit authentication conversations between the NAS and the server, instead of the current implicit password-only authentication. The utility of a robust conversation mechanism can be seen from the efforts currently being put into working around the strict username/password only authentication. However, this is probably beyond the scope of the current discussion. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Oct 26 09:53:15 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA20133 for ; Mon, 26 Oct 1998 09:53:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id GAA05243; Mon, 26 Oct 1998 06:47:29 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA29012 for ietf-radius-outgoing; Mon, 26 Oct 1998 06:43:39 -0800 (PST) Date: Mon, 26 Oct 1998 06:40:44 -0800 (PST) From: "pcalhoun@eng.sun.com" Subject: Re: (radius) Username/User-Password attributes To: Alan DeKok Cc: ietf-radius@livingston.com In-Reply-To: "Your message with ID" <199810251538.KAA14185@beowulf.cryptocard.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "pcalhoun@eng.sun.com" > William Bulley wrote: > > I am pretty sure that we should keep User-Name and *-Password present: > > > > 1) for if we abandon *-Password we lose the security of MD-5 and RADIUS > > > > 2) lots of stuff depends upon User-Name being present (at a minimum) > > I agree with most of this. However, I'm all for making the > *-Password attributes '0-1', instead of '1' in Access-Request packets. > > We're a token card vendor, and the current radius spec forces customers > to type in a password *prior* to performing challenge-response > authentication. This is annoying. > > I'd like to see a NAS configured so that it can query a RADIUS > server as to which prompt to use when asking for a password. This > will can each NAS multi-lingual support, and will allow us to send an > X9.9 challenge as part of the password prompt. > > Right now we can hack around this problem, but it's a continual > source of frustration. > > It would also be useful to not require a User-Name, and define new > explicit authentication conversations between the NAS and the server, > instead of the current implicit password-only authentication. The > utility of a robust conversation mechanism can be seen from the > efforts currently being put into working around the strict > username/password only authentication. > > However, this is probably beyond the scope of the current > discussion. This is exactly what EAP was meant for. I would propose the use of EAP as opposed to hacking RADIUS more than we have to. PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Oct 26 10:25:11 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA20964 for ; Mon, 26 Oct 1998 10:25:10 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id HAA05926; Mon, 26 Oct 1998 07:19:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA00960 for ietf-radius-outgoing; Mon, 26 Oct 1998 07:16:29 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Mon, 26 Oct 1998 10:08 EST Subject: Re: (radius) Username/User-Password attributes Content-Type: text/plain Message-ID: <363492630.67a0@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff While we already have a problem with the installed base, I would support defining specific strings that mean "not a real value" for use in the user and pw attributes. Every vendor has chosen a different way to deal with this, and some vendors have chosen more than one. Ridiculous. We ought to at least provide a target to which all can gradually evolve. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Oct 26 14:59:13 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA28142 for ; Mon, 26 Oct 1998 14:59:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id LAA15593; Mon, 26 Oct 1998 11:53:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA01039 for ietf-radius-outgoing; Mon, 26 Oct 1998 11:49:15 -0800 (PST) Date: Mon, 26 Oct 98 14:46:17 EST From: David Bolen To: Barney Wolff Cc: ietf-radius@livingston.com Subject: Re: (radius) Username/User-Password attributes In-Reply-To: Your message of Mon, 26 Oct 1998 10:08 EST Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: David Bolen Barney Wolff writes: > While we already have a problem with the installed base, I would support > defining specific strings that mean "not a real value" for use in the > user and pw attributes. The only risk with that is conflicting with something that someone needs as a true value, so I prefer the option of the NAS permitting the value to be used to be configurable. Then, you just configure the NAS and your RADIUS server with matching values (that work in the specified system) and the server can detect their existence. I suppose I'd still take statically defined values over no such specification, but I think the configurable is better. > Every vendor has chosen a different way to > deal with this, and some vendors have chosen more than one. Ridiculous. We've been using the above approach (configurable values) with one vendor's gear for a few years now without any problems. The box can be configured with how much it should do before the initial request (from nothing to both user/password prompts) and with default values for user/password. By being configured with the default values, the server can thus detect how much of the information it needs to do extra challenges to get (e.g., how much of the login sequence it is in control of, including prompting), and how much the NAS already prompted for. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Oct 27 12:11:15 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA20048 for ; Tue, 27 Oct 1998 12:11:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id JAA22118; Tue, 27 Oct 1998 09:05:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA20862 for ietf-radius-outgoing; Tue, 27 Oct 1998 09:03:20 -0800 (PST) From: "Brian K McIntire" To: , , , , Subject: (radius) Membership Date: Tue, 27 Oct 1998 11:58:52 -0600 Message-ID: <000001be01d3$7550a820$169695c0@dragon.commnet.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 V4.72.3155.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Brian K McIntire" How do I sign up? =================================================================== Brian K. McIntire 317-558-5050 x113 bmcintire@commnet.com Systems Engineer III CommNetPlus, Indianapolis, IN http://www.commnet.com Experts in Remote Access; NetWork Design; Security; Implementation Serving North America and parts of Canada. Reselling to the world. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Oct 27 14:13:45 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA23220 for ; Tue, 27 Oct 1998 14:13:44 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id LAA26797; Tue, 27 Oct 1998 11:08:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA05660 for ietf-radius-outgoing; Tue, 27 Oct 1998 11:07:25 -0800 (PST) Date: Tue, 27 Oct 1998 11:07:11 -0800 (PST) Message-Id: <199810271907.LAA02984@mailsrv.acc.com> X-Sender: lcuff@acc.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Dale E. Reed Jr." From: Leonard Cuff Subject: Re: (radius) Username/User-Password attributes Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Leonard Cuff Most of what I know about cryptography comes from browsing in Bruce Schneier's "Applied Cryptography" (so therefore I DON'T consider myself an expert), but as I see it, having a fixed value in the password field (such as "Ascend-DNIS") makes possible the recovery of the shared secret by hackers through a "known plaintext" attack. Basically they can snoop the message on the net, then pick shared secrets via any favorite method and keeping running MD5 'till the known plaintext pops out, shazaam they know the shared secret. RADIUS does have a 128 byte keyspace, but given the reality of how people pick their key - short lengths, all printable characters, what's the vulnerability? I'd like to have someone who IS a cryptography expert comment on the security aspects here. Leonard At 05:53 PM 10/23/98 -0700, Dale E. Reed Jr. wrote: >Aydin Edguer wrote: >> >> Yes. Ascend supports DNIS and CLID authentication (and has for at least >> three years). >> >> Ascend sends the DNIS or CLID information in the Access-Request as the >> User-Name attribute along with a standard User-Password. >> >> For example, if the NAS is configured to use DNIS to pre-authenticate >> a call, the number that was dialed would be placed in the User-Name. >> >> If the number was 5551212, then the User-Name would be "5551212" and >> the Password would be "Ascend-DNIS". > >This is what I prefer to see. It makes life REALLY easy to diagnose >and interpret this. Just set the username to the same as the > >> The use of User-Name could be fairly generic between all NAS vendors and >> is very easy to implement. The use of "Ascend-*" as a User-Password is >> not generic and most vendors would probably not agree to such a value. >> The option on the RADIUS server side would be to ignore the password if >> other NAS vendors use a different password. > >The password really isn't relevant and in most cases is ignored. It >COULD be definable on the NAS for added security, though. > >> > How many servers will break if they get an Access-Request w/o them? >> >> Most. The typical index into the RADIUS user database is the User-Name >> attribute. It is a requirement for Livingston 1.x and Merit 2/3/4.x >> RADIUS servers at least. > >RadiusNT does require it unless Caller-ID Authentication is enabled. > >-- >Dale E. Reed Jr. (daler@iea-software.com) >_________________________________________________________________ > IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs > Internet Solutions for Today | http://www.iea-software.com >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Oct 27 18:14:45 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA25890 for ; Tue, 27 Oct 1998 18:14:40 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id PAA06757; Tue, 27 Oct 1998 15:09:06 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA05124 for ietf-radius-outgoing; Tue, 27 Oct 1998 15:06:31 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Tue, 27 Oct 1998 17:00 EST Subject: Re: (radius) Username/User-Password attributes Content-Type: text/plain Message-ID: <363651f90.1075@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Without claiming any real expertise, I'll jump in. I see no added risk here - if one assumes the attacker can sniff the packets, it's a triviality to know your OWN password, so you can run the same attack by just dialing in. As the shared secret is set up by network operators, not users, the use of a short or guessable one is self-abuse. Barney Wolff > Date: Tue, 27 Oct 1998 11:07:11 -0800 (PST) > From: Leonard Cuff > > Most of what I know about cryptography comes from browsing in Bruce Schneier's > "Applied Cryptography" (so therefore I DON'T consider myself an expert), but > as I see it, having a fixed value in the password field (such as "Ascend-DNIS") > makes possible the recovery > of the shared secret by hackers through a "known plaintext" attack. Basically > they can snoop the message on the net, then pick shared secrets via any favorite > method and keeping running MD5 'till the known plaintext pops out, shazaam they > know the shared secret. RADIUS does have a 128 byte keyspace, but given the > reality > of how people pick their key - short lengths, all printable characters, > what's the > vulnerability? > > I'd like to have someone who IS a cryptography expert > comment on the security aspects here. > > Leonard - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Oct 27 18:50:16 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA26082 for ; Tue, 27 Oct 1998 18:50:15 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id PAA07757; Tue, 27 Oct 1998 15:44:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA09066 for ietf-radius-outgoing; Tue, 27 Oct 1998 15:44:38 -0800 (PST) Message-ID: <002f01be0203$73403de0$c889e9cc@titanium.techapp.com> From: "Russell J. LeBar" To: Subject: Re: (radius) Username/User-Password attributes Date: Tue, 27 Oct 1998 17:42:24 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002C_01BE01D1.28706600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Russell J. LeBar" This is a multi-part message in MIME format. ------=_NextPart_000_002C_01BE01D1.28706600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Who says the hacker is hacking his own ISP? Besides, we want to try to avoid giving hackers clues/exploits, no matter how trivial. -----Original Message----- From: Barney Wolff >Without claiming any real expertise, I'll jump in. I see no added risk >here - if one assumes the attacker can sniff the packets, it's a triviality >to know your OWN password, so you can run the same attack by just dialing >in. As the shared secret is set up by network operators, not users, the >use of a short or guessable one is self-abuse. From owner-ietf-radius@livingston.com Tue Oct 27 19:13:25 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA26216 for ; Tue, 27 Oct 1998 19:13:24 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id QAA08791; Tue, 27 Oct 1998 16:07:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA12232 for ietf-radius-outgoing; Tue, 27 Oct 1998 16:07:42 -0800 (PST) Message-ID: <80E3B3A23D94D1119A1E00805FBB58B09569C9@hstnhq01.splitrock.net> From: Tom Fraser To: "'Leonard Cuff'" , "Dale E. Reed Jr." Cc: ietf-radius@livingston.com Subject: RE: (radius) Username/User-Password attributes Date: Tue, 27 Oct 1998 18:06:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Tom Fraser The real preventative it seems is to remove the ASCII component (user id) somehow. The simplest method, from my perspective, would be to generate a CHAP request. This removes the user id from the packet and vendors can generically generate one from whatever type of user authorization profiles are being used (terminal login, DNIS, etc.). This maintains the RADIUS protocol as utilized in the field but removing an attribute that can allow hackers to fairly easily crack the secret. Tom Fraser tfraser@splitrock.net -----Original Message----- From: Leonard Cuff [SMTP:lcuff@acc.com] Sent: Tuesday, October 27, 1998 1:07 PM To: Dale E. Reed Jr. Cc: ietf-radius@livingston.com Subject: Re: (radius) Username/User-Password attributes Most of what I know about cryptography comes from browsing in Bruce Schneier's "Applied Cryptography" (so therefore I DON'T consider myself an expert), but as I see it, having a fixed value in the password field (such as "Ascend-DNIS") makes possible the recovery of the shared secret by hackers through a "known plaintext" attack. Basically they can snoop the message on the net, then pick shared secrets via any favorite method and keeping running MD5 'till the known plaintext pops out, shazaam they know the shared secret. RADIUS does have a 128 byte keyspace, but given the reality of how people pick their key - short lengths, all printable characters, what's the vulnerability? I'd like to have someone who IS a cryptography expert comment on the security aspects here. Leonard At 05:53 PM 10/23/98 -0700, Dale E. Reed Jr. wrote: >Aydin Edguer wrote: >> >> Yes. Ascend supports DNIS and CLID authentication (and has for at least >> three years). >> >> Ascend sends the DNIS or CLID information in the Access-Request as the >> User-Name attribute along with a standard User-Password. >> >> For example, if the NAS is configured to use DNIS to pre-authenticate >> a call, the number that was dialed would be placed in the User-Name. >> >> If the number was 5551212, then the User-Name would be "5551212" and >> the Password would be "Ascend-DNIS". > >This is what I prefer to see. It makes life REALLY easy to diagnose >and interpret this. Just set the username to the same as the > >> The use of User-Name could be fairly generic between all NAS vendors and >> is very easy to implement. The use of "Ascend-*" as a User-Password is >> not generic and most vendors would probably not agree to such a value. >> The option on the RADIUS server side would be to ignore the password if >> other NAS vendors use a different password. > >The password really isn't relevant and in most cases is ignored. It >COULD be definable on the NAS for added security, though. > >> > How many servers will break if they get an Access-Request w/o them? >> >> Most. The typical index into the RADIUS user database is the User-Name >> attribute. It is a requirement for Livingston 1.x and Merit 2/3/4.x >> RADIUS servers at least. > >RadiusNT does require it unless Caller-ID Authentication is enabled. > >-- >Dale E. Reed Jr. (daler@iea-software.com) >_________________________________________________________________ > IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs > Internet Solutions for Today | http://www.iea-software.com >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Oct 27 20:24:40 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA26704 for ; Tue, 27 Oct 1998 20:24:39 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id RAA11148; Tue, 27 Oct 1998 17:19:05 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA20597 for ietf-radius-outgoing; Tue, 27 Oct 1998 17:17:37 -0800 (PST) From: Barney Wolff Message-Id: <199810280116.UAA14679@pit.databus.com> Subject: Re: (radius) Username/User-Password attributes Date: Tue, 27 Oct 1998 20:16:38 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <002f01be0203$73403de0$c889e9cc@titanium.techapp.com> from "Russell J. LeBar" at "Oct 27, 98 05:42:24 pm" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Oh, nonsense. The attacker can always sign up briefly. Or, if you like, the attack can be done without knowledge of the user's password just be looking for an all-ascii result after decryption, on a few captured access-requests. But even 8 lower-case letters gives 200 billion possibilities, and mixed case or extending to 12 char puts it out of current technological reach. A properly-chosen shared secret is longer than 12 and mixed case, digits and specials. Anybody wants to brute-force that, go right ahead and try. The best algorithm in the world won't help if you choose "maintenance" as your password or post-it on the monitor. Barney > Who says the hacker is hacking his own ISP? Besides, we want to try to avoid > giving hackers clues/exploits, no matter how trivial. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 28 04:13:56 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA07195 for ; Wed, 28 Oct 1998 04:13:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id BAA21380; Wed, 28 Oct 1998 01:08:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA10055 for ietf-radius-outgoing; Wed, 28 Oct 1998 01:07:00 -0800 (PST) From: "Bernard Aboba" To: "Leonard Cuff" , "Dale E. Reed Jr." Cc: Subject: Re: (radius) Username/User-Password attributes Date: Tue, 27 Oct 1998 17:19:52 -0800 Message-Id: <01be0211$1056dbe0$0f8939cc@e1kj2.internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-Mimeole: Produced By Microsoft MimeOLE V4.71.1712.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" The vulnerability depends completely on the shared secret chosen. If it is an English word, then a dictionary attack would be very easy to mount. I'm told that English only has 1.3 bits of entropy/character -- which means that a 20 character password would be the equivalent of a 26 bit key -- which is crackable in seconds. -----Original Message----- From: Leonard Cuff To: Dale E. Reed Jr. Cc: ietf-radius@livingston.com Date: Tuesday, October 27, 1998 1:05 PM Subject: Re: (radius) Username/User-Password attributes > >Most of what I know about cryptography comes from browsing in Bruce Schneier's >"Applied Cryptography" (so therefore I DON'T consider myself an expert), but >as I see it, having a fixed value in the password field (such as "Ascend-DNIS") >makes possible the recovery >of the shared secret by hackers through a "known plaintext" attack. Basically >they can snoop the message on the net, then pick shared secrets via any favorite >method and keeping running MD5 'till the known plaintext pops out, shazaam they >know the shared secret. RADIUS does have a 128 byte keyspace, but given the >reality >of how people pick their key - short lengths, all printable characters, >what's the >vulnerability? > >I'd like to have someone who IS a cryptography expert >comment on the security aspects here. > >Leonard > >At 05:53 PM 10/23/98 -0700, Dale E. Reed Jr. wrote: >>Aydin Edguer wrote: >>> >>> Yes. Ascend supports DNIS and CLID authentication (and has for at least >>> three years). >>> >>> Ascend sends the DNIS or CLID information in the Access-Request as the >>> User-Name attribute along with a standard User-Password. >>> >>> For example, if the NAS is configured to use DNIS to pre-authenticate >>> a call, the number that was dialed would be placed in the User-Name. >>> >>> If the number was 5551212, then the User-Name would be "5551212" and >>> the Password would be "Ascend-DNIS". >> >>This is what I prefer to see. It makes life REALLY easy to diagnose >>and interpret this. Just set the username to the same as the >> >>> The use of User-Name could be fairly generic between all NAS vendors and >>> is very easy to implement. The use of "Ascend-*" as a User-Password is >>> not generic and most vendors would probably not agree to such a value. >>> The option on the RADIUS server side would be to ignore the password if >>> other NAS vendors use a different password. >> >>The password really isn't relevant and in most cases is ignored. It >>COULD be definable on the NAS for added security, though. >> >>> > How many servers will break if they get an Access-Request w/o them? >>> >>> Most. The typical index into the RADIUS user database is the User-Name >>> attribute. It is a requirement for Livingston 1.x and Merit 2/3/4.x >>> RADIUS servers at least. >> >>RadiusNT does require it unless Caller-ID Authentication is enabled. >> >>-- >>Dale E. Reed Jr. (daler@iea-software.com) >>_________________________________________________________________ >> IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs >> Internet Solutions for Today | http://www.iea-software.com >>- >>To unsubscribe, email 'majordomo@livingston.com' with >>'unsubscribe ietf-radius' in the body of the message. >> >> > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 28 08:28:49 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA08188 for ; Wed, 28 Oct 1998 08:28:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id FAA24503; Wed, 28 Oct 1998 05:23:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA16856 for ietf-radius-outgoing; Wed, 28 Oct 1998 05:21:08 -0800 (PST) Date: Wed, 28 Oct 1998 05:17:36 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199810281317.FAA08147@hsmpka.eng.sun.com> To: "Barney Wolff" Cc: ietf-radius@livingston.com X-Mailer: Sun NetMail 2.1.6 Subject: Re: (radius) Username/User-Password attributes Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) I agree with Barney. You have 128 bits to play with. Even if all of these bits were in ascii I really don't see the issue. If a manufacturer's default password is inadequate, change it (I am sure this is an option, as I recall from my experience building NASes they have plenty of options). PatC >Oh, nonsense. The attacker can always sign up briefly. >Or, if you like, the attack can be done without knowledge of the user's >password just be looking for an all-ascii result after decryption, on >a few captured access-requests. >But even 8 lower-case letters gives 200 billion possibilities, and >mixed case or extending to 12 char puts it out of current technological >reach. A properly-chosen shared secret is longer than 12 and mixed >case, digits and specials. Anybody wants to brute-force that, go >right ahead and try. > >The best algorithm in the world won't help if you choose "maintenance" as >your password or post-it on the monitor. >Barney > >> Who says the hacker is hacking his own ISP? Besides, we want to try to avoid >> giving hackers clues/exploits, no matter how trivial. >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 28 09:49:34 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA08912 for ; Wed, 28 Oct 1998 09:49:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id GAA26315; Wed, 28 Oct 1998 06:43:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA20074 for ietf-radius-outgoing; Wed, 28 Oct 1998 06:39:51 -0800 (PST) Date: Wed, 28 Oct 1998 06:40:12 -0500 From: Paul Krumviede Subject: Re: (radius) Username/User-Password attributes To: ietf-radius@livingston.com Message-id: <3637029C.4CD974AE@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.06 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <01be0211$1056dbe0$0f8939cc@e1kj2.internaut.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede Yes, entropy of English (or most other languages) is quite low. One can find a collision in MD5 much more quickly than one can find the shared secret, but if the shared secret is not recognizable as such finding a collision won't help much. Joe Touch had a paper a few years ago on MD5 throughput from which one might be able to derive an estimate of how long it would take to brute force attack MD5 (without any pre-computation). -paul Bernard Aboba wrote: > > The vulnerability depends completely on the shared secret > chosen. If it is an English word, then a dictionary attack > would be very easy to mount. I'm told that English only > has 1.3 bits of entropy/character -- which means that a > 20 character password would be the equivalent of a > 26 bit key -- which is crackable in seconds. > > -----Original Message----- > From: Leonard Cuff > To: Dale E. Reed Jr. > Cc: ietf-radius@livingston.com > Date: Tuesday, October 27, 1998 1:05 PM > Subject: Re: (radius) Username/User-Password attributes > > > > >Most of what I know about cryptography comes from browsing in Bruce > Schneier's > >"Applied Cryptography" (so therefore I DON'T consider myself an expert), > but > >as I see it, having a fixed value in the password field (such as > "Ascend-DNIS") > >makes possible the recovery > >of the shared secret by hackers through a "known plaintext" attack. > Basically > >they can snoop the message on the net, then pick shared secrets via any > favorite > >method and keeping running MD5 'till the known plaintext pops out, shazaam > they > >know the shared secret. RADIUS does have a 128 byte keyspace, but given > the > >reality > >of how people pick their key - short lengths, all printable characters, > >what's the > >vulnerability? > > > >I'd like to have someone who IS a cryptography expert > >comment on the security aspects here. > > > >Leonard > > > >At 05:53 PM 10/23/98 -0700, Dale E. Reed Jr. wrote: > >>Aydin Edguer wrote: > >>> > >>> Yes. Ascend supports DNIS and CLID authentication (and has for at least > >>> three years). > >>> > >>> Ascend sends the DNIS or CLID information in the Access-Request as the > >>> User-Name attribute along with a standard User-Password. > >>> > >>> For example, if the NAS is configured to use DNIS to pre-authenticate > >>> a call, the number that was dialed would be placed in the User-Name. > >>> > >>> If the number was 5551212, then the User-Name would be "5551212" and > >>> the Password would be "Ascend-DNIS". > >> > >>This is what I prefer to see. It makes life REALLY easy to diagnose > >>and interpret this. Just set the username to the same as the > >> > >>> The use of User-Name could be fairly generic between all NAS vendors and > >>> is very easy to implement. The use of "Ascend-*" as a User-Password is > >>> not generic and most vendors would probably not agree to such a value. > >>> The option on the RADIUS server side would be to ignore the password if > >>> other NAS vendors use a different password. > >> > >>The password really isn't relevant and in most cases is ignored. It > >>COULD be definable on the NAS for added security, though. > >> > >>> > How many servers will break if they get an Access-Request w/o them? > >>> > >>> Most. The typical index into the RADIUS user database is the User-Name > >>> attribute. It is a requirement for Livingston 1.x and Merit 2/3/4.x > >>> RADIUS servers at least. > >> > >>RadiusNT does require it unless Caller-ID Authentication is enabled. > >> > >>-- > >>Dale E. Reed Jr. (daler@iea-software.com) > >>_________________________________________________________________ > >> IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs > >> Internet Solutions for Today | http://www.iea-software.com > >>- > >>To unsubscribe, email 'majordomo@livingston.com' with > >>'unsubscribe ietf-radius' in the body of the message. > >> > >> > > > >- > >To unsubscribe, email 'majordomo@livingston.com' with > >'unsubscribe ietf-radius' in the body of the message. > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 28 10:10:51 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA09458 for ; Wed, 28 Oct 1998 10:10:50 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id HAA27269; Wed, 28 Oct 1998 07:05:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA21801 for ietf-radius-outgoing; Wed, 28 Oct 1998 07:04:21 -0800 (PST) Message-Id: <199810281502.KAA09299@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-ms-vsa-01.txt Date: Wed, 28 Oct 1998 10:02:44 -0500 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 : Microsoft Vendor-specific RADIUS Attributes Author(s) : G. Zorn Filename : draft-ietf-radius-ms-vsa-01.txt Pages : 39 Date : 27-Oct-98 This document describes the set of Microsoft vendor-specific RADIUS attributes. These attributes are designed to support Microsoft propri- etary dial-up protocols and/or provide support for features which is not provided by the standard RADIUS attribute set [3]. It is expected that this memo will be updated whenever Microsoft defines a new vendor-spe- cific attribute, since its primary purpose is to provide an open, easily accessible reference for third-parties wishing to interoperate with Microsoft products. Internet-Drafts are 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-ms-vsa-01.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-ms-vsa-01.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: ftp.ietf.org US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-ms-vsa-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: <19981028094002.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-ms-vsa-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-ms-vsa-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981028094002.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 Wed Oct 28 12:08:27 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA13526 for ; Wed, 28 Oct 1998 12:08:26 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id JAA02025; Wed, 28 Oct 1998 09:02:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA01853 for ietf-radius-outgoing; Wed, 28 Oct 1998 09:01:17 -0800 (PST) Message-ID: <36374CCE.CE63CFE4@baynetworks.com> Date: Wed, 28 Oct 1998 11:56:46 -0500 From: Murtaza Chiba Organization: Bay Networks, Inc. X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Patrice Calhoun CC: Barney Wolff , ietf-radius@livingston.com Subject: Re: (radius) Username/User-Password attributes References: <199810281317.FAA08147@hsmpka.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Murtaza Chiba > You have 128 bits to play with. Even if all of these bits were in ascii I really > don't see the issue. 128 bits is pretty safe. Also, some vendors do allow hexadecimal strings for shared secrets which further increases the entropy. >If a manufacturer's default password is inadequate, change > it (I am sure this is an option, as I recall from my experience building NASes > they have plenty of options). I do not quite understand this. This is a typical RADIUS problem where the distinction between the shared secret and password is often lost. The issue here is that the password used for Pre-Auth is a known value. This cannot be changed as they are usually hard coded values. Unless a vedor allows them to be configurable, which I dont think anybody does. Given enough number of plaintext/ciphertext combinations through sniffing packets, it would be pretty easy to derive the key (shared secret). Plus it is made easier which Access-Requests to look for, since we know the username would look like a telephone number. Although, a 128 bit shared secret should make things pretty secure even under known plaintext attacks. But who said anything about RADIUS being a very secure protocol?? Murtaza -- ************************************************************** Name: Murtaza S. Chiba Company:Bay Networks Tel No. : (978)916-4689 Fax: (978)916-4789 Interests: Bicycling, chess and the outdoors Home Page: http://lynx.neu.edu/m/mchiba - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 28 12:49:21 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA14361 for ; Wed, 28 Oct 1998 12:49:20 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id JAA03413; Wed, 28 Oct 1998 09:43:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA06470 for ietf-radius-outgoing; Wed, 28 Oct 1998 09:43:15 -0800 (PST) Date: Wed, 28 Oct 1998 09:38:47 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199810281738.JAA29612@hsmpka.eng.sun.com> To: "Murtaza Chiba" , "Patrice Calhoun" Cc: "Barney Wolff" , ietf-radius@livingston.com X-Mailer: Sun NetMail 2.1.6 Subject: Re: (radius) Username/User-Password attributes Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) >> You have 128 bits to play with. Even if all of these bits were in ascii I >really >> don't see the issue. > >128 bits is pretty safe. Also, some vendors do allow hexadecimal strings >for shared secrets which further increases the entropy. > > >>If a manufacturer's default password is inadequate, change >> it (I am sure this is an option, as I recall from my experience building >NASes >> they have plenty of options). > >I do not quite understand this. This is a typical RADIUS problem where >the distinction between the shared secret and password is often lost. >The issue here is that the password used for Pre-Auth is a known value. >This cannot be changed as they are usually hard coded values. Unless a >vedor allows them to be configurable, which I dont think anybody does. 3Com (or USR :) allowed the pre-auth secret to be changed. I think that any NAS vendor that hard codes secrets and does not allow for configuration should rethink their strategy. Security is an important issue within ISP networks and leaving such a security hole is unforgivable (IMHO). >Given enough number of plaintext/ciphertext combinations through sniffing >packets, it would be pretty easy to derive the key (shared secret). Plus >it is made easier which Access-Requests to look for, since we know the >username would look like a telephone number. Again, if the password is configurable, this is a non-issue. In addition, how would the user sniff packets? By issuing bogus route updates to direct traffic to him? If the user can do this on an ISP's network then RADIUS' cryto strength is not even an issue as there are plenty of other ways to attack a network once this has been done. And remember that a RADIUS server receiving packets from an unknown client MUST NOT respond. >Although, a 128 bit shared secret should make things pretty secure even >under known plaintext attacks. > >But who said anything about RADIUS being a very secure protocol?? I agree :( PatC > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Oct 28 15:52:02 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA16473 for ; Wed, 28 Oct 1998 15:52:01 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id MAA09111; Wed, 28 Oct 1998 12:40:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA25510 for ietf-radius-outgoing; Wed, 28 Oct 1998 12:38:44 -0800 (PST) From: William Bulley Message-Id: <199810282039.PAA04493@ohm.merit.edu> Subject: Re: (radius) Username/User-Password attributes To: Pat.Calhoun@eng.sun.com Date: Wed, 28 Oct 1998 15:39:31 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <199810281738.JAA29612@hsmpka.eng.sun.com> from "Patrice Calhoun" at Oct 28, 98 09:38:47 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William Bulley According to Patrice Calhoun: > > 3Com (or USR :) allowed the pre-auth secret to be changed. I think that any > NAS vendor that hard codes secrets and does not allow for configuration should > rethink their strategy. Security is an important issue within ISP networks and > leaving such a security hole is unforgivable (IMHO). > > Again, if the password is configurable, this is a non-issue. In addition, > how would the user sniff packets? By issuing bogus route updates to direct > traffic to him? If the user can do this on an ISP's network then RADIUS' > cryto strength is not even an issue as there are plenty of other ways to > attack a network once this has been done. > > And remember that a RADIUS server receiving packets from an unknown client > MUST NOT respond. > > >But who said anything about RADIUS being a very secure protocol?? > > I agree :( But it seems people have forgotten the random contents of the vector in the header of each Access-Request packet. Regards, web... -- William Bulley Senior Systems Research Programmer Merit Network, Inc. Email: web@merit.edu 4251 Plymouth Road, Suite C Phone: (734) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (734) 647-3185 [ Reuters, London, February 29, 1998: Scientists have announced discovering ] [ a meteorite which will strike the earth in March, 2028. Millions of UNIX ] [ coders expressed relief for being spared the UNIX epoch "crisis" of 2038. ] - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Oct 29 11:50:38 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA06354 for ; Thu, 29 Oct 1998 11:50:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id IAA00144; Thu, 29 Oct 1998 08:44:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA02232 for ietf-radius-outgoing; Thu, 29 Oct 1998 08:41:01 -0800 (PST) Message-ID: <363899B2.7C60B4C4@baynetworks.com> Date: Thu, 29 Oct 1998 11:37:06 -0500 From: Murtaza Chiba Organization: Bay Networks, Inc. X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 5.5.1 sun4u) MIME-Version: 1.0 To: Patrice Calhoun , ietf-radius@livingston.com Subject: Re: (radius) Username/User-Password attributes References: <199810281738.JAA29612@hsmpka.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Murtaza Chiba >In addition, > how would the user sniff packets? By issuing bogus route updates to direct > traffic to him? That is only one of the possible methods. Its basically an issue of whom do you trust. RADIUS is built on the model that everybody on an internal network can be trusted. Hence, everything is in clear text (except for the passwords) and there is no attempt to secure it using TLS or any such mechanism. Although, I agree that a dial-in user may not be able to do much (unless he can write up agents to capture RADIUS packets using some bug in well known applications, e.g. Web servers running CGI scripts or worse java programs without proper security), I am not sure that you can trust EVERYONE on the internal network either. >But it seems people have forgotten the random contents >of the vector >in the header of each Access-Request packet. Dont forget that that is sent along with the packet, else how would the server verify the password? On the other hand RADIUS is a good simple protocol that allows future protocols to easily adapt on its weaknesses. Murtaza -- ************************************************************** Name: Murtaza S. Chiba Company:Bay Networks Tel No. : (978)916-4689 Fax: (978)916-4789 Interests: Bicycling, chess and the outdoors Home Page: http://lynx.neu.edu/m/mchiba - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Oct 31 15:57:19 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA12959 for ; Sat, 31 Oct 1998 15:57:18 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast (8.8.5/8.6.9) with ESMTP id MAA21733; Sat, 31 Oct 1998 12:51:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA09940 for ietf-radius-outgoing; Sat, 31 Oct 1998 12:46:04 -0800 (PST) From: scj2@gs4.revnet.com Message-Id: <199810312042.OAA31172@revnet4.revnet.com> To: scj2@gs4.revnet.com Subject: (radius) ISM Corp has acquired 4.7 mill to begin production Stock up 100 percent Date: Sat, 31 Oct 1998 14:46:38 -0600 Originator: scj2@gs4.revnet.com X-Mailer: GroupMaster X-Mailer-Version: 1.5 X-GroupMasterUser: Revnet Express Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: scj2@gs4.revnet.com Please open the following message in your web browser http://gs4.revnet.com/GM/MSGVIEW/MSOHNOPA.HTML ____________________________________________________________ International Shoe Manufacturing Corp Update: International Shoe Manufacturing Corp. (Ticker-ISHO) has acquired the final-stage financing to begin full-scale production at its plants in India. The $4.75 million is being used to purchase the final equipment needed to begin production at the company’s existing plant in India. With equipment in place, the company projects net profits of over $25 million a year within two years. The company stated that the financing will be followed up by a $9 million dollar IPO in India, anticipated for March 1999. The IPO will be handled by underwriters in India, and will leave ISM with control of its wholly owned subsidiary in India. The proceeds of the IPO will pay off the $4.75 million dollar financing. The balance will be used for the acquisition of additional shoe manufacturing. ISHO is in the business of manufacturing athletic footwear for the world’s leading shoe companies. It owns a 23,000-square-foot plant located in the protected “free trade zone” in Noida, just outside of New Delhi, India, where skilled labor is plentiful and very inexpensive. The Indian government recently developed new economic policy to attract foreign investment that is export-oriented, and could employ large numbers of people. ISM is the only athletic shoe manufacturer in India directed toward the international market. It currently has contracts with Adidas and The Pentland Group. These two companies have agreed to purchase all the shoes ISM can manufacture. The athletic shoe industry is estimated at $14.25 billion a year. The world’s leading shoe companies such as Adidas, Nike, and Reebok do not manufacture shoes. They are design and marketing organizations that spend hundreds of millions of dollars a year getting their products sold. They then rely on others to manufacture to their specifications. Almost, if not all athletic shoe manufacturers are privately owned, benefiting from the hundreds of millions of dollars spent on advertising by the name-brand companies. The result is an open purchase order where such manufacturers literally can sell every pair of shoes they can produce. A business like this lends itself to being privately held due to the large cash flow allowing for internal financing. International Shoe Manufacturing Corp. is the only company known to exist that offers a public investor the opportunity to own a share of this highly lucrative business in a pure investment play. For inquiries please contact the office of the director of investor relations toll free at: 877-ISM-CORP (877-476-2677) or send your e-mail request to nsi@smallcapjournal.com Your request will be handled immediately. Or write to ISM Corp at P.O. Box 520310 Longwood, Florida 32752 Please visit ISM’s web site at www.ismcorp.net Safe Harbor for Forward-Looking Statements: Except for historical information contained herein, the statements in this press release are forward-looking statements that are made pursuant to the safe harbor provisions of the Private Securities Reform Act of 1995. Forward-looking statements involve known and unknown risks and uncertainties which may cause the company’s actual results in the future periods to differ materially from forecasted results. These risks and uncertainties include, among other things, product price volatility, product demand, market competition, risk inherent in the company’s domestic and international operations, imprecision in estimating product reserves and the company’s ability to replace and expand its holdings. ____________________________________________________________ Unsubscribe or access your membership settings at: http://gs4.revnet.com/GMG/ctrlpanel/0/79 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message.