From owner-ietf-radius@portmasters.com Fri Mar 1 03:11:55 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00942 for ; Fri, 1 Mar 2002 03:11:55 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g217lSa26278 for ietf-radius-outgoing; Fri, 1 Mar 2002 01:47:28 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Date: Fri, 1 Mar 2002 00:06:23 -0800 (PST) From: Murtaza Chiba To: Subject: (radius) Updated draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Murtaza Chiba Hi All, Thanks for the feedback. Here is another take at the draft. BTW, we only intend to further this as an Informational RFC. Thanks and Best Regards, Murtaza ========================================================================= INTERNET-DRAFT Murtaza S. Chiba Title: Cisco Systems, Inc. draft-chiba-radius-dynamic-authorization-01.txt Expires July 2002 Gopal Dommety Cisco Systems, Inc. Mark Eklund Cisco Systems, Inc. David Mitton Circular Logic, UnLtd. February 2002 Dynamic Authorization Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html To view the entire list of current Internet-Drafts, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes the current practices for dynamically disconnecting and changing filters applicable to a user session. The protocol uses RADIUS messages to send the disconnect request, but unlike RADIUS, the NAS in this case acts as a server and listens on a UDP port for requests originating from a client. M. Chiba Expires July 2002 [Page 1] ^L Internet Draft Dynamic Disconnect February 2002 1.0 Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be prepared to interoperate with another implementation which does include the option. 1.1 Introduction The RADIUS protocol sends all the authorization information for a particular user in the Access-Accept packet and there are no further authorization exchanges between the NAS and the RADIUS server for the entire duration of the user session. To overcome this limitation, various vendors have implemented a reverse RADIUS protocol in which the NAS listens on a port for messages initiated from a client. These messages currently belong to two groups: 1) Disconnect messages, and 2) Change of Filters messages The disconnect messages cause a user session to be terminated immediately, whereas change of filter messages modify the applicable packet filters for the user session. The packet format consists of the fields: Code, Identifier, Length, Authenticator and the Attributes in the Type, Length and Value (TLV) formats. All the fields hold the same meaning as those described in RADIUS[1]. The Authenticator field is calculated as specified in [3] M. Chiba Expires July 2002 [Page 2] ^L Internet Draft Dynamic Disconnect February 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Authenticator | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Attributes ... +-+-+-+-+-+-+-+-+-+-+-+-+- 1.2 Current Practices This draft outlines the details for Disconnect Requests and Change of Filters Requests that are commonly implemented. 1.2.1 Protocol Port Information For either type of request (Disconnect, or Change of Filters), the UDP port 1700 is used as the destination port. For responses the source and destination ports are reversed. 1.2.2 Identification Attributes A number of attributes are used to uniquely identify a user session on the NAS and one, or more of these are present in either type of requests (Disconnect or, Change of Filters). The set of attributes includes the following: Username(1): This is the name of the user associated with the session Acct-Session-Id(44): This is derived from a RADIUS Accounting-Start Framed-IP-Address(8): This is the IP Address associated with the session Note:The numbers in parenthesis denote the attribute number in [1]. The ability to use all/some of the identifiers to map to unique/multiple session(s) is beyond the scope of this document. 1.2.3 Disconnect-Request (DR) The packet of disconnect is used to dynamically end a user session on a NAS. Current practices use the UPD port 1700 for sending requests. For responses the ports are reversed. The request message contains one or more of the identification attributes. M. Chiba Expires July 2002 [Page 3] ^L Internet Draft Dynamic Disconnect February 2002 ---------- Disconnect-Request ---------- | | <-------------------- | | | NAS | | Client | | | Disconnect-Response | | | | ---------------------> | | ---------- ---------- Codes used: 40 - Disconnect-Request 41 - Disconnect-ACK 42 - Disconnect-NAK A Disconnect Request is followed by a response of either, Disconnect-Ack if the NAS successfully disconnects the user, or a Disconnect-NAK if it was unable to disconnect the user. A Disconnect-Ack MAY contain the attribute Acct-Terminate-Cause(49) with the value set to 6 for Admin-Reset. 1.2.4 Change of Filters (CoF) The CoF request packets contain information for dynamically changing filters of a user's session. The filters can be of either ingress, or egress kind and are in addition to the identification attributes. The port used and packet format are the same as that for disconnect. The following is the attribute sent in a request: Filter-ID(11) - Indicates the name of a filter list to be applied for the session that maps to the identification attributes. ---------- CoF Request ---------- | | <-------------------- | | | NAS | | Client | | | CoF Response | | | | ---------------------> | | ---------- ---------- Codes used: 43 - CoF-Request 44 - CoF-ACK 45 - CoF-NAK A Change of Filter request is followed by a response of either, CoF-Ack if the NAS is able to successfully change the filters for the user's session and a CoF-NAK if it does not succeed. M. Chiba Expires July 2002 [Page 4] ^L Internet Draft Dynamic Disconnect February 2002 1.3 Security Considerations To prevent modification of the packets, a 16 byte Authenticator is calculated employing the same algorithm as the one used for Accounting-Requests[3]. To prevent replay attacks it is recommended that the Acct-Session-ID and Username combination be present in the disconnect requests. Further, it is also recommended to include the Event-Timestamp(55)[4] attribute to prevent replay attacks. The protocol, in addition, is susceptible to the same vulnerabilities as RADIUS and it is recommended to use IPSec to afford better security. 1.4 Example Traces of current Disconnect Requests Disconnect Request with Username: 0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....# 16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^.. 32: 6d63 6869 6261 Disconnect Request with Acct-Session-ID: 0: xxxx xxxx xxxx xxxx xxxx 2801 0018 ad0d .B..... ~.(..... 16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,. 32: 3930 3233 3435 3637 90234567 Disconnect Request with Framed-IP-Address: 0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(..... 16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ... 32: 0a00 0203 1.4 References [1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [2] Mitton, D., "Network Access Server Requirements: Extended RADIUS Practices", RFC 2882, July 2000. [3] Rigney, C., "RADIUS Accounting", RFC 2866 June 2000. [4] Rigney, C., Willats W., Calhoun P., "RADIUS Extensions", RFC 2869, June 2000 M. Chiba Expires July 2002 [Page 5] ^L Internet Draft Dynamic Disconnect February 2002 1.5 Copyright Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1.6 Acknowledgements Funding for the RFC Editor function is currently provided by the Internet Society. 1.7 Author's Address Murtaza Chiba Gopal Dommety Mark Eklund Cisco Systems, Inc. Cisco Systems, Inc. Cisco Systems, Inc. 170 West Tasman Dr. 170 West Tasman Dr. 170 West Tasman Dr. San Jose, CA 95134 San Jose, CA 95134 San Jose, CA 95134 Tel: (408) 525-7198 Tel: (408) 525-1404 Tel: (865) 671-6255 mchiba@cisco.com gdommety@cisco.com meklund@cisco.com David Mitton Circular Logic UnLtd. 733 Turnpike Street #154 North Andover, MA 01845 Phone: 978 683-1814 Email: david@mitton.com - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Mon Mar 4 20:50:19 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03652 for ; Mon, 4 Mar 2002 20:50:19 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g251QWq29521 for ietf-radius-outgoing; Mon, 4 Mar 2002 19:26:32 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Date: Mon, 4 Mar 2002 17:04:32 -0800 (PST) From: Bernard Aboba To: ietf-radius@portmasters.com Subject: (radius) Some issues with RFC 2869 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Bernard Aboba RFC 2869 has some corner conditions that have turned out to be a big headache. These occur when the encapsulated EAP Message does not agree with the RADIUS message within which it is encapsulated (Accept/Reject/Challenge). RFC 2865 is clear that a NAS makes its access decision based on the RADIUS message alone (Access Accept or Reject), *not* based on the contents of any enclosed attributes, including an EAP-Message attribute. This makes sense, since the NAS acts as a "passthrough" for EAP. However, this makes for some interesting corner conditions, because RFC 2869 allows the following packets to be sent by the RADIUS server: a. Access Accept/EAP-Message/EAP-Failure b. Access Reject/EAP-Message/EAP-Success c. Access Accept/EAP-Message/Notification d. Access Reject/EAP-Message/Notification e. Access Accept (no EAP Message) f. Access Reject (no EAP Message) g. Access Accept/EAP-Message/EAP-Failure, Reply-Message h. Access Accept/EAP-Message/EAP-Success, Reply-Message i. Access Reject/EAP-Message/EAP-Failure, Reply-Message j. Access Accept/EAP-Message/EAP-Success, Reply-Message k. Access Challenge/EAP-Message/EAP-Success l. Access Challenge/EAP-Message/EAP-Failure There are probably more corner conditions than this, but my fingers are getting tired :( a. Message a is a problem because the Accept says "grant access" while the Failure, if passed on to the EAP peer will make it think that authentication has failed. If there are alternate indications of success, one might argue that the peer will eventually figure it out. For media in which there are no such indications (IEEE 802 and 802.11 are examples), a timeout will result. b. Message b is a problem because the Reject says "no access" while the EAP-Success passed to the peer makes it think it is successful. If there are alternate indications of Failure on a given media, the peer may eventually figure things out. On IEEE 802.11 a Disassociate from the AP would put things right, as would an LCP-Terminate in PPP. On wired IEEE 802 there is no alternate indication of failure, so a timeout will result. c-d. These are an issue since the peer receives a displayable Notification, but no indication of Success/Failure. Alternate indications might help, but for media in which they don't exist, a timeout will result. e-f. Ditto, except no notification. g-j. These are a problem since it is not clear within RFC 2869 how a Reply-Message is to be handled within an EAP conversation. Some NAS implementations translate Reply-Mesage to an EAP-Notification, resulting in the NAS having *two* EAP messages to send to the peer. Some NAS implementations treat the Reply-Message as a terminal non-ACK'd message, in which case the subsequent EAP-Message attributes are never sent. Which interpretation is correct? If you're in the "translate to Notification" camp, then presumably the Notification has to be sent first, since the Success/Failure message terminates the conversation and therefore nothing can be sent after that. Note that the Reply-Message doesn't come with an Identifier field, so presumably the NAS has to make one up. But since the Success/Failure already has an Identifier field in it, what is the NAS/AP supposed to do, particularly if the Identifier field is incremented sequentially? The problems are obviously worse if the Reply-Message is sent in the middle of the conversation, so that a simple Identifier swap wouldn't work. k-l. These are problematic because an Access-Challenge indicates a continuing conversation, but an EAP-Success/EAP-Failure is a terminating message. Therefore the RADIUS Server will not receive a response to these messages -- but the NAS will neither have granted nor rejected access. OK. If you've gotten this far, hopefully you understand why these messages are a headache. Here are some possible ways to address the Reply-Message issue in RFC 2869bis: 1. On the Reply-Message processing issue, we could suggest that the right way to notify the EAP peer in an EAP conversation is to use EAP-Notification instead of Reply-Message, and that Reply-Message is a terminal message that is sent, and not translated to EAP-Motification. 2. Alternatively, we could specify that Reply Message is to be translated to EAP-Notification by an EAP capable NAS (what about one which isn't EAP capable?). Here are some approaches to addressing the issue of a mismatch between the RADIUS message (accept/reject) and the EAP-Message attribute: 1. "Dr., it hurts when I do this". This approach says: these corner conditions are difficult to handle for media in which there are no alternate failure/success indications, so that RFC 2869bis should state that RADIUS servers SHOULD NOT (MUST NOT?) send these messages. Since an RFC 2869bis compliant RADIUS-server can be assumed not to send these messages, the NAS can blithely decapsulate and send whatever is inside an EAP-Message attribute, if one is present, then act on the RADIUS message (Accept/Reject). In this approach, RFC 2869bis states that an Access-Challenge MUST NOT contain an EAP-Success/Failure message, and that if a Reply-Message needs to be sent, then this should be encapsulated in a packet with no EAP-Message attribute, adding an extra round-trip; the Reply-Message is translated to EAP-Notification, and an Access-Request/EAP-Message/Notification-Response is sent back to the RADIUS server, after which the EAP conversation continues. 2. "Mr. NAS will make it better". This approach says: the NAS should make sure these corner conditions will not occur by "manufacturing" EAP Success packets on receipt of an Access Accept, and "manufacturing" EAP Failure packets on receipt of an Access Reject. This handles cases a-f, but has some undesirable implications for cryptographically protected EAP. In proposals to cryptographically protect EAP (such as EAP TTLS or PEAP), it is desirable to have as much of the EAP conversation as possible be protected. The idea of these protocols is to create an encrypted channel, then complete the EAP conversation within that channel. That means that in theory the final Success/Failure message is sent down the encrypted channel. Since EAP Success/Failure messages are not ACK'd, such a message, if sent, must terminate the EAP conversation. This implies that they must be the last message sent, and so if the NAS is to know the result of the conversation, then they need to be sent within an Access Accept or Reject message. But if the "Mr. NAS will make it better" approach is taken, then the NAS will swallow the encrypted Success/Failure packet and replace it with a cleartext Success/Failure. This undermines the concept of protection, which is to be able to authenticate and encrypt each packet in the EAP conversation. So it seems to me that, to address these issues in an RFC 2869bis, we need to do one of two things: 1. If we adopt the "Dr., it hurts when I do this" approach, then we need to suggest changes to the 802.1X state machine to conform to a clarified RFC 2869bis. In this approach, we would presumably leave the EAP Success/Failure messages as they are in RFC 2284, forbid the bad messages, and add some text on how Reply-Message attributes are to be processed within an EAP conversation. 2. If we adopt the "Mr. NAS will make it better" approach, then we may need to introduce new ACK'd Success and Failure messages within EAP. Doing this will ensure a response to the success/failure indication, removing the need for "alternative indications" and ensuring that the encrypted Success/Failure indication gets through. - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Tue Mar 5 13:46:57 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23441 for ; Tue, 5 Mar 2002 13:46:53 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g25IPBj10479 for ietf-radius-outgoing; Tue, 5 Mar 2002 12:25:11 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Date: Tue, 5 Mar 2002 10:03:02 -0800 (PST) From: Bernard Aboba To: John Vollbrecht cc: ietf-radius@portmasters.com Subject: Re: (radius) Some issues with RFC 2869 In-Reply-To: <3C850080.1A453482@interlinknetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Bernard Aboba > but it can do this in most (all?) cases now - right? 802.11 does it with a self > generated EAP message, and others do it somehow now. I guess it would be > interesting to look through the PPP state diagram to see what is supposed to happen > if no success/failure is sent. IEEE 802 does not provide all the "alternate indications" that PPP does. RFC 2284 discusses how LCP-Terminate can be taken as an alternate indication of failure, and NCP as an alternate indication of success. IEEE 802.11 has an alternate failure indication (Disassociate), but no alternate success indication. For wired IEEE 802, "carrier loss" is the closest we come to an alternate failure indicator (most implementations don't use it this way), and there is no alternate success indicator. This is one reason why IEEE 802.1X chose the "Mr. NAS will make it better" approach. But today, NAS behavior is *not* consistent across media. > But if I send an Access Challenge, presumably the NAS would have to do something to > finish authentication. I guess it is not clear what it would do with EAP, but we > could spell it out. Remember, the NAS is acting as a passthrough device here. It sends EAP frames to the peer, and then takes the response and encapsulates it in a RADIUS Access-Request. If there is no response from the peer, it can't send an Access-Request on its own, since it is typically not aware of the contents of the EAP-Message that was sent. For example, based on RFC 2869 and 2284, it is not even clear that a NAS needs to understand the meaning of EAP Success and Failure when used with AAA, although 802.1X does appear to require this. The NAS could just rely on the AAA Accept/Reject to provide the information on what it is supposed to do. > > Unfortunately, the EAP/{encrypted/Success} is not ACK'd, so the peer will > > not reply. There is therefore no way to generate an Access-Request, and no > > vehicle for sending a subsequent EAP Success/Failure message. > > Yes, but if the encrypted success is sent in a EAP/REQ/encrpted type, the peer must > send a REPLY/encrypted type. Or am I missing something? If the encrypted message is an EAP-Success or EAP-Failure, then no reply is possible. RFC 2284 does not define an ACK'd Failure or Success message to encrypt and send down the channel. Are you suggesting that new Types be allocated to Success and Failure? If this were done, then an EAP-Request/Type=Success could be sent, followed by an EAP-Response/Type=Success, and similarly with Failure. This solves two problems. First, it eliminates the need for "alternate indications" which are problematic for media that don't provide them. Second, it enables the EAP conversation to be continued, and thus for EAP methods to be developed which can work regardless of media. The conversation would look like this: <--- Challenge/EAP-Message {EAP-Request/Type=Success} Request/EAP-Message (EAP-Response/Type=Success} ---> <--- Accept/EAP-Message/EAP-Success Here {} denotes encryption. This approach could even be made backward compatible in that the Success and Failure types could be NAK'd by implementations which don't support them. - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Tue Mar 12 22:30:20 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17318 for ; Tue, 12 Mar 2002 22:30:16 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g2D38E604147 for ietf-radius-outgoing; Tue, 12 Mar 2002 21:08:14 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f X-Sent: 13 Mar 2002 03:25:35 GMT Message-Id: <5.1.0.14.2.20020312222424.00a9e7e0@mail.attbi.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 12 Mar 2002 22:24:29 -0500 To: ietf-radius@portmasters.com From: David Mitton Subject: (radius) =?iso-8859-1?Q?CERT=AE_Advisory_CA-2002-06_Vulnerabilities_?= in Various Implementations of the RADIUS Protocol Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by linux2.portmasters.com id g2D38CH04145 Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: David Mitton Content-Transfer-Encoding: 8bit Some people may be interested in reviewing this (and the references) for applicability to their own systems - Dave. ---- CERTŪ Advisory CA-2002-06 Vulnerabilities in Various Implementations of the RADIUS Protocol Original release date: March 4, 2002 Last revised: -- Source: CERT/CC A complete revision history can be found at the end of this file. Systems Affected Systems running any of the following RADIUS implementations: · Ascend RADIUS versions 1.16 and prior · Cistron RADIUS versions 1.6.5 and prior · FreeRADIUS versions 0.3 and prior · GnuRADIUS versions 0.95 and prior · ICRADIUS versions 0.18.1 and prior · Livingston RADIUS versions 2.1 and earlier · RADIUS (previously known as Lucent RADIUS) versions 2.1 and prior · RADIUSClient versions 0.3.1 and prior · XTRADIUS 1.1-pre1 and prior · YARD RADIUS 1.0.19 and prior http://www.cert.org/advisories/CA-2002-06.html - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message.