From owner-ietf-radius@livingston.com Tue Nov 3 18:35:40 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA17518 for ; Tue, 3 Nov 1998 18:35: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 PAA27376; Tue, 3 Nov 1998 15:29:47 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA24423 for ietf-radius-outgoing; Tue, 3 Nov 1998 15:23:07 -0800 (PST) Date: Tue, 3 Nov 1998 15:23:08 -0800 (PST) Message-Id: <199811032323.PAA20136@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: glennz@microsoft.com From: Leonard Cuff Subject: (radius) draft-ietf-radius-tunnel-auth-06.txt feedback & question Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Leonard Cuff Glen, (1) (Nit) Section 1 says the document is filed as draft-ietf-radius-tunnel-auth-05.txt, (instead of -06). You should change it to -06 for the next draft :-) :-) (2) (Nit) Section 5.2, the paragraph talking about tags specifies that an unused tag must be zero (0x0000) but since the tag is only an octet, zero is (0x00). (3) As I interpret it, Section 5 says that the Tag field SHOULD NOT be used used unless multiple instances of an attribute occur. Is there a strong reason why a single set of attributes could not tagged??? As a frame of reference I'm mostly focussed on proxy environments, where a proxy may send a set of tunnel attributes, and another set of attributes might already exist (in which case they needed to be deleted or re-written with tags prior to proxying), so it simplifies the implementation a hair if we can tag a set even if it's the only set in the packet. (4) We're currently doing some interoperability testing with another vendor who sends an "untagged" Tunnel-Client-Endpoint (and Tunnel-Server-Endpoint), but has put a zero in the tag field. Our \implementation doesn't currently support this. My reading of Sections 5.3 and 5.4 is that this is not a valid. To wit the Tag paragraph says "Valid values for this field are 0x01 through 0x1F", but I have some sympathy for the other vendor, as the diagram doesn't have any indication that the tag field is optional, and when the tag field is unused for other attributes (the non-string attributes) it is "unused" by setting it to zero. I suggest that this be clarified in three places: (a) The first paragraph of Section 5 could have some added text as follows: Note: "unused" means set to zero for some attributes, and entirely omitted for other attributes. (b) the packet format diagram for these attributes should have some indication that this tag is optional. Perhaps nothing more than: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Tag (optional)| String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (c) The text for the Tag attribute should say the tag field is optional, and MUST BE omitted if unused. Yes, that's what's implied by the existing phrase "otherwise, it SHOULD be interpreted as the first byte of the following String field", but this wasn't enough for at least one implementor.... ...for that matter, SHOULD doesn't seem strong enough in the just-cited text...... Regards, Leonard - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Nov 3 19:50:58 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA18108 for ; Tue, 3 Nov 1998 19:50:57 -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 QAA00281; Tue, 3 Nov 1998 16:45:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA03613 for ietf-radius-outgoing; Tue, 3 Nov 1998 16:43:55 -0800 (PST) Message-ID: <003a01be078b$703c4840$86f61fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Leonard Cuff" , Cc: Subject: Re: (radius) draft-ietf-radius-tunnel-auth-06.txt feedback & question Date: Tue, 3 Nov 1998 16:38:24 -0800 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" Leonard Cuff writes: >Glen, > >(1) (Nit) Section 1 says the document is filed as >draft-ietf-radius-tunnel-auth-05.txt, >(instead of -06). You should change it to -06 for the next draft :-) :-) Whoops! > >(2) (Nit) Section 5.2, the paragraph talking about tags specifies that an >unused tag >must be zero (0x0000) but since the tag is only an octet, zero is (0x00). Whoops! redux > >(3) As I interpret it, Section 5 says that the Tag field SHOULD NOT be used >used unless >multiple instances of an attribute occur. Is there a strong reason why a >single set of >attributes could not tagged??? I suppose not - outside of the waste of a byte. Not finding another set of tagged attributes might confuse some servers... > >As a frame of reference I'm mostly focussed on proxy environments, where a proxy >may send a set of tunnel attributes, and another set of attributes might >already exist (in >which case they needed to be deleted or re-written with tags prior to >proxying), so it simplifies >the implementation a hair if we can tag a set even if it's the only set in >the packet. > >(4) We're currently doing some interoperability testing with another vendor >who sends an "untagged" >Tunnel-Client-Endpoint (and Tunnel-Server-Endpoint), but has put a zero in >the tag field. Our \implementation doesn't currently support this. My >reading of Sections 5.3 and 5.4 >is that this is not a valid. To wit the Tag paragraph says "Valid values >for this field are >0x01 through 0x1F", but I have some sympathy for the other vendor, as the >diagram doesn't have >any indication that the tag field is optional, and when the tag field is >unused for other attributes >(the non-string attributes) it is "unused" by setting it to zero. > >I suggest that this be clarified in three places: > >(a) The first paragraph of Section 5 could have some added text as follows: >Note: "unused" means set to zero for some attributes, and entirely omitted >for other attributes. > >(b) the packet format diagram for these attributes should have some >indication that this tag is optional. >Perhaps nothing more than: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length |Tag (optional)| String ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >(c) The text for the Tag attribute should say the tag field is optional, >and MUST BE omitted >if unused. Yes, that's what's implied by the existing phrase "otherwise, >it SHOULD be interpreted as >the first byte of the following String field", but this wasn't enough for at >least one implementor.... Strictly speaking, the Tag _isn't_ optional -- it just becomes "invisible" if it's not in use. > >...for that matter, SHOULD doesn't seem strong enough in the just-cited >text...... I can agree w/that, I think. > >Regards, > >Leonard > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > begin 666 Glen Zorn.vcf M0D5'24XZ5D-!4D0-"E9%4E-)3TXZ,BXQ#0I..EIOD!P:6YK>2YM:6-R;W-O I9G0N8V]M#0I2158Z,3DY.#$Q,#14,# S.#(S6@T*14Y$.E9#05)$#0H` ` end - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 01:35:56 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA28977 for ; Wed, 4 Nov 1998 01:35: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 WAA07940; Tue, 3 Nov 1998 22:30:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA21542 for ietf-radius-outgoing; Tue, 3 Nov 1998 22:28:59 -0800 (PST) From: MorRB@optonline.net Message-Id: <199811040629.BAA27259@nms.optonline.net> To: Subject: (radius) Ready For The Holidays ?? How about a head start ?? Date: Wed, 4 Nov 1998 02:04:56 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MorRB@optonline.net NOW WOULD BE A GREAT TIME TO GET READY FOR THE HOLIDAYS !! You probably have received this in the past and done nothing about it, then wondered about it. It really does work. All you need is to invest a some time and effort into this, but the pay off can be great. I received this letter late last year, put little effort onto it and got moderate results. The system does work!! I am starting this again for the upcoming holiday season. This is a ground floor opportunity!! This could possible be the best HOLIDAY SEASON ever !! Never Thought I'd Be the One Telling You This: I Actually Read a Piece of E-Mail & I'm Going to Europe on the Proceeds! Hello! My name is Karen Liddell; I'm a 35-year-old mom, wife, and part-time accountant. As a rule, I delete all unsolicited "junk" e-mail and use my account primarily for business. I received what I assumed was this same e-mail countless times and deleted it each time. About two months ago I received it again and, because of the catchy subject line, I finally read it. Afterwards, I thought , "OK, I give in, I'm going to try this. I can certainly afford to invest $20 and, on the other hand, there's nothing wrong with creating a little excess cash." I promptly mailed four $5 bills and, after receiving the reports, paid a friend of mine a small fee to send out some e-mail advertisements for me. After reading the reports, I also learned how easy it is to bulk e-mail for free! I was not prepared for the results. Everyday for the last six weeks, my P.O. box has been overflowing with $5 bills; many days the excess fills up an extra mail bin and I've had to upgrade to the corporate-size box! I am stunned by all the money that keeps rolling in! My husband and I have been saving for several years to make a substantial downpayment on a house. Now, not only are we purchasing a house with 40% down, we're going to Venice, Italy to celebrate! I promise you, if you follow the directions in this e-mail and be prepared to eventually set aside about an hour each day to follow up (and count your money!), you will make at least as much money as we did. You don't need to be a wiz at the computer, but I'll bet you already are. If you can open an envelope, remove the money, and send an e-mail message, then you're on your way to the bank. Take the time to read this so you'll understand how easy it is. If I can do this, so can you! GO FOR IT NOW!! Karen Liddell The following is a copy of the e-mail I read: $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ This is a. LEGAL, MONEY-MAKING PHENOMENON. PRINT this letter, read the directions, THEN READ IT AGAIN !!! You are about to embark on the most profitable and unique program you may ever see. Many times over, it has demonstrated and proven its ability to generate large amounts of cash. This program is showing fantastic appeal with a huge and ever-growing on-line population desirous of additional income. This is a legitimate, LEGAL, money-making opportunity. It does not require you to come in contact with people, do any hard work, and best of all, you never have to leave the house, except to get the mail and go to the bank! This truly is that lucky break you've been waiting for! Simply follow the easy instructions in this letter, and your financial dreams will come true! When followed correctly, this electronic, multi-level marketing program works perfectly...100% EVERY TIME! Thousands of people have used this program to: - Raise capital to start their own business - Pay off debts - Buy homes, cars, etc., - Even retire! This is your chance, so don't pass it up! ----------------------------------------------------------------- ----------------- OVERVIEW OF THIS EXTRAORDINARY ELECTRONIC MULTI-LEVEL MARKETING PROGRAM ----------------------------------------------------------------- ----------------- Basically, this is what we do: We send thousands of people a product for $5.00 that costs next to nothing to produce and e-mail. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the U.S. allows you to recruit new multi- level business online (via your computer). The products in this program are a series of four business and financial reports costing $5.00 each. Each order you receive via "snail mail" will include: * $5.00 cash * The name and number of the report they are ordering * The e-mail address where you will e-mail them the report they ordered. To fill each order, you simply e-mail the product to the buyer. THAT'S IT! The $5.00 is yours! This is the EASIEST electronic multi-level marketing business anywhere! FOLLOW THE INSTRUCTIONS TO THE LETTER AND BE PREPARED TO REAP THE STAGGERING BENEFITS! ******* I N S T R U C T I O N S ******* This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if you don't order them). * For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR RETURN POSTAL ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. * When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. * Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT-- DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "d" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested, and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, replace the name and address under REPORT #1 with your name and address, moving the one that was there down to REPORT #2. c. Move the name and address that was under REPORT #2 down to REPORT #3. d. Move the name and address that was under REPORT #3 down to REPORT #4. e. The name and address that was under REPORT #4 is removed from the list and has NO DOUBT collected their 50 grand. Please make sure you copy everyone's name and address ACCURATELY!!! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. 4. Now you're ready to start an advertising campaign on the WORLDWIDE WEB! Advertising on the WEB is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Another avenue which you could use for advertising is e-mail lists. You can buy these lists for under $20/2,000 addresses or you can pay someone a minimal charge to take care of it for you. BE SURE TO START YOUR AD CAMPAIGN IMMEDIATELY! 5. For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out, with YOUR name and address on it, will be prompt because they can't advertise until they receive the report! ------------------------------------------ AVAILABLE REPORTS ------------------------------------------ ***Order Each REPORT by NUMBER and NAME*** Notes: - ALWAYS SEND $5 CASH FOR EACH REPORT - ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL - Make sure the cash is concealed by wrapping it in at least two sheets of paper n On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your postal address. Note: Because I am starting this over again and will be selling all of the reports, I am listed in all of the 4 address positions. Simple follow the program to the letter. ( Remove these three sentences as it won’t make sense when you send your letters.) _________________________________________________________________ REPORT #1 "HOW TO MAKE $250,000 THROUGH MULTI-LEVEL SALES" ORDER REPORT #1 FROM: RB & Co. 1021 Windermere Rd. Franklin Sq. NY 11010 _________________________________________________________________ REPORT #2 "MAJOR CORPORATIONS AND MULTI-LEVEL SALES" ORDER REPORT #2 FROM: RB & Co. 1021 Windermere Rd. Franklin Sq. NY 11010 _________________________________________________________________ _ REPORT #3 "SOURCES FOR THE BEST MAILING LISTS" ORDER REPORT #3 FROM: RB & Co. 1021 Windermere Rd. Franklin Sq. NY 11010 ________________________________________________________________ REPORT #4 "EVALUATING MULTI-LEVEL SALES PLANS" ORDER REPORT #4 FROM: RB & Co. 1021 Windermere Rd. Franklin Sq. NY 11010 _________________________________________________________________ ----------------------------------------------------------------- --------------------------------- HERE'S HOW THIS AMAZING PLAN WILL MAKE YOU $MONEY$ ----------------------------------------------------------------- --------------------------------- Let's say you decide to start small just to see how well it works. Assume your goal is to get 10 people to participate on your first level. (Placing a lot of FREE ads on the internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below. 1st level--your 10 members with $5...........................................$50 2nd level--10 members from those 10 ($5 x 100)..................$500 3rd level--10 members from those 100 ($5 x 1,000)..........$5,000 4th level--10 members from those 1,000 ($5 x 10,000)...$50,000 THIS TOTALS ----------->$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! THINK ABOUT IT! Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an internet connection and e-mail is FREE!!! REPORT#3 shows you the most productive methods for bulk e-mailing and purchasing e-mail lists. Some list & bulk e-mail vendors even work on trade! About 50,000 new people get online every month! *******TIPS FOR SUCCESS******* * TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. * Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report to comply with the U.S. Postal & Lottery Laws, Title 18,Sections 1302 and 1341 or Title 18, Section 3005 in the U.S. Code, also Code of Federal Regs. vol. 16, Sections 255 and 436, which state that "a product or service must be exchanged for money received." * ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. * Be patient and persistent with this program. If you follow the instructions exactly, the results WILL undoubtedly be SUCCESSFUL! * ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! *******YOUR SUCCESS GUIDELINE******* Follow these guidelines to guarantee your success: If you don't receive 10 to 20 orders for REPORT #1 within two weeks, continue advertising until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don't, continue advertising until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails and start the whole process again! There is no limit to the income you will generate from this business! NOTE: If you need help with starting a business, registering a business name, how income tax is handled, etc., contact your local office of the Small Business Administration (a Federal agency) for free help and answers to questions. Also, the Internal Revenue Service offers free help via telephone and free seminars about business taxes. *******T E S T I M O N I A L S******* This program does work, but you must follow it EXACTLY! Especially the rule of not trying to place your name in a different position, it won't work and you'll lose a lot of potential income. I'm living proof that it works. It really is a great opportunity to make relatively easy money, with little cost to you. If you do choose to participate, follow the program exactly, and you'll be on your way to financial security. Sean McLaughlin, Jackson, MS My name is Frank. My wife, Doris, and I live in Bel-Air, MD. I am a cost accountant with a major U.S. Corporation and I make pretty good money. When I received the program I grumbled to Doris about receiving "junk mail." I made fun of the whole thing, spouting my knowledge of the population and percentages involved. I "knew" it wouldn't work. Doris totally ignored my supposed intelligence and jumped in with both feet. I made merciless fun of her, and was ready to lay the old "I told you so" on her when the thing didn't work... well, the laugh was on me! Within two weeks she had received over 50 responses. Within 45 days she had received over $147,200 in $5 bills! I was shocked! I was sure that I had it all figured and that it wouldn't work. I AM a believer now. I have joined Doris in her "hobby." I did have seven more years until retirement, but I think of the "rat race" and it's not for me. We owe it all to MLM. Frank T., Bel-Air, MD I just want to pass along my best wishes and encouragement to you. Any doubts you have will vanish when your first orders come in. I even checked with the U.S. Post Office to verify that the plan was legal. It definitely is! IT WORKS!!! Paul Johnson, Raleigh, NC The main reason for this letter is to convince you that this system is honest, lawful, extremely profitable, and is a way to get a large amount of money in a short time. I was approached several times before I checked this out. I joined just to see what one could expect in return for the minimal effort and money required. To my astonishment, I received $36,470.00 in the first 14 weeks, with money still coming in. Sincerely yours, Phillip A. Brown, Esq. Not being the gambling type, it took me several weeks to make up my mind to participate in this plan. But conservative that I am, I decided that the initial investment was so little that there was just no way that I wouldn't get enough orders to at least get my money back. Boy, was I surprised when I found my medium-size post office box crammed with orders! For awhile, it got so overloaded that I had to start picking up my mail at the window. I'll make more money this year than any 10 years of my life before. The nice thing about this deal is that it doesn't matter where in the U.S. the people live. There simply isn't a better investment with a faster return. Mary Rockland, Lansing, MI I had received this program before. I deleted it, but later I wondered if I shouldn't have given it a try. Of course, I had no idea who to contact to get another copy, so I had to wait until I was e-mailed another program...11 months passed then it came...I didn't delete this one!...I made more than $41,000 on the first try!! D. Wilburn, Muncie, IN This is my third time to participate in this plan. We have quit our jobs, and will soon buy a home on the beach and live off the interest on our money. The only way on earth that this plan will work for you is if you do it. For your sake, and for your family's sake don't pass up this golden opportunity. Good luck and happy spending! Charles Fairchild, Spokane, WA ORDER YOUR REPORTS TODAY AND GET STARTED ON YOUR ROAD TO FINANCIAL FREEDOM!!! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 06:43:31 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA04706 for ; Wed, 4 Nov 1998 06:43:31 -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 DAA12656; Wed, 4 Nov 1998 03:36:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA04080 for ietf-radius-outgoing; Wed, 4 Nov 1998 03:35:41 -0800 (PST) Date: Wed, 4 Nov 1998 03:35:39 -0800 (PST) From: Carl Rigney Message-Id: <199811041135.DAA04071@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Implementation survey Cc: isp-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney As part of moving RADIUS from Proposed to Draft Standard I need to write an informational RFC documenting interoperability among independent implementations. If you have a RADIUS server or client and would like to be mentioned, would you please email me (NOT the list, just me) the following info by 11/10, and I'll write up a summary and post it to the mailing list before submitting it. Whether its a RADIUS server or client or both Name of product (optional) Company or Organizational name Contact person & email address (optional). If the implementation was done only referring to the RFCs, specify that, or if you based on yours on someone else's (such as Livingston's 1.13 or 1.16 source code), specify its ancestor. If you want to mention that it was successful at either the first or second RADIUS interoperability experiences, you're welcome to do so, but you don't have to. Optionally, you can add a paragraph mentioning anything else that you think relevant (like language of implementation, number of years its been available, or whatever), but no ads please. If it has any interoperability issues that you're aware of and you'd like to mention them, that'd be fine. If you want to include a URL pointing to more info that's excellent, but certainly optional. -- Carl Rigney cdr@livingston.com "We reject kings, presidents and voting. We believe in rough consensus and running code." -- Dave Clark 1992 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 07:23:08 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA04960 for ; Wed, 4 Nov 1998 07:23:07 -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 EAA13198; Wed, 4 Nov 1998 04:17:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA05758 for ietf-radius-outgoing; Wed, 4 Nov 1998 04:17:20 -0800 (PST) Date: Wed, 4 Nov 1998 04:17:19 -0800 (PST) From: Carl Rigney Message-Id: <199811041217.EAA05752@server.livingston.com> To: ietf-radius@livingston.com Subject: Re: (radius) Username/User-Password attributes Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney I agree that it makes sense to send the Calling-Station-Id as the User-Name for NASes that want to send an Access-Request before prompting the user for their username. If the password hasn't been received from the user yet, the best thing for the NAS to do is to use Signature (from the extensions draft), rather than using a dummy placeholder Password attribute. Of course, if they want to use Password instead of Signature, that already works. How about a Service-Type = Call-Check (10) available as a hint in the Access-Request, used by the NAS to indicate that a call is being received and that the RADIUS server should send back an Access-Accept (with Service-Type = Call-Check) to answer the call, or an Access-Reject to not accept the call, typically based on the Called-Station-Id or Calling-Station-Id attributes. It is recommended that such Access-Requests use the value Calling-Station-Id as the User-Name. A further step might be to permit User-Name in Access-Accept so that a NAS can find out the name of the user dialing in on a given line and send that along in accounting requests. -- Carl Rigney - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 07:27:24 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA04992 for ; Wed, 4 Nov 1998 07:27:23 -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 EAA13561; Wed, 4 Nov 1998 04:21:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA06019 for ietf-radius-outgoing; Wed, 4 Nov 1998 04:21:52 -0800 (PST) Date: Wed, 4 Nov 1998 04:21:51 -0800 (PST) From: Carl Rigney Message-Id: <199811041221.EAA06013@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Acct-Session-Id in Access-Requests Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Possibly I'm mellowing in my dotage, but as I'm looking over the attribute tables for the revised drafts I recall that once upon a time people asked about the possibility of allowing NASes to send Acct-Session-Id in their Access-Request, so that such requests could be linked up later with the matching accounting record. At the time it seemed marginal, but in the Brave New World of Proxy it seems more useful. Would there be a firestorm of protest if Acct-Session-Id were permitted in Access-Request as well as Accounting-Requests? -- Carl Rigney RADIUS WG Editor 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 Nov 4 07:29:42 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA05004 for ; Wed, 4 Nov 1998 07:29:41 -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 EAA13817; Wed, 4 Nov 1998 04:24:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA06193 for ietf-radius-outgoing; Wed, 4 Nov 1998 04:24:21 -0800 (PST) Date: Wed, 4 Nov 1998 04:24:19 -0800 (PST) From: Carl Rigney Message-Id: <199811041224.EAA06182@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Orlando or Bust Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney The RADIUS WG is not meeting at the 43rd IETF in Orlando, but I'm planning to attend for most of the conference, so if anyone wants to meet & talk, I'll be in the Radisson Saturday through Friday (I might leave earlier in the week, depending on what winds up when). Probably best to contact me ahead of time and arrange a time to meet, if you like. -- 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 Nov 4 07:36:18 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA05126 for ; Wed, 4 Nov 1998 07:36:17 -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 EAA14125; Wed, 4 Nov 1998 04:30:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA06781 for ietf-radius-outgoing; Wed, 4 Nov 1998 04:30:31 -0800 (PST) Date: Wed, 4 Nov 1998 04:30:30 -0800 (PST) From: Carl Rigney Message-Id: <199811041230.EAA06775@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) IANA guidance draft Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney As part of the progression of the RADIUS RFC from Proposed to Draft Standard, I need to write another RFC providing guidelines for the IANA to know when its OK to hand out an attribute (90 upwards). I'm reviewing some examples of such, but if anyone has well-reasoned text they'd like to contribute to the cause, please feel free to email me. On a similar note, is there really any reason to reserve attributes 192-254 for experimental and implementation specific use, or should they be freed up for eventual use? Or should we keep them reserved for now and 100 attributes from now it can be done in a revision? -- Carl Rigney RADIUS WG Editor cdr@livingston.com "Tell everyone you know except John Glenn: When John Glenn returns from space, let's all dress in ape suits. Pass it on." - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 09:24:59 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA05994 for ; Wed, 4 Nov 1998 09:24:59 -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 GAA16366; Wed, 4 Nov 1998 06:18:56 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA11804 for ietf-radius-outgoing; Wed, 4 Nov 1998 06:18:08 -0800 (PST) From: William Bulley Message-Id: <199811041419.JAA20932@ohm.merit.edu> Subject: Re: (radius) IANA guidance draft To: cdr@livingston.com Date: Wed, 4 Nov 1998 09:19:10 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <199811041230.EAA06775@server.livingston.com> from "Carl Rigney" at Nov 4, 98 04:30:30 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 Carl Rigney: > > As part of the progression of the RADIUS RFC from Proposed to Draft > Standard, I need to write another RFC providing guidelines for the IANA > to know when its OK to hand out an attribute (90 upwards). I'm > reviewing some examples of such, but if anyone has well-reasoned text > they'd like to contribute to the cause, please feel free to email me. I thought ICANN was replacing IANA... 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 Wed Nov 4 09:32:51 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA06122 for ; Wed, 4 Nov 1998 09:32: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 GAA16720; Wed, 4 Nov 1998 06:27:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA12376 for ietf-radius-outgoing; Wed, 4 Nov 1998 06:27:21 -0800 (PST) Message-ID: <364063A2.2E8A2C37@umich.edu> Date: Wed, 04 Nov 1998 14:24:34 +0000 From: Wei Wang Organization: University of Michigan X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.0.35 i586) X-Accept-Language: en MIME-Version: 1.0 To: Carl Rigney CC: ietf-radius@livingston.com Subject: Re: (radius) Acct-Session-Id in Access-Requests References: <199811041221.EAA06013@server.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Wei Wang Carl Rigney wrote: > > Possibly I'm mellowing in my dotage, but as I'm looking over the > attribute tables for the revised drafts I recall that once upon a time > people asked about the possibility of allowing NASes to send > Acct-Session-Id in their Access-Request, so that such requests could be > linked up later with the matching accounting record. At the time it > seemed marginal, but in the Brave New World of Proxy it seems more > useful. > > Would there be a firestorm of protest if Acct-Session-Id were permitted > in Access-Request as well as Accounting-Requests? I'd say that's great, especially as you said in the world of proxy. But there should be some provision on making the Acct-Session-Id's unique across NAS'es without having to do any trick with its content on the server side. Otherwise, it would be difficult to use the Acct-Session-Id's in a generalized way. Since NAS-IP-Address and NAS-Identifier are defined as "SHOULD" be in access requests, life would much easier if one can depend on the Acct-Session-Id to be unique. Regards, -- Wei Wang weiwang@umich.edu Merit Network, Inc. http://www-personal.umich.edu/~weiwang/ [Tel] 734-764-2874 [Fax] 734-647-3745 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 09:41:02 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA06198 for ; Wed, 4 Nov 1998 09:41: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 GAA17010; Wed, 4 Nov 1998 06:35:22 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA12995 for ietf-radius-outgoing; Wed, 4 Nov 1998 06:35:33 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Wed, 4 Nov 1998 09:15 EST Subject: Re: (radius) Username/User-Password attributes Content-Type: text/plain Message-ID: <3640664e0.2f30@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff > Date: Wed, 4 Nov 1998 04:17:19 -0800 (PST) > From: Carl Rigney > > I agree that it makes sense to send the Calling-Station-Id as the > User-Name for NASes that want to send an Access-Request before prompting > the user for their username. Oh I suppose. But the server MUST then check for your new service type, as otherwise a user could enter an arbitrary digit string in response to a prompt, and perhaps get accepted. All this is really doing is getting around a server check for the presence of officially-required attributes. > A further step might be to permit User-Name in Access-Accept so that a > NAS can find out the name of the user dialing in on a given line and > send that along in accounting requests. We should think seriously about what the appropriate response is, to a call-check access-request. One of the things I'd use that for is to direct the NAS to do different things based on the called-station-id. For that scenario, I'd feel safer replying with Access-Challenge, not Accept, because further user authentication must be done. So I would like to define the NAS's action on all three server responses: Kill the call on reject. Answer the call and do further user authentication on challenge. Answer the call and do no further user authentication on accept. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 10:05:46 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA06901 for ; Wed, 4 Nov 1998 10:05:46 -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 HAA17952; Wed, 4 Nov 1998 07:00:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA15313 for ietf-radius-outgoing; Wed, 4 Nov 1998 06:59:58 -0800 (PST) From: Aydin Edguer Message-Id: <199811041459.JAA03807@volitans.MorningStar.Com> Subject: Re: (radius) Username/User-Password attributes To: ietf-radius@livingston.com Date: Wed, 4 Nov 1998 09:59:05 -0500 (EST) Cc: cdr@livingston.com In-Reply-To: <199811041217.EAA05752@server.livingston.com> from "Carl Rigney" at Nov 4, 98 04:17:19 am 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 > A further step might be to permit User-Name in Access-Accept so that a > NAS can find out the name of the user dialing in on a given line and > send that along in accounting requests. Gee... I thought this was already decided as permitted. I refer you back to the archives of the mailing list. [ietf-radius.9704] Date: Thu, 3 Apr 1997 01:50:35 -0800 (PST) From: Carl Rigney Subject: (radius) Agenda for 38th IETF Tue 4/8 15:30-17:30 ... Allowing Usernames in Access-Accepts (for use with Calling-Station-Id)? [ietf-radius.9708] Date: Mon, 25 Aug 1997 23:47:40 -0700 (PDT) From: Carl Rigney Subject: (radius) 38th IETF RADIUS Working Group Minutes ... Usernames are now allowed in Access-Accepts, for example in a case where the User is identified by their Calling-Station-Id. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 10:29:38 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA07480 for ; Wed, 4 Nov 1998 10:29: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 HAA18520; Wed, 4 Nov 1998 07:23:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA17322 for ietf-radius-outgoing; Wed, 4 Nov 1998 07:22:33 -0800 (PST) From: Aydin Edguer Message-Id: <199811041521.KAA04047@volitans.MorningStar.Com> Subject: Re: (radius) Username/User-Password attributes To: ietf-radius@livingston.com Date: Wed, 4 Nov 1998 10:21:45 -0500 (EST) In-Reply-To: <3640664e0.2f30@databus.databus.com> from "Barney Wolff" at Nov 4, 98 09:15:00 am 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 > > A further step might be to permit User-Name in Access-Accept so that a > > NAS can find out the name of the user dialing in on a given line and > > send that along in accounting requests. > > We should think seriously about what the appropriate response is, to a > call-check access-request. The appropriate reponse is to allow the call to be answered. The "call-check" takes place before the NAS goes off-hook. > One of the things I'd use that for is to direct the NAS to do different > things based on the called-station-id. Yes, you can certainly authorize different services based on the called or calling station-id. > For that scenario, I'd feel safer replying with Access-Challenge, not > Accept, because further user authentication must be done. Using an Access-Challenge might be an option, but it is not strictly necessary. In the Ascend implementation, you are able to either accept the call an immediately start a framed protocol or terminal server login without additional authentication, or you can require user authentication in addition to called or calling station "call-check" based on a vendor specific attribute in the Access-Accept message. Specifically using Ascend-Require-Auth = Require-Auth forces the user to go through "normal" framed (PAP/CHAP) or terminal server (login/password) authentication. > So I would like to define the NAS's action on all three server responses: > > Kill the call on reject. This is controlled by the NAS. The Access-Reject can cause the call to be rejected (not-answered) or the NAS can accept the call but require the normal authentication. > Answer the call and do further user authentication on challenge. I can see that using Access-Challenge would be useful for certain purposes but it is not strictly necessary to acheive the behavior you describe. It requires more intelligence in the RADIUS server to implement (similar to the Livingston RADIUS server method of implementing menus). > Answer the call and do no further user authentication on accept. This is an option, but it can be modified by other attributes in the Access-Accept. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 10:40:12 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA07898 for ; Wed, 4 Nov 1998 10:40:11 -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 HAA18944; Wed, 4 Nov 1998 07:34:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA18358 for ietf-radius-outgoing; Wed, 4 Nov 1998 07:32:39 -0800 (PST) Date: Wed, 4 Nov 1998 07:29:38 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199811041529.HAA05393@hsmpka.eng.sun.com> To: ietf-radius@livingston.com X-Mailer: Sun NetMail 2.1.6 Subject: Re: (radius) IANA guidance draft Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) > >On a similar note, is there really any reason to reserve attributes >192-254 for experimental and implementation specific use, or should they >be freed up for eventual use? Or should we keep them reserved for now >and 100 attributes from now it can be done in a revision? Freed up for eventual use? They are already being used :) :) PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 10:43:46 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA08003 for ; Wed, 4 Nov 1998 10:43:45 -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 HAA19156; Wed, 4 Nov 1998 07:37:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA18758 for ietf-radius-outgoing; Wed, 4 Nov 1998 07:37:16 -0800 (PST) From: Aydin Edguer Message-Id: <199811041536.KAA04207@volitans.MorningStar.Com> Subject: Re: (radius) Acct-Session-Id in Access-Requests To: ietf-radius@livingston.com Date: Wed, 4 Nov 1998 10:36:15 -0500 (EST) In-Reply-To: <364063A2.2E8A2C37@umich.edu> from "Wei Wang" at Nov 4, 98 02:24:34 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 Wei Wang wrote: > Carl Rigney wrote: > > Would there be a firestorm of protest if Acct-Session-Id were permitted > > in Access-Request as well as Accounting-Requests? > > But there should be some provision on making the Acct-Session-Id's > unique across NAS'es without having to do any trick with its content > on the server side. I have no objection to allowing the Acct-Session-Id in an Access-Request. In fact, some NAS vendors are already putting it there, so it makes sense to allow it. I would have an objection to trying to force the Acct-Session-Id to be unique across NAS'es. In my opinion, it would not help, since you have no guarantee in a roaming situation that the originating NAS will have this feature/capability. Further, how is a NAS supposed to guarantee this? Requiring the owner/operator to configure something on the NAS is not going to guarantee it. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 11:31:00 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA09914 for ; Wed, 4 Nov 1998 11:30:59 -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 IAA21029; Wed, 4 Nov 1998 08:25:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA24115 for ietf-radius-outgoing; Wed, 4 Nov 1998 08:24:54 -0800 (PST) Date: Wed, 4 Nov 1998 08:21:53 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199811041621.IAA16217@hsmpka.eng.sun.com> To: "Carl Rigney" , 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) My personal preference is to have an Access-Request message that includes Calling-Station-Id and Called-Station-Id and the Service-Type set to Authorize-Only. I really don't see the need for another service type. Of course, this could cause backward compatibility problems, but I think that you'll have problems regardless of the approach unless you require the User-Name attribute to be present. PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 12:13:05 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA11904 for ; Wed, 4 Nov 1998 12:13:04 -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 JAA22680; Wed, 4 Nov 1998 09:07:24 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA29329 for ietf-radius-outgoing; Wed, 4 Nov 1998 09:07:23 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Wed, 4 Nov 1998 11:44 EST Subject: Re: (radius) Username/User-Password attributes Content-Type: text/plain Message-ID: <364089e50.320a@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff > From: Aydin Edguer > Date: Wed, 4 Nov 1998 10:21:45 -0500 (EST) > > > For that scenario, I'd feel safer replying with Access-Challenge, not > > Accept, because further user authentication must be done. > > Using an Access-Challenge might be an option, but it is not strictly > necessary. In the Ascend implementation, you are able to either accept > the call an immediately start a framed protocol or terminal server > login without additional authentication, or you can require user > authentication in addition to called or calling station "call-check" > based on a vendor specific attribute in the Access-Accept message. > > Specifically using Ascend-Require-Auth = Require-Auth forces the user to > go through "normal" framed (PAP/CHAP) or terminal server (login/password) > authentication. Need I point out that Ascend-Require-Auth is NOT a generally-accepted RADIUS attribute, but a vendor-specific attribute in drag? If we are trying to define the standard (or at least recommended) way to handle this issue, I strongly oppose using an Access-Accept as anything other than meaning "accept this user" because of the risk of allowing a caller inappropriately. > > So I would like to define the NAS's action on all three server responses: > > > > Kill the call on reject. > > This is controlled by the NAS. The Access-Reject can cause the call to > be rejected (not-answered) or the NAS can accept the call but require the > normal authentication. The server has no method of physically forcing the NAS to terminate the call, I agree. But I believe, strongly, that we have three responses that have perfectly intuitive meanings, and should not blur the meanings without some really good reason. You're advocating an Accept that can say "do more authentication" and a reject that says "no good this try, but feel free to try again". Whatever is wrong with Access Challenge? Are we really going to say that because some old demo-level code (for which we should all be grateful!) might not issue one that we can't now use it? > > Answer the call and do further user authentication on challenge. > > I can see that using Access-Challenge would be useful for certain purposes > but it is not strictly necessary to acheive the behavior you describe. > It requires more intelligence in the RADIUS server to implement (similar > to the Livingston RADIUS server method of implementing menus). Strictly speaking, packet type is not necessary at all, if packet attributes completely define the meaning of the packet. But that's some other protocol, not RADIUS. > > Answer the call and do no further user authentication on accept. > > This is an option, but it can be modified by other attributes in the > Access-Accept. See above for why I believe Accept and Reject should have unequivocal meanings. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 14:40:16 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA15774 for ; Wed, 4 Nov 1998 14:40:13 -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 LAA28126; Wed, 4 Nov 1998 11:34:14 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA17675 for ietf-radius-outgoing; Wed, 4 Nov 1998 11:33:55 -0800 (PST) From: Aydin Edguer Message-Id: <199811041932.OAA04643@harlequin.MorningStar.Com> Subject: Re: (radius) Username/User-Password attributes To: ietf-radius@livingston.com Date: Wed, 4 Nov 1998 14:32:50 -0500 (EST) In-Reply-To: <364089e50.320a@databus.databus.com> from "Barney Wolff" at Nov 4, 98 11:44:00 am 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 > > > For that scenario, I'd feel safer replying with Access-Challenge, not > > > Accept, because further user authentication must be done. > > > > Using an Access-Challenge might be an option, but it is not strictly > > necessary. In the Ascend implementation, you are able to either accept > > the call an immediately start a framed protocol or terminal server > > login without additional authentication, or you can require user > > authentication in addition to called or calling station "call-check" > > based on a vendor specific attribute in the Access-Accept message. > > > > Specifically using Ascend-Require-Auth = Require-Auth forces the user to > > go through "normal" framed (PAP/CHAP) or terminal server (login/password) > > authentication. > > Need I point out that Ascend-Require-Auth is NOT a generally-accepted > RADIUS attribute, but a vendor-specific attribute in drag? No, you do not need to point it out, since I stated explicitly that it was a vendor specific attribute. > If we are trying to define the standard (or at least recommended) way to > handle this issue, I strongly oppose using an Access-Accept as anything > other than meaning "accept this user" because of the risk of allowing a > caller inappropriately. Access-Accept in this case means accept this call, since what you are "authenticating" is the phone number, not a user. The decision on whether to authenticate the user separately can be a distinct issue from accepting the call. Please note, that I was not saying that we should not look into using the Access-Challenge. I was pointing out that it is not strictly necessary to implement the desired functionality. The fact that Ascend-Require-Auth is a vendor specific attribute, does not mean that a standard attribute with similar functionality could not be provided. > > > So I would like to define the NAS's action on all three server responses: > > > > > > Kill the call on reject. > > > > This is controlled by the NAS. The Access-Reject can cause the call to > > be rejected (not-answered) or the NAS can accept the call but require the > > normal authentication. > > The server has no method of physically forcing the NAS to terminate the > call, I agree. But I believe, strongly, that we have three responses > that have perfectly intuitive meanings, and should not blur the > meanings without some really good reason. You're advocating an Accept > that can say "do more authentication" and a reject that says "no good > this try, but feel free to try again". Whatever is wrong with Access > Challenge? Are we really going to say that because some old > demo-level code (for which we should all be grateful!) might not issue > one that we can't now use it? No, I am not advocating anything. I am pointing out *an* alternative that should be discussed and which is currently in use at some sites. Since much of RADIUS was supposed to be based on current practice, examining current practice seems reasonable. No where did I say that using an Access-Challenge was wrong, just that it was not strictly necessary and to point out that it requires greater intelligence in the RADIUS server. Access-Challenge is certainly a viable option. I am trying to make the point that the Access-Accept is accepting the call, and does not have to accept the user. I am saying that when sending an Access-Accept to a called or calling station-id request the RADIUS server can be used to authorize the call to proceed to user authentication. I think you are reading too much into an Access-Reject. I do not see that the current RADIUS standard uses sending an Access-Reject to mean "drop the call". There are many NAS vendors who will permit the user to attempt more than one authentication. Thus the NAS may receive an Access-Reject because of a typo and then an Access-Accept on the next attempt, without ever disconnecting the user. > > > Answer the call and do no further user authentication on accept. > > > > This is an option, but it can be modified by other attributes in the > > Access-Accept. > > See above for why I believe Accept and Reject should have unequivocal > meanings. I don't agree that Accept and Reject have unequivocal meanings beyond the RADIUS server accepting the information in the Request as valid or invalid. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 15:11:07 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA16594 for ; Wed, 4 Nov 1998 15:11:07 -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 MAA00364; Wed, 4 Nov 1998 12:05:20 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA22077 for ietf-radius-outgoing; Wed, 4 Nov 1998 12:05:24 -0800 (PST) From: Aydin Edguer Message-Id: <199811042004.PAA04687@harlequin.MorningStar.Com> Subject: Re: (radius) Username/User-Password attributes To: ietf-radius@livingston.com Date: Wed, 4 Nov 1998 15:04:20 -0500 (EST) In-Reply-To: <364089e50.320a@databus.databus.com> from "Barney Wolff" at Nov 4, 98 11:44:00 am 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 > > > Answer the call and do further user authentication on challenge. Just as you feel that the option I presented changes the meaning of the Access-Accept and Access-Reject, I think the option you presented changes to meaning of Access-Challenge. Normally an Access-Challenge does not give the user any greater access to the NAS. It allows the authentication to continue at the same level. When using called or calling station-id for pre-authentication of the call, the Access-Challenge would actually be giving access to the NAS, which the caller did not previously have. The use of an Access-Challenge also raises the question of how the Reply-Message in the Access-Challenge is supposed to be "displayed" to a user who is dialing in with a frame connection (rather than a terminal server). But I still think your idea is of interest and should be investigated. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 15:29:42 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA16920 for ; Wed, 4 Nov 1998 15:29:41 -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 MAA01103; Wed, 4 Nov 1998 12:23:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA24472 for ietf-radius-outgoing; Wed, 4 Nov 1998 12:23:52 -0800 (PST) Message-ID: From: "Nelson, David" To: ietf-radius@livingston.com, "'Aydin Edguer'" Subject: RE: (radius) Username/User-Password attributes Date: Wed, 4 Nov 1998 15:21:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2217.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA16920 > > If we are trying to define the standard (or at least recommended) > way to > > handle this issue, I strongly oppose using an Access-Accept as > anything > > other than meaning "accept this user" because of the risk of > allowing a > > caller inappropriately. > > Access-Accept in this case means accept this call, since what you are > "authenticating" is the phone number, not a user. > Ah, but the "U" in RADIUS stands for USER. I think the basic paradigm of RADIUS is the authentication of, and service provision to, USERS. While this distinction may seem pedantic, I think we could easily go astray if we start authenticating other entities. In the Caller-ID case, one typically thinks of the calling phone number as the alias of a user (or group of users). > The decision on whether to authenticate the user separately can be a > distinct issue from accepting the call. > There can be a distinct decision, but it should not be up the NAS to decide. The RADIUS server is uniquely positioned to make such security policy decisions, IMHO. > Please note, that I was not saying that we should not look into using > the > Access-Challenge. I was pointing out that it is not strictly > necessary > to implement the desired functionality. > > The fact that Ascend-Require-Auth is a vendor specific attribute, does > not > mean that a standard attribute with similar functionality could not be > provided. > Adding a another standard attribute whose functionality overlaps and confuses that of existing standard attributes is only slightly better than adding a vendor-specific attribute with the same properties. > > > > So I would like to define the NAS's action on all three server > responses: > > > > > > > > Kill the call on reject. > > > > > > This is controlled by the NAS. The Access-Reject can cause the > call to > > > be rejected (not-answered) or the NAS can accept the call but > require the > > > normal authentication. > > > > The server has no method of physically forcing the NAS to terminate > the > > call, I agree. But I believe, strongly, that we have three > responses > > that have perfectly intuitive meanings, and should not blur the > > meanings without some really good reason. You're advocating an > Accept > > that can say "do more authentication" and a reject that says "no > good > > this try, but feel free to try again". Whatever is wrong with > Access > > Challenge? Are we really going to say that because some old > > demo-level code (for which we should all be grateful!) might not > issue > > one that we can't now use it? > I have to support this view. > I think you are reading too much into an Access-Reject. > How so? To use the cliché: "What part of 'no' don't you understand?" What's to read into the meaning of Access-Reject? > I do not see that the current RADIUS standard uses sending an > Access-Reject > to mean "drop the call". There are many NAS vendors who will permit > the > user to attempt more than one authentication. Thus the NAS may > receive > an Access-Reject because of a typo and then an Access-Accept on the > next > attempt, without ever disconnecting the user. > Well, here I concur. The NAS may decide to drop the call or it may allow authentication retries. That is an implementation decision. Access-Reject certainly means "don't start the service", however. > I don't agree that Accept and Reject have unequivocal meanings beyond > the RADIUS server accepting the information in the Request as valid or > invalid. > Yes and no. Access-Reject means "do not start the service". If the NAS is not prepared to implement an authentication retry method, then it certainly implies "drop the call". Access- Accept dictates what service will be delivered -- it need not the service requested or expected by the user. Any service type information in an Access-Request packet is just a hint to the RADIUS server. 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 Wed Nov 4 15:49:59 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA17229 for ; Wed, 4 Nov 1998 15:49:58 -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 MAA01941; Wed, 4 Nov 1998 12:44:11 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA26589 for ietf-radius-outgoing; Wed, 4 Nov 1998 12:43:57 -0800 (PST) Message-Id: <3.0.2.32.19981104213929.00a29d80@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 04 Nov 1998 21:39:29 +0100 To: Carl Rigney , ietf-radius@livingston.com From: Harald Tveit Alvestrand Subject: Re: (radius) Implementation survey Cc: isp-radius@livingston.com In-Reply-To: <199811041135.DAA04071@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Harald Tveit Alvestrand At 03:35 04.11.98 -0800, Carl Rigney wrote: >As part of moving RADIUS from Proposed to Draft Standard I need to >write an informational RFC documenting interoperability among >independent implementations. > >If you have a RADIUS server or client and would like to be mentioned, >would you please email me (NOT the list, just me) the following info >by 11/10, and I'll write up a summary and post it to the mailing list >before submitting it. > Remember to include in the documentation a list of supported features; the IETF rules say that *every feature* of a protocol, optional or not, must be implemented by at least 2 independent implementations (in this case, 2 clients and 2 servers). Otherwise, it will be removed from the draft version. (Better get that feature listing completed, too....) Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 15:50:01 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA17239 for ; Wed, 4 Nov 1998 15:50:00 -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 MAA01939; Wed, 4 Nov 1998 12:44:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA26599 for ietf-radius-outgoing; Wed, 4 Nov 1998 12:44:00 -0800 (PST) Message-Id: <3.0.2.32.19981104214506.01373940@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 04 Nov 1998 21:45:06 +0100 To: William Bulley , cdr@livingston.com From: Harald Tveit Alvestrand Subject: ICANN and IANA (Re: (radius) IANA guidance draft) Cc: ietf-radius@livingston.com In-Reply-To: <199811041419.JAA20932@ohm.merit.edu> References: <199811041230.EAA06775@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Harald Tveit Alvestrand At 09:19 04.11.98 -0500, William Bulley wrote: >According to Carl Rigney: >> >> As part of the progression of the RADIUS RFC from Proposed to Draft >> Standard, I need to write another RFC providing guidelines for the IANA >> to know when its OK to hand out an attribute (90 upwards). I'm >> reviewing some examples of such, but if anyone has well-reasoned text >> they'd like to contribute to the cause, please feel free to email me. > >I thought ICANN was replacing IANA... > IANA, which in this case is the registration function for identifiers in Internet protocols, is a function, which the IAB decides to place with some agency to execute. At the moment, the IAB has asked ISI to execute this function. It's assumed that if everything goes well, the IAB will ask ICANN to execute this function. But we're not there yet, by quite a few rows of apple trees. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 4 16:02:06 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA17432 for ; Wed, 4 Nov 1998 16:02:05 -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 MAA02443; Wed, 4 Nov 1998 12:56:28 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA27978 for ietf-radius-outgoing; Wed, 4 Nov 1998 12:56:28 -0800 (PST) Date: Wed, 4 Nov 1998 12:53:15 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199811042053.MAA07978@hsmpka.eng.sun.com> To: "Aydin Edguer" , 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) What if there is no further user authentication? An example is a tunneled user and the LNS information is determined based on DNIS. In this case the NAS should an Access-Accept (with service type=Authorize-Only) and the LNS information. PatC >> > > Answer the call and do further user authentication on challenge. > >Just as you feel that the option I presented changes the meaning of >the Access-Accept and Access-Reject, I think the option you presented >changes to meaning of Access-Challenge. > >Normally an Access-Challenge does not give the user any greater access >to the NAS. It allows the authentication to continue at the same level. > >When using called or calling station-id for pre-authentication of the >call, the Access-Challenge would actually be giving access to the NAS, >which the caller did not previously have. > >The use of an Access-Challenge also raises the question of how the >Reply-Message in the Access-Challenge is supposed to be "displayed" >to a user who is dialing in with a frame connection (rather than a >terminal server). > >But I still think your idea is of interest and should be investigated. >- >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 Nov 4 16:41:07 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA18220 for ; Wed, 4 Nov 1998 16:41:07 -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 NAA04028; Wed, 4 Nov 1998 13:35:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA02501 for ietf-radius-outgoing; Wed, 4 Nov 1998 13:35:33 -0800 (PST) From: Aydin Edguer Message-Id: <199811042134.QAA04855@harlequin.MorningStar.Com> Subject: Re: (radius) Implementation survey To: ietf-radius@livingston.com Date: Wed, 4 Nov 1998 16:34:29 -0500 (EST) In-Reply-To: <3.0.2.32.19981104213929.00a29d80@dokka.maxware.no> from "Harald Tveit Alvestrand" at Nov 4, 98 09:39:29 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 Harald@Alvestrand.no writes: > (Better get that feature listing completed, too....) Carl, are you going to put together a feature listing? Or would it be better to have one of use volunteer, so that you can get the draft document of the Draft-Standard completed? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Nov 5 07:33:48 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA02860 for ; Thu, 5 Nov 1998 07:33:47 -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 EAA04256; Thu, 5 Nov 1998 04:27:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA04615 for ietf-radius-outgoing; Thu, 5 Nov 1998 04:24:53 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Thu, 05 Nov 1998 13:19:03 +0200 MR-Received: by mta BTMV98; Relayed; Thu, 05 Nov 1998 13:19:06 +0200 MR-Received: by mta BTMA06; Relayed; Thu, 05 Nov 1998 13:18:56 +0200 Disclose-recipients: prohibited Date: Thu, 05 Nov 1998 13:19:03 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) Acct-Session-Id in Access-Requests In-reply-to: <364063A2.2E8A2C37@umich.edu> To: ietf-radius Message-id: <7703191305111998/A22251/BTMV98/11CB2B530000*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11CB2B530000 X400-MTS-identifier: [;7703191305111998/A22251/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT Having worked on a RADIUS proxy for some time now, I'd say a session-id in Access-Request is a MUST, but I can live with SHOULD... Advantages in keeping session state are obvious. There are work-arounds now (NAS-Id, NAS-Port, User-Name combos) but only the session-id really does the trick. I would like to remark that the DIAMETER protocol (possible successor for RADIUS??) requires a session-id in all requests as it is session-oriented. As for the global uniqueness of session-ids: I fail to see the reason for that, at least on the NAS level. The first proxy communicating with the NAS can distinguish the NASes (by source IP or attribute 4 or 32). If it also has the session-id, it can 'combine' them to form a system-unique session-id when forwarding the requests. If further down the line, a RADIUS server receives requests from multiple proxy servers and NASses, it can use the same logic to come up with it's own system-unique IDs. Regards, Marc >Carl Rigney wrote: >> >> Possibly I'm mellowing in my dotage, but as I'm looking over the >> attribute tables for the revised drafts I recall that once upon a time >> people asked about the possibility of allowing NASes to send >> Acct-Session-Id in their Access-Request, so that such requests could be >> linked up later with the matching accounting record. At the time it >> seemed marginal, but in the Brave New World of Proxy it seems more >> useful. >> >> Would there be a firestorm of protest if Acct-Session-Id were permitted >> in Access-Request as well as Accounting-Requests? > >I'd say that's great, especially as you said in the world of proxy. >But there should be some provision on making the Acct-Session-Id's >unique across NAS'es without having to do any trick with its content >on the server side. Otherwise, it would be difficult to use the >Acct-Session-Id's in a generalized way. Since NAS-IP-Address and >NAS-Identifier are defined as "SHOULD" be in access requests, life >would much easier if one can depend on the Acct-Session-Id to be >unique. > >Regards, >-- >Wei Wang weiwang@umich.edu >Merit Network, Inc. http://www-personal.umich.edu/~weiwang/ >[Tel] 734-764-2874 [Fax] 734-647-3745 >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Nov 5 21:46:09 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA13560 for ; Thu, 5 Nov 1998 21:46:09 -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 SAA02110; Thu, 5 Nov 1998 18:30:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA27887 for ietf-radius-outgoing; Thu, 5 Nov 1998 18:28:42 -0800 (PST) Message-ID: <25983782061AD111B0800000F86310FE07F631FC@RED-MSG-42> From: Ashwin Palekar To: "'Carl Rigney'" , ietf-radius@livingston.com Subject: RE: (radius) Acct-Session-Id in Access-Requests Date: Thu, 5 Nov 1998 18:28:11 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ashwin Palekar Another possible approach is that the RADIUS server could generate a unique Class attribute for each successful authentication and return it in the access-accept. The NAS then sends the class attribute in each accounting request for that session. This Class attribute can also be used to link authentication_accepts with accounting records. Any disadvantages of using the Class attribute instead of the NAS generating the Acct-Session-Id? -----Original Message----- From: Carl Rigney [mailto:cdr@livingston.com] Sent: Wednesday, November 04, 1998 4:22 AM To: ietf-radius@livingston.com Subject: (radius) Acct-Session-Id in Access-Requests Possibly I'm mellowing in my dotage, but as I'm looking over the attribute tables for the revised drafts I recall that once upon a time people asked about the possibility of allowing NASes to send Acct-Session-Id in their Access-Request, so that such requests could be linked up later with the matching accounting record. At the time it seemed marginal, but in the Brave New World of Proxy it seems more useful. Would there be a firestorm of protest if Acct-Session-Id were permitted in Access-Request as well as Accounting-Requests? -- Carl Rigney RADIUS WG Editor 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 Thu Nov 5 22:13:44 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA13859 for ; Thu, 5 Nov 1998 22:13:43 -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 TAA02953; Thu, 5 Nov 1998 19:03:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA29352 for ietf-radius-outgoing; Thu, 5 Nov 1998 19:02:31 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Thu, 5 Nov 1998 21:59 EST Subject: RE: (radius) Acct-Session-Id in Access-Requests Content-Type: text/plain Message-ID: <364266e30.534b@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff The technique works (in fact, I use it) but think about retries, to the same or different auth server. It really is cleaner when the NAS, which has the ultimate knowledge of call start/end, generates the session id. Barney Wolff > From: Ashwin Palekar > Date: Thu, 5 Nov 1998 18:28:11 -0800 > > Another possible approach is that the RADIUS server could generate a unique > Class attribute for each successful authentication and return it in the > access-accept. The NAS then sends the class attribute in each accounting > request for that session. This Class attribute can also be used to link > authentication_accepts with accounting records. Any disadvantages of using > the Class attribute instead of the NAS generating the Acct-Session-Id? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Nov 6 01:05:40 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA23009 for ; Fri, 6 Nov 1998 01:05: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 VAA09458; Thu, 5 Nov 1998 21:59:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA09881 for ietf-radius-outgoing; Thu, 5 Nov 1998 21:59:31 -0800 (PST) Date: Thu, 5 Nov 1998 21:59:30 -0800 (PST) From: Carl Rigney Message-Id: <199811060559.VAA09875@server.livingston.com> To: ietf-radius@livingston.com Subject: Re: (radius) Implementation survey Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Our Area Director raises an excellent point, that every feature must have at least two independent implementations, or must be omitted from the draft when it advances to Proposed Standard. I'm especially concerned about LAT and Appletalk. So first I'd like comments on this list of features, but do NOT send me info yet on whether your implementation supports any of these or not. Just send me (just me, to avoid flooding the list) email on whether there should be any more (or fewer) features on this list, and once I have a definitive list I'll post that and ask everyone to send in the features they support NOW. No fair saying you'll be adding it later, it has to be in your implementation that's already done and being used somewhere, although I'd think that beta or experimental software counts, as long as its actually running code. Possibly we should have seperate sections for servers and NASes? Servers that support proxy would be assumed to pass along anything as a client that they accept as a server. Note that not all values of a given attribute need to be supported, if your NAS only supports PPP but not SLIP, that still counts for Framed-Protocol. Proxy supported: Packet Types supported: Access-Request Access-Accept Access-Reject Access-Challenge Accounting-Request Accounting-Response Attributes supported: User-Name User-Password up to 16 characters long User-Password up to 128 characters long (encrypted as described in draft) CHAP-Password NAS-IP-Address NAS-Port Service-Type Framed-Protocol Framed-IP-Address Framed-IP-Netmask Framed-Routing Filter-Id Framed-MTU Framed-Compression Login-IP-Host Login-Service Login-TCP-Port Reply-Message Callback-Number Callback-Id Framed-Route Framed-IPX-Network State Class Vendor-Specific Session-Timeout Idle-Timeout Termination-Action Called-Station-Id Calling-Station-Id NAS-Identifier Proxy-State Login-LAT-Service Login-LAT-Node Login-LAT-Group Framed-AppleTalk-Link Framed-AppleTalk-Network Framed-AppleTalk-Zone CHAP-Challenge NAS-Port-Type Port-Limit Login-LAT-Port Features supported: Identifier (in packet header) Request Authenticator Response Authenticator Challenge Response Supports PAP Supports CHAP OK, what have I forgotten? Please email ME, not the entire list, and preferably email me quickly, in the next day or two. Note that Accounting is informational so its attributes do not need to be listed here, but the Accounting packet codes *are* included in the RADIUS RFC, thus their mention above. Again, do NOT send me the list of features you support yet; first I want to create the complete list, THEN I'll send email asking for people to tell me which features they support (so you only have to send that once)! -- Carl Rigney RADIUS WG Editor 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 Fri Nov 6 01:08:34 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA23031 for ; Fri, 6 Nov 1998 01:08: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 VAA09293; Thu, 5 Nov 1998 21:54:21 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA09540 for ietf-radius-outgoing; Thu, 5 Nov 1998 21:53:27 -0800 (PST) Message-Id: <3.0.1.32.19981106004638.018e6e00@pop.prodigy.net> X-Sender: victor@pop.prodigy.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 06 Nov 1998 00:46:38 -0500 To: Carl Rigney , ietf-radius@livingston.com From: Victor Muslin Subject: Re: (radius) Acct-Session-Id in Access-Requests In-Reply-To: <199811041221.EAA06013@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Victor Muslin I would strongly encourage allowing Acct-Session-Id in Access-Request. It's a needed feature for the servers that keep session state. At 04:21 AM 11/4/98 -0800, Carl Rigney wrote: >Possibly I'm mellowing in my dotage, but as I'm looking over the >attribute tables for the revised drafts I recall that once upon a time >people asked about the possibility of allowing NASes to send >Acct-Session-Id in their Access-Request, so that such requests could be >linked up later with the matching accounting record. At the time it >seemed marginal, but in the Brave New World of Proxy it seems more >useful. > >Would there be a firestorm of protest if Acct-Session-Id were permitted >in Access-Request as well as Accounting-Requests? > >-- >Carl Rigney >RADIUS WG Editor >cdr@livingston.com >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > _______________________________________________________________________ Victor Muslin - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Nov 6 06:13:20 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA24661 for ; Fri, 6 Nov 1998 06:13:19 -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 DAA13262; Fri, 6 Nov 1998 03:02:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA20828 for ietf-radius-outgoing; Fri, 6 Nov 1998 03:00:36 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Fri, 06 Nov 1998 11:55:11 +0200 MR-Received: by mta BTMV98; Relayed; Fri, 06 Nov 1998 11:55:12 +0200 MR-Received: by mta BTMA06; Relayed; Fri, 06 Nov 1998 11:55:02 +0200 Disclose-recipients: prohibited Date: Fri, 06 Nov 1998 11:55:11 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) Acct-Session-Id in Access-Requests In-reply-to: <25983782061AD111B0800000F86310FE07F631FC@RED-MSG-42> To: ietf-radius Message-id: <7011551106111998/A23517/BTMV98/11CB32F70A00*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11CB32F70A00 X400-MTS-identifier: [;7011551106111998/A23517/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT This has several drawbacks: 1. The Class attribute is already used for other purposes in some of the implementations I have come across. Typically it is used to identify the 'group' the user belongs to. The wording in the RFC suggests such use. Other implementations use it to get authentication-time info into the accounting logs. 2. At least one NAS vendor I know of sends proprietary RADIUS messages (on timer basis) with a list of how many sessions are currently active on the NAS for each Class. Using a unique Class value per session would cause this message to be too large (720 sessions per NAS). I read (I think it was on this mailing list) other vendors provide per-Class information via SNMP. With a formatted Class value (containing both a session-id and a user group id) issue 1. could be solved, but not issue 2. >Another possible approach is that the RADIUS server could generate a unique >Class attribute for each successful authentication and return it in the >access-accept. The NAS then sends the class attribute in each accounting >request for that session. This Class attribute can also be used to link >authentication_accepts with accounting records. Any disadvantages of using >the Class attribute instead of the NAS generating the Acct-Session-Id? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Nov 6 06:44:06 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA24952 for ; Fri, 6 Nov 1998 06:44:06 -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 DAA13777; Fri, 6 Nov 1998 03:38:19 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA22121 for ietf-radius-outgoing; Fri, 6 Nov 1998 03:36:56 -0800 (PST) Message-Id: <3.0.2.32.19981106122446.014c62f0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 06 Nov 1998 12:24:46 +0100 To: Carl Rigney , ietf-radius@livingston.com From: Harald Tveit Alvestrand Subject: Re: (radius) Implementation survey In-Reply-To: <199811060559.VAA09875@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Harald Tveit Alvestrand At 21:59 05.11.98 -0800, Carl Rigney wrote: No fair saying you'll be adding it later, >it has to be in your implementation that's already done and being used >somewhere, although I'd think that beta or experimental software >counts, as long as its actually running code. Right on. As long as you managed to code it correctly, and test it, it is an "implementation". Released code with version numbers preferred, of course; it's easier to verify those claims if anyone should challenge them. >Possibly we should have seperate sections for servers and NASes? Yes, I think so. Possibly even 3 columns: Server, NAS, Proxy. >Servers that support proxy would be assumed to pass along anything as a >client that they accept as a server. Note that not all values of a >given attribute need to be supported, if your NAS only supports PPP but >not SLIP, that still counts for Framed-Protocol. Yes. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Nov 8 04:22:50 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA01217 for ; Sun, 8 Nov 1998 04:22: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 BAA27775; Sun, 8 Nov 1998 01:16:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA27226 for ietf-radius-outgoing; Sun, 8 Nov 1998 01:12:05 -0800 (PST) Message-Id: <199811080911.BAA27748@bast> Date: Sun, 8 Nov 1998 03:50:13 -0500 (EST) From: "info@save-net.com" Subject: (radius) ADV: Save Up To 50% on International Calling Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "info@save-net.com" Message sent by: ITC Int'l Callback, 25 Tarhelia Lane, Whittier, NC 28789, 1-828-497-6282. To be removed, click reply with "remove" in the subject. Save Up To 50% on International Calling Here is a sample of some of our rates FROM the USA To: (US$) Per Minute Rates COUNTRY RATE Australia .23 Brazil .65 Canada .14 China .75 France .23 Germany .23 India .79 Philippines .55 Russia .50 Taiwan .47 United Kingdom .14 - Rates apply 24 hrs/day, 7 days per week - No sign-up fees, or monthly fees - Complementary Calling Card, at same rates with no surcharges - Same rates apply to mobile phones, with no surcharges - Ideal for Home, Business, and mobile phone - No need to switch your current provider - For residents outside the USA, we have INT'L CALLBACK Contact us for our low callback rates. Contact us for more information and complete rate table at: info@save-net.com For SERVICE information, type "info" in the subject line. ******* AGENTS NEEDED WORLDWIDE ****** $ Earn Extra Income $ signing up friends, family, and business associates. Attractive commission rates, and NO sign-up fees. For AGENT information, type "agent" in the subject line. Please include your full name, when requesting agent information. Thank You! info@save-net.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Nov 9 16:48:05 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA04089 for ; Mon, 9 Nov 1998 16:48:04 -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 NAA02794; Mon, 9 Nov 1998 13:40:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA16019 for ietf-radius-outgoing; Mon, 9 Nov 1998 13:34:28 -0800 (PST) Message-ID: From: "Beadles, Mark A." To: "'Patrice Calhoun'" , ietf-radius@livingston.com, Aydin Edguer Subject: RE: (radius) Username/User-Password attributes Date: Mon, 9 Nov 1998 16:27:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." There are really a number of scenarios, some of which have wider application than others, for Phone-Number-only authorization. For example: 1) Compulsory tunneling of a connection based solely on number dialed. 2) Compulsory tunneling of a connection based solely on calling number. 3) Application of a preset filter to a connection based solely on number dialed. 4) Selection of a secondary authentication server based solely on number dialed. In many cases when authorization is based solely on the number dialed, this authorization takes place prior to the going off-hook. For example, in case 4, you can think of this as a "RADIUS referral" mechanism, where the selection of which RADIUS server the NAS should authenticate against is determined by which number is dialed. The mechanism for making this determination? RADIUS, of course. This allows the sharing of NAS's across multiple service providers without the use of RADIUS proxy. Another interesting application is a help-desk scenario. User's password expires, or user is new and has no password - then just dial this toll-free number which connects you (either via a tunnel or via application of filters) to a preset site which has help-desk or sign-up information. Or consider where a corporation provides its sales force with a bunch of cellular modems from a predetermined pool of phone numbers. Perhaps when these folks dial in, they automatically get tunneled to a corporate intranet site. I have noted some objections to going down this road, paraphrased here: Objection 1) RADIUS stands for ...USER SERVICE, how can we even think about authenti- cating things that aren't user-based? Response 1) It's really just a matter of degree. RADIUS is just a tool for service providers and enterprises to implement policy. Policy may be very strict or very loose, and this is a business decision, not a technical one. Phone number based authorization is really just authentication based on a very loose set of credentials - specifically, just knowing a phone number. But these credentials may be good enough to authorize a very limited set of services, such as a help desk, a sign-up service, or the granting of a try at a round of REAL authentication. Objection 2) Couldn't this lead to the use of predictable passwords in a DNIS-based Access-Request, which could aid an attacker in recovering a shared secret if they could snoop the wire? Response 2) I agree with those who point out that service providers should be policing their shared secrets anyway, and that if you posit the ability to snoop the wire, guessing shared secrets via a known plaintext/dictionary attack is not a high risk. Objection 3) But doesn't this subvert the RADIUS model? What is the proper action when a NAS gets an Access-Accept or -Reject on a DNIS-authorized call? Response 3) Really quite straightforward. The NAS just does what the RADIUS server says. If the RADIUS server says, Access-Reject, then the NAS doesn't pick up the phone. If the RADIUS server says, Access-Accept, Tunnel-*, then the NAS connects the user and builds a tunnel. If the RADIUS server says, Access-Accept, Filter 17, then the NAS connects the user and applies filter 17. If the RADIUS server says, Access-Accept, RADIUS-Referral-Address 10.10.10.1[note], then the NAS picks up the phone and begins a normal PPP negotiation, using RADIUS server 10.10.10.1. Note 1: OK, so this attribute doesn't exist in the standard, but you get the idea. Besides, the ability to provide the services described above is required, IMHO, and since RADIUS is all we have today, then it is RADIUS that will be used to provide them. + Mark Anthony Beadles + MCI WorldCom Advanced Networks + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + -----Original Message----- From: Patrice Calhoun [mailto:Pat.Calhoun@eng.sun.com] Sent: Wednesday, 04 November 1998 15:59 To: ietf-radius@livingston.com; Aydin Edguer Subject: Re: (radius) Username/User-Password attributes Sender: owner-ietf-radius@livingston.com Received: from bast (bast.livingston.com [149.198.247.2]) by arl-img-12.compuserve.com (8.8.6/8.8.6/2.16) with ESMTP id PAA03926 for ; Wed, 4 Nov 1998 15:59:07 -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 MAA02469; Wed, 4 Nov 1998 12:56:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA27978 for ietf-radius-outgoing; Wed, 4 Nov 1998 12:56:28 -0800 (PST) Date: Wed, 4 Nov 1998 12:53:15 -0800 From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199811042053.MAA07978@hsmpka.eng.sun.com> To: "Aydin Edguer" , 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) What if there is no further user authentication? An example is a tunneled user and the LNS information is determined based on DNIS. In this case the NAS should an Access-Accept (with service type=Authorize-Only) and the LNS information. PatC >> > > Answer the call and do further user authentication on challenge. > >Just as you feel that the option I presented changes the meaning of >the Access-Accept and Access-Reject, I think the option you presented >changes to meaning of Access-Challenge. > >Normally an Access-Challenge does not give the user any greater access >to the NAS. It allows the authentication to continue at the same level. > >When using called or calling station-id for pre-authentication of the >call, the Access-Challenge would actually be giving access to the NAS, >which the caller did not previously have. > >The use of an Access-Challenge also raises the question of how the >Reply-Message in the Access-Challenge is supposed to be "displayed" >to a user who is dialing in with a frame connection (rather than a >terminal server). > >But I still think your idea is of interest and should be investigated. >- >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 Nov 10 02:02:28 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA19755 for ; Tue, 10 Nov 1998 02:02:27 -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 WAA18593; Mon, 9 Nov 1998 22:56:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA01251 for ietf-radius-outgoing; Mon, 9 Nov 1998 22:56:17 -0800 (PST) Message-Id: <199811100654.WAA11810@shell4.ba.best.com> Subject: RE: (radius) Username/User-Password attributes (fwd) To: ietf-radius@livingston.com Date: Mon, 9 Nov 1998 22:54:56 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Once upon a time Beadles, Mark A. shaped the electrons to say... >1) Compulsory tunneling of a connection based solely on number dialed. >2) Compulsory tunneling of a connection based solely on calling number. >3) Application of a preset filter to a connection based solely on number >dialed. >4) Selection of a secondary authentication server based solely on number >dialed. All good. I also know of one user who wants to use Call-Check with a PM-3 and Lucent RADIUS 2.1b6 to do a *dialback* for specific Calling-Station-Ids - 5551212 calls in, the unit dials them back at that number. Nifty way to trigger dialback - the normal method being to dialin, authenticate via username/password, then disconnet and be called back. This way there is no charge for the inbound call. I think it is safe to say that there are a number of legitimate reasons to use Call-Check *without* an accompanying username/password immediately following. -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! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Nov 10 02:25:43 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA19878 for ; Tue, 10 Nov 1998 02:25:43 -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 XAA19328; Mon, 9 Nov 1998 23:19:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA02417 for ietf-radius-outgoing; Mon, 9 Nov 1998 23:20:27 -0800 (PST) Message-ID: <3647E92B.50E0A907@remusis.ro> Date: Tue, 10 Nov 1998 09:20:11 +0200 From: "Mugur Tomita" Organization: Remus Romania X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: (radius) PM2 without authentication References: <199811100654.WAA11810@shell4.ba.best.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mugur Tomita" Hi I have a PortMaster 2 with ELSA 56K and Motorola 28.8K modems. I want to set PM2 to let a user that calls one of my modems go into Internet without any authentication. I mean that I want the user not to be asked for any username or password... Does anybody knows how should I do? TIA, Mugur - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Nov 10 02:41:08 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA20016 for ; Tue, 10 Nov 1998 02:41:07 -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 XAA19583; Mon, 9 Nov 1998 23:30:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA02915 for ietf-radius-outgoing; Mon, 9 Nov 1998 23:31:07 -0800 (PST) Message-Id: <199811100728.XAA16217@shell4.ba.best.com> Subject: Re: (radius) PM2 without authentication In-Reply-To: <3647E92B.50E0A907@remusis.ro> from Mugur Tomita at "Nov 10, 98 09:20:11 am" To: Mugur.Tomita@remusis.ro Date: Mon, 9 Nov 1998 23:28:54 -0800 (PST) Cc: ietf-radius@livingston.com From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone You are asking the wrong group - this is the ietf-radius group - used by the IETF RADIUS WG for discussion of the development of the RADIUS protocol. It is not a support group. You want portmaster-users@livingston.com and/or portmaster-radius@livingston.com -MZ Once upon a time Mugur Tomita shaped the electrons to say... >Hi > >I have a PortMaster 2 with ELSA 56K and Motorola 28.8K modems. I want to set PM2 >to let a user that calls one of my modems go into Internet without any >authentication. >I mean that I want the user not to be asked for any username or password... >Does anybody knows how should I do? > >TIA, >Mugur > >- >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 Nov 10 06:08:55 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA21218 for ; Tue, 10 Nov 1998 06:08:54 -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 DAA23046; Tue, 10 Nov 1998 03:02:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA10713 for ietf-radius-outgoing; Tue, 10 Nov 1998 03:00:31 -0800 (PST) From: info@hot-stock.com Message-Id: <199811101543.KAA03856@mars.cyber-website.com> To: user@the.internet Date: Tue, 10 Nov 98 04:39:30 EST Subject: (radius) ADV: Hot-Stock Discovers Emerging Entertainment Company Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: info@hot-stock.com To be removed from our mailing list, simply reply with "Remove" in the subject line. Companies providing live streaming video content such as Broadcast.Com have had valuations as high as one billion dollars. Alternative Entertainment is a live streaming video content provider for Adult related Internet sites. Adult related sites on the Internet are not only profitable but represent the largest segment of E-Commerce and generate 1.2 billion in annual revenues. The Company was recently approved for trading by the NASD and there has been quite a bit of interest generated in this issue in the past weeks trading. Visit http://www.hot-stock.com for full details. Alternative Entertainment (OTC BB : BOYS) Shares Outstanding 3,013,790 Shares Public Float 980,000 Number Shareholders 790 Approved by NASD for Trading October 7, 1998 Visit http://www.hot-stock.com for full details. --- Disclaimer --- This material is being provided by Hot-Stock, an electronic newsletter paid by the issuer for publishing the information contained in this report. Alternative Entertainment, Inc. has paid a consideration of 5,000 shares of common stock of Alternative Entertainment, Inc. to Hot-Stock as payment for the publication of the information contained in this report. Hot-Stock and its affiliates have agreed not to sell the common stock received as payment for its services until November 1, 1998, which date is 15 days from the initial dissemination of this report. After such date, Hot-Stock may sell such shares. Because Hot-Stock is paid for its services, there is an inherent conflict of interest in Hot-Stock’s statements and opinions and such statements and opinions cannot be considered independent. The information contained in this publication is for informational purposes only, and not to be construed as an offer to sell or solicitation of an offer to buy any security. Hot-Stock makes no representation or warrant relating to the validity of the facts presented nor does Hot-Stock represent or warrant that all material facts necessary to make an investment decision are presented above. All statements of opinions are those of Hot-Stock. Hot-Stock relies exclusively on information gathered from public filings on featured companies, as well as, in certain circumstances, interviews conducted by Hot-Stock of management of featured companies. 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 conducting additional research on the featured companies in order to allow the investor to form his or her own opinion regarding the featured companies. Factual statements contained in this publication are made as of the date stated and they are subject to change without notice. Hot-Stock is not a registered investment adviser, broker or a dealer. Investment in the companies reviewed is speculative and extremely high-risk and may result in the loss of some or all of any investment made in Alternative Entertainment, Inc. 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 the judgment of Alternative Entertainment, Inc. as of the date of this publication. The Company disclaims any intent or obligation to update these forward-looking statements. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Nov 10 06:21:51 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA21255 for ; Tue, 10 Nov 1998 06:21: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 DAA23448; Tue, 10 Nov 1998 03:15:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA11460 for ietf-radius-outgoing; Tue, 10 Nov 1998 03:15:33 -0800 (PST) Message-ID: <004201be0c9a$de519ce0$0103a8c0@ds9> From: "Darran Potter" To: "Beadles, Mark A." , "'Patrice Calhoun'" , , "Aydin Edguer" Subject: Re: (radius) Username/User-Password attributes Date: Tue, 10 Nov 1998 11:11:29 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" We have clients wanting user access via premium rate nos' they dont care who so long as they come in via the correct number... So I'd like CLID/DNIS authentication.. So long as the standard defines how to recognise it... I think there may already by several proprietry implementations with CLID in the User-Name etc.. etc.. IMHO you should have a Calling/Called-Station-Id but NO User-Name or User-Password. That way it would be clear what type of authentication was needed. Otherwise you have to add per-vendor cludges. Wouldnt it be nice if there was an Authentication-Type attribute... so you didnt have to work out what you're supposed to do....Diameter maybe? Darran -----Original Message----- From: Beadles, Mark A. To: 'Patrice Calhoun' ; ietf-radius@livingston.com ; Aydin Edguer Date: 09 November 1998 21:40 Subject: RE: (radius) Username/User-Password attributes >There are really a number of scenarios, some of which have wider >application than others, for Phone-Number-only authorization. >For example: > >1) Compulsory tunneling of a connection based solely on number dialed. >2) Compulsory tunneling of a connection based solely on calling number. >3) Application of a preset filter to a connection based solely on number >dialed. >4) Selection of a secondary authentication server based solely on number >dialed. > >In many cases when authorization is based solely on the number dialed, this >authorization takes place prior to the going off-hook. For example, in case >4, >you can think of this as a "RADIUS referral" mechanism, where the selection >of >which RADIUS server the NAS should authenticate against is determined by >which >number is dialed. The mechanism for making this determination? RADIUS, of >course. >This allows the sharing of NAS's across multiple service providers without >the use >of RADIUS proxy. > >Another interesting application is a help-desk scenario. User's password >expires, >or user is new and has no password - then just dial this toll-free number >which >connects you (either via a tunnel or via application of filters) to a preset >site >which has help-desk or sign-up information. > >Or consider where a corporation provides its sales force with a bunch of >cellular >modems from a predetermined pool of phone numbers. Perhaps when these folks >dial in, they automatically get tunneled to a corporate intranet site. > >I have noted some objections to going down this road, paraphrased here: > >Objection 1) RADIUS stands for ...USER SERVICE, how can we even think about >authenti- > cating things that aren't user-based? > >Response 1) It's really just a matter of degree. RADIUS is just a tool for >service > providers and enterprises to implement policy. Policy may be >very strict > or very loose, and this is a business decision, not a technical >one. > Phone number based authorization is really just authentication >based on a > very loose set of credentials - specifically, just knowing a >phone number. > But these credentials may be good enough to authorize a very >limited set of > services, such as a help desk, a sign-up service, or the >granting of a try > at a round of REAL authentication. > >Objection 2) Couldn't this lead to the use of predictable passwords in a >DNIS-based > Access-Request, which could aid an attacker in recovering a >shared secret > if they could snoop the wire? > >Response 2) I agree with those who point out that service providers should >be policing > their shared secrets anyway, and that if you posit the ability >to snoop > the wire, guessing shared secrets via a known >plaintext/dictionary attack > is not a high risk. > >Objection 3) But doesn't this subvert the RADIUS model? What is the proper >action when a > NAS gets an Access-Accept or -Reject on a DNIS-authorized call? > >Response 3) Really quite straightforward. The NAS just does what the >RADIUS server says. > If the RADIUS server says, Access-Reject, then the NAS doesn't >pick up the phone. > If the RADIUS server says, Access-Accept, Tunnel-*, then the >NAS connects the > user and builds a tunnel. If the RADIUS server says, >Access-Accept, Filter 17, then > the NAS connects the user and applies filter 17. If the RADIUS >server says, > Access-Accept, RADIUS-Referral-Address 10.10.10.1[note], then >the NAS picks up the phone > and begins a normal PPP negotiation, using RADIUS server >10.10.10.1. > >Note 1: OK, so this attribute doesn't exist in the standard, but you get >the idea. > >Besides, the ability to provide the services described above is required, >IMHO, and since >RADIUS is all we have today, then it is RADIUS that will be used to provide >them. > > >+ Mark Anthony Beadles + MCI WorldCom Advanced Networks + >+ mbeadles@wcom.net + http://www.wcom.net + >+ Voice 614.723.1941 + Fax 614.723.8407 + > > >-----Original Message----- >From: Patrice Calhoun [mailto:Pat.Calhoun@eng.sun.com] >Sent: Wednesday, 04 November 1998 15:59 >To: ietf-radius@livingston.com; Aydin Edguer >Subject: Re: (radius) Username/User-Password attributes > > >Sender: owner-ietf-radius@livingston.com >Received: from bast (bast.livingston.com [149.198.247.2]) > by arl-img-12.compuserve.com (8.8.6/8.8.6/2.16) with ESMTP id >PAA03926 > for ; Wed, 4 Nov 1998 15:59:07 -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 MAA02469; Wed, 4 Nov 1998 12:56:35 -0800 >(PST) >Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) >id MAA27978 for ietf-radius-outgoing; Wed, 4 Nov 1998 12:56:28 -0800 (PST) >Date: Wed, 4 Nov 1998 12:53:15 -0800 >From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) >Message-Id: <199811042053.MAA07978@hsmpka.eng.sun.com> >To: "Aydin Edguer" , 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) > >What if there is no further user authentication? An example is a tunneled >user >and the LNS information is determined based on DNIS. In this case the NAS >should an Access-Accept (with service type=Authorize-Only) and the LNS >information. > > >PatC >>> > > Answer the call and do further user authentication on challenge. >> >>Just as you feel that the option I presented changes the meaning of >>the Access-Accept and Access-Reject, I think the option you presented >>changes to meaning of Access-Challenge. >> >>Normally an Access-Challenge does not give the user any greater access >>to the NAS. It allows the authentication to continue at the same level. >> >>When using called or calling station-id for pre-authentication of the >>call, the Access-Challenge would actually be giving access to the NAS, >>which the caller did not previously have. >> >>The use of an Access-Challenge also raises the question of how the >>Reply-Message in the Access-Challenge is supposed to be "displayed" >>to a user who is dialing in with a frame connection (rather than a >>terminal server). >> >>But I still think your idea is of interest and should be investigated. >>- >>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 Tue Nov 10 10:39:35 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA26332 for ; Tue, 10 Nov 1998 10:39:34 -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 HAA28759; Tue, 10 Nov 1998 07:28:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA23580 for ietf-radius-outgoing; Tue, 10 Nov 1998 07:26:53 -0800 (PST) Message-ID: <00e801be0cbe$32c71520$c889e9cc@titanium.techapp.com> From: "Russell J. LeBar" To: Subject: Re: (radius) PM2 without authentication Date: Tue, 10 Nov 1998 09:24:24 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.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" You have to admit that the timing is a bit ironic though, what with all the discussion about authenticating by phone number instead of username. I think Mugur unintentionally helped prove a point.... -----Original Message----- From: MegaZone >You are asking the wrong group - this is the ietf-radius group - used by >the IETF RADIUS WG for discussion of the development of the RADIUS protocol. >It is not a support group. From owner-ietf-radius@livingston.com Tue Nov 10 18:10:13 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA12178 for ; Tue, 10 Nov 1998 18:10:11 -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 PAA19641; Tue, 10 Nov 1998 15:04:16 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA18437 for ietf-radius-outgoing; Tue, 10 Nov 1998 14:59:26 -0800 (PST) Message-Id: <4.1.19981110130819.012d6980@bichon.cisco.com> X-Sender: hmorris@bichon.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 10 Nov 1998 14:52:40 -0800 To: ietf-radius@livingston.com From: Herb Morris Subject: (radius) Any CHAP-Challenge Attribute (#60) implementations Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Herb Morris Have any vendors implemented RADIUS clients or servers that support CHAP-Challenge attributes with a length of 32 bytes? From reading the RFC, I would expect the server to pass the CHAP ID octet, the user's password, and the 32-byte CHAP challenge to the MD5 code and then do a 16-byte comparison of the MD5 results against the 16 byte CHAP response contained in the CHAP-Password attribute (#3). In looking at the Merit's RADIUS server source code, version 3.6B, available at: ftp://ftp.merit.edu/radius/releases/ I find that Merit's server computes the MD5 digest based on the CHAP ID octet, the user's password, and ONLY the first 16 bytes of the 32 byte CHAP-Challenge attribute. The MD5 results are then compared against the 16 byte CHAP response contained in the CHAP-Password attribute. There are several comments in the Merit code that question the validity of the implementation. [This code is located in the funcs.c file, routine get_pass()] Any insight from vendors on how they have implemented 32 byte CHAP-Challenge attributes in their products would be helpful. As an aside, I remember a while back some posts that indicated that a RADIUS test suite was available. Could the owner(s) of this test suite provide information on it's availability (and possibly it's location)? Herb Morris Senior Software Engineer Cisco Systems Inc - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Nov 10 18:53:37 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA13048 for ; Tue, 10 Nov 1998 18:53:36 -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 PAA21162; Tue, 10 Nov 1998 15:42:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA23956 for ietf-radius-outgoing; Tue, 10 Nov 1998 15:39:54 -0800 (PST) Message-ID: <3648CEBA.FCDF09C4@iea-software.com> Date: Tue, 10 Nov 1998 15:39:38 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.07 [en] (WinNT; I) MIME-Version: 1.0 To: Herb Morris CC: ietf-radius@livingston.com Subject: Re: (radius) Any CHAP-Challenge Attribute (#60) implementations References: <4.1.19981110130819.012d6980@bichon.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Herb Morris wrote: > > Have any vendors implemented RADIUS clients or servers that support CHAP-Challenge > attributes with a length of 32 bytes? > > From reading the RFC, I would expect the server to pass the CHAP ID octet, > the user's password, and the 32-byte CHAP challenge to the MD5 code and > then do a 16-byte comparison of the MD5 results against the 16 byte CHAP > response contained in the CHAP-Password attribute (#3). > > In looking at the Merit's RADIUS server source code, version 3.6B, available at: > ftp://ftp.merit.edu/radius/releases/ > > I find that Merit's server computes the MD5 digest based on the CHAP ID octet, > the user's password, and ONLY the first 16 bytes of the 32 byte CHAP-Challenge > attribute. The MD5 results are then compared against the 16 byte CHAP > response contained in the CHAP-Password attribute. There are several > comments in the Merit code that question the validity of the implementation. > > Any insight from vendors on how they have implemented 32 byte CHAP-Challenge attributes in > their products would be helpful. RadiusNT supports any length (>= 5) CHAP-Challenge in attribute #60 to override the Challenge in the vector. It is computed exactly how you specify above, and not restricted or limited to 16 bytes. > As an aside, I remember a while back some posts that indicated that a RADIUS test suite > was available. Could the owner(s) of this test suite provide information on it's availability > (and possibly it's location)? What are you trying to test? RadiusNT includes Radlogin, which can send auth and accouting (start/stop) requests as well as do stress simulation (multi-thread). Anyone could use it to test a server. I just recently added the ability to send a request based on a binary capture of the request. Very useful for playback. :) -- 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 Nov 11 14:48:43 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA17415 for ; Wed, 11 Nov 1998 14:48:43 -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 LAA19189; Wed, 11 Nov 1998 11:42:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA14730 for ietf-radius-outgoing; Wed, 11 Nov 1998 11:40:29 -0800 (PST) From: "Bernard Aboba" To: "William Chops Westfield" , "Dave Mitton" Cc: Subject: Re: (radius) Client MIB & Traps? Date: Wed, 11 Nov 1998 11:33:53 -0800 Message-Id: <01be0daa$371929f0$1b8939cc@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" Do you have the text for the notifications that you would like me to add to the MIBs? If you send this to me, I will add it to the drafts. >Are "primary" and "secondary" all ready well defined terms? (I haven't >been paying attention recently.) our implementation has the ability to >have lists of more than two servers, possibly different for authentication >and accounting. Perhaps all the above should simplify to "no response from >a server." > >BillW > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Nov 12 10:48:59 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA11927 for ; Thu, 12 Nov 1998 10:48:58 -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 HAA25297; Thu, 12 Nov 1998 07:42:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA20083 for ietf-radius-outgoing; Thu, 12 Nov 1998 07:39:59 -0800 (PST) Message-Id: <199811121537.KAA11684@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-acc-clientmib-02.txt Date: Thu, 12 Nov 1998 10:37:53 -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 : RADIUS Accounting Client MIB Author(s) : B. Aboba, G. Zorn Filename : draft-ietf-radius-acc-clientmib-02.txt Pages : 11 Date : 11-Nov-98 This memo defines a set of extensions which instrument RADIUS account- ing client functions. These extensions represent a portion of the Man- agement Information Base (MIB) for use with network management proto- cols in the Internet community. Using these extensions IP-based man- agement stations can manage RADIUS accounting clients. 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-acc-clientmib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-acc-clientmib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.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-acc-clientmib-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: <19981111161504.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-acc-clientmib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-acc-clientmib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981111161504.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Nov 12 10:49:01 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA11937 for ; Thu, 12 Nov 1998 10:49:00 -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 HAA25293; Thu, 12 Nov 1998 07:42:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA20107 for ietf-radius-outgoing; Thu, 12 Nov 1998 07:40:05 -0800 (PST) Message-Id: <199811121538.KAA11698@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-acc-servmib-02.txt Date: Thu, 12 Nov 1998 10:37:59 -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 : RADIUS Accounting Server MIB Author(s) : G. Zorn, B. Aboba Filename : draft-ietf-radius-acc-servmib-02.txt Pages : 13 Date : 11-Nov-98 This memo defines a set of extensions which instrument RADIUS account- ing server functions. These extensions represent a portion of the Man- agement Information Base (MIB) for use with network management proto- cols in the Internet community. Using these extensions IP-based man- agement stations can manage RADIUS accounting servers. 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-acc-servmib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-acc-servmib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.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-acc-servmib-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: <19981111170232.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-acc-servmib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-acc-servmib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981111170232.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Nov 12 10:49:04 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA11947 for ; Thu, 12 Nov 1998 10:49:03 -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 HAA25299; Thu, 12 Nov 1998 07:42:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA20128 for ietf-radius-outgoing; Thu, 12 Nov 1998 07:40:18 -0800 (PST) Message-Id: <199811121538.KAA11721@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-auth-servmib-02.txt Date: Thu, 12 Nov 1998 10:38:12 -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 : RADIUS Authentication Server MIB Author(s) : G. Zorn, B. Aboba Filename : draft-ietf-radius-auth-servmib-02.txt Pages : 15 Date : 11-Nov-98 This memo defines a set of extensions which instrument RADIUS authen- tication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management pro- tocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers. 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-auth-servmib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-auth-servmib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.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-auth-servmib-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: <19981111170604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-auth-servmib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-auth-servmib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981111170604.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Nov 12 10:49:26 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA11971 for ; Thu, 12 Nov 1998 10:49:25 -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 HAA25295; Thu, 12 Nov 1998 07:42:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA20136 for ietf-radius-outgoing; Thu, 12 Nov 1998 07:40:22 -0800 (PST) Message-Id: <199811121538.KAA11736@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-auth-clientmib-02.txt Date: Thu, 12 Nov 1998 10:38:17 -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 : RADIUS Authentication Client MIB Author(s) : B. Aboba, G. Zorn Filename : draft-ietf-radius-auth-clientmib-02.txt Pages : 13 Date : 11-Nov-98 This memo defines a set of extensions which instrument RADIUS authen- tication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management pro- tocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients. 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-auth-clientmib-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-auth-clientmib-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nic.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-auth-clientmib-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: <19981111170937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-auth-clientmib-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-auth-clientmib-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19981111170937.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 Tue Nov 17 17:01:28 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA26967 for ; Tue, 17 Nov 1998 17:01:27 -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 NAA06104; Tue, 17 Nov 1998 13:55:11 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA05044 for ietf-radius-outgoing; Tue, 17 Nov 1998 13:50:08 -0800 (PST) Message-ID: <8F76211F5DB3D1119F6F00A0C95A6630A6074E@SOL> From: Indranil Bagchi To: "'ietf-radius@livingston.com'" Subject: (radius) Open domain radius source code Date: Tue, 17 Nov 1998 13:49:07 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Indranil Bagchi Hello Everybody, I am looking for open domain source code or source code product for radius client. Any information in this regard will be appreciated. My apologies to those offended by such trivial questions. Thanks - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 18 07:10:17 1998 Received: from bast (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA25130 for ; Wed, 18 Nov 1998 07:10:16 -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 EAA02537; Wed, 18 Nov 1998 04:03:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA10593 for ietf-radius-outgoing; Wed, 18 Nov 1998 04:02:47 -0800 (PST) From: hiredhit@hiredhits.com DATE: Wed, 18 Nov 1998 06:13:28 -0600 Message-ID: Subject: (radius) Independent Price Survey of 175+ Insurance Companies To: lifeinsurancelist@livingston.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: hiredhit@hiredhits.com Please visit http://www.hiredhits.com/insurance/ to see the results of a recent independent survey of over 175 life insurance companies. Here is a sample: GUARANTEED MONTHLY PREMIUM FOR $250,000 FOR 10 YEAR TERM: Age Sex Preferred Health Standard Health 25 M $14.14 $17.18 25 F $11.96 $14.36 35 M $14.14 $17.18 35 F $11.96 $14.36 45 M $30.01 $36.68 45 F $20.47 $25.20 55 M $59.72 $77.85 55 F $44.41 $52.88 WE ARE NOT AFFILIATED WITH THE INSURANCE INDUSTRY... ..so these are not quotes. We are computer specialists, and we publish information. So take advantage of months of research and development. DON'T TALK TO AN AGENT UNTIL YOU GET THE FACTS http://www.hiredhits.com/insurance/ **************************************** Required Sender Information: MasterPromote, Inc. 120 Broadview Village Square Suite 315 Broadview, IL 60153 773-271-8484 To remove yourself from our mailing list(s), please visit: http://www.hiredhits.com/ and type your email address(es) in the "Remove Me!" box. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Nov 23 15:13:06 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 PAA01017 for ; Mon, 23 Nov 1998 15:13:04 -0500 (EST) 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 MAA08130; Mon, 23 Nov 1998 12:06:16 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA15070 for ietf-radius-outgoing; Mon, 23 Nov 1998 12:03:43 -0800 (PST) Message-ID: <002501be171b$e3675b30$0378a8c0@dima.svgdomain> From: "Dmitry G. Goncharenko" To: Subject: (radius) CHAP and Shared Secret Date: Mon, 23 Nov 1998 11:59:36 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3115.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dmitry G. Goncharenko" RFC 2138 says: " The RADIUS server looks up a password based on the User-Name, encrypts the challenge using MD5 on the CHAP ID octet, that password, and the CHAP challenge (from the CHAP-Challenge attribute if present, otherwise from the Request Authenticator), and compares that result to the CHAP-Password. If they match, the server sends back an Access-Accept, otherwise it sends back an Access-Reject." So it looks like shared secret is not used for CHAP authentication and RADIUS server will send "Access-Accept" response to a NAS for CHAP request without regard to shared secret configured between the NAS and RADIUS server. Is that right or I'm missing anything? Dmitry. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Nov 23 15:34: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 PAA01548 for ; Mon, 23 Nov 1998 15:34:36 -0500 (EST) 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 MAA09414; Mon, 23 Nov 1998 12:28:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA18531 for ietf-radius-outgoing; Mon, 23 Nov 1998 12:29:08 -0800 (PST) Date: Mon, 23 Nov 1998 12:29:01 -0500 From: Paul Krumviede Subject: Re: (radius) CHAP and Shared Secret To: "Dmitry G. Goncharenko" Cc: ietf-radius@livingston.com Message-id: <36599B5D.153BA383@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: <002501be171b$e3675b30$0378a8c0@dima.svgdomain> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede You're missing something. The secret shared between the NAS and the RADIUS server is used to compute an authenticator for communications between the RADIUS server and the NAS (think of it as a form of integrity check and a form of authentication of the sender to the recipient of any particular message). But this has nothing to do with how a server validates a user. -paul Dmitry G. Goncharenko wrote: > > RFC 2138 says: > " The RADIUS server looks up a password based on the User-Name, > encrypts the challenge using MD5 on the CHAP ID octet, that password, > and the CHAP challenge (from the CHAP-Challenge attribute if present, > otherwise from the Request Authenticator), and compares that result > to the CHAP-Password. If they match, the server sends back an > Access-Accept, otherwise it sends back an Access-Reject." > > So it looks like shared secret is not used for CHAP authentication and > RADIUS server will send "Access-Accept" response to a NAS for CHAP request > without regard to shared secret configured between the NAS and RADIUS > server. > Is that right or I'm missing anything? > > Dmitry. > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Nov 23 15:59: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 PAA02030 for ; Mon, 23 Nov 1998 15:59:07 -0500 (EST) 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 MAA10451; Mon, 23 Nov 1998 12:52:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA21757 for ietf-radius-outgoing; Mon, 23 Nov 1998 12:52:37 -0800 (PST) Date: Mon, 23 Nov 1998 16:00:13 -0500 Message-Id: <199811232100.QAA21855@cpu1751.striker.ottawa.on.ca> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) CHAP and Shared Secret Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok From draft-ietf-radius-ext-02.txt: ------------ 5.14. Signature Description This attribute MAY be used to sign Access-Requests to prevent dictionary attacks on CHAP, ARAP or EAP authentication methods. ... ------------ Yes, CHAP is subject to dictionary attacks without a packet Signature (based on the shared secret). 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 Nov 23 16:05:28 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 QAA02244 for ; Mon, 23 Nov 1998 16:05:27 -0500 (EST) 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 MAA10787; Mon, 23 Nov 1998 12:59:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA22736 for ietf-radius-outgoing; Mon, 23 Nov 1998 13:00:15 -0800 (PST) Message-ID: <003801be1723$cc09ef90$0378a8c0@dima.svgdomain> From: "Dmitry G. Goncharenko" To: Subject: Re: (radius) CHAP and Shared Secret Date: Mon, 23 Nov 1998 12:56:13 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3115.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dmitry G. Goncharenko" OK, then, RFC says: " Transactions between the client and RADIUS server are authenticated through the use of a shared secret, which is never sent over the network. In addition, any user passwords are sent encrypted between the client and RADIUS server, to eliminate the possibility that someone snooping on an unsecure network could determine a user's password." So in the case of using CHAP the "transaction between the client and RADIUS server" cannot be authenticated. And as a result of it I continue to process request, successfully authenticate a user and write to log message about permitted request. But, I think, I have to have a way to find out whether that request was from the client that knows correct shared secret or not to be able to deny the request. So how I can perform that "integrity check and a form of authentication of the sender to the recipient of any particular message" when CHAP is used? Dmitry. -----Original Message----- From: Paul Krumviede To: Dmitry G. Goncharenko Cc: ietf-radius@livingston.com Date: Monday, November 23, 1998 12:30 PM Subject: Re: (radius) CHAP and Shared Secret You're missing something. The secret shared between the NAS and the RADIUS server is used to compute an authenticator for communications between the RADIUS server and the NAS (think of it as a form of integrity check and a form of authentication of the sender to the recipient of any particular message). But this has nothing to do with how a server validates a user. -paul - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Nov 23 16:30:36 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 QAA02716 for ; Mon, 23 Nov 1998 16:30:35 -0500 (EST) 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 NAA12474; Mon, 23 Nov 1998 13:24:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA26562 for ietf-radius-outgoing; Mon, 23 Nov 1998 13:23:57 -0800 (PST) Message-ID: <004701be1727$1a593590$0378a8c0@dima.svgdomain> From: "Dmitry G. Goncharenko" To: Subject: Re: (radius) CHAP and Shared Secret Date: Mon, 23 Nov 1998 13:19:57 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3115.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dmitry G. Goncharenko" Thanx, now it's clear. -----Original Message----- From: Alan DeKok To: ietf-radius@livingston.com Date: Monday, November 23, 1998 12:55 PM Subject: Re: (radius) CHAP and Shared Secret > From draft-ietf-radius-ext-02.txt: > >------------ >5.14. Signature > > Description > > This attribute MAY be used to sign Access-Requests to prevent > dictionary attacks on CHAP, ARAP or EAP authentication methods. > ... >------------ > > Yes, CHAP is subject to dictionary attacks without a packet Signature >(based on the shared secret). > > Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Nov 24 01:01: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 BAA04457 for ; Tue, 24 Nov 1998 01:01:03 -0500 (EST) 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 VAA00768; Mon, 23 Nov 1998 21:54:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA17518 for ietf-radius-outgoing; Mon, 23 Nov 1998 21:53:16 -0800 (PST) Date: Mon, 23 Nov 1998 21:53:14 -0800 (PST) From: Carl Rigney Message-Id: <199811240553.VAA17508@server.livingston.com> To: web@merit.edu Subject: (radius) Re: omission(s) from Extensions Draft -02 Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney > 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? They're mentioned in the paragraph preceding the table: Acct-Input-Gigawords, Acct-Output-Gigawords, and Event-Timestamp may have 0-1 instances in an Accounting-Request packet. That way the table doesn't have to use up an entire column for Accounting-Request for just those three entries. -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Nov 24 01:26:36 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 BAA06089 for ; Tue, 24 Nov 1998 01:26:36 -0500 (EST) 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 WAA01236; Mon, 23 Nov 1998 22:20:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA18844 for ietf-radius-outgoing; Mon, 23 Nov 1998 22:20:02 -0800 (PST) From: 4details@bitsmart.com Message-Id: <199811240618.WAA01211@bast.livingston.com> To: Subject: (radius) Export Market for Security Products Date: Tue, 24 Nov 1998 10:46:12 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: 4details@bitsmart.com Dear reader, We have just visited your website and became interested in developing a long-term trading relationship with your company. We are the largest manufacturer of video door phones, specializing in a full range of security systems. Strong alliances have been established with many industries, such as: design institutes, building developers, construction and engineering firms, and real estate companies, etc. Our annual sales volume for 1997 was approximately US$ 10 million. Our core business is producing standard OEM & ODM security products that meet the individual needs of our customer's designs. Our quality control measures are strictly followed, from the very beginning of material development, until the goods are released to our customers. For full details on our company's profile, products, and distributorship / licensing agreements, please reply now. mailto:4details@bitsmart.com?Subject=VIDEO_DOOR_PHONES mailto:4details@bitsmart.com?Subject=DOOR_PHONES mailto:4details@bitsmart.com?Subject=SECURITY_PRODUCTS We look forward to your soonest reply! Thank you very much in advance. Sincerely yours, Mr. White Van Export Sales Manager Shenzhen Bailan Industrial Development Co., Ltd. Sales & Marketing Dept. Address: A 505, 5F, Build SEG Science Park, North. HuaQuing Road Shenzhen China Tel. (86)-755-376 2520 (8 Lines) P.C. 51828 Fax. (86)-755-332 1197 Pager: 191-548 4749 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 25 12:05:28 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 MAA10851 for ; Wed, 25 Nov 1998 12:05:27 -0500 (EST) 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 IAA26716; Wed, 25 Nov 1998 08:57:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA29477 for ietf-radius-outgoing; Wed, 25 Nov 1998 08:52:47 -0800 (PST) Message-ID: <8B3E2522987ED211B90900805F9F81A64D33AB@wcomexch1.wcom.net> From: "Beadles, Mark A." Subject: (radius) FYI: 43rd IETF-ORLANDO, FL: NASREQNG Date: Wed, 25 Nov 1998 11:46:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." The following BOF meeting in Orlando may be of interest to members of this group: This is to confirm one session for NASREQNG as follows: Thursday, December 10 at 1300-1500 other groups scheduled at that time: msgtrk, webdav, ipvbi, idr, saag, avt, rsvp NASreqNG BOF ------------- Title: Next Generation Network Access Server Requirements (NASreqNG) Chairs: David Mitton (dmitton@baynetworks.com) Mark Beadles (mbeadles@wcom.net) Operation and Management Area Directors: Harald Alvestrand (Harald.Alvestrand@maxware.no) Bert Wijnen (wijnen@vnet.ibm.com) BOF Description --------------- The goal of this BOF is to reconfirm interest and come to agreement on goals and charter of the proposed Next-generation Network Access Server Requirements (NASreqNG) Working Group. This BOF is a follow-on and culmination of the NASreqNG BOF held in December 1997 in Washington, DC. The proposed WG is to be focused on developing requirements for NAS's, documenting current practices of NAS vendors and deployers, and determining the suitability of candidate protocols for meeting the requirements of next-generation NAS's. The work items for this BOF are reconfirmation of interest in the WG, finalization of the charter and development of target dates for the WG goals, and, if the above are successful, drafting of volunteers to begin the work of the proposed WG. BOF Agenda ---------- -Agenda bashing -Review and discussion of charter -NAS Best Current Practices -Discussion of goal -Discussion of milestone completion target date -Volunteers for work -NAS Requirements -Discussion of goal -Discussion of milestone completion target date -Volunteers for work - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Nov 25 12:46:01 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 MAA13650 for ; Wed, 25 Nov 1998 12:45:59 -0500 (EST) 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 JAA28303; Wed, 25 Nov 1998 09:33:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA04762 for ietf-radius-outgoing; Wed, 25 Nov 1998 09:34:27 -0800 (PST) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199811251730.JAA02422@hsmpka.eng.sun.com> Date: Wed, 25 Nov 1998 09:25:17 -0800 To: , Subject: (radius) 43rd IETF-ORLANDO, FL: EAP BOF X-Mailer: Sun NetMail 2.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) FYI, PatC This is to confirm one session for EAP BOF as follows: Friday, December 11 at 0900-1130 other groups scheduled at that time: ptopomib, idr, megaco, avt, ipngwg -------- Name: Extensible Authentication Protocol (EAP) BOF Area: Security Chair: Glen Zorn (Microsoft) Purpose: Understand the extensions and or modifications required to generalize EAP (RFC 2284) for use outside of PPP. Goal: Form a WG to design and formalize the necessary extensions. Conflicts to Avoid: CAT, IPSEC, PPP, ROAMOPS, AAA BOF Expected Attendance: 75 Proposed Agenda 1. Agenda bashing. 2. What is the problem? 3. Is EAP the right solution? 4. How much work is involved? 4. Is the formation of a WG a good idea? 5. Definition of Working Group charter? Rationale Over the last few months, it has become apparent that several groups within the IETF are facing the same problem, having to do with the encapsulation and use of various methods for initial authentication. Several groups (e.g., ipsec, cat) have invented methods of their own. It is believed that considerable efficiency of effort may be had by defining a single standards-track protocol that can satisfy these multiple requirements. Note that this proposal does not conflict with the GSSAPI work of the CAT WG, since the GSSAPI cannot be used for initial authentication (i.e., logon). - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Nov 26 03:09: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 DAA24859 for ; Thu, 26 Nov 1998 03:09:57 -0500 (EST) 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 AAA24811; Thu, 26 Nov 1998 00:02:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id AAA12110 for ietf-radius-outgoing; Thu, 26 Nov 1998 00:01:38 -0800 (PST) From: Athena7868@aol.com Message-ID: <25af1299.365d07bc@aol.com> Date: Thu, 26 Nov 1998 02:48:12 EST Mime-Version: 1.0 Subject: (radius) !! Wanted Home Product Assemblers !! Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 18 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Athena7868@aol.com *****This is a one time Mailing. You will not receive mail from us again.***** Looking for Home Product Assemblers!! How would you like to Assemble Products at Home & get Paid! Choose your own Hours! Be your own Boss! Easy Work! Excellent Pay! Earn Hundreds of Dollars Weekly! Here are just a few examples of the work you will have to choose from: Wooden Products - up to $220.00 Weekly! Hair Accessories - up to $320.00 Weekly! Holiday Crafts - up to $270.00 Weekly! Beaded Accessories - up to $350.00 Weekly! ........Plus many others. There are over 75 Companies to choose from! Why not enjoy the Benefits and Freedom of Home Assembly Work! To find out more Call.....Toll Free (24 Hour Recording) 1-888-289-9708. U.S. Publishing Co. P.O. Box 633 Rocky Mount NC 27802 Name ___________________________________________ Address ___________________________________________ City & State ___________________________________________ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Nov 28 12:46:34 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 MAA13678 for ; Sat, 28 Nov 1998 12:46:33 -0500 (EST) 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 JAA21935; Fri, 27 Nov 1998 09:34:27 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA16360 for ietf-radius-outgoing; Fri, 27 Nov 1998 09:32:18 -0800 (PST) From: BHead68652@aol.com Message-ID: <4fd39203.365ed374@aol.com> Date: Fri, 27 Nov 1998 11:29:40 EST Mime-Version: 1.0 Subject: (radius) PREMIUM TV .......... NO MONTHLY BILLS ! Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 64 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: BHead68652@aol.com This is really cool! PREMIUM CHANNELS........Descrambled! EASY to assemble plans for only $7.00 ! YOU WILL BE WATCHING all your FAVORITE PAY STATIONS featuring MOVIES, SPORTS. Adult entertainment, and any other scrambled signal NEXT WEEK! You can EASILY assemble a cable descrambler in less than 30 minutes! You have probably seen many advertisments for similar plans......... BUT OURS are BETTER! We have compared it to all the others and have actually IMPROVED the quality and SIMPLIFIED the design !!! ** We even include PHOTOS! ** OUR PLANS ARE BETTER! We have NEW, EASY TO READ,EASY to assemble plans for only $7.00! We have seen them advertised for as much as $29.00 and you have to wait weeks to receive them! WHAT THE OTHERS SAY IS TRUE! Parts are available at "The TV HUT" or any electronics store. Trademark rights do not allow us to use a national electronics retail chains' name but there is one in your town! Call and ask them BEFORE you order! They are very familiar with these plans! You will need these easy to obtain parts : 270-235 mini box 271-1325 2.2k ohm resistor 278-212 chasis connectors RG59 coaxial cable #12 copper wire Variable capacitor They may have to special order the variable capacitor, But WHY WAIT for a special order? WE have them! WE have secured a supply of the capacitors directly from the manufacturer and We WILL include one with your plans for an ADDITIONAL $10.00 only! All you need now is the EASY TO ASSEMBLE plans to show you how this educational device in 30 MINUTES! It is LEGAL, providing of course you use these plans for EDUCATIONAL PURPOSES only. See first hand and LEARN how this SIMPLE circuitry works! If you intend to use these plans for any other purpose DO NOT ORDER them. IT'S FUN TO BUILD! We're sure you'll enjoy this project! This is a unique opportunity for hobbiest of ANY skill level to learn simple circuitry! Learn how easy descrambling is! $ 7.00 for plans only $10.00 for variable capacitor only $17.00 for The easy to assemble plans and one variable capacitor! Please send check or money order payable to: Kraftworks P.O. Box 11752 San Rafael, Ca. 94912 WE pay postage and handling! Please allow 14 days for delivery. This is a one time only mailing! You have already been placed on our remove list and will not receive another offer from us! Thank You - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Nov 30 06:08: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 GAA16748 for ; Mon, 30 Nov 1998 06:08:36 -0500 (EST) 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 DAA05194; Mon, 30 Nov 1998 03:01:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA17791 for ietf-radius-outgoing; Mon, 30 Nov 1998 02:57:25 -0800 (PST) From: twpe@msn.com Date: Mon, 30 Nov 1998 02:53:00 -0800 Message-Id: <199811301053.CAA10454@.ctxintl.com> To: hjdgfs@aol.com Subject: (radius) FIRM UP WITHOUT GIVING UP...the food you love! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: twpe@msn.com
INCREASE YOUR ENERGY LEVEL & FIRM UP WITHOUT
GIVING UP THE FOOD YOU LOVE!
* All Natural Energizer * Reduce Sugar Cravings
* Burn the Fat While You Keep the Muscle * Eat the Foods You Love
* Preferred by Fitness Experts *• 100% Safe and Natural

AN INCREDIBLE NUTRITIONAL BREAKTHROUGH!
I know what you're thinking. I felt the same way at
first but I found that there is finally a way to trim down
and shed unwanted fat without all the hassles of a diet
and strenuous exercise. Yes, there’s actually a wayto
firm up without giving up the food you love. And it’s so
easy! I just take one Thermo-Lift capsule twice a day
and that’s it! Sure, exercise and daily activity will
contribute to your results, but they’re not required!
And just thinkno messy powders or mixes. No starvation.
No rationing your food by the ounce. Thermo-Lift
improves your metabolism so your body burns the
excess fat!I actually noticed my clothes fitting better
before I noticed the pounds coming off!

METABOLISM IS THE KEY
Anyone who has struggled to lose weight can tell
you diets alone don't work! That’s because your size,
or your weight, has more to do with your metabolism
more than what you eat. Changes International has
designed a product that works several ways to help you
achieve maximum results from your weight-loss program.
This unique blend of herbs, botanicals and Chromium Picolinate
improves your metabolism so your body relies more on
stored body fat and less on stored proteins.

STOP THE YO-YO CYCLE!
On a typical diet, up to 30% of lost weight is muscle.
Losing muscle lowers your metabolic rate and slows
the burning of calories. This lower metabolic rate also
makes it hard to keep lost pounds from creeping back.
Result: the Yo-Yo syndrome! You know, up and down
up and down. After each lose-gain cycle the proportion
of fat actually increases! To break this vicious cycle,
it is important to lose only fat while maintaining or even
increasing muscle! Our unique formula is a specialized
combination of herbs and botanicals coupled with the
best source of chromium available.
Patented Chromium Picolinate, a bio-active chromium
with clinically proven benefits, is vital to good health
and is essential for the effective functioning of insulin.
Studies have shown chromium nutrition to be an
effective part of LONG TERM fat loss programs!

NATIONALLY RECOGNIZED
Three million readers of Cosmopolitan read a
discussion of Chromium Picolinate's value for dieters
under the headline, "A Miracle Mineral?". The
cholesterol-reducing effect of Chromium Picolinate
was highlighted in Ladies Home Journal
,Longevity magazine has praised it as a safe alternative
to anabolic steroids. A large number of publications
for athletes and health food shoppers have also
run feature articles on Chromium Picolinate,
including: Prevention, Today’s Living, Total Health
and Muscular Development

HERE’S MORE EVIDENCE!
Several double-blind crossover studies conducted
along with clinical and laboratory tests at a leading
university and hospital have proven that the ingredients
in Thermo-Lift are effective. Without changing dietary
or exercise habits over a 6-week period, subjects in
separate studies lost an average of 23% body fat or
approximately 4.4 pounds of fat, and increased lean
body mass by 1.5 pounds. People over the age of 46
did even better, and women seemed to do the best!
People with elevated cholesterol levels averaged a
10% drop in LDL cholesterol.

WHAT’S IN THERMO-LIFT?
Chromium Picolinate, Bee Pollen, Astralagus,
Licorice Root, Ginger Root, Rehmannia Root,
Siberian Ginseng, Ma Huang Extract, Gotu Kola,
Bladderwrack, White Willow Bark, Guarana Extract
and Reishi Mushroom. All ingredients are formulated
and synergistically blended to be both 100% safe and
effective. Thermo-Lift is manufactured and bottled by
a 25 year-old, pharmaceutical company and all FDA
standards have been met or exceeded.

THE ENERGIZERS
Siberian Ginseng: Good source of energy and
endurance. Increases physical and mental vigor.
Ma Huang extract: Helps to increase energy, improve
circulation,control appetite and decongest. The Chinese
use it for treatment of asthma and other respiratory
disorders. Guarana extract: Increases mental alertness
and fights fatigue a very high energy source.
Rehmannia Root: Used to treat anemia, fatigue, and
to promote the healing of bones. Astralagus: Acts as
a tonic to protect the immune system and increases
metabolism. Bee Pollen: Effective for combating fatigue,
depression, and colon disorders.

WHAT OTHERS HAVE FOUND
"My name is Denita Kellet. In just 18 months, I have
been able to lose 212 pounds and over 52 inches over
my entire body! I have a non-functioning thyroid and for
years have fought a losing battle with a bad weight problem.
Then I found Thermo-Lift. This product has greatly enriched my life and my health. I wish everybody could feel as good as I feel.
I'm a lot more active and able to play with my family.
All I can say is, thanks 110% Thermo-Lift for what you've
done for me and my life."

"My name is Misty McDonald. I'm a twenty-two year
old working mother of two children. In just five months
I have lost an amazing seventy pounds. I dropped an
incredible sixteen dress sizes! At 180 pounds, I was
very unhappy and depressed. I felt very insecure about
myself and really didn't like to go outside the house.
Then I found Thermo-Lift and what a difference it has
made in my life! Thank you Thermo-Lift for changing
my life and making me feel complete." Misty went from
180 pounds to 110 pounds in only 5 months.
Before and after pictures available!

"I have been examined by my doctor and my weight
loss has blown his mind! People that I used to work
with, and even some family members, have trouble
recognizing me. I wish everyone that is overweight
could be sent my way so that I could talk to them.
Maybe I could be of help, since I’ve lost 150 pounds so far."

"I started taking Thermo-Lift March 1st of this year.
My sister just kept after me. I felt happy eating, and
did not want to change my life, so I didn't. I just took
Thermo-Lift and kept eating. I noticed my clothes getting
looser on me, but I haven't kept a scale in my house for
over ten years. The middle of May, I found a
commercial scale and weighed myself. I had lost
50 pounds, in just 2 1/2 months! I celebrated by buying
myself a new pair of jeans. I went from a size 48 waist
to a size 42! The best part is I am a non insulin-dependent
diabetic and was taking 10 mg of diabeta every day to
control my blood sugar. I monitor my blood sugar
myself, and with Thermo-Lift my sugar level went
below 70 for the first time in years. My doctor has
now taken me off my medication, and Thermo-Lift is
keeping up very good. I still watch it closely, but I hate
to be chemically dependent like that. I thank my
sister every week for turning me on to Thermo-Lift."
Bernie has lost 60 pounds so far and is still going!

"Over the last 10 years, I have tried a variety of
weight loss methods, spent thousands of dollars
and failed at all of them. By December 1995, I was the
heaviest I had ever weighed 235 pounds. I had no
energy. My self-esteem had hit rock bottom… I was
introduced to Changes International and Thermo-Lift
and have never looked back! My energy level has
boosted and my weight loss increased In total I have
lost 70 pounds and went from a size 22 to a size 12.
The amazing part it's so easy!

*************************************************

NOW IT'S YOUR TURN!

Experience the incredible changes Thermo-Lift
can make in YOUR life. Over 90% of our customers
report feeling a change within 2 to 3 days! Even if
it took YOU 2 to 3 weeks, wouldn’t it be worth it? With
your order, you will receive a one month supply of 60
capsules. No diet is included because none is needed!
Your small investment of only $29.95 plus $3.00 S&H will
start you on the path to a NEW YOU for about a dollar a day.

Your satisfaction is 100% guaranteed or your
purchase price (less S&H) will be cheerfully refunded
upon return of the unused portion.
TAKE ACTION RIGHT NOW! Only by starting
Thermo-Lift immediately can you begin to feel the
boost in energy and the increased fat burning
efficiency of your new metabolic rate. Be prepared to
experience a bit of a "spring" in your step when you
use Thermo-Lift and remember if you find it
CURBING YOUR APPETITE, don’t blame me. You were warned!

*****************************************************
TO ORDER THERMO-LIFT:
Complete the form below and mail it with your
check or money order payable to:

Energy Works
PO Box 66464
Albuquerque, NM 87193-6464


Also available -- an alternative supplement for those who desire weight
loss without the energizing effects of Thermo-Lift
Changes NOW! A revolutionary combination of fibers, enzymes, vitamins and
minerals designed to attract and hold fats and remove them from the digestive tract.

------------------------------------------------ CUT HERE------------------------------------------------
YES! I want ____ bottles of THERMO-LIFT at $29.95 each: $________
YES! I want ____ bottles of Changes NOW!at $29.95 each: $________
$3.00 shipping and handling per bottle $________

Total Amount Enclosed (Payable to Energy Works): $________

Your Name: ______________________________

Address: _______________________________

City, State, Zip: __________________________

Phone (Day): ________________________ (Eve): ___________________

THANK YOU for your order! ************************************************
The information contained in this e-mail was derived from many medical, nutritional, and media publications. It is not intended for medical or nutritional claims but for informational and educational purposes. Please consult a health professional should the need for one be indicated.
THE FIRST 100 ORDERS WILL RECEIVE A FREE GIFT************
DON'T MISS THIS GREAT OFFER, THERE ARE LIMITED SUPPLIES. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Nov 30 18:16: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 SAA26897 for ; Mon, 30 Nov 1998 18:16:34 -0500 (EST) 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 PAA01969; Mon, 30 Nov 1998 15:09:16 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA26879 for ietf-radius-outgoing; Mon, 30 Nov 1998 15:09:09 -0800 (PST) Message-ID: From: "Varghese, Joe" To: ietf-radius@livingston.com Subject: (radius) Vendor Specific Attributes Date: Mon, 30 Nov 1998 17:07:41 -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: "Varghese, Joe" I apologize in advance if this is not the right forum to ask this question ... Our project needs to use attributes that are not defined in the Radius specification for authentication, and apparantly the correct place for this is under vendor-specific attributes. However, I'm confused about *how* to place them here and still conform to the specification. Namely, * For vendor-id, the RFC says to have the high-order byte be 0 and the low order 3 bytes be the SMI code for the vendor. I looked at the Assigned Numbers RFC, and the code with the highest value is less than 1100. Does this mean you take the binary of the code value and pad the left with zeros? *My understanding is that the vendor-id code is used only to make your product/application be general purpose ... so, if our Radius client/server is running in a controlled environment, this code is not that important. Is this correct? * Surprisingly, I didn't see a code for Lucent Technologies. Did I miss it? I made a request for a code, but was wondering if I did the right thing or not ... If someone has implemented vendor-specific values, I'd appreciate if you could e-mail me. Thank you! joe varghese -------------------------------- George (Joe) Varghese varghese@lucent.com (630) 713-9522 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message.