From owner-ietf-radius@livingston.com Sat Apr 1 15:59:38 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11543 for ; Sat, 1 Apr 2000 15:59:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id MAA19555; Sat, 1 Apr 2000 12:56:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA14712 for ietf-radius-outgoing; Sat, 1 Apr 2000 12:54:48 -0800 (PST) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Chris_Cormier@3com.com Cc: ietf-radius@livingston.com, matt@ascend.com, wijnen@VNET.IBM.COM Subject: Re: (radius) iesg security review of draft-ietf-radius-ext-05.txt References: <882568B3.0073064D.00@hqoutbound.ops.3com.com> Message-Id: Date: Sat, 01 Apr 2000 12:53:28 -0800 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit i do not know who you are, but, given that the accounting draft is currently at -05 and is pretty much passed the iesg, i presume you are just someone with a broken mail system. randy > > draft-ietf-radius-radius-v2-03.txt > > o waiting for changes as outlined in carl's message [1] below > > I've submitted (today) draft-ietf-radius-radius-v2-04.txt including > this change. > > > draft-ietf-radius-ext-05.txt > > o waiting for response to security review comments [2] below > > o also would be nice if iana points in [3] were addressed in an iana > > considerations section or by some other means > > I've submitted (today) draft-ietf-radius-ext-06.txt with these two > changes updating draft 05. Signature has been renamed > Message-Authenticator and the claims about preventing dictionary > attacks clarified to indicate that they do not protect against packet > interception for offline attacks, only against dictionary attacks against > the server itself (using the text suggested on the ietf-radius mailing list > by the person who raised the objection). > > An IANA Considerations section has been added as follows (I also > added the same language to the RADIUS Accounting draft): > > IANA Considerations > > The Packet Type Codes, Attribute Types, and Attribute Values defined in > this document are registered by the Internet Assigned Numbers Authority > (IANA) from the RADIUS name spaces as described in the "IANA > Considerations" section of [1], in accordance with BCP 26 [10]. > > [1] refers to the updated RADIUS Draft. > > > --- Attachment > > >From randy@psg.com Fri Jan 28 16:53:41 2000 > From: Randy Bush > To: Matt Holdrege > Cc: crigney@lucent.com, ietf-radius@livingston.com > Subject: Re: (radius) iesg security review of draft-ietf-radius-ext-05.txt > Message-Id: > Date: Fri, 28 Jan 2000 16:53:07 -0800 > > ---[1]--- > > From: Carl Rigney > Date: Wed, 5 Jan 2000 04:02:01 -0800 (PST) > To: ietf-radius@livingston.com > Subject: (radius) Security Considerations text > > Here's the text I plan to put into Security Considerations of the new > RADIUS draft. The authors for the RADIUS Tunneling draft should insert > similar language (for Tunnel-Password instead of Password) and also > insert an IANA Considerations section into their draft (feel free to > borrow the one from my latest RADIUS draft). Please make these changes > and submit the update to the Internet-Drafts directory by this Friday > 1/7 so things can move along. I'll have the new RADIUS draft submitted > Wednesday. > > The User-Password hiding mechanism described in Section 5.2 has not > been subjected to significant amounts of cryptanalysis in the published > literature. Some in the IETF community are concerned that this method > might not provide sufficient confidentiality protection [14] to > passwords transmitted using RADIUS. Users should evaluate their threat > environment and consider whether additional security mechanisms should > be employed. > > [14] Dobbertin, H., "The Status of MD5 After a Recent Attack." > CryptoBytes Vol.2 No.2, Summer 1996. > > Suggestions for wordsmithing the language to be more useful are gratefully > accepted, if you send them Wednesday. > > ---[2]--- > > Much of my nervousness about cryptographic goop appearing in this draft was > in the section that describes the ARAP authentication protocol. Since > this is descriptive, rather than prescriptive, I can't really say that > any issue I have with it is meaningful; ARAP isn't our protocol. > > Section 5.14 talks about Signature attributes. Two issues with this: > > 1) They're not really signatures, if we want to be precise in our use > of the language. A more precise usage would be a MAC (Message > Authenticator Code). > > 2) The draft talks about how this attribute can prevent dictionary > attacks against CHAP, ARAP or EAP. I fail to see how it accomplishes > this. If I can intercept one of these packets, then I can still > mount a dictionary attack against a CHAP response, for example, and > use a front-door attack using the NAS. That is, I don't need to be > able to forge NAS<-->RADIUS-SERVER packets in order to sucessfully > mount a dictionary attack. While having a cryptographic MAC in the > NAS<--->RADIUS-SERVER protocol is useful for other very good reasons, > it doesn't, in this case, provide protection from dictionary attacks. > > ---[3]--- > > Rereading all the notes, I now see that there is an IANA > considerations section in draft-ietf-radius-radius-v2-03.txt (coming > down the pipeline) that takes care of much of this. However, they > don't list all the types that have been defined (the IANA site should > do this I guess), rather they just say what is left to assign (which > isn't exactly in sync with what is up on the IANA page). > > Seem to me like draft-ietf-radius-ext-05.txt defines a bunch of the > IANA values that are apparently in use, but are not recorded on the > IANA page. It would be good if the document would be clear that IANA > needs to record them. > > -30- > > - > 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 Apr 3 14:53:42 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21948 for ; Mon, 3 Apr 2000 14:53:40 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id LAA08439; Mon, 3 Apr 2000 11:49:49 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id LAA13079 for ietf-radius-outgoing; Mon, 3 Apr 2000 11:45:43 -0700 (PDT) Message-ID: <4DEC824F6F1FD3119BEF0000E86CEA01013C77D6@shasta-exch.shastanets.com> From: Vipin Jain To: ietf-radius@livingston.com Subject: (radius) Tag field for radius tunnel authentication Date: Mon, 3 Apr 2000 11:44:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Vipin Jain Draft: http://www.ietf.org/internet-drafts/draft-ietf-radius-tunnel-auth-09.txt What is the purpose of "tag" field? Is it used to group various tunnel attributes? From some attributes, like "Tunnel-Client-Endpoint", "tag" field optional, as the draft mentions: "If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. " How these attributes are grouped with other attributes? Are they common to all "tag" groups? Any response appreciated. Thanks, - Vipin. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Apr 4 10:49:31 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05221 for ; Tue, 4 Apr 2000 10:49:30 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id HAA22346; Tue, 4 Apr 2000 07:45:56 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA24320 for ietf-radius-outgoing; Tue, 4 Apr 2000 07:45:44 -0700 (PDT) Message-ID: <38E9FF31.83E891C7@eed.ericsson.se> Date: Tue, 04 Apr 2000 16:41:53 +0200 From: Bernd Viefhues Organization: Ericsson Eurolab Deutschland X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: (radius) Radius for service authentication? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Bernd Viefhues Content-Transfer-Encoding: 7bit Hi, as far as I understand the RFCs, the Radius protocol is designed to provide network access authentication. I wonder if it is also possible to use the Radius protocol also for application/service access authorization. The scenario I am currently dealing with, consists of some access server, a Radius server and some application servers. All machines are sitting on the same network. I am looking for a method to authenticate users not only to the network (that works already using the Radius server) but also to the applications running on the application servers. What the applications basically should do when some user tries to connect to them is to verify that this user (identified by a DHCP IP address) is allowed to use the application. Is it feasible to use the existing Radius server to do this? How would this usage scenario fit into the Radius protocol? I would like to stick to some standard instead of inventing something own... Best regards, Bernd -- Bernd Viefhues Phone: +49 2407 575 925 Ericsson Eurolab Deutschland GmbH Fax: +49 2407 575-7893 52134 Herzogenrath, Germany Bernd.Viefhues@eed.ericsson.se - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Apr 4 12:14:55 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07703 for ; Tue, 4 Apr 2000 12:14:54 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id JAA24808; Tue, 4 Apr 2000 09:11:17 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA28701 for ietf-radius-outgoing; Tue, 4 Apr 2000 09:12:03 -0700 (PDT) Message-ID: <004501bf9e50$eea49900$f118a8c0@AuthorizedUser> From: "bob_bosen" To: "Bernd Viefhues" , Cc: , Subject: Re: (radius) Radius for service authentication? Date: Tue, 4 Apr 2000 09:15:02 -0700 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.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "bob_bosen" Content-Transfer-Encoding: 7bit Bernd: Yes, software applications can use the RADIUS protocol to ask a convenient RADIUS server to authenticate the identity of a user requesting use of that software. You just need to insert RADIUS "client" logic into one or more appropriate points in your application. Free source code implementing RADIUS client logic is available on the Internet. Contact me if you need a pointer. Regards, -Bob Bosen- Secure Computing Corporation -----Original Message----- From: Bernd Viefhues To: ietf-radius@livingston.com Date: Tuesday, April 04, 2000 7:46 AM Subject: (radius) Radius for service authentication? >Hi, > >as far as I understand the RFCs, the Radius protocol is designed to provide >network access authentication. I wonder if it is also possible to use the Radius >protocol also for application/service access authorization. > >The scenario I am currently dealing with, consists of some access server, a >Radius server and some application servers. All machines are sitting on the same >network. I am looking for a method to authenticate users not only to the network >(that works already using the Radius server) but also to the applications >running on the application servers. > >What the applications basically should do when some user tries to connect to >them is to verify that this user (identified by a DHCP IP address) is allowed to >use the application. Is it feasible to use the existing Radius server to do >this? How would this usage scenario fit into the Radius protocol? I would like >to stick to some standard instead of inventing something own... > >Best regards, >Bernd > >-- >Bernd Viefhues Phone: +49 2407 575 925 >Ericsson Eurolab Deutschland GmbH Fax: +49 2407 575-7893 >52134 Herzogenrath, Germany Bernd.Viefhues@eed.ericsson.se >- >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 Apr 5 00:05:11 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24428 for ; Wed, 5 Apr 2000 00:05:10 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA08754; Tue, 4 Apr 2000 21:01:57 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA03544 for ietf-radius-outgoing; Tue, 4 Apr 2000 21:00:05 -0700 (PDT) Message-Id: <200002151135.GAA22341@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-accounting-v2-03.txt Date: Tue, 15 Feb 2000 06:35:09 -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 Author(s) : C. Rigney Filename : draft-ietf-radius-accounting-v2-03.txt Pages : 28 Date : 14-Feb-00 This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-accounting-v2-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-accounting-v2-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-accounting-v2-03.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: <20000214115345.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-accounting-v2-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-accounting-v2-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000214115345.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 5 00:09:16 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24440 for ; Wed, 5 Apr 2000 00:09:15 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA08943; Tue, 4 Apr 2000 21:05:38 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA03745 for ietf-radius-outgoing; Tue, 4 Apr 2000 21:06:27 -0700 (PDT) Message-Id: <200002151135.GAA22356@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-ext-06.txt Date: Tue, 15 Feb 2000 06:35:15 -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 Extensions Author(s) : C. Rigney, W. Willats, P. Calhoun Filename : draft-ietf-radius-ext-06.txt Pages : 48 Date : 14-Feb-00 This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC xxxx [1] and RFC yyyy [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-ext-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-ext-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-ext-06.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: <20000214115355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-ext-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-ext-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000214115355.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 5 00:09:24 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24453 for ; Wed, 5 Apr 2000 00:09:22 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA08966; Tue, 4 Apr 2000 21:05:45 -0700 (PDT) Received: by server.livingston.com (8.9.3/8.9.3/0.5) id VAA03764 for ietf-radius-outgoing; Tue, 4 Apr 2000 21:06:32 -0700 (PDT) Message-Id: <200002151135.GAA22370@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-radius-v2-04.txt Date: Tue, 15 Feb 2000 06:35:21 -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 : Remote Authentication Dial In User Service (RADIUS) Author(s) : C. Rigney, A. Rubens, W. Simpson, S. Willens Filename : draft-ietf-radius-radius-v2-04.txt Pages : 79 Date : 14-Feb-00 This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-radius-v2-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-radius-v2-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-radius-v2-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000214115624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-radius-v2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-radius-v2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000214115624.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 5 00:09:50 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24464 for ; Wed, 5 Apr 2000 00:09:49 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA09027; Tue, 4 Apr 2000 21:05:55 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA03795 for ietf-radius-outgoing; Tue, 4 Apr 2000 21:06:40 -0700 (PDT) Message-Id: <200002241126.GAA25785@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-radius-v2-05.txt Date: Thu, 24 Feb 2000 06:26:40 -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 : Remote Authentication Dial In User Service (RADIUS) Author(s) : C. Rigney, A. Rubens, W. Simpson, S. Willens Filename : draft-ietf-radius-radius-v2-05.txt Pages : 79 Date : 23-Feb-00 This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-radius-v2-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-radius-v2-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-radius-v2-05.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: <20000223110523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-radius-v2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-radius-v2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000223110523.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 5 00:09:51 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24465 for ; Wed, 5 Apr 2000 00:09:50 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA09046; Tue, 4 Apr 2000 21:05:58 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA03802 for ietf-radius-outgoing; Tue, 4 Apr 2000 21:06:42 -0700 (PDT) Message-Id: <200002251132.GAA05062@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-accounting-v2-05.txt Date: Fri, 25 Feb 2000 06:32:29 -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 Author(s) : C. Rigney Filename : draft-ietf-radius-accounting-v2-05.txt Pages : 29 Date : 24-Feb-00 This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-accounting-v2-05.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-accounting-v2-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-accounting-v2-05.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: <20000224111724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-accounting-v2-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-accounting-v2-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000224111724.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 5 00:09:51 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24475 for ; Wed, 5 Apr 2000 00:09:50 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA09086; Tue, 4 Apr 2000 21:06:03 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA03807 for ietf-radius-outgoing; Tue, 4 Apr 2000 21:06:45 -0700 (PDT) Message-Id: <200002251132.GAA05100@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-radius-v2-06.txt Date: Fri, 25 Feb 2000 06:32:39 -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 : Remote Authentication Dial In User Service (RADIUS) Author(s) : C. Rigney, A. Rubens, W. Simpson, S. Willens Filename : draft-ietf-radius-radius-v2-06.txt Pages : 80 Date : 24-Feb-00 This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-radius-v2-06.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-radius-v2-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-radius-v2-06.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: <20000224111745.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-radius-v2-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-radius-v2-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000224111745.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 5 00:09:56 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24494 for ; Wed, 5 Apr 2000 00:09:55 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA09127; Tue, 4 Apr 2000 21:06:09 -0700 (PDT) Received: by server.livingston.com (8.9.3/8.9.3/0.5) id VAA03811 for ietf-radius-outgoing; Tue, 4 Apr 2000 21:06:48 -0700 (PDT) Message-Id: <200002091317.IAA05396@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-radius@livingston.com From: The IESG Subject: (radius) Document Action: Implementation of L2TP Compulsory Tunneling via RADIUS to Informational Date: Wed, 09 Feb 2000 08:17:03 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: The IESG The IESG has approved the Internet-Draft 'Implementation of L2TP Compulsory Tunneling via RADIUS' as an Informational RFC. This document is the product of the Remote Authentication Dial-In User Service Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 5 00:12:33 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24514 for ; Wed, 5 Apr 2000 00:12:32 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA09078; Tue, 4 Apr 2000 21:06:02 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA03806 for ietf-radius-outgoing; Tue, 4 Apr 2000 21:06:44 -0700 (PDT) Message-Id: <200002251132.GAA05086@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-ext-07.txt Date: Fri, 25 Feb 2000 06:32:34 -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 Extensions Author(s) : C. Rigney, W. Willats, P. Calhoun Filename : draft-ietf-radius-ext-07.txt Pages : 48 Date : 24-Feb-00 This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC xxxx [1] and RFC yyyy [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-ext-07.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-ext-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-ext-07.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: <20000224111734.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-ext-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-ext-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000224111734.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 5 00:14:25 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24529 for ; Wed, 5 Apr 2000 00:14:24 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA08989; Tue, 4 Apr 2000 21:05:50 -0700 (PDT) Received: by server.livingston.com (8.9.3/8.9.3/0.5) id VAA03784 for ietf-radius-outgoing; Tue, 4 Apr 2000 21:06:36 -0700 (PDT) Message-Id: <200002241126.GAA25757@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-accounting-v2-04.txt Date: Thu, 24 Feb 2000 06:26:29 -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 Author(s) : C. Rigney Filename : draft-ietf-radius-accounting-v2-04.txt Pages : 29 Date : 23-Feb-00 This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-accounting-v2-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-accounting-v2-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-accounting-v2-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000223092754.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-accounting-v2-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-accounting-v2-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000223092754.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 5 05:04:06 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07437 for ; Wed, 5 Apr 2000 05:04:05 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id BAA17729; Wed, 5 Apr 2000 01:59:19 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id BAA15117 for ietf-radius-outgoing; Wed, 5 Apr 2000 01:59:35 -0700 (PDT) Date: Wed, 05 Apr 2000 20:59:24 +1200 From: Paul Krumviede Subject: Re: (radius) Radius for service authentication? In-reply-to: <38E9FF31.83E891C7@eed.ericsson.se> To: Bernd Viefhues , ietf-radius@livingston.com Message-id: <1485624688.954968364@SKOLEM2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede Content-Transfer-Encoding: 7BIT --On Tuesday, 04 April, 2000 16:41 +0200 Bernd Viefhues wrote: > Hi, > > as far as I understand the RFCs, the Radius protocol is designed to > provide network access authentication. I wonder if it is also possible > to use the Radius protocol also for application/service access > authorization. Sure. There may be some issues with the kinds of information you can stick in a response if you want more than a yes/no answer, and there may be limits to the authentication mechanisms that you can use. Depending on the actual setup, there could also be interesting questions as whether a server wants to see accounting messages, but that isn't really a protocol issue. -paul - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 5 11:48:24 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11847 for ; Wed, 5 Apr 2000 11:48:23 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id IAA21797; Wed, 5 Apr 2000 08:39:30 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA24435 for ietf-radius-outgoing; Wed, 5 Apr 2000 08:39:06 -0700 (PDT) From: "Glen Zorn" To: "Vipin Jain" , Subject: RE: (radius) Tag field for radius tunnel authentication Date: Wed, 5 Apr 2000 08:37:02 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4DEC824F6F1FD3119BEF0000E86CEA01013C77D6@shasta-exch.shastanets.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit > Draft: > http://www.ietf.org/internet-drafts/draft-ietf-radius-tunnel-auth-09.txt > What is the purpose of "tag" field? Is it used to group various tunnel > attributes? Yes. > From some attributes, like "Tunnel-Client-Endpoint", > "tag" field optional, as the draft mentions: > "If the value of the Tag field is greater than 0x00 > and less than or equal to 0x1F, it SHOULD be interpreted as > indicating which tunnel (of several alternatives) this attribute > pertains. " > > How these attributes are grouped with other attributes? > Are they common to all "tag" groups? Yes. > > Any response appreciated. > > Thanks, > - Vipin. > - > 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 Apr 6 06:34:17 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06609 for ; Thu, 6 Apr 2000 06:34:16 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id DAA08689; Thu, 6 Apr 2000 03:30:39 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id DAA09822 for ietf-radius-outgoing; Thu, 6 Apr 2000 03:28:49 -0700 (PDT) Message-ID: <38EC65F2.F7F04185@eed.ericsson.se> Date: Thu, 06 Apr 2000 12:24:50 +0200 From: Bernd Viefhues Organization: Ericsson Eurolab Deutschland X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: Re: (radius) Radius for service authentication? References: <1485624688.954968364@SKOLEM2> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Bernd Viefhues Content-Transfer-Encoding: 7bit Hi, again, Maybe I did not come to the point in my first posting, so I'll try to explain my problem a bit more detailed. After a user is authenticated by the Radius server, the network "knows" him. So there should be no need to login again to specific services/applications. Instead, an application should query the Radius server for access authentication. To do that, the Radius server must keep a user privilege database. If the user does not have to identify himself explicitly to the applications, the only information applications have about users are their IP addresses (that's the current status in the environment I work in). And that's where I have a problem: How to use the Radius protocol in this case? RFC 2138 says that I must send a User-Name attribute in an Access-Request packet. Since I don't have a user name, I can't really do what the RFC describes. So, I have some (probably bad) ideas to deal with this: 1) Send the IP address as user name and implement the Radius server in a way that it can handle this. That's not exactly what the RFC says... 2) Use another "standard" solution which is already used by others. That's why I'm asking here :-) 3) Somehow (mis)use Radius Accounting for this task. Not nice. 4) Define some own packet type and possibly additional attributes. That's what I want to avoid. What would you do here? Do I miss something important? Are there other solutions? Best regards and thanks for your help, Bernd -- Bernd Viefhues Phone: +49 2407 575 925 Ericsson Eurolab Deutschland GmbH Fax: +49 2407 575-7893 52134 Herzogenrath, Germany Bernd.Viefhues@eed.ericsson.se - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Apr 6 12:07:41 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10392 for ; Thu, 6 Apr 2000 12:07:40 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id JAA12089; Thu, 6 Apr 2000 09:03:45 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id JAA19712 for ietf-radius-outgoing; Thu, 6 Apr 2000 09:03:23 -0700 (PDT) Message-Id: <4.2.2.20000406114801.00d1aef0@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Apr 2000 11:57:58 -0400 To: Bernd Viefhues , ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) Radius for service authentication? In-Reply-To: <38EC65F2.F7F04185@eed.ericsson.se> References: <1485624688.954968364@SKOLEM2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David Mitton" At 12:24 PM 4/6/00 +0200, Bernd Viefhues wrote: >Hi, again, > >Maybe I did not come to the point in my first posting, so I'll try to >explain my >problem a bit more detailed. > >After a user is authenticated by the Radius server, the network "knows" >him. So >there should be no need to login again to specific services/applications. This assumption is not valid. Authorization to access the network is different than authorization for a given application. Furthermore, the design of RADIUS, for better or worse, does not presume to keep "state", if you will, in the server about the current status of the user in the network. Stateful servers have been built, but that is outside the intended design of the RFCs. >Instead, an application should query the Radius server for access >authentication. To do that, the Radius server must keep a user privilege >database. Most servers do not support this concept. >If the user does not have to identify himself explicitly to the applications, >the only information applications have about users are their IP addresses >(that's the current status in the environment I work in). > >And that's where I have a problem: How to use the Radius protocol in this >case? >RFC 2138 says that I must send a User-Name attribute in an Access-Request >packet. Since I don't have a user name, I can't really do what the RFC >describes. I guess this is a problem with your application. Other IETF applications, like Telnet and FTP do require user identification and passwords. These can easily mapped into a RADIUS solution if needed. >So, I have some (probably bad) ideas to deal with this: >1) Send the IP address as user name and implement the Radius server in a way >that it > can handle this. That's not exactly what the RFC says... If all you have is an IP address which is sufficient along with server state, then you could create a new service-type value and handle this message in your custom server. You are already outside the RFC. >2) Use another "standard" solution which is already used by others. That's why >I'm > asking here :-) >3) Somehow (mis)use Radius Accounting for this task. Not nice. >4) Define some own packet type and possibly additional attributes. That's >what I >want > to avoid. > >What would you do here? Do I miss something important? Are there other >solutions? I'm not aware of other people doing stuff like this. But doesn't mean it isn't being done quietly somewhere. Dave. >Best regards and thanks for your help, >Bernd > >-- >Bernd Viefhues Phone: +49 2407 575 925 >Ericsson Eurolab Deutschland GmbH Fax: +49 2407 575-7893 >52134 Herzogenrath, Germany Bernd.Viefhues@eed.ericsson.se >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 7 04:52:10 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04833 for ; Fri, 7 Apr 2000 04:52:09 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id BAA24292; Fri, 7 Apr 2000 01:48:34 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id BAA29037 for ietf-radius-outgoing; Fri, 7 Apr 2000 01:48:48 -0700 (PDT) Message-ID: <4DEC824F6F1FD3119BEF0000E86CEA01013C77EC@shasta-exch.shastanets.com> From: Vipin Jain To: "'Glen Zorn'" , ietf-radius@livingston.com Subject: RE: (radius) Tag field for radius tunnel authentication Date: Fri, 7 Apr 2000 01:47:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Vipin Jain Same Draft: draft-ietf-radius-tunnel-auth-09.txt May I ask the reason for having three different interpretation of "tag" field for various attributes; Three interpretations being: [1] Attributes like Tunnel-Type: if < 32 its part of a tunnel group, otherwise error [2] Attributes like Tunnel-Client-Endpoint: if < 32 its part of a tunnel group, otherwise it is common to all groups [3] Attributes like Tunnel-Password: if <32 its part of a tunnel group, otherwise IGNORE the value of "tag". Why can't it be interpreted as [2]? thanks for any help! - Vipin - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 7 05:57:49 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05365 for ; Fri, 7 Apr 2000 05:57:48 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id CAA24862; Fri, 7 Apr 2000 02:54:13 -0700 (PDT) Received: by server.livingston.com (8.9.3/8.9.3/0.5) id CAA00575 for ietf-radius-outgoing; Fri, 7 Apr 2000 02:54:49 -0700 (PDT) From: "Bernard Aboba" To: "'David Mitton'" , "'Bernd Viefhues'" , Subject: RE: (radius) Radius for service authentication? Date: Fri, 7 Apr 2000 02:56:08 -0700 Message-ID: <002f01bfa077$800d4950$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4.2.2.20000406114801.00d1aef0@ZBL6C008.corpeast.baynetworks.com> Importance: Normal Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit >Authorization to access the network is >different than authorization for a given application. Indeed. Among other things, network access authorization is something you only need once in a session which can be long-lived. Application authorization is something that can be needed many times in a session. This is why application authorization solutions (like Kerberos) support ticket re-use, so that the app server does not have to go back to the KDC to validate a ticket. This not only takes load off the KDC, but it also provides convenience for the user, who doesn't have to re-enter their password everytime they run an application. The concept of re-use is absent in RADIUS and as a result, RADIUS is not a scalable or appropriate solution for application authorization. >What would you do here? Do I miss something important? Are there other >solutions? Why not just existing solutions such as Kerberos, SSL or SSH that were designed for this purpose? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 7 06:14:32 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05517 for ; Fri, 7 Apr 2000 06:14:31 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id DAA25091; Fri, 7 Apr 2000 03:10:55 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id DAA01057 for ietf-radius-outgoing; Fri, 7 Apr 2000 03:12:09 -0700 (PDT) Message-ID: <00ad01bfa079$27b084f0$0103a8c0@ds9> From: "Darran Potter" To: "Vipin Jain" , References: <4DEC824F6F1FD3119BEF0000E86CEA01013C77EC@shasta-exch.shastanets.com> Subject: Re: (radius) Tag field for radius tunnel authentication Date: Fri, 7 Apr 2000 11:07:57 +0100 Organization: Cisco Systems Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit There's a can of worms... This was all gone over last year at quite some length. I recall the final text resulting from a compromise. The big problem is backwards compatibility. There are some NASs today that still expect a clear text tunnel password. ..and in a proxy chain you could get a clear text T-P given back to you... although perhaps unlikely. Darran ----- Original Message ----- From: "Vipin Jain" To: "'Glen Zorn'" ; Sent: 07 April 2000 09:47 Subject: RE: (radius) Tag field for radius tunnel authentication > > Same Draft: draft-ietf-radius-tunnel-auth-09.txt > > May I ask the reason for having three different interpretation of "tag" > field for various attributes; Three interpretations being: > [1] Attributes like Tunnel-Type: if < 32 its part of a tunnel group, > otherwise error > [2] Attributes like Tunnel-Client-Endpoint: if < 32 its part of a > tunnel group, otherwise it is common to all groups > [3] Attributes like Tunnel-Password: if <32 its part of a tunnel > group, otherwise IGNORE the value of "tag". Why can't it be interpreted as > [2]? > > thanks for any help! > - Vipin > > > - > 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 Apr 10 09:28:06 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10546 for ; Mon, 10 Apr 2000 09:28:06 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id GAA22305; Mon, 10 Apr 2000 06:24:05 -0700 (PDT) Received: by server.livingston.com (8.9.3/8.9.3/0.5) id GAA11899 for ietf-radius-outgoing; Mon, 10 Apr 2000 06:22:04 -0700 (PDT) Message-ID: <000f01bfa2ec$d7828520$0401a8c0@oleane.com> From: "Peter Lewis" To: Subject: (radius) IP Policing 2000 Date: Mon, 10 Apr 2000 15:00:13 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01BFA2FD.79104C00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Peter Lewis" This is a multi-part message in MIME format. ------=_NextPart_000_000C_01BFA2FD.79104C00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IP Policing 2000, Paris, 12-15 September =20 The need to police IP networks has grown in importance with the rise of = a new generation of applications such as VPNs, VoIP or IPSec. Approaches under consideration include COPS, DEN/LDAP and PIB, but their = ultimate potential remains undecided. =20 See: http://www.upperside.fr/baippol.htm ------=_NextPart_000_000C_01BFA2FD.79104C00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IP Policing 2000, Paris, = 12-15=20 September
 
The need to police IP = networks has=20 grown in importance with the rise of a new generation of applications = such as=20 VPNs, VoIP or IPSec.
Approaches under consideration include COPS, = DEN/LDAP=20 and PIB, but their ultimate potential remains undecided.
 
See:
http://www.upperside.fr/baip= pol.htm
 
 
------=_NextPart_000_000C_01BFA2FD.79104C00-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Apr 10 09:45:44 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11449 for ; Mon, 10 Apr 2000 09:45:43 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id GAA22607; Mon, 10 Apr 2000 06:41:48 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id GAA12409 for ietf-radius-outgoing; Mon, 10 Apr 2000 06:42:57 -0700 (PDT) Message-ID: <6FFEC516CDF6D211AB7700805F65699E037732@wdserver.xwd.com> From: "Varghese, Joe" To: ietf-radius@livingston.com Subject: (radius) Reply Attributes in Access-Reject Date: Mon, 10 Apr 2000 08:42:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Varghese, Joe" Can someone clarify the following: "It MAY include one or more Reply-Message Attributes with a text message which the NAS MAY display to the user." Does this mean that only Attribute 18 (i.e., Reply-Message) should be used, or *any* attribute could be used, as long as the NAS understands the meaning? For our application, we include a Counter value that is used to prevent replay-attacks (used in a hash of the password and counter). The Counter and the Hash are forwarded to the Radius server as VSAs. To solve the problem of the the counters on the client and server side being out of synch, I had wanted the Radius server to reply with an Access-Reject with a counter value (as opposed to a simple Access-Reject) i.e., in the Access-Reject include a VSA. Is this breaking the standard? joe varghese -------------------------------- George (Joe) Varghese varghese@lucent.com (630) 713-9522 > -----Original Message----- > From: Darran Potter [mailto:dpotter@cisco.com] > Sent: Friday, April 07, 2000 5:08 AM > To: Vipin Jain; ietf-radius@livingston.com > Subject: Re: (radius) Tag field for radius tunnel authentication > > > There's a can of worms... This was all gone over last year at > quite some length. > I recall the final text resulting from a compromise. The big > problem is backwards > compatibility. There are some NASs today that still expect a > clear text tunnel password. > > ..and in a proxy chain you could get a clear text T-P given > back to you... although > perhaps unlikely. > > > Darran > > ----- Original Message ----- > From: "Vipin Jain" > To: "'Glen Zorn'" ; > Sent: 07 April 2000 09:47 > Subject: RE: (radius) Tag field for radius tunnel authentication > > > > > > Same Draft: draft-ietf-radius-tunnel-auth-09.txt > > > > May I ask the reason for having three different > interpretation of "tag" > > field for various attributes; Three interpretations being: > > [1] Attributes like Tunnel-Type: if < 32 its part of a tunnel group, > > otherwise error > > [2] Attributes like Tunnel-Client-Endpoint: if < 32 its part of a > > tunnel group, otherwise it is common to all groups > > [3] Attributes like Tunnel-Password: if <32 its part of a tunnel > > group, otherwise IGNORE the value of "tag". Why can't it be > interpreted as > > [2]? > > > > thanks for any help! > > - Vipin > > > > > > - > > To unsubscribe, email 'majordomo@livingston.com' with > > 'unsubscribe ietf-radius' in the body of the message. > > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Apr 10 12:01:31 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20454 for ; Mon, 10 Apr 2000 12:01:30 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id IAA24988; Mon, 10 Apr 2000 08:56:20 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA17728 for ietf-radius-outgoing; Mon, 10 Apr 2000 08:56:37 -0700 (PDT) Message-Id: <4.2.2.20000410095529.00d49e00@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 10 Apr 2000 10:03:15 -0400 To: "Varghese, Joe" , ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) Reply Attributes in Access-Reject In-Reply-To: <6FFEC516CDF6D211AB7700805F65699E037732@wdserver.xwd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "David Mitton" Hi Joe! I don't think there is anything wrong with including your VSA (or any number of them) in the Access-Reject message. Just that most other standard implementations won't know what to do with those attributes, and probably ignore them. You could make this server function NAS dependent. The RFC is explaining the standard behavior for error reporting which may include a multi-line text message. The table 5.44 on pages 58-59, shows the inclusion rules for each std attribute and message. Dave. At 08:42 AM 4/10/00 -0500, Varghese, Joe wrote: >Can someone clarify the following: > >"It MAY include one or more Reply-Message Attributes with a text message >which the NAS MAY display to the user." > >Does this mean that only Attribute 18 (i.e., Reply-Message) should be used, >or *any* attribute could be used, as long as the NAS understands the >meaning? > >For our application, we include a Counter value that is used to prevent >replay-attacks (used in a hash of the password and counter). The Counter and >the Hash are forwarded to the Radius server as VSAs. > >To solve the problem of the the counters on the client and server side being >out of synch, I had wanted the Radius server to reply with an Access-Reject >with a counter value (as opposed to a simple Access-Reject) i.e., in the >Access-Reject include a VSA. > >Is this breaking the standard? > >joe varghese > >-------------------------------- >George (Joe) Varghese >varghese@lucent.com >(630) 713-9522 > > > > > -----Original Message----- > > From: Darran Potter [mailto:dpotter@cisco.com] > > Sent: Friday, April 07, 2000 5:08 AM > > To: Vipin Jain; ietf-radius@livingston.com > > Subject: Re: (radius) Tag field for radius tunnel authentication > > > > > > There's a can of worms... This was all gone over last year at > > quite some length. > > I recall the final text resulting from a compromise. The big > > problem is backwards > > compatibility. There are some NASs today that still expect a > > clear text tunnel password. > > > > ..and in a proxy chain you could get a clear text T-P given > > back to you... although > > perhaps unlikely. > > > > > > Darran > > > > ----- Original Message ----- > > From: "Vipin Jain" > > To: "'Glen Zorn'" ; > > Sent: 07 April 2000 09:47 > > Subject: RE: (radius) Tag field for radius tunnel authentication > > > > > > > > > > Same Draft: draft-ietf-radius-tunnel-auth-09.txt > > > > > > May I ask the reason for having three different > > interpretation of "tag" > > > field for various attributes; Three interpretations being: > > > [1] Attributes like Tunnel-Type: if < 32 its part of a tunnel group, > > > otherwise error > > > [2] Attributes like Tunnel-Client-Endpoint: if < 32 its part of a > > > tunnel group, otherwise it is common to all groups > > > [3] Attributes like Tunnel-Password: if <32 its part of a tunnel > > > group, otherwise IGNORE the value of "tag". Why can't it be > > interpreted as > > > [2]? > > > > > > thanks for any help! > > > - Vipin > > > > > > > > > - > > > 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. --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, Preside 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Apr 10 15:06:14 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00525 for ; Mon, 10 Apr 2000 15:06:14 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id MAA28965; Mon, 10 Apr 2000 12:01:03 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA28890 for ietf-radius-outgoing; Mon, 10 Apr 2000 12:00:35 -0700 (PDT) From: "Glen Zorn" To: "David Mitton" , "Varghese, Joe" , Subject: RE: (radius) Reply Attributes in Access-Reject Date: Mon, 10 Apr 2000 11:58:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <4.2.2.20000410095529.00d49e00@ZBL6C008.corpeast.baynetworks.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit > Hi Joe! > > I don't think there is anything wrong with including > your VSA (or > any number of them) in the Access-Reject message. Just that most other > standard implementations won't know what to do with those attributes, and > probably ignore them. You could make this server function NAS dependent. > In other words: yes, in breaks the standard, but why do you care? ;-) > The RFC is explaining the standard behavior for error reporting > which may include a multi-line text message. The table 5.44 on pages > 58-59, shows the inclusion rules for each std attribute and message. > > Dave. > > At 08:42 AM 4/10/00 -0500, Varghese, Joe wrote: > >Can someone clarify the following: > > > >"It MAY include one or more Reply-Message Attributes with a text message > >which the NAS MAY display to the user." > > > >Does this mean that only Attribute 18 (i.e., Reply-Message) > should be used, > >or *any* attribute could be used, as long as the NAS understands the > >meaning? > > > >For our application, we include a Counter value that is used to prevent > >replay-attacks (used in a hash of the password and counter). The > Counter and > >the Hash are forwarded to the Radius server as VSAs. > > > >To solve the problem of the the counters on the client and > server side being > >out of synch, I had wanted the Radius server to reply with an > Access-Reject > >with a counter value (as opposed to a simple Access-Reject) i.e., in the > >Access-Reject include a VSA. > > > >Is this breaking the standard? > > > >joe varghese > > > >-------------------------------- > >George (Joe) Varghese > >varghese@lucent.com > >(630) 713-9522 > > > > > > > > > -----Original Message----- > > > From: Darran Potter [mailto:dpotter@cisco.com] > > > Sent: Friday, April 07, 2000 5:08 AM > > > To: Vipin Jain; ietf-radius@livingston.com > > > Subject: Re: (radius) Tag field for radius tunnel authentication > > > > > > > > > There's a can of worms... This was all gone over last year at > > > quite some length. > > > I recall the final text resulting from a compromise. The big > > > problem is backwards > > > compatibility. There are some NASs today that still expect a > > > clear text tunnel password. > > > > > > ..and in a proxy chain you could get a clear text T-P given > > > back to you... although > > > perhaps unlikely. > > > > > > > > > Darran > > > > > > ----- Original Message ----- > > > From: "Vipin Jain" > > > To: "'Glen Zorn'" ; > > > Sent: 07 April 2000 09:47 > > > Subject: RE: (radius) Tag field for radius tunnel authentication > > > > > > > > > > > > > > Same Draft: draft-ietf-radius-tunnel-auth-09.txt > > > > > > > > May I ask the reason for having three different > > > interpretation of "tag" > > > > field for various attributes; Three interpretations being: > > > > [1] Attributes like Tunnel-Type: if < 32 its part of a tunnel group, > > > > otherwise error > > > > [2] Attributes like Tunnel-Client-Endpoint: if < 32 its part of a > > > > tunnel group, otherwise it is common to all groups > > > > [3] Attributes like Tunnel-Password: if <32 its part of a tunnel > > > > group, otherwise IGNORE the value of "tag". Why can't it be > > > interpreted as > > > > [2]? > > > > > > > > thanks for any help! > > > > - Vipin > > > > > > > > > > > > - > > > > 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. > > --------------------------------------------------------------- > David Mitton ESN: 248-4570 > Advisor, Nortel Networks 978-288-4570 Direct > Carrier Packet Solutions, Preside 978-288-3030 FAX > Billerica, MA 01821 dmitton@nortelnetworks.com > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 14 00:12:22 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21069 for ; Fri, 14 Apr 2000 00:12:21 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id VAA08550; Thu, 13 Apr 2000 21:08:27 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id VAA15713 for ietf-radius-outgoing; Thu, 13 Apr 2000 21:06:44 -0700 (PDT) From: "Bernard Aboba" To: Subject: (radius) SOLICITATION OF PROTOCOL SUBMISSIONS -- IETF AAA WORKING GROUP Date: Thu, 13 Apr 2000 21:08:02 -0700 Message-ID: <016201bfa5c7$07d68f00$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit SOLICITATION OF PROTOCOL SUBMISSIONS -- IETF AAA WORKING GROUP The Authentication, Authorization and Accounting (AAA) Working Group of the Internet Engineering Task Force is currently soliciting submission of protocols for authentication, authorization and accounting as applied to network access. Submissions are being solicited effective immediately. Authors of candidate protocols are required to notify the AAA WG chairs, Bernard Aboba and Paul Krumviede of their intent to submit a candidate protocol. It is desirable that this notification be sent by May 1, 2000. Protocol submissions and compliance description documents are to be submitted in Internet Draft format by email to internet-drafts@ietf.org. The deadline for submissions is June 1, 2000. To be considered as a candidate, submissions must include an unqualified RFC 2026 statement, as described at: http://www.ietf.org/Sec10.txt Information on the Internet Draft format is available at: http://www.ietf.org/ietf/1id-guidelines.txt The compliance description document must explain on a detailed requirement-by-requirement basis how the submitted protocol satisfies the AAA network access requirements. The requirements are available for inspection at: http://www.ietf.org/internet-drafts/draft-ietf-aaa-na-reqts-03.txt (or later version). The protocol submission and compliance description documents will then be used as the basis for an independent evaluation. Based on the results of the independent evaluation, the working group will decide whether one or more submissions meet the requirements sufficiently to become the basis of the subsequent design phase, or whether it is necessary to design a protocol from scratch. In the protocol development process, it is to be understood that the IETF does not function as a rubber stamp. A protocol, if accepted, will likely be changed significantly during the process of development. Authors of candidate protocols must be willing to give up change control to the IETF, so as to allow modification of the candidate protocols to AAA WG needs. For further information on the IETF AAA WG, including working group drafts and milestones, please consult the working group web page at: http://www.ietf.org/html.charters/aaa-charter.html - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 14 16:28:56 2000 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13998 for ; Fri, 14 Apr 2000 16:28:55 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id NAA20173; Fri, 14 Apr 2000 13:23:49 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA14208 for ietf-radius-outgoing; Fri, 14 Apr 2000 13:21:48 -0700 (PDT) Message-ID: <00ad01bfa079$27b084f0$0103a8c0@ds9> From: "Darran Potter" To: "Vipin Jain" , References: <4DEC824F6F1FD3119BEF0000E86CEA01013C77EC@shasta-exch.shastanets.com> Subject: Re: (radius) Tag field for radius tunnel authentication Date: Fri, 7 Apr 2000 11:07:57 +0100 Organization: Cisco Systems Inc MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit There's a can of worms... This was all gone over last year at quite some length. I recall the final text resulting from a compromise. The big problem is backwards compatibility. There are some NASs today that still expect a clear text tunnel password. ..and in a proxy chain you could get a clear text T-P given back to you... although perhaps unlikely. Darran ----- Original Message ----- From: "Vipin Jain" To: "'Glen Zorn'" ; Sent: 07 April 2000 09:47 Subject: RE: (radius) Tag field for radius tunnel authentication > > Same Draft: draft-ietf-radius-tunnel-auth-09.txt > > May I ask the reason for having three different interpretation of "tag" > field for various attributes; Three interpretations being: > [1] Attributes like Tunnel-Type: if < 32 its part of a tunnel group, > otherwise error > [2] Attributes like Tunnel-Client-Endpoint: if < 32 its part of a > tunnel group, otherwise it is common to all groups > [3] Attributes like Tunnel-Password: if <32 its part of a tunnel > group, otherwise IGNORE the value of "tag". Why can't it be interpreted as > [2]? > > thanks for any help! > - Vipin > > > - > 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.