From owner-ietf-radius@livingston.com Sat Jul 1 00:41:20 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 AAA04297 for ; Sat, 1 Jul 2000 00:41:20 -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 VAA25061; Fri, 30 Jun 2000 21:35:48 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id VAA24877 for ietf-radius-outgoing; Fri, 30 Jun 2000 21:36:32 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f From: Carl Rigney Date: Fri, 30 Jun 2000 21:35:25 -0700 (PDT) Message-Id: <200007010435.VAA03416@oldserver.livingston.com> To: ietf-radius@livingston.com Subject: Re: (radius) RE: Radius MP attributes? Cc: ietf-ppp@merit.edu Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney The two RADIUS accounting attributes for use with Multilink PPP are Acct-Multi-Session-Id and Acct-Link-Count, documented in draft-ietf-radius-accounting-v2-05.txt (and soon RFC 2866). -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jul 4 13:24:37 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29276 for ; Tue, 4 Jul 2000 13:24:36 -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 KAA19365; Tue, 4 Jul 2000 10:18:13 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id KAA10627 for ietf-radius-outgoing; Tue, 4 Jul 2000 10:13:46 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f From: Kaushik Narayan Message-Id: <200007041710.WAA02385@megha.cisco.com> Subject: (radius) Proposed draft for Radius Security extensions using Kerberos v5 To: ietf-radius@livingston.com Date: Tue, 4 Jul 2000 22:40:17 +0530 (IST) Cc: kaushik@cisco.com (Kaushik Narayan) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="%--multipart-mixed-boundary-2.18259.962730617--%" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Kaushik Narayan --%--multipart-mixed-boundary-2.18259.962730617--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit hi all, I am proposing security extensions to the Radius protocol using Kerberos v5. Kerberos network authentication would be used to provide dynamic authentication for Radius . Kerberos would also provide a framework for encrypting sensitive Radius attributes. I am attaching the proposed draft. Please review it and send your feedback. thanks, kaushik! --%--multipart-mixed-boundary-2.18259.962730617--% Content-Type: text/plain Content-Description: ascii text Content-Disposition: attachment; filename="draft-kaushik-radius-sec-ext-01.txt" Content-Transfer-Encoding: 7bit Network Working Group Kaushik Narayan Category :Standards Track HCL Technologies Ltd. Updates :RFC 2138 June 2000 Radius Security Extensions using Kerberos v5 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The distribution of this memo is unlimited. It is filed as , and expires December 22, 2000. Please send comments to the author (kaushik@cisco.com). Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a Authentication and Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC2138 and RFC2139. Kaushik expires December 2000 [Page 1] Internet-Draft Radius Security Extensions using Kerberos v5 June 2000 Table of Contents 1.0 Introduction ................................................. 2 2.0 Need for Radius encryption and role of Kerberos .............. 2 3.0 Kerberized Radius operation .................................. 3 4.0 Packet Format ................................................ 4 5.0 Packet Types ................................................. 5 6.0 Attributes ................................................... 5 6.1 Kerberos-Data ................................................ 5 6.2 Kerberos-Crypt ............................................... 6 7.0 Implementation using GSSAPI v2 ............................... 7 8.0 IANA Considerations .......................................... 8 9.0 Security Considerations ...................................... 8 10.0 References ................................................. 9 11.0 Author's Address ............................................ 9 12.0 Full Copyright Statement .................................... 9 1.0 Introduction This memo describes the changes required to the Remote Authentication Dial In User Service(RADIUS) protocol to integrate it with the Kerberos Network Authentication service (V5). The memo is an extension to the basic Radius protocol and the approach has been to avoid making any major changes the Radius protocol. It also provides full backward compatibility with the current Radius protocol. This memo describes the use of Kerberos authentication and encryption mechanism in the Radius protocol using the additional Kerberos-Data and Kerberos-Crypt attributes. 2.0 Need for Radius encryption and role of Kerberos V5 Remote Authentication Dial In User Service (RADIUS) provides basic Authentication, Authorization and Accounting(AAA) services to a Network Access Server(NAS). The NAS uses the Radius protocol to communicate with a Radius server which has the AAA user/policy information. Radius is a UDP based protocol with a very elementary security framework which includes a 128 bit authenticator and static encryption of the password field in the Radius header. This level of security just isn't enough and is major drawback with the current Radius protocol. Essentially there are a couple of problems, firstly since most of the Radius packet is transmitted in cleartext it is vulnerable to attack from a third party. Secondly the radius password encryption uses a static encryption mechanism using a preconfigured key which makes the password vulnerable to attack by packet interception. Kerberos V5 provides a network authentication and encryption service which can easily integrated seamlessly with other protocols. Radius already provides a basic framework for encryption, it's just a matter of extending the framework to fit Kerberos. Kaushik expires December 2000 [Page 2] Internet-Draft Radius Security Extensions using Kerberos v5 June 2000 Note: The original operation and attributes defined in the Radius protocol(RFC2138) are referred as normal Radius operation and normal Radius attributes in this memo. 3.0 Kerberized Radius operation The Kerberized Radius operation basically adds the Kerberos authentication process to the normal Radius operation. All the Radius packets types would be the same, just additionally they would carry the Kerberos-Data and Kerberos-Crypt attributes. Note: Currently there is no way a NAS cannot determine whether a Radius server is Kerberized or not. If a NAS sends a Kerberized Radius request to a Radius server which doesn't support Kerberos, the server would silently discard the Radius packet since Kerberos-Data and Kerberos-Crypt would be invalid Radius codes for the server. The NAS cannot determine whether the request has timed out because of a network error or because the server doesn't support Kerberos. Dynamic discovery of Radius servers supporting Kerberos is out of the scope of this memo. Implementation have to take care that clients are made aware whether Radius servers support Kerberos via some static configuration. This section we take a look at a typical operation and the interaction of the Kerberized Radius peers when the NAS receives a authentication request. This operation would remain the same for an accounting request as well. The "radius" keyword would be used in the Kerberos service principal. The Kerberos principal for a Radius server called servername would be radius/servername.anywhere.com@ANYWHERE.COM. The NAS would first send out a KRB_TGS_REQ to the Ticket Granting Service(TGS) to obtain the credentials for the Radius server. The TGS would reply back with a KRB_TGS_REP which would contain a session key and a Kerberos ticket. In case the credentials are cached on the NAS the KRB_TGS_REQ won't be sent but the credentials would be retrived from the cache. It is required that a valid Ticket Granting Ticket(TGT) has been cached on the NAS before sending a request to the Ticket Granting Service(TGS). The NAS would first create a KRB_AP_REQ message using the credentials just obtained. The KRB_AP_REQ message will have MUTUAL-REQUIRED and USE_SECRET_KEY set in its ap-options field to turn on the mutual authentication mode and specify to the server to use it's secret key to decrypt the Kerberos ticket. The NAS would first encrypt the normal Radius attributes for a Access Request using the session key. The encryption is an optional phase and the NAS can decide not encrypt the attributes in case it wants to use Kerberos only for authentication. The NAS needs to set the Kerberos-Crypt attribute to 1 or 0 based on whether it wants to use encryption or not. The NAS would set the Kerberos-Data attribute with the KRB_AP_REQ message and create the Access-Request packet which would be sent to the Radius Server. Kaushik expires December 2000 [Page 3] Internet-Draft Radius Security Extensions using Kerberos v5 June 2000 The Kerberized Radius server on reception of the Access-Request would get the secret key for the service principal from the Kerberos service tab file. The server would then get the Kerberos-Data attribute and retrieve the KRB_AP_REQ message, it would then decrypt the Kerberos Ticket using it's secret key and extract the Kerberos session key. This session key would be used to extract the Kerberos authenticator and authenticate the NAS. In case of an any error in the Kerberos authentication, an Access-Reject with Kerberos-Data attribute set with KRB_ERROR message would be sent back to the NAS. In case the Kerberos authentication succeeds the Kerberos-Crypt attribute is retrieved to check whether the normal Radius attributes are encrypted and these attributes are retrived and decrypted using the session key in case the Kerberos-Crypt is set to 1. The Radius protocol would then resort to it's normal processing to authenticate the User-Name, User-Password from it's database of users. The Radius server based on the Radius processing can respond with Access-Accept, Accept-Reject or a Access-Challange. In any case the Radius server would form a KRB_AP_RES message which would contain the Kerberos Response Authenticator. The Kerberos-Data attribute would be set with the contents of the KRB_AP_RES message. The server can also set the value of the Kerberos-Crypt attribute in case it wants to encrypt any of the normal Radius attributes to be returned to the NAS and these attributes would be encrypted using the Kerberos session key. The Kerberos-Crypt attribute would not be set in case no normal Radius attributes have to returned in the reply. The Radius server response is ready and is sent back to the NAS. The NAS would receive the reply from the Radius server and retrieve the Kerberos-Data attribute, if this attribute contains a KRB_ERROR message it would indicate that the Radius server had encountered an error in the Kerberos authentication and the NAS would throw a Login error to the user. In case the Kerberos-Data attribute contains a KRB_AP_RES message, the NAS would decrypt the message and authenticate the server. In case this authentication fails the NAS would send a Login error to the user even if a Access-Accept or Access-Challange has been sent by the Radius Server. The NAS would then retrieve the normal Radius attributes (if any) and decrypt them if the Kerberos-Crypt attribute is set to 1. At this point the NAS and Radius server have mutually authenticated each other, the NAS would destroy the current Kerberos context and it would create a new Kerberos context for any further interaction with the Radius server. This means that there would a new Kerberos context created for every Radius request and reply. Kaushik expires December 2000 [Page 4] Internet-Draft Radius Security Extensions using Kerberos v5 June 2000 4.0 Packet Format The Packet Format is exactly the same as defined in RFC2138 and RFC2139. 5.0 Packet Types The Packet Types are exactly the same as defined in RFC2138 and RFC2139. 6.0 Attributes The format and types of Attributes are the same as defined in RFC2138 Additional Radius attributes Kerberos-Data and Kerberos-Crypt would be used to carry the Kerberos messages. The Radius Attribute Type values are specified in the most recent "Assigned Numbers" RFC [5]. Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation specific use, and values 241-255 are reserved and should not be used. This memo uses the following values: 92 Kerberos-Data 93 Kerberos-Crypt 6.1 Kerberos-Data Description The Kerberos-Data attribute would contain the KRB_AP_REQ request which would be sent from the NAS to server and KRB_AP_RES or KRB_ERROR response which would be sent back from the Radius server. In case the length KRB_AP_REQ,KRB_AP_RES or KRB_ERROR messages exceed 255 octets, then these messages have to be split up into 255 octet blocks. Each 255 octet block would be carried in a Kerberos-Data attribute and multiple instances of the Kerberos-Data attribute would be present in the Radius packet. The Request Kerberos-Data attribute contains the Kerberos authenticator for the NAS authentication and also the session key used for encrypting the normal Radius attribute values. The Response Kerberos-Data contains the Kerberos authenticator sent back by the Radius Server for mutual authentication. Refer to RFC1510 for fields and all the authentication checks made on the Kerberos Request and Response Authenticator. A summary of the Kerberos-Data Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Kaushik expires December 2000 [Page 5] Internet-Draft Radius Security Extensions using Kerberos v5 June 2000 Type 92 for Kerberos-Data. Length Length of the KRB_AP_REQ or KRB_AP_REQ message . String KRB_AP_REQ or KRB_AP_REQ message. 6.2 Kerberos-Crypt Description The Kerberos-Crypt attribute is used to indicate that the current set of Radius attributes sent along with the Kerberized Radius PDUs have been encrypted with the Kerberos session key. Certain set of Kerberized Radius interactions would like to use the basic Kerberos authentication without actually encrypting the normal Radius attributes. In such cases this attribute can be set to 0 indicating that the normal Radius attributes in the Kerberized Radius PDU are in cleartext. Note: The Kerberos-Data and Kerberos-Crypt attributes are not encrypted and these attributes are sent in cleartext. The Kerberos-Crypt attribute is applicable to the normal Radius attributes only. A summary of the Kerberos-Crypt Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Value ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 93 for Kerberos-Crypt. Length 6 Value 1 - Encrypted Radius attributes 0 - Cleartext Radius attributes Kaushik expires December 2000 [Page 6] Internet-Draft Radius Security Extensions using Kerberos v5 June 2000 7.0 Implementation using GSSAPI v2 This section we take a look at how the Kerberized Radius extensions can be implemented on the client and server using the Generic Security Service Application Program Interface, Version 2 (RFC2078) for Kerberos. The NAS would first call GSS_Init_sec_context to initialize the Kerberos session context. It will check the local cache for an existing ticket for the radius service principal, if it is not found then it would request credentials from the Ticket Granting Service(TGS). The credentials obtained are then used to construct a KRB_AP_REQ. The Kerberized NAS should call the GSS_Init_sec_context with the mutual_req_flag (mutual-authentication) and sequence_req_flag set to TRUE and mech_type should be set to NULL to indicate default Mechanism type. The GSS_Init_sec_context would return the KRB_AP_REQ message in an output token and return major_status as GSS_S_CONTINUE_NEEDED in case the call doesn't encounter any errors. The NAS can use GSS_Wrap method to encrypt the normal Radius attributes with the Kerberos session key. In case the GSS_Init_sec_context returns an error, then the NAS returns an error to the user. Note: The GSSAPI v2 implementation should support Per-Message Protection During Context Establishment. The GSS_Init_sec_context call would return prot_ready_state set to TRUE in case the GSSAPI v2 implementation supports this feature. This would allow the use of GSS_Wrap to encrypt the normal Radius attributes even before receiving a GSS_S_COMPLETE status from GSS_Init_sec_context call. In case this feature is not supported by the Kerberos GSSAPI v2 implementation then only the Kerberos authentication without any encryption can be used (Kerberos-Crypt = 0). The Radius server on reception of a Kerberized Radius request would first call GSS_Acquire_Cred to acquire the secret key for the Radius server principal. It would then call GSS_Accept_sec_context and pass it the token received in the Kerberos-Data attribute as input token parameter and the secret key obtained in the acceptor_cred_handle input parameter. The GSS_Accept_sec_context would authenticate the Kerberized NAS and extract the Kerberos session key. It would return the KRB_AP_RES message in the output_token and status set to GSS_S_COMPLETE on successful completion, any other return code would indicate an error and the server would send a Kerberos_Access_Reject with Kerberos-Data attribute set to KRB_ERROR message input_token. The Kerberos-Crypt attribute would be checked for encryption and in case it is true, the GSS_Unwrap is used to decrypt the normal Radius attributes After this the normal Radius operation takes over and a Radius reply is created. Any normal Radius attributes generated from the Radius response to be returned to the NAS can be encrypted using GSS_Wrap and the Kerberos-Crypt is set to 0 or 1 accordingly, the Kerberos-Data attribute is set with the Response Kerberos authenticator. Kaushik expires December 2000 [Page 7] Internet-Draft Radius Security Extensions using Kerberos v5 June 2000 The NAS would receive the reply from the server and pass the context token received in the Kerberos-Data attribute to the GSS_Init_sec_context method. The GSS_Init_sec_context method check the data included in the token and return an error in case of a KRB_ERROR message in the token. If the context token contains a KRB_AP_RES then the GSS_Init_sec_context would process the token in order to achieve mutual authentication from the NAS's viewpoint and returns the GSS_S_COMPLETE status to indicate that the mutual authentication is successful. After this the normal Radius operation takes over and processes the received Radius reply. In case the GSS_Init_sec_context method returns an error during authentication of the context token, the Kerberized Radius operation fails and an error would be returned to the user. This memo just looks at the major GSSAPI v2 interfaces that would be used to implement the Radius extensions. The other helper interfaces that would also be used are not discussed in this memo, more details of all the GSSAPI v2 interfaces can be found in RFC2078. 8.0 IANA Considerations The Packet Type Codes, Attribute Types, and Attribute Values defined in this document are registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS name spaces. 9.0 Security Considerations This entire document deals with security considerations related to the Radius protocol. 10.0 References [RFC-1964]: Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, January 1997 [RFC-2078]: Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997 [RFC-1509]: Wray, J., "Generic Security Service Application Program Interface: C-bindings", RFC 1509, September 1993. [RFC-1510]: Kohl, J., and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993. [RFC-2138]: C. Rigney, A. Rubens, W. Simpson, and S. Willens "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [RFC-2139]: C. Rigney "RADIUS Accounting", RFC 2139, April 1997. Kaushik expires December 2000 [Page 8] Internet-Draft Radius Security Extensions using Kerberos v5 June 2000 11.0 Author's Address Kaushik Narayan HCL Technologies Ltd. Cisco Offshore Development Centre, 49-50, Nelson Manickam Road, Chennai, Tamilnadu 600 029 India Phone: +091-44-3741939 EMail: kaushik@cisco.com 12.0 Full Copyright Statement 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." Kaushik expires December 2000 [Page 9] --%--multipart-mixed-boundary-2.18259.962730617--%-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 01:50:08 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10972 for ; Wed, 5 Jul 2000 01:50:07 -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 WAA23023; Tue, 4 Jul 2000 22:44:32 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id WAA20333 for ietf-radius-outgoing; Tue, 4 Jul 2000 22:45:48 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f Message-ID: <3962D1C2.A74B0396@cdotb.ernet.in> Date: Wed, 05 Jul 2000 11:12:18 +0500 From: gurmeet X-Mailer: Mozilla 4.5 [en] (X11; I; OSF1 V4.0 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Kaushik Narayan CC: ietf-radius@livingston.com Subject: Re: (radius) Proposed draft for Radius Security extensions using Kerberos v5 References: <200007041710.WAA02385@megha.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: gurmeet Content-Transfer-Encoding: 7bit Hi, Line 122 of the draft reads Note: Currently there is no way a NAS cannot determine whether a Radius server is Kerberized or not. I think what is meant is the opposite. So kaushik can you modify it. Secondly , as far as i think both the NAS and the radius server generally sit on the ISP Lan only , so is there a definite requirement for enhancing the security of the radius protocol. with regards, Gurmeet Singh - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 01:59:28 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10998 for ; Wed, 5 Jul 2000 01:59:27 -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 WAA23209; Tue, 4 Jul 2000 22:53:55 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id WAA20517 for ietf-radius-outgoing; Tue, 4 Jul 2000 22:57:36 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f Message-Id: <4.2.2.20000705155234.00b5e430@kid> X-Sender: ira@kid X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 05 Jul 2000 15:56:44 +1000 To: ietf-radius@livingston.com From: Imran Ahmad Subject: (radius) Radius client for Web Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Imran Ahmad Hi All; I am not sure weather this place is right for this type of question. I want to pass authentication from Web to Radius server. I am using Apache as the webserver and Steelbelted Radius Server. Is there any body using some client for Radius server. I will appreciate for your help. Regards; - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 05:42:49 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19107 for ; Wed, 5 Jul 2000 05:42: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 CAA24613; Wed, 5 Jul 2000 02:37:06 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id CAA24454 for ietf-radius-outgoing; Wed, 5 Jul 2000 02:39:35 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f From: Kaushik Narayan Message-Id: <200007050933.PAA23986@megha.cisco.com> Subject: Re: (radius) Proposed draft for Radius Security extensions using To: gurmeet@cdotb.ernet.in Date: Wed, 5 Jul 2000 15:03:56 +0530 (IST) Cc: kaushik@cisco.com (Kaushik Narayan), ietf-radius@livingston.com In-Reply-To: <3962D1C2.A74B0396@cdotb.ernet.in> from "gurmeet" at Jul 05, 2000 11:12:18 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Kaushik Narayan Content-Transfer-Encoding: 7bit gurmeet, hi! Well all Radius requests are initiated by the NAS. The NAS needs to be aware of the type of the Radius server (whether Kerberized or not) before it sends out a Kerberized Radius request. A Radius server would only respond to a requeut and it need not be aware of the nature of the client. A Kerberized Radius server would send the Kerberos information in the reply if it recieves a Kerberized Radius request and it would send a normal Radius reply on the reciept of a normal Radius request. A normal Radius server would just ignore the Kerberos attributes in a Kerberized radius request and treat it as a normal Radius request. It would be able to service the Radius request if the Radius data is in cleartext and would send back an Access-Reject if the data is encrypted. Thus it's really the NAS which has to know the nature of the Radius server. There has been a growing demand for secure AAA protocols . The Radius security extensions proposed provide a mechanism to optionally enable both Kerberos authentication and/or encryption. This feature can be turned for a set of sensitive users and plain vannila radius can be used for another set of users. kaushik! > > Hi, > > Line 122 of the draft reads > > Note: Currently there is no way a NAS cannot determine whether a > Radius server is Kerberized or not. > > I think what is meant is the opposite. So kaushik can you modify it. > > Secondly , as far as i think both the NAS and the radius server generally > sit on the ISP Lan only , so is there a definite requirement for enhancing the > security of the radius protocol. > > with regards, > > Gurmeet Singh > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 13:31:53 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12502 for ; Wed, 5 Jul 2000 13:31: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 KAA29644; Wed, 5 Jul 2000 10:26:07 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id KAA10559 for ietf-radius-outgoing; Wed, 5 Jul 2000 10:21:26 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f Date: Wed, 5 Jul 2000 10:20:23 -0700 (PDT) From: "pcalhoun@eng.sun.com" Subject: (radius) RADIUS Vendor Specific Attributes To: diameter@diameter.org, ietf-radius@livingston.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, First, sorry for the cross post, but I believe that this e-mail needs to be sent to both lists. I am in the process of updating the DIAMETER implementation guidelines, and had a question for the mailing list subscribers. The document contains a section that discusses how one implements a RADIUS/DIAMETER protocol gateway. However, one area that will be very problematic is vendor specific attributes. RFC 2138 contains a suggested VSA format, but this format is a SHOULD, and it is well known that many vendors have not followed this format. I would like to add an appendix to the document that describes the Vendor ID, and the related format. This would be useful for protocol gateways that handle vendor specific attributes. The question I have for the list is whether people believe that such an appendix would be useful. If so, if you work for a manufacturer, and would be interested in sending me your Vendor ID and the VSA format, that would be very useful. BTW, I am only interested in VSA formats that derive from the suggested format in RFC 2138, so if you have more than a single octet attribute ID space, this e-mail is for you. The IETF deadline is next Friday, so having it by next Wednesday (7/12) would be most appreciated. Thanks, PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 16:07:05 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15882 for ; Wed, 5 Jul 2000 16:07:04 -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 NAA02430; Wed, 5 Jul 2000 13:01:21 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id MAA22676 for ietf-radius-outgoing; Wed, 5 Jul 2000 12:59:51 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f From: aboba@internaut.com To: Subject: (radius) Definition of Framed MTU attribute? Date: Wed, 5 Jul 2000 12:58:25 -0700 Message-ID: <000301bfe6bb$6236e1e0$268939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <200007050933.PAA23986@megha.cisco.com> Importance: Normal Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: aboba@internaut.com Content-Transfer-Encoding: 7bit A question has arisen about the definition of the Framed-MTU attribute. draft-ietf-radius-radius-v2-06.txt says: "This Attribute indicates the Maximum Transmission Unit to be configured for the user, when it is not negotiated by some other means (such as PPP). It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that value, but the server is not required to honor the hint." The question is whether the Framed-MTU size refers to the maximum sized IP packet that may be sent, or the maximum size of the packet with framing. For example, for Ethernet the maximum frame size is 1518 octets, but this corresponds to an IP packet size of 1500 (1518 minus 6 octets for source, 6 for dest, 2 for Ethertype and 4 for the FCS). - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 19:56:55 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18799 for ; Wed, 5 Jul 2000 19:56:55 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id QAA06128; Wed, 5 Jul 2000 16:51:17 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id QAA06386 for ietf-radius-outgoing; Wed, 5 Jul 2000 16:51:54 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f Date: Thu, 6 Jul 2000 01:51:25 +0200 (CEST) From: Milos Prodanovic To: Imran Ahmad cc: ietf-radius@livingston.com Subject: Re: (radius) Radius client for Web In-Reply-To: <4.2.2.20000705155234.00b5e430@kid> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Milos Prodanovic Hello I've wrote mod_radius_auth for apache, recently. For more details you can look at www.freshmeat.net or directly from www.verat.net/~awl Regards Milos On Wed, 5 Jul 2000, Imran Ahmad wrote: > Hi All; > I am not sure weather this place is right for this type of question. I want > to pass authentication from Web to Radius server. I am using Apache as the > webserver and Steelbelted Radius Server. Is there any body using some > client for Radius server. > I will appreciate for your help. > > Regards; > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 20:44:17 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19724 for ; Wed, 5 Jul 2000 20:44:17 -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 RAA06878; Wed, 5 Jul 2000 17:38:41 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id RAA08949 for ietf-radius-outgoing; Wed, 5 Jul 2000 17:42:27 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f Message-Id: <200007060006.RAA22081@boreas.isi.edu> To: IETF-Announce: ; Subject: (radius) RFC 2869 on RADIUS Extensions Cc: rfc-ed@isi.edu, ietf-radius@livingston.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 05 Jul 2000 17:06:41 -0700 From: RFC Editor Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2869 Title: RADIUS Extensions Author(s): C. Rigney, W. Willats, P. Calhoun Status: Informational Date: June 2000 Mailbox: cdr@livingston.com, ward@cyno.com, pcalhoun@eng.sun.com Pages: 47 Characters: 96854 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-radius-ext-07.txt URL: ftp://ftp.isi.edu/in-notes/rfc2869.txt This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 [1] and RFC 2866 [2]. This document is a product of the Remote Authentication Dial-In User Service Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000705170430.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2869 --OtherAccess Content-Type: Message/External-body; name="rfc2869.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000705170430.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 20:44:23 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19736 for ; Wed, 5 Jul 2000 20:44: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 RAA06891; Wed, 5 Jul 2000 17:38:49 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id RAA08883 for ietf-radius-outgoing; Wed, 5 Jul 2000 17:42:22 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f Message-Id: <200007052353.QAA19736@boreas.isi.edu> To: IETF-Announce: ; Subject: (radius) RFC 2865 on RADIUS Cc: rfc-ed@isi.edu, ietf-radius@livingston.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 05 Jul 2000 16:53:05 -0700 From: RFC Editor Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2865 Title: Remote Authentication Dial In User Service (RADIUS) Author(s): C. Rigney, S. Willens, A. Rubens, W. Simpson Status: Standards Track Date: June 2000 Mailbox: cdr@livingston.com, acr@merit.edu, wsimpson@greendragon.com, steve@livingston.com Pages: 76 Characters: 146456 Obsoletes: 2138 I-D Tag: draft-ietf-radius-radius-v2-06.txt URL: ftp://ftp.isi.edu/in-notes/rfc2865.txt This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. This document is a product of the Remote Authentication Dial-In User Service Working Group of the IETF. This is now a Draft Standard Protocol This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000705164957.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2865 --OtherAccess Content-Type: Message/External-body; name="rfc2865.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000705164957.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 20:44:27 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19747 for ; Wed, 5 Jul 2000 20:44:26 -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 RAA06896; Wed, 5 Jul 2000 17:38:51 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id RAA08915 for ietf-radius-outgoing; Wed, 5 Jul 2000 17:42:25 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f Message-Id: <200007060000.RAA20807@boreas.isi.edu> To: IETF-Announce: ; Subject: (radius) RFC 2867 on RADIUS Tunnel Accounting Support Cc: rfc-ed@isi.edu, ietf-radius@livingston.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 05 Jul 2000 17:00:53 -0700 From: RFC Editor Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2867 Title: RADIUS Accounting Modifications for Tunnel Protocol Support Author(s): G. Zorn, B. Aboba, D. Mitton Status: Informational Date: June 2000 Mailbox: gwz@cisco.com, dmitton@nortelnetworks.com, aboba@internaut.com Pages: 11 Characters: 19062 Updates: 2866 I-D Tag: draft-ietf-radius-tunnel-acct-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2867.txt This document defines new RADIUS accounting Attributes and new values for the existing Acct-Status-Type Attribute [1] designed to support the provision of compulsory tunneling in dial-up networks. This document is a product of the Remote Authentication Dial-In User Service Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000705165701.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2867 --OtherAccess Content-Type: Message/External-body; name="rfc2867.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000705165701.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 20:44:28 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19757 for ; Wed, 5 Jul 2000 20:44:28 -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 RAA06906; Wed, 5 Jul 2000 17:38:54 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id RAA08933 for ietf-radius-outgoing; Wed, 5 Jul 2000 17:42:26 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f Message-Id: <200007060003.RAA21027@boreas.isi.edu> To: IETF-Announce: ; Subject: (radius) RFC 2868 on RADIUS Tunnel Authentication Attributes Cc: rfc-ed@isi.edu, ietf-radius@livingston.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 05 Jul 2000 17:03:36 -0700 From: RFC Editor Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2868 Title: RADIUS Attributes for Tunnel Protocol Support Author(s): G. Zorn, D. Leifer, A. Rubens, J. Shriver, M. Holdrege, I. Goyret Status: Informational Date: June 2000 Mailbox: gwz@cisco.com, leifer@del.com, John.Shriver@intel.com, acr@del.com, matt@ipverse.com, igoyret@lucent.com Pages: 20 Characters: 42609 Updates: 2865 I-D Tag: draft-ietf-radius-tunnel-auth-09.txt URL: ftp://ftp.isi.edu/in-notes/rfc2868.txt This document defines a set of RADIUS attributes designed to support the provision of compulsory tunneling in dial-up networks. This document is a product of the Remote Authentication Dial-In User Service Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000705170123.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2868 --OtherAccess Content-Type: Message/External-body; name="rfc2868.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000705170123.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 20:44:43 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19767 for ; Wed, 5 Jul 2000 20:44:42 -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 RAA06980; Wed, 5 Jul 2000 17:39:06 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id RAA08899 for ietf-radius-outgoing; Wed, 5 Jul 2000 17:42:23 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f Message-Id: <200007052356.QAA20176@boreas.isi.edu> To: IETF-Announce: ; Subject: (radius) RFC 2866 on RADIUS Accounting Cc: rfc-ed@isi.edu, ietf-radius@livingston.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 05 Jul 2000 16:56:05 -0700 From: RFC Editor Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: RFC Editor --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2866 Title: RADIUS Accounting Author(s): C. Rigney Status: Informational Date: June 2000 Mailbox: cdr@livingston.com Pages: 28 Characters: 51135 Obsoletes: 2139 I-D Tag: draft-ietf-radius-accounting-v2-05.txt URL: ftp://ftp.isi.edu/in-notes/rfc2866.txt This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This document is a product of the Remote Authentication Dial-In User Service Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000705165407.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2866 --OtherAccess Content-Type: Message/External-body; name="rfc2866.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000705165407.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jul 5 21:33:32 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21354 for ; Wed, 5 Jul 2000 21:33:31 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id SAA08472; Wed, 5 Jul 2000 18:27:56 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id SAA11127 for ietf-radius-outgoing; Wed, 5 Jul 2000 18:30:05 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ietf-radius@livingston.com Subject: (radius) rfcs Message-Id: Date: Wed, 05 Jul 2000 18:30:03 -0700 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit as you may have noticed, all the drafts are now rfcs, and rv2 is draft. congratulations! this concludes the work of this wg. thank you all! randy - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jul 6 12:39:16 2000 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20471 for ; Thu, 6 Jul 2000 12:39:16 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.9.3/8.9.3) with ESMTP id IAA16495; Thu, 6 Jul 2000 08:54:09 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.9.3/8.9.3/1.0) id IAA04981 for ietf-radius-outgoing; Thu, 6 Jul 2000 08:57:00 -0700 (PDT) X-Authentication-Warning: server.livingston.com: majordom set sender to owner-ietf-radius@livingston.com using -f Message-Id: <4.2.2.20000706115041.00e0f280@ZBL6C008.corpeast.baynetworks.com> X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 06 Jul 2000 11:53:39 -0400 To: Randy Bush , ietf-radius@livingston.com From: "David Mitton" Subject: Re: (radius) rfcs 2809 too. In-Reply-To: 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" gee, Some how I never received the announcement for RFC 2809, Compulsory Tunneling via RADIUS, which evidently happened a while back. But it's already on the WG page. - Dave. At 06:30 PM 7/5/00 -0700, Randy Bush wrote: >as you may have noticed, all the drafts are now rfcs, and rv2 is draft. >congratulations! > >this concludes the work of this wg. thank you all! > >randy >- >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 ServiceWare, IP Mobility 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.