From owner-ietf-radius@livingston.com Tue Jun 1 05:03:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25352 for ; Tue, 1 Jun 1999 05:03:49 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id BAA08248; Tue, 1 Jun 1999 01:56:33 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA01572 for ietf-radius-outgoing; Tue, 1 Jun 1999 01:59:36 -0700 (PDT) Posted-Date: Tue, 1 Jun 1999 10:49:00 +0200 (MET DST) Message-ID: <37539F0D.AE3E425E@tid.es> Date: Tue, 01 Jun 1999 10:51:25 +0200 From: Jose Ignacio =?iso-8859-1?Q?Caba=F1as?= X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: es,en MIME-Version: 1.0 To: cistron-radius@info.cistron.nl, "Lista =?iso-8859-1?Q?distribuci=F3n?= Radius" , "portmaster-radius@livingston.com" , "ietf-radius@livingston.com" Subject: (radius) Problems with Cistron Solaris version Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jose Ignacio =?iso-8859-1?Q?Caba=F1as?= Content-Transfer-Encoding: 8bit Hello everybody: I´m trying to use Cistron Radius 1.5.4.3-p18 in a SparcStation under Solaris 2.5.1 I got sources from ftp.cistron.nl server and compiled them (using Makefile.sunos5) with FSFgcc 2.7.2. for Solaris. There have not been any errors. Trying to use it, I have encountered some problems which leads to malfunctions: - Authentication works well using System Auth (UNIX passwd) but does not work with the ./raddb/users file. A simple entry like showed below causes bad authentication (always rejected) : pepe Auth-Type = Local , Password = "pp" Framed-IP-Address = 192.168.2.69 - Accounting info is record nowhere, although Acct-Reply is generated - Radius log does not show nothing but "Starting" or some error during startup. While running, nothing is record in the log. I have tried to many configuration combinations to reach the properway, but I have not get anything satisfactory. My question is: Does anybody use Cistron Radius under Solaris environment? and does it work fine? If affirmative, how did you compile it? Is there any place where I could get compiled sources for Solaris? Thanks in advance, Jose Ignacio - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jun 2 12:54:48 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05605 for ; Wed, 2 Jun 1999 12:54:48 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA18724; Wed, 2 Jun 1999 09:47:14 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA00627 for ietf-radius-outgoing; Wed, 2 Jun 1999 09:50:03 -0700 (PDT) Message-Id: <4.1.19990602123843.023ff810@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 02 Jun 1999 12:45:55 -0400 To: ietf-radius@livingston.com From: Dave Mitton Subject: (radius) Comment on Acct-Session-ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton The new Accounting draft mentions that an Access-Accept may include a Acct-Session-ID and it MUST be the same value as Accounting-Requests for that session. However, the new Authentication draft does not add this attribute to it's table in 5.44 or make any mention of it. Dave. --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions 978-288-3030 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jun 2 13:20:03 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06097 for ; Wed, 2 Jun 1999 13:20:02 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA19818; Wed, 2 Jun 1999 10:11:44 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA03833 for ietf-radius-outgoing; Wed, 2 Jun 1999 10:16:56 -0700 (PDT) Message-ID: <1180113EC576D011AADE0060975B88B367A603@neonet_server1.nexabit.com> From: Umesh Sirsiwal To: ietf-radius@livingston.com Subject: (radius) RADIUS Authentication MIB Date: Wed, 2 Jun 1999 13:16:06 -0400 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1457.3) Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Umesh Sirsiwal Why is RADIUS server a read-only variable in RADIUS authentication MIB draft? -Umesh - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jun 2 13:37:16 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06487 for ; Wed, 2 Jun 1999 13:37:15 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA20936; Wed, 2 Jun 1999 10:29:30 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA06348 for ietf-radius-outgoing; Wed, 2 Jun 1999 10:34:56 -0700 (PDT) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF6807@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'ietf-radius (E-mail)'" Subject: (radius) Problem with tunnel-auth-06 and Tag Date: Wed, 2 Jun 1999 13:34:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." > The description of how to handle Tag is ambiguous and misleading. You > want proof? Implementations by some of the vendors who authored the draft > DO NOT INTEROPERATE because they interpret the draft differently, and each > claims the other is doing it the wrong way. It's pretty bad when even the > draft authors disagree on how a protocol is to be implemented. > > The problem is that the text description, and the interpretation, for the > Tag field is different every time is it used. The text is even different > between the Tag for Tunnel-Type and the Tag for Tunnel-Medium-Type, even > though the interpretation is evidently supposed to be identical. The Tag > for other attributes is interpreted variously. In some cases, it is > required, in others, it is not. > > I suggest having both a uniform text and interpretation for the Tag field > throughout all attributes. I have heard the argument that this will break > interoperability with previous versions of the draft. IMHO, > interoperability with previous draft versions in not a desirable goal. > One should not have to know the history of a draft to implement it, and > all that matters is interoperability with the final published version. > > Here is a little table I have devised to show the inconsistencies with the > current draft. View in a fixed font for best results: > > Key: > --Req? Is tag field required for this attribute? > > --Range What is the allowed range of values for the tag field for this > attribute? Include all possible byte values that may legally appear in > this position. > > --Zero? Is a zero value allowed for this attribute? > > > Attribute Req? Range Zero? Comments > --------- ---- ----- ----- -------- > -Type Yes 0x00-0x1F Yes (1) > -Medium-type Yes 0x00-0x1F Yes (1) > -Client-Endpoint No 0x01-0xFF No (2) > -Server-Endpoint No 0x01-0xFF No (2) > -password Yes 0x01-0x1F No (3) > -pr-group-id No 0x01-0xFF No (2) > -assignment-id No 0x01-0xFF No (2) > -preference yes 0x01-0x1F Yes (4) > > > (1) Even though the interpretation of Tag for these two attribute types is > identical, the text describing them is not identical. For some reason, > the Tag description Tunnel-Medium-Type explicitly calls zero "0x0000", > while Tag for Tunnel-Type does not. Actually, 0x0000 must be wrong, > because there's not enough room in a Tag field for 0x0000, just for 0x00. > > (2) If value > 0x1F, behave as if tag was omitted, and interpret the value > here as the first byte of the next field. > > (3) "Ignore" values > 0x1F. It is not clear what ignore means - ignore > the whole attribute, or just the field? > > (4) Behavior is undefined for values >0x1F. Behavior is contradictory for > the value 0x00. 0x01-0x1F is given as the explicit range of valid values, > but the text immediately following says that 0x00 is also a valid value. > So it is unclear whether a 0x00 is a valid value. What a receiver is > supposed to do if it receives a value > 0x1F is undefined. > > ------------------------------------------------------ > > Here is my suggestion on how to fix this mess: > > Have a uniform interpretation and text for the Tag field, for all > attributes, as follows. The Tag field is always required, never > interpreted as part of the next field, and has defined behavior for all > possible values. > > Tag > > The Tag field is one octet in length and is intended to provide a means > of grouping attributes in the same packet which refer to the same > tunnel. > Valid values for Tags used to group attributes are 0x01 through 0x1F, > inclusive. If the Tag field is not used to group attributes, it MUST be > zero (0x00). Any other value found in the Tag field SHOULD be treated > as > a value of zero by the receiver. > > + Mark Anthony Beadles + UUNET Product Development + > + mbeadles@wcom.net + http://networking.us.uu.net + > + Voice 614.723.1941 + Fax 614.723.8407 + > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jun 2 13:59:55 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07050 for ; Wed, 2 Jun 1999 13:59:54 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA22462; Wed, 2 Jun 1999 10:52:55 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA09116 for ietf-radius-outgoing; Wed, 2 Jun 1999 10:57:31 -0700 (PDT) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF6808@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'John Shriver'" Cc: ietf-radius@livingston.com, glennz@microsoft.com, leifer@ascend.com, acr@del.com Subject: (radius) RE: Problem with tunnel-auth-06 and Tag Date: Wed, 2 Jun 1999 13:56:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." Your suggestions still do not clear up the following issues. Simple clarification is not enough, the behavior prescribed by the draft is flawed: In Tunnel-Type and Tunnel-Medium-Type: > (1) Even though the interpretation of Tag for these two attribute types is > identical, the text describing them is not identical. For some reason, > the Tag description Tunnel-Medium-Type explicitly calls zero "0x0000", > while Tag for Tunnel-Type does not. Actually, 0x0000 must be wrong, > because there's not enough room in a Tag field for 0x0000, just for 0x00. > In Tunnel-Password: > (3) "Ignore" values > 0x1F. It is not clear what ignore means - ignore > the whole attribute, or just the field? In Tunnel-Preference: > (4) Behavior is undefined for values >0x1F. Behavior is contradictory for > the value 0x00. 0x01-0x1F is given as the explicit range of valid values, > but the text immediately following says that 0x00 is also a valid value. > So it is unclear whether a 0x00 is a valid value. What a receiver is > supposed to do if it receives a value > 0x1F is undefined. IMO, we MUST NOT design protocols that have values for which behavior is undefined or contradictory. We also MUST NOT use different text to describe what is supposed to be the same functionality. I think it's also a real bad idea to bend these attributes to the breaking point just so we don't have to change code in real old servers, but I may be outvoted on that one. The thing is, RADIUS Client/Tunnel Initiator Vendors are going to have to write new code NO MATTER WHAT to support this functionality. And old RADIUS Servers are never going to support password ANYWAY. You could always do something like: One set of attributes where Tag is always required and explicit: > Tunnel-Type > Tunnel-Medium-type > Tunnel-Client-Endpoint > Tunnel-Server-Endpoint > Tunnel-password > Tunnel-pr-group-id > Tunnel-assignment-id > Tunnel-preference One set of attributes (minus password) for old RADIUS servers, where there is no Tag field at all: > Compat-Tunnel-Type > Compat-Tunnel-Medium-type > Compat-Tunnel-Client-Endpoint > Compat-Tunnel-Server-Endpoint > Compat-Tunnel-pr-group-id > Compat-Tunnel-assignment-id > Compat-Tunnel-preference Old servers can then support the latter set, new servers can support the former, and NAS's have to be prepared to accept either JUST AS THEY ARE WITH THE CURRENT PROPOSAL. + Mark Anthony Beadles + UUNET Product Development + + mbeadles@wcom.net + http://networking.us.uu.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jun 2 16:23:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09700 for ; Wed, 2 Jun 1999 16:23:12 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA26887; Wed, 2 Jun 1999 13:16:11 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA24478 for ietf-radius-outgoing; Wed, 2 Jun 1999 13:21:27 -0700 (PDT) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF680E@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "ietf-radius (E-mail)" Cc: "'jas@shiva.com'" Subject: (radius) FW: Problem with tunnel-auth-06 and Tag Date: Wed, 2 Jun 1999 16:21:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." Forwarded at John's request. + Mark Anthony Beadles + UUNET Product Development + + mbeadles@wcom.net + http://networking.us.uu.net + + Voice 614.723.1941 + Fax 614.723.8407 + -----Original Message----- From: John Shriver [mailto:jas@shiva.com] Sent: Wednesday, 02 June 1999 12:20 PM To: MBeadles@wcom.net Cc: ietf-radius@livingston.com; glennz@microsoft.com; leifer@ascend.com; acr@del.com Subject: Re: Problem with tunnel-auth-06 and Tag I think what is going on with the tag is not about compatiblity with earlier revs of the Internet-Draft. I think it's about compatability with certain very popular RADIUS servers. In particular, the old free one from Livingston. Probably also the last of the free Merit servers. But, really, adding the tags in the first place pushed the envelope of the whole "data dictionary" idea from Livingston's first proposals for RAIDUS. The idea what that new AVP's could be designed, and implemented in existing RADIUS servers by modifying the data dictionary file, and not the source code of the server. By adding the tag, we've changed from an AVP (attribute value pair) to an AVVT (attribute value value triplet). So, the idea is to design the definitions of the tags such that if you are NOT using tags, there are special coding rules such that an old data dictionary RADIUS server can be used without modification. In this case, the tags on numeric fields have value 0, and the tags for string fields have the first character of the string (> 0x1f). However, I see that this rule has not been applied uniformly. Atttribute Tunnel-Password (69) is probably impossible to implement on the old data dictionary RADIUS servers. (Looking at the contents, that makes sense.) Still, we should probably say to send 0 in the tag when tags are not in use. (Or 0xFF, or something.) I think if the motivation for the Tag field is better written, and an explanation of why the strange values for the Tag field when it's not in use, it would help a lot. Let's give it a try (offering up 3 paragraphs before is how I became a co-author): 5. Attributes There are two modes in which these set of attributes may be used. In the first, only one instance of each attribute may be included in a single RADIUS packet, on the second, there may be multiple instances of these attributes. The coding of the Tag field differs in each mode. 5.1 Single Instance of Each Attribute Implementation of single-instance mode is a MUST for RADIUS clients (tunnel initiators) and RADIUS servers. In the single-instance mode, there are special coding rules for the Tag field. The purpose of these codings rules is to be compatible with the installed base of RADIUS servers that use the "data dictionary" concept. The coding of the Tag in numeric attributes is 0, so that the numeric attribute can be viewed by the RADIUS server as a single 32-bit number. The coding of the Tag in string attributes is as the first character of the string, which must be greater than 0x1f. (The coding of the Tunnel-Password attribute is so complicated that it simply won't work with older RADIUS servers.) [XXX Am I right here?] In particalar, when the tunnel-initiator sends an Access-Request packet, if there is only one instance, then this compatible encoding MUST be used. 5.2 Multiple Instances of Each Attribute Multiple-instance mode is a MAY for RADIUS clients (tunnel initiators) and RADIUS servers. Use of this mode must be controlled by user configuration. (This MAY be implicit by the nature of the data coded into the RADIUS server.) In the multiple-instance mode, there can be up to 15 instances of each attribute, numbered 1-15 (0x01 - 0x1f). The attributes come in logical sets, each of which MUST have the same value in the Tag field. Each of these sets SHOULD include the Tunnel-Preference attribute. These sets of instances SHOULD be interpreted by the tunnel initiator as alternatives. They SHOULD be evaluated in order of the value of the Tunnel-Preference attribute, comparing the set of instances to the preferences and capabilities of the tunnel initiator. Similary, the tunnel initiator MAY include multiple sets of tunnel Attributes in an Access-Request packet. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jun 2 16:23:20 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09712 for ; Wed, 2 Jun 1999 16:23:20 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA26903; Wed, 2 Jun 1999 13:16:17 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA24425 for ietf-radius-outgoing; Wed, 2 Jun 1999 13:20:58 -0700 (PDT) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF680D@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "ietf-radius (E-mail)" Cc: "'jas@shiva.com'" Subject: (radius) FW: Problem with tunnel-auth-06 and Tag Date: Wed, 2 Jun 1999 16:20:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." Forwarded at John's request. + Mark Anthony Beadles + UUNET Product Development + + mbeadles@wcom.net + http://networking.us.uu.net + + Voice 614.723.1941 + Fax 614.723.8407 + -----Original Message----- From: John Shriver [mailto:jas@shiva.com] Sent: Wednesday, 02 June 1999 3:10 PM To: MBeadles@wcom.net Cc: glennz@microsoft.com; leifer@ascend.com; acr@del.com Subject: Re: Problem with tunnel-auth-06 and Tag (By the way, I'm not on the ietf-radius list, if people think my messages should be seen there, please forward them, as the SPAM filtering won't let me post to it.) As I look through this draft, I think someone has been too generous with the SHOULD's. There should be more MUST. Some may be "if, then, MUST". From: "Beadles, Mark A." To: "'John Shriver'" Cc: ietf-radius@livingston.com, glennz@microsoft.com, leifer@ascend.com, acr@del.com Subject: RE: Problem with tunnel-auth-06 and Tag Date: Wed, 2 Jun 1999 13:56:35 -0400 Your suggestions still do not clear up the following issues. Simple clarification is not enough, the behavior prescribed by the draft is flawed: In Tunnel-Type and Tunnel-Medium-Type: > (1) Even though the interpretation of Tag for these two attribute types is > identical, the text describing them is not identical. For some reason, > the Tag description Tunnel-Medium-Type explicitly calls zero "0x0000", > while Tag for Tunnel-Type does not. Actually, 0x0000 must be wrong, > because there's not enough room in a Tag field for 0x0000, just for 0x00. > Yeah, that's a typo. Nobody's going to argue against fixing that. In Tunnel-Password: > (3) "Ignore" values > 0x1F. It is not clear what ignore means - ignore > the whole attribute, or just the field? My suggestion was that we should define a particular "not used" value. I don't know why it's not zero. Maybe because this attribute can be handled by a data-dictionary RADIUS server after all, but only if it's non-zero. Maybe we should define the "unused" value to be 0x69 ('i' in ASCII), since this is parameter 69. In Tunnel-Preference: > (4) Behavior is undefined for values >0x1F. Behavior is contradictory for > the value 0x00. 0x01-0x1F is given as the explicit range of valid values, > but the text immediately following says that 0x00 is also a valid value. > So it is unclear whether a 0x00 is a valid value. What a receiver is > supposed to do if it receives a value > 0x1F is undefined. IMO, we MUST NOT design protocols that have values for which behavior is undefined or contradictory. We also MUST NOT use different text to describe what is supposed to be the same functionality. I think it's also a real bad idea to bend these attributes to the breaking point just so we don't have to change code in real old servers, but I may be outvoted on that one. If not tagged, the tag is 0x00, if tagged, the value is 0x0-0x1f. If the value is between 0x20 and 0xff, the attribute is ignored. (It does not belong to any of the 15 valid tag sets.) IETF RFC's aren't a formal language. But, if we explain the motivation better, minor lapses in clarity are less likely to cause problems in interpretation. Clearly, we need to word things more clearly. But I think we're stuck with the fact that the intended protocol is somewhat wart-encrusted. The thing is, RADIUS Client/Tunnel Initiator Vendors are going to have to write new code NO MATTER WHAT to support this functionality. And old RADIUS Servers are never going to support password ANYWAY. An ancient data-dictionary RADIUS server can implement the tunnel-password attribute, if it is willing to violate the MUST about the salt being different each time. This may be why 0 isn't the canonical no-tag value for this attribute's Tag, the data-dictionary servers may strip leading bytes of 0x00 from hex strings... You could always do something like: One set of attributes where Tag is always required and explicit: > Tunnel-Type > Tunnel-Medium-type > Tunnel-Client-Endpoint > Tunnel-Server-Endpoint > Tunnel-password > Tunnel-pr-group-id > Tunnel-assignment-id > Tunnel-preference One set of attributes (minus password) for old RADIUS servers, where there is no Tag field at all: > Compat-Tunnel-Type > Compat-Tunnel-Medium-type > Compat-Tunnel-Client-Endpoint > Compat-Tunnel-Server-Endpoint > Compat-Tunnel-pr-group-id > Compat-Tunnel-assignment-id > Compat-Tunnel-preference Old servers can then support the latter set, new servers can support the former, and NAS's have to be prepared to accept either JUST AS THEY ARE WITH THE CURRENT PROPOSAL. Umm, the RADIUS attribute numbering space is too damn small to get two sets of values. (This has been one of causes of much that has been problematic about RADIUS standardization through the years.) Some ISP's (obviously not UUNet) are VERY stubborn about sticking with the ancient RADIUS server they are presently using, yet adding new features. That WAS a design goal of RADIUS. (I was at the last RADIUS BOF before the working group started.) Also, this is why every RAS vendor has to implement all the proprietary Ascend attributes, standardized or not... + Mark Anthony Beadles + UUNET Product Development + + mbeadles@wcom.net + http://networking.us.uu.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jun 2 16:34:42 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09971 for ; Wed, 2 Jun 1999 16:34:41 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA27446; Wed, 2 Jun 1999 13:27:42 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA25988 for ietf-radius-outgoing; Wed, 2 Jun 1999 13:33:06 -0700 (PDT) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF680F@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'John Shriver'" , "ietf-radius (E-mail)" Cc: glennz@microsoft.com, leifer@ascend.com, acr@del.com Subject: (radius) RE: Problem with tunnel-auth-06 and Tag Date: Wed, 2 Jun 1999 16:32:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." I concur that the current RADIUS protocol severely hampers our ability to add new functionality. In the absence of being able to write a completely sane set of attributes, then by all means, let's make the current language unambiguous enough that we can get interoperability among vendors. We would REALLY like to deploy systems based on the functionality in this draft - and we cannot if we do not have interop. The biggest problem that we have found is that the Tunnel-Password Tag is treated differently from all others, and it is very easy for an implementor to miss or misinterpret this. I know that these are not written in formal language, but at the very least we need to explicitly state what behavior is expected for all possible values. If a particular Tag field value is not allowed in certain cases, we must explicitly state what a receiver is supposed to _do_ if it receives it. In particular: -What does a receiver do if it receives a Tag field > 0x1F in a Tunnel-Preference attribute? -What does a receiver do if it receives a Tag field of 0x00 in a Tunnel-Password attribute? + Mark Anthony Beadles + UUNET Product Development + + mbeadles@wcom.net + http://networking.us.uu.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jun 11 00:49:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11742 for ; Fri, 11 Jun 1999 00:49:39 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA04189; Thu, 10 Jun 1999 21:42:26 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA10248 for ietf-radius-outgoing; Thu, 10 Jun 1999 21:46:03 -0700 (PDT) Date: Thu, 10 Jun 1999 21:40:13 -0700 (PDT) From: Carl Rigney Message-Id: <199906110440.VAA10007@server.livingston.com> To: dmitton@nortelnetworks.com Subject: Re: (radius) Comment on Acct-Session-ID Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney dmitton@nortelnetworks.com writes: > The new Accounting draft mentions that an Access-Accept may include a > Acct-Session-ID and it MUST be the same value as Accounting-Requests for > that session. > However, the new Authentication draft does not add this attribute to it's > table in 5.44 or make any mention of it. Accounting attributes are described in the RADIUS Accounting document, not the RADIUS document, even when they appear in packet types defined in the RADIUS document. It can't be otherwise, since RADIUS is on standards track and can't depend on anything in RADIUS Accounting, which is informational. There's language in the RADIUS draft mentioning that packets may have attributes that are defined in other documents, and those other documents should be referred to accordingly. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jun 11 00:50:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11758 for ; Fri, 11 Jun 1999 00:50:34 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA04238; Thu, 10 Jun 1999 21:43:26 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA10374 for ietf-radius-outgoing; Thu, 10 Jun 1999 21:49:13 -0700 (PDT) Date: Thu, 10 Jun 1999 21:49:09 -0700 (PDT) From: Carl Rigney Message-Id: <199906110449.VAA10367@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Last call for last call Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney The Working Group Last Call for RADIUS & RADIUS Accounting drafts expired 5/26 with very few comments. I'm about to submit them to the IESG for IETF Last Call, so if you haven't reviewed them yet and would like to, please try to get your comments to me by Monday 6/14. -- Carl Rigney IETF RADIUS Working Group Chair 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 Jun 11 00:53:27 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11774 for ; Fri, 11 Jun 1999 00:53:26 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA04398; Thu, 10 Jun 1999 21:46:10 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA10482 for ietf-radius-outgoing; Thu, 10 Jun 1999 21:51:57 -0700 (PDT) Date: Thu, 10 Jun 1999 21:46:33 -0700 (PDT) From: Carl Rigney Message-Id: <199906110446.VAA10268@server.livingston.com> To: jas@shiva.com Subject: Re: (radius) FW: Problem with tunnel-auth-06 and Tag Cc: MBeadles@wcom.net, ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney mbeadles@wcom.net forwards email by jas@shiva.com: > (By the way, I'm not on the ietf-radius list, if people think my > messages should be seen there, please forward them, as the SPAM > filtering won't let me post to it.) It's not my intention that the spam filtering keep people who aren't on the list from contributing. I've added your address to the list of 'addresses not on the list who can mail to it anyway' so you can mail to ietf-radius@livingston.com 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 Fri Jun 11 00:54:02 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11785 for ; Fri, 11 Jun 1999 00:54:01 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA04449; Thu, 10 Jun 1999 21:46:22 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA10505 for ietf-radius-outgoing; Thu, 10 Jun 1999 21:52:09 -0700 (PDT) Date: Thu, 10 Jun 1999 21:52:06 -0700 (PDT) From: Carl Rigney Message-Id: <199906110452.VAA10496@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Tags in L2TP draft Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney I'd like to see the L2TP draft specify Tags fully and completely enough to guarantee interoperability. Anything less is inadequate. If people could hammer out some language quickly and thoroughly it would be very nice to get those drafts moving along. I've seen lots of postings from Mark (& the forwardings from John) but so far not much in the other direction. Are discussions happening by private email, or languishing? -- Carl Rigney IETF RADIUS WG Chair cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message.