From owner-ietf-radius@livingston.com Thu Jun 1 10:14:13 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 KAA23942 for ; Thu, 1 Jun 2000 10:14:12 -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 HAA18201; Thu, 1 Jun 2000 07:09:16 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA07704 for ietf-radius-outgoing; Thu, 1 Jun 2000 07:08:56 -0700 (PDT) From: "Darran Potter" To: "David Mitton" , "Carl Rigney" , , Subject: RE: (radius) IPv6 Date: Thu, 1 Jun 2000 15:01:39 +0100 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <4.2.2.20000531182910.00db77d0@ZBL6C008.corpeast.baynetworks.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit I also think a new IPADDR_6 type would at least allow older stuff to carry on working.. sending > 32 bits in IPADDR would be painful. The transition from ye-olde-plain-text tunnel password to tagged+encrypted has caused some problems for older hw/sw. But thats nothing to what messing with IPADDR could cause. Darran -----Original Message----- From: owner-ietf-radius@livingston.com [mailto:owner-ietf-radius@livingston.com]On Behalf Of David Mitton Sent: 31 May 2000 23:44 To: Carl Rigney; aboba@internaut.com; cdr@livingston.com; David Mitton; ietf-radius@livingston.com Subject: RE: (radius) IPv6 At 11:06 AM 5/30/00 -0700, Carl Rigney wrote: >I'd rather add attributes with a new type, since there are only a handful of >those, than break all existing RADIUS servers by adding the concept of length >sensitive processing. > >-- >Carl Rigney While I think that's a fair enough decision.... ... I'm concerned about the concept of non-six byte ipaddr attributes "breaking" existing servers. While they may not understand the value, I would hope that; a) they would check the length and realize the attribute value received is not-as-expected for the data type (by their implementation timeframe) b) ignore the attribute value c) perhaps flag or log the problem d) not reject the whole message (though they might per earlier interpretations of the RADIUS message processing rules) None of these consequences would be really unusual, as operationally the client and server must converge on a mutually understood set of attributes anyways. Going a step further, I think primarily NAS-IP-Address would be client generated. (and Framed-IP-Address if the address was user or NAS chosen) Most other ipaddr values would be in a server return profile to start with. Older servers would not be able to encode these values, and therefore would not interoperate with a hypothetical IPv6 RADIUS-speaking NAS. So I guess that's sort of a rationale for new attributes. However if they are anything other than ASCII\\\\\ UTF-8 strings there is something new here to be implemented anyways. Dave. --------------------------------------------------------------- David Mitton ESN: 248-4570 Advisor, Nortel Networks 978-288-4570 Direct Carrier Packet Solutions, IP Mobility 978-288-???? 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 Thu Jun 1 10:42:53 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 KAA24568 for ; Thu, 1 Jun 2000 10:42:52 -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 HAA18788; Thu, 1 Jun 2000 07:37:38 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id HAA08719 for ietf-radius-outgoing; Thu, 1 Jun 2000 07:39:32 -0700 (PDT) Message-Id: <200006011443.KAA25739@cpu1751.adsl.bellglobal.com> To: ietf-radius@livingston.com Subject: Re: (radius) IPv6 In-reply-to: Your message of "Wed, 31 May 2000 18:44:12 EDT." <4.2.2.20000531182910.00db77d0@ZBL6C008.corpeast.baynetworks.com> Date: Thu, 01 Jun 2000 10:43:46 -0400 From: Alan DeKok Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok "David Mitton" wrote: > ... I'm concerned about the concept of non-six byte ipaddr attributes > "breaking" existing servers. Over-loading functionality onto something never designed to have that functionality often breaks it. This shouldn't be a surprise. > While they may not understand the value, I would hope that; > > a) they would check the length and realize the attribute value received is > not-as-expected for the data type (by their implementation timeframe) And for the RADIUS server which do NOT check the length, what do they do? Often, they'll just use the first 4 octets of the IPv6 address as the IPv4 address. > b) ignore the attribute value Or happily core dump. > c) perhaps flag or log the problem Or ignore the problem silently, if they don't core dump. > None of these consequences would be really unusual, as operationally the > client and server must converge on a mutually understood set of attributes > anyways. (laughs hysterically) I guess you have more faith than I do in the various RADIUS implementations. Many of the ones I've seen work fine. However, there are a large number which are abysmal, and the people using them cannot, or will not upgrade, or else they simply don't understand that there is a problem. Given the worst scenario (the status quo), I don't think my descriptions of events are unreasonable. > Older servers would not be able to encode these values, and therefore would > not interoperate with a hypothetical IPv6 RADIUS-speaking NAS. I'm pessimistic. I've seen enough RADIUS interoperability problems to be wary of changes which can cause even more problems. New attributes for IPv6 would be the path to the highest level of interoperation. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jun 1 15:20: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 PAA01299 for ; Thu, 1 Jun 2000 15:20: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 MAA25739; Thu, 1 Jun 2000 12:15:50 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA23061 for ietf-radius-outgoing; Thu, 1 Jun 2000 12:16:31 -0700 (PDT) Message-Id: <4.2.2.20000601144616.00d6d820@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 01 Jun 2000 14:53:50 -0400 To: Alan DeKok , ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) IPv6 In-Reply-To: <200006011443.KAA25739@cpu1751.adsl.bellglobal.com> References: 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 10:43 AM 6/1/00 -0400, Alan DeKok wrote: >"David Mitton" wrote: > > ... I'm concerned about the concept of non-six byte ipaddr attributes > > "breaking" existing servers. > > Over-loading functionality onto something never designed to have >that functionality often breaks it. This shouldn't be a surprise. > > > While they may not understand the value, I would hope that; > > > > a) they would check the length and realize the attribute value received is > > not-as-expected for the data type (by their implementation timeframe) > > And for the RADIUS server which do NOT check the length, what do >they do? Often, they'll just use the first 4 octets of the IPv6 >address as the IPv4 address. I would argue that implementation is already broken. And this just serves as an illustration and impetus to change. > > b) ignore the attribute value > > Or happily core dump. That gets people's attention quickly. > > > c) perhaps flag or log the problem > > Or ignore the problem silently, if they don't core dump. Except that the users' don't get the address they wanted or need. > > None of these consequences would be really unusual, as operationally the > > client and server must converge on a mutually understood set of attributes > > anyways. > > (laughs hysterically) > > I guess you have more faith than I do in the various RADIUS >implementations. Many of the ones I've seen work fine. However, >there are a large number which are abysmal, and the people using them >cannot, or will not upgrade, or else they simply don't understand that >there is a problem. But the fact of the matter is that the RADIUS client and server MUST exchange what's needed or the ISP cannot provide the service. Actually, I'm just grabbing the opportunity to play advocate for more robust software. If I just get one more person to write more defensive protocol code, the network becomes a safer place. > Given the worst scenario (the status quo), I don't think my >descriptions of events are unreasonable. > > > Older servers would not be able to encode these values, and therefore > would > > not interoperate with a hypothetical IPv6 RADIUS-speaking NAS. > > I'm pessimistic. I've seen enough RADIUS interoperability problems >to be wary of changes which can cause even more problems. New >attributes for IPv6 would be the path to the highest level of >interoperation. > Don't try to out-pessim me...;^) If you always believe the current stuff won't work if extended, how will you ever build new stuff?? Eventually you have to go there. Given the speed of NAS IPv6 implementations I've witnessed, maybe they won't have to implement RADIUS by the time they are ready. sigh... Dave. > Alan DeKok. >- >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, IP Mobility 978-288-???? 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 Thu Jun 1 15:28: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 PAA01567 for ; Thu, 1 Jun 2000 15:28: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 MAA25982; Thu, 1 Jun 2000 12:23:34 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id MAA23664 for ietf-radius-outgoing; Thu, 1 Jun 2000 12:25:30 -0700 (PDT) Message-Id: <200006011929.PAA27022@cpu1751.adsl.bellglobal.com> To: ietf-radius@livingston.com Subject: Re: (radius) IPv6 In-reply-to: Your message of "Thu, 01 Jun 2000 14:53:50 EDT." <4.2.2.20000601144616.00d6d820@ZBL6C008.corpeast.baynetworks.com> Date: Thu, 01 Jun 2000 15:29:45 -0400 From: Alan DeKok Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok "David Mitton" wrote: [re: ipv6 address in RADIUS pseudo-IPv4 attributes ] > > Or ignore the problem silently, if they don't core dump. > > Except that the users' don't get the address they wanted or need. And they call YOUR tech support, and waste YOUR time, because the software does weird things. I don't know about you, but I hate anwering questions. If the protocol can be designed to be robust and well-behaved under implementation and administrator abuse, that's a damn good thing. > But the fact of the matter is that the RADIUS client and server MUST > exchange what's needed or the ISP cannot provide the service. What about: NAS -> ipv6 aware proxy -> non-ipv6 aware server With IPv6 addresses in old IPv4 RADIUS attributes, the end server dumps core, or returns garbage, and the CORRECTLY WRITTEN proxy server cannot properly handle the request. Your servers are no better than the weakest link in the authorization/authentication chain. If the end server sees the IPv6 attributes as NEW attributes, it just logs & ignores them. Everything should still mostly work the same. > Actually, I'm just grabbing the opportunity to play advocate for more > robust software. If I just get one more person to write more defensive > protocol code, the network becomes a safer place. That's why my opinion is that new IPv6 specific RADIUS attributes are the preferred approach. > If you always believe the current stuff won't work if extended, how will > you ever build new stuff?? Eventually you have to go there. You don't change the foundation under the house if you don't have to. The RADIUS foundation is shaky, but it's mostly stable. I'd rather see an IPv6 addition in RADIUS, than knocking a whole in an already shaky foundation, and patching it with duct tape. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jun 1 16:15:00 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 QAA02599 for ; Thu, 1 Jun 2000 16:15:00 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id NAA26856; Thu, 1 Jun 2000 13:05:08 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA26286 for ietf-radius-outgoing; Thu, 1 Jun 2000 13:06:45 -0700 (PDT) Message-Id: <200006012011.QAA27257@cpu1751.adsl.bellglobal.com> To: ietf-radius@livingston.com Subject: Re: (radius) IPv6 In-reply-to: Your message of "Thu, 01 Jun 2000 12:47:26 PDT." Date: Thu, 01 Jun 2000 16:10:59 -0400 From: Alan DeKok Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok "pcalhoun@eng.sun.com" wrote: > Putting aside the core dump, creating new Attributes with a new > Type, call it IPv6-Address, will NOT work with non-IPv6 aware > routers. At best, they will be handled as opaque objects. Yes. Or, they can be handled as 'string', which will work with most servers. This is an aside, but I'm really disappointed that the original RADIUS protocol didn't define an 'octets' data type, where the data is input/output as hex strings. The 'string' attribute is nice, but there are too many different implementation-specific modes of behaviour for non-ASCII 'string' data. > However, if the NAS-IP-Address-V6 attribute (or whatever it ends up > being called) is not recognized by the non-v6 server, the request > will be dropped. Why? Servers can get hordes of attributes that they don't understand. Some NAS vendors pollute the low attribute numbers with their own VSA's. Some RADIUS administrators don't update their dictionaries with NAS vendor VSA's. In either case, the server can generally ignore what it doesn't understand, and continue processing the parts of the request it does understand. (i.e. Access-Request, User-Name, Password). I think that few, if any, RADIUS servers drop requests which contain an attribute that they don't understand. > Certainly one could request that the proxy be responsible for > address translation, but this removes the NAS' original address, > which is required by most ISPs. Agreed, we shouldn't go down that path. > I would argue that replacing the foundation would not only be MUCH > more solid, but it would design to withstand eathquakes that > register 8 on the richter scale, water proof, etc. Then it's DIAMETER, not RADIUS. And for full confidence, it would greatly help to have a reference implementation that people interoperate with or ELSE. One of the reasons RADIUS is so shaky is that most people did their own thing on implementation. The protocol is *nearly* interoperable across implementations, but it isn't *completely* interoperable. > Certainly, replacing the foundation with cardboard and tape is not > an option, and I am not sure that anyone was proposing doing that. There was the suggestion for dropping IPv6 addresses into IPv4 RADIUS attributes, and having the IPv6 recognition via the different length. I'd like to squash that with loud cries of "please, no!" Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jun 1 16:39:41 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 QAA03057 for ; Thu, 1 Jun 2000 16:39: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 NAA27836; Thu, 1 Jun 2000 13:34:44 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id NAA27713 for ietf-radius-outgoing; Thu, 1 Jun 2000 13:36:00 -0700 (PDT) Message-Id: <200006012040.QAA27451@cpu1751.adsl.bellglobal.com> To: ietf-radius@livingston.com Subject: Re: (radius) IPv6 In-reply-to: Your message of "Thu, 01 Jun 2000 13:25:43 PDT." <3936C6C6.A121A5F@ascend.com> Date: Thu, 01 Jun 2000 16:40:16 -0400 From: Alan DeKok Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok Bill Webb wrote: > Well, given that certain unnamed NAS vendors are running out of Attribute > numbers (yes, even using VSA's), I'd hate to see an extra 5-10 attributes > identical to existing attributes except for having IPv6 addresses. That is a problem, definitely. > How about having an attribute that when sent to a radius server says > if it will accept IPv4, or IPv6 addresses (or both) and when sent > from the radius server to the NAS says that the NAS can assume IP > addresses are IPv4, IPv6, or it should check the length of IP > addresses to figure it out. RADIUS as a stateful protocol? The ground shakes beneath me! :) Another possible idea is over-loading of the Vendor-ID in the VSA. My reading of the network management private enterprise code documents shows that this space is very sparsely populated. It should be possible to change the 32-bit Vendor-Id to: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Attribute-Sub-Space | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Off of the top of my head, I can't think of many ways that this would break existing RADIUS implementations. You'd just have vendors 'lucent-1', 'lucent-2', etc. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jun 14 11:33:34 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 LAA25357 for ; Wed, 14 Jun 2000 11:33:34 -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 IAA23617; Wed, 14 Jun 2000 08:27:04 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA03266 for ietf-radius-outgoing; Wed, 14 Jun 2000 08:25:19 -0700 (PDT) From: "Volodymyr Tarasevych" To: Subject: (radius) MS-CHAP and RADIUS Date: Wed, 14 Jun 2000 11:27:31 -0400 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Volodymyr Tarasevych" Content-Transfer-Encoding: 7bit I would like some help. How may I properly calculate MS-CHAP in a RADIUS request? I have used RFC 2433, but this does not work as I expected. Using the RFC, I get only the last byte matching in the triplets (LM hash and NT hash). Here is an example: Username: "user" Password: "password" Challenge string(Vendor-Type 11): 2E 39 14 22 2E 0B 3D 05 Valid MS-CHAP reponse (Vendor-Type 1) is: 81 01 A0 A7 84 FC 1F 25 A6 DD F6 01 12 40 ED F8 F1 2B C1 03 E0 A1 9F 96 85 A1 5B 06 EA 06 0F 3C CC B1 89 14 F0 43 ED 4A AC 8A 38 65 0F D9 BB 56 99 B9 I have properly calculated LM hash and NT hash: LM hash is 45 7C 2A 41 10 D8 98 80 7C 04 38 8A 05 EF 75 CB C1 03 E0 A1 9F 96 85 A1 NT hash is 3F B7 B6 BC 66 98 CF E7 8C 80 F0 97 F9 35 33 1E 38 65 0F D9 BB 56 99 B9 You can see that only the last byte matches in the triplets. I know that my error resides in that I did not take in account the MSCHAP Identifier, (in our case 0x81) the first byte in the MS-CHAP reponse. What I should to do next to get a valid MS-CHAP reponse? Best Regards, Volodymyr Tarasevych volodymyr@vircom.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 21 11:05:12 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 LAA03619 for ; Wed, 21 Jun 2000 11:05:11 -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 HAA01517; Wed, 21 Jun 2000 07:58:52 -0700 (PDT) Received: by server.livingston.com (8.9.3/8.9.3/0.5) id HAA15636 for ietf-radius-outgoing; Wed, 21 Jun 2000 07:56:35 -0700 (PDT) Message-ID: <00a201bfdb90$933bb300$7501a8c0@oleane.oleane.com> From: "Peter Lewis" To: Subject: (radius) IP Policing Conference Date: Wed, 21 Jun 2000 16:54:12 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01BFDBA1.539737E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Peter Lewis" This is a multi-part message in MIME format. ------=_NextPart_000_009E_01BFDBA1.539737E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SNMP/Configuration or COPS/DEN? The " IP Policing Conference" will stand in Paris next 12-15 September: http://www.upperside.fr/baippol.htm ------=_NextPart_000_009E_01BFDBA1.539737E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
SNMP/Configuration or COPS/DEN?
The " IP Policing Conference" will stand in Paris next = 12-15=20 September:
 
http://www.upperside.fr/baip= pol.htm
------=_NextPart_000_009E_01BFDBA1.539737E0-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jun 21 11:51:37 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 LAA04623 for ; Wed, 21 Jun 2000 11:51:37 -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 IAA02329; Wed, 21 Jun 2000 08:45:40 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/0.5) id IAA17606 for ietf-radius-outgoing; Wed, 21 Jun 2000 08:47:44 -0700 (PDT) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Peter Lewis" Cc: Subject: Re: (radius) IP Policing Conference References: <00a201bfdb90$933bb300$7501a8c0@oleane.oleane.com> Message-Id: Date: Wed, 21 Jun 2000 16:46:18 +0100 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit > SNMP/Configuration or COPS/DEN? > The " IP Policing Conference" will stand in Paris next 12-15 September: and will we have to wait until then for your damned spam to stop? randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jun 28 19:25:36 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 TAA06377 for ; Wed, 28 Jun 2000 19:25:35 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id QAA20037; Wed, 28 Jun 2000 16:20:27 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id QAA07461 for ietf-radius-outgoing; Wed, 28 Jun 2000 16:17:57 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f Date: Wed, 28 Jun 2000 16:17:11 -0700 (PDT) From: "pcalhoun@eng.sun.com" Subject: (radius) Vendor Specific Attributes To: ietf-radius@livingston.com In-Reply-To: "Your message with ID" <200006011929.PAA27022@cpu1751.adsl.bellglobal.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "pcalhoun@eng.sun.com" All, Is there ANY vendors out there that currently have defined a vendor specific attribute of 256? What I mean by this would be the standards VSA (26), with the "Vendor type" field below set to 256: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | Vendor type | Vendor length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Of course, I understand that if one was to follow this structure, one could NEVER use 256, but there are some vendors out there that do not follow this suggested VSA structure (and those are the one to whom I am asking this question). Thanks, PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jun 30 13:57:47 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 NAA23123 for ; Fri, 30 Jun 2000 13:57:47 -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 KAA17068; Fri, 30 Jun 2000 10:51:21 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id KAA24024 for ietf-radius-outgoing; Fri, 30 Jun 2000 10:49:01 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f From: "Glen Zorn" To: "John R. Martz" Cc: "RADIUS Mailing List" , Subject: (radius) RE: Radius MP attributes? Date: Fri, 30 Jun 2000 10:45:46 -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 In-Reply-To: <001b01bfe213$1d7dc160$c0458209@endicott.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit John R. Martz [maailto://jmartz@us.ibm.com] writes: > A co-worker mentioned to me that there are Radius attributes > defined for use with the Multilink > Protocol (MP). I've looked at the list of attributes on page 59 > RFC 2138, but nothing I saw there > seemed to pertain specifically to MP. > > Are there Radius attributes for MP (and BAP)? And if so, can > someone point me towards the RFC that > describes them? The only BAP-specific RADIUS attributes of which I'm aware are also Microsoft vendor-specific (RFC 2548). > > Thanks, > -john martz (jmartz@us.ibm.com) > IBM AS/400 TCP/IP PPP (and stuff) > > > > > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jun 30 15:26:19 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 PAA24810 for ; Fri, 30 Jun 2000 15:26:18 -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 MAA18983; Fri, 30 Jun 2000 12:19:54 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id MAA01159 for ietf-radius-outgoing; Fri, 30 Jun 2000 12:21:35 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f From: "Mark Jones" To: "IETF RADIUS WG" Subject: (radius) Question on RFC2619: radiusAuthServTotalBadAuthenticators Date: Fri, 30 Jun 2000 15:21:31 -0400 Message-ID: <007901bfe2c8$65db9850$2096a8c0@bridgewatersys.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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mark Jones" Content-Transfer-Encoding: 7bit The description for this MIB variable is: "The number of RADIUS Authentication-Request packets which contained invalid Signature attributes received." I assume this should read: "The number of RADIUS Authentication-Request packets received which contained invalid Signature attributes." What is a RADIUS Signature attribute in the context of an Authentication-Request? If it is the Request Authenticator field in the packet header, how does one determine that it is 'Bad' given that it is a 16 octet random number? Regards, Mark - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jun 30 15:48: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 PAA25207 for ; Fri, 30 Jun 2000 15:48: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 MAA19503; Fri, 30 Jun 2000 12:42:27 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id MAA02784 for ietf-radius-outgoing; Fri, 30 Jun 2000 12:44:48 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f From: "Glen Zorn" To: "Mark Jones" , "IETF RADIUS WG" Subject: RE: (radius) Question on RFC2619: radiusAuthServTotalBadAuthenticators Date: Fri, 30 Jun 2000 12:42:00 -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 In-Reply-To: <007901bfe2c8$65db9850$2096a8c0@bridgewatersys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Mark Jones [mailto://mjones@bridgewatersys.com] writes: > The description for this MIB variable is: > > "The number of RADIUS Authentication-Request packets > which contained invalid Signature attributes received." > > I assume this should read: > > "The number of RADIUS Authentication-Request packets > received which contained invalid Signature attributes." Actually, it should probably read: "The number of RADIUS Authentication-Request packets received which contained invalid Message-Authenticator attributes." The name of the Signature attribute was changed to avoid confusing people who habitually equate signatures with public-ley crypto, I believe. > > What is a RADIUS Signature attribute in the context of an > Authentication-Request? See http://www.ietf.org/internet-drafts/draft-ietf-radius-ext-07.txt > If it is the Request Authenticator field in the > packet header, how does one determine that it is 'Bad' given that > it is a 16 > octet random number? > > Regards, > Mark > > - > 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 Jun 30 16:23:03 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 QAA25836 for ; Fri, 30 Jun 2000 16:23:02 -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 NAA20162; Fri, 30 Jun 2000 13:16:22 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id NAA04620 for ietf-radius-outgoing; Fri, 30 Jun 2000 13:18:44 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f From: "Glen Zorn" To: "Mark Jones" , "IETF RADIUS WG" Cc: "Glen Zorn" Subject: RE: (radius) Question on RFC2619: radiusAuthServTotalBadAuthenticators Date: Fri, 30 Jun 2000 13:15:47 -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 In-Reply-To: <008701bfe2ce$05c88170$2096a8c0@bridgewatersys.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Mark Jones [mailto:mjones@bridgewatersystems.com] writes: > Glen, > > Thanks for the prompt reply. While you're changing the description, some > mention of EAP would be helpful too. Maybe you're right. However, the use of the Message-Authenticator Attribute, while mandated for use with the EAP-Message Attribute, is not restricted thereto... > > Regards, > Mark > > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message.