0blivion nº1:(RAAP.txt):15/03/2000 << Back To 0blivion nº 1

<< Prev file: NT-RAS.txt

Next file: SET.txt >>

+------------------------------------------------------+ ▌ Oblivion Underground Magazine - Issue 1 - 15/03/2000 ▌ ▌ Remote Access Authentication Protocols by Slider ▌ ▌ E-Mail : SlideR_100@hotmail.com ▌ +------------------------------------------------------+ REMOTE ACCESS AUTHENTICATION PROTOCOLS Session Start: Fri Mar 13 18:15:45 2000 * Logging #xhackx to '#xhackx.log' <SNIP> <18:48>* Slider is off out on the PISS!!!!!! <18:48><phill> Heh <18:48><slider> Laters all, im going to pull <SNIP> Session Close: Fri Mar 13 19:16:36 2000 And that was my deep meaningful night out on the town, that led to this being compiled. Remote dial-in to the corporate intranet and to the Internet has made the remote access server a very vital part of today's internetworking services. More and more mobile users are requiring access not only to central-site resources, but to information sources on the Internet. The widespread use of the Internet and the corporate intranet has fueled the growth of remote access services and devices. There is an increasing demand for simplified connection to corporate network resources from mobile computing devices such as a notebook computer, or a palmtop device for e-mail access. The emergence of remote access has caused significant development work in the area of security. The AAA (triple A) security model has evolved in the industry to address the issues of remote access security. Authentication, authorization and accounting answers the questions who, what, and when respectively. A brief description of each of the three As in the AAA security model is listed below: Authentication This is the action of determining who a user (or entity) is. Authentication can take many forms. Traditional authentication utilizes a name and a fixed password. Most computers work this way, However, fixed passwords have limitations, mainly in the area of security. Many modern authentication mechanisms utilize one-time passwords or a challenge-response query. Authentication generally takes place when the user first logs in to a machine or requests a service of it. Session Start: Sat Mar 14 02:31:45 2000 * Logging #xhackx to '#xhackx.log' <02:34><slider> Rigth i am completley hammerd on Stela and hve pullde this rather fit brid... Im off tooo give hre a dman good raggin up the arss. Session Close: Sat Mar 14 02:35:21 2000 Authorization This is the action of determining what a user is allowed to do. Generally authentication precedes authorization, but again, this is not required. An authorization request may indicate that the user is not authenticated. (we don't know who they are.) In this case it is up to the authorization agent to determine if an unauthenticated user is allowed the services in question. In current remote authentication protocols authorization does not merely provide yes or no answers, but it may also customize the service for the particular user. Accounting This is typically the third action after authentication and authorization. But again, neither authentication or authorization are required. Accounting is the action of recording what a user is doing, and/or has done. In the distributed client/server security database model, a number of communications servers, or clients, authenticate a dial-in user's identity through a single, central database, or authentication server. The authentication server stores all information about users, their passwords and access privileges. Distributed security provides a central location for authentication data that is more secure than scattering the user information on different devices throughout a network. A single authentication server can support hundreds of communications servers, serving up to tens of thousand of users. Communications servers can access an authentication server locally or remotely over WAN connections. Several remote access vendors and the Internet Engineering Task Force (IETF) have been in the forefront of this remote access security effort, and the means whereby such security measures are standardized. Remote Authentication Dial In User Service (RADIUS) and Terminal Access Controller Access Control System (TACACS) are two such cooperative ventures that have evolved out of the Internet standardizing body and remote access vendors. Session Start: Sat Mar 14 06:29:45 2000 * Logging #xhackx to '#xhackx.log' <06:30 AM><Slider> Fuck im think im still half cut, gotta go to work in ummmmmmmmm... 4 hours... fuck... Session Close: Sat Mar 14 06:31:21 2000 Remote Authentication Dial-In User Service (RADIUS) is a distributed security system developed by Livingston Enterprises. RADIUS was designed based on a previous recommendation from the IETF's Network Access Server Working Requirements Group. An IETF Working Group for RADIUS was formed in January 1996 to address the standardization of RADIUS protocol; RADIUS is now an IETF-recognized dial-in security solution (RFC 2058 and RFC 2138). Similar to RADIUS, Terminal Access Controller Access Control System (TACACS) is an industry standard protocol specification, RFC 1492. Similar to RADIUS, TACACS receives authentication request from a NAS client and forwards the user name and password information to a centralized security server. The centralized server can either be a TACACS database or an external security database. Session Start: Sat Mar 14 14:57:45 2000 * Logging #xhackx to '#xhackx.log' <14:57><Slider>fuck... i missed work... ah bollocks to it, it was shit job anyway... <SNIP> Session Close: Sat Mar 14 15:34:21 2000 Extended TACACS (XTACACS) is a version of TACACS with extensions that Cisco added to the basic TACACS protocol to support advanced features. TACACS+ is another Cisco extension that allows a separate access server (the TACACS+ server) to provide independent authentication, authorization, and accounting services. Although RADIUS and TACACS Authentication Servers can be set up in a variety of ways, depending upon the security scheme of the network they are serving, the basic process for authenticating a user is essentially the same. Using a modem, a remote dial-in user connects to a remote access server, (also called the network access server or NAS) with a built-in analog or digital modem. Once the modem connection is made, the NAS prompts the user for a name and password. The NAS then creates the so-called authentication request from the supplied data packet, which consists of information identifying the specific NAS device sending the authentication request, the port that is being used for the modem connection, and the user name and password. For protection against eavesdropping by hackers, the NAS, acting as the RADIUS or TACACS client encrypts the password before it sends it to the authentication server. If the primary security server cannot be reached, the security client or NAS device can route the request to an alternate server. When an authentication request is received, the authentication server validates the request and then decrypts the data packet to access the user name and password information. If the user name and password are correct, the server sends an Authentication Acknowledgment packet. This acknowledgement packet may include additional filters, such as information on the user's network resource requirements and authorization levels. The security server may, for instance, inform the NAS that a user needs TCP/IP and/or IPX using PPP, or that the user needs SLIP to connect to the network. It may include information on the specific network resource that the user is allowed to access. To circumvent snooping on the network, the security server sends an authentication key, or signature, identifying itself to the security client. Once the NAS receives this information, it enables the necessary configuration to allow the user the necessary access rights to network services and resources. If at any point in this log-in process all necessary authentication conditions are not met, the security database server sends an authentication reject message to the NAS device and the user is denied access to the network. Session Start: Sat Mar 14 18:01:27 2000 * Logging #xhackx to '#xhackx.log' <18:01><Slider>Fuck, that birds still here <18:02><Slider>Fuck her, im going out on the pull again. Session Close: Sat Mar 14 18:25:58 2000 Slider.