- a INGEN, Taxonomia de los Servidores AAA: Radius, Diameter y TACACS+" AAA Server Taxonomy: Radius, Diameter and TACACS+ Néstor Gabriel Forero Saboya!™ "ani Indi Espa o» Infrmie» Mini, My on Imes onda y Coda « Destro eis Tete Parks Univer oe Vigo ~ Exp. Gon de Fests GRUIRETEL, Unie Libr, Pts * ncofirn@ wide Fecha le recep del aelo: 13/11/2000 Fecha de acepracén dl arco: 13/12/2009 Resumen EL presente documento es un breve estudio taxonémico de los tres principales servidores AAA (RADIUS, Diameter y TACACS+). Para cada uno de los protocolos de control de acceso presentado se lleva.a cabo una explicacidn de su funcionamiento y los diferentes elementos que intervienen en sus procesos de comunicacién, Palabras clave Autorizacién, —autenticacién, —_contabilizacién, seguridad, dominio, Abstract This paper is a brief taxonomic study of the theee main AAA server (RADIUS, Diameter, and TACACS+). For each of the protocols presented access control is eatsied out an explanation of its operation and the different elements involved in communication processes. Key Words Authorization, autentication, accounting, security, domain. Introduccién El control de acceso es en la actualidad uno de los principales temas en materiade seguridad porquenose seduce ala simple limitacién de acceso de los usuatios alos recursos compartidos de un sistema, sino que, ademas, administra el e6mo los syjefarinteractian con los abjefor al interior del mismo, El conteol de acceso funciona mediante la implementacién de servidores AAA y sus protocolos asociados. A continuacién se realiza un estudio taxonmico de RADIUS, Dianeter y TACACS+ a Ja luz de los diferentes RFC que los definen. Las exigencias de los nuevos servicios electrOnicos del mundo moderno, tales como: Voz sobre IP, Fax sobre IP, IP Movil y RAP, los cuales, requieren servicios similares que permitan Ja autenticaciéa, la recuperacién de informacién autorizada y Ia generacion de cuentas de control con fines de facturacion y que, a su vez, acepten procesos de anditoria hacen que hoy mas que nunca cobre especial importancia el tema del control de acceso y los servidores que lo soportan. Servidor RADIUS Historia RADIUS (RDS), es el acronimo de Remote Authentication Dial In User Service [1]. Para el orofio de 1992, un requerimiento de NAS (NASREQ) se formulé para el IETF (Internet Engineering Task Force) y como respuesta en 1994 se present6 como borrador a RDS desartollado por Livingston Enterprises Inc. [2]. La primera versién RFC 2039 fue publicada en eneto de 1997 y el actual estindar RFC 2865 fue publicado en junio de 2000, adicionalmente a éste estindat seme desarroll6 la documentacién de la especificacion Accounting la cual fue anexada como extensién informal con el cédigo RFC 2139 [3]. Desde 1997 ha sido aceptado como un estindar REC por la IETF convirtiéndose hasta ahora en el estindar ficial para las implementaciones de RDS. RADIUS fuedesarrollado para permitirel despliegue de acceso por servicios dial-up (PPP) y terminal Server y con el paso del tiempo ensanchado para soportat los servicios de NAS [4]. Operacién y Arquitectura Bs utilizado para autenticacién y autotizacién y para pasar datos de configuracién entre dos servidores Estos servidores son RDS Server y NAS (Network Access Server) que acta como cliente, La Figura 1. ilustra la arquitectura de RDS. User NAS 24008 = mee Figura 1, Anquitectura de RADIUS, El Servidor NAS envia requisiciones al Servidor RDS las cuales se replican con una aceptacién 0 tuna denegacién [1]. El servidor RDS contiene una lista valida de usuatios. Hay un secreto compartido entre el servidor y sus clientes, ese secreto no puede ser vacio, y es utilizado para autenticar al servidor RDS con el servidor NAS y para mantener ocultas las claves de los usuarios. Existe para estos efectos tuna base de datos en el Servidor RDS conteniendo las claves de los usuarios posibilitando otorgar acceso a los usuarios dentro del sistema una vez, sean autenticados. Los usuarios llaman al NAS que actia como cliente del RDS y en el caso de miiltiples dominios el RDS funciona como un Servidor PROXY entre el NAS y el RDS que mangja el proceso AAA. Entonces, el NAS espera la respuesta del RDS que puede aceptar 0 rechazar In solicitud 0 presentar un Challenge para que el usuario responda, En caso de ser aceptado el requerimiento el RDS puede proveer al NAS datos de configuracién y un tipo de servicio con acceso otorgado al usuario. En caso de no haber respuesta del RDS en un tiempo dado, el NAS puede retransmitir la solicitud (5) Formato del paquete EI paquete RDS es encapsulado en paquetes UDP y su puerto de comunicacién asignado oficialmente es el 1812. El paquete contiene los siguientes campos: cade, identifier, length, request anthesticalor y atribates [1]. Cada campo se enearga de lo siguiente: Code: para el Acces-Request Ldentifeator. Campo que debe cambiar cuando el campo de attributes cambie, y siempre que se reciba una respuesta valida de la solicitud anterior. En las retransmisiones no debe cambiar: Request Autbentiator: Su valor cambia cada vex que tun nuevo identificador sea utilizado Atribate: Bs un campo de longitud variable y contiene informaciéa adicional referente a la configuracién ¢ informacién acerca del usuario y del servicio, los valores de campo son de cinco tipos posibles: tex, string, address, integer y time, Bin la Figura 2. se ilustra el formato de paquete de RADIUS. ° 1 2 3 01234567890123456789012345678901 Code Monser Lene Anthendetor Figura 2. Formato de Paquere de RADIUS, Una deseripcién detallada se encuentra en [5]Antenticacién y Autorizacién Cuando el servidor NAS autentica por medio de RDS, el NAS envia un paquete de peticién de acceso indicando los atributos y la informacién necesatia referente al el. servicio solicitado, RDS recibe la peticién y verifica contra la lista de usuarios autorizados, en caso de provenir la peticién de un usuario fuera de la lista la peticién es descartada, sin respuesta de error, por el contrario, en caso de ser un usuario en Ia lista se desencripta la contrascfia del usuario en caso de existir, y la verifiea en la base de datos; en caso de presentarse inconsistencia en Ia informacién verifieada, el servidor envia un paquete de usuario. y acceso rechazado al cliente. En caso de no existit problemas en la verificacién del usuario y que no se necesite de una respuesta challenge, entonces RDS envia un paquete de acceso aceptado al usuario. Cuando NAS recibe el paquete y 1o compara con la peticién utilizando el identificador, calculando cl Response Authenticator de la respuesta, en el caso de coincidie con el valor devuelto por RADIUS, entonces, NAS autentica la identidad de servidor. FI protocolo RADIUS soporta la autenticacién Chaitence{ Response, método en el que el servidor RADIUS, después de haber recibido la peticién de acceso y teniendo Ia informacién del usuario de su base de datos envia un paquete Challenge/ Response al cliente, El paquete puede contener un atributo de mensaje para desplegar al usuario, Cuando el servidor NAS recibe el paquete Chatlage de acceso, desplicga el mensaje al usuario (siempre que exista un mensaje que desplegar) y espera por la respuesta del usuario, Una ver Ia respuesta del usuario llega, el servidor NAS envia el paquete original de peticién de acceso con un nuevo identificador y la respuesta del usuario encriptada en el atributo UserPassword. En caso que €l servidor NAS n0 soporte el esquema del método Challenge/ Response, entonces el servidor RDS rechaza el acceso [1]. Tin lon psa siguientes se exon el proceso del paguete de respuesta chllenge/eespoase enc protocolo ras. INGENIP,. Contabilizacion Se realiza mas o menos de la misma forma que los pprocesos de autorizacién yautenticacién con algunas diferencias. Para el proceso se emplea el puerto 1813 y dos mensajes del protocolo RDS mis doce ributos para la contabilizacién [3]. Fl accounting comienza con la peticién de acevanting del servidor NAS teniendo el atributo AcctStatus-Type en Start (octeto 1) y conteniendo la informacién del usuatio y el servicio a utilizar, ‘Todos los atributos que se utilizan en la peticién de acceso pueden también set utilizados en la peticién para contabilizacién con cinco excepciones: Urer-Passwurd, CHAP-Passvord, Reph-Message, State y CHAP-Challenge [3]. Cuando el servidor NAS desea detener el accounting, eavia una peticién con eédigo AntStatus-Lype en Stop (octeto 2) al servidor RDS, con atributos que pueden contener informacién del servicio utlizado yestadisticas de uso. Una vez recibido el mensaje del servidor NAS el servidor RDS Jo graba y envia un mensaje de reconocimiento de regreso; cuando no se recibe el paquete de reconocimiento el servidor NAS reenvia Ia peticién al servidor RDS, o bien, 2 otto servidor [5] Servidor Diameter Historia Diameter (DMT), fue especialmente diseftado para satisfacer los requerimientos de diferentes grupos de trabajo y se ha centrado y limitado al soporte del acceso a las redes IP [6], para lo cual emplea el puerto 3828 [4]. Inicialmente disefiado como una mejora del protocolo RDS la meta era maximizar la compatibilidad y facilitar Ia migracién desde RDS. El servidor DMT esta definido en términos de un protocolo base y un grupo de aplicaciones, lo cual, provee mecanismos bisicos de transporte, de mensajes, manejo de errores y la capacidad de soportar tipos especificos de accesos de red. Las dos mayores aplicaciones de DMT son MobilelPV4 y NASREQ [4]. Entre los requisitos ‘que originaron a Diameter estén los siguientes:_ ET 1. BI grupo Roaming Operations (ROAMOPS) del IETF que publicé un grupo de requerimientos para roaming networks. El grupo de trabajo NAS Requirements (NASREQ) del IETF que document6 los requetimientos AAA de la nueva generacién de NAS. 3. Bl grupo de trabajo de Mobile IP del IETF que documents los requerimientos AAA que deben ayudar al Mobile IP a escalar la movilidad Inter- Dominios. 4. E] grupo de trabajo TR-45.6 Adjunct Wireless Packet Data Technology de la "Telecommunication Industry Association (TIA) que documents el CDMA2000 Wireless Data Requirements para AAA, Basado en el trabajo TR-45.6, 3GPP2 hha especificado una arquitectura de dos fases pata soportar Wirekss IP networking apoyado en los protocolos IETF; la segunda fase de la funcionalidad AAA requerida no sopottada en RDS. De los requisites citados se explica la razén por Ja cual numerosos autores citan a DMT como la evolucién de RDS y el fururo de los protocolos AAA [7]. Igualmente se comprende el origen de su nombre que adiferencia de RDS, no es un acrénimo, en lugar de eso, es un juego de palabras y de logien ingeniosa que representa al dismetro como el doble del radio [8], sin embargo, es mucho mis que eso tan simple, Arquitectura y el Protocolo SCTP Como se menciono anteriormente DMT esti definidoen términos de un protocolobase yun grupo de aplicaciones. E protocolo base debe utilizarse de la mano con una aplicacién DMT, de tal forma, que ‘cada aplicacién depende del protocolo base sobre el setvidor para soportar el tipo especifico de acceso de red. Las aplicaciones NASREQ soportan dial jin PPP/IP mientras que el protocolo base define 41 formato del mensaje, los datos son levados como una coleccién de AVP (Adiibute Value Pair) ‘equivalents a los Attributes de RDS, de forma tal que los AVP estin conformados por multiples campos: AVP Cod, Length, Flags y Data. Algunos de Jos campos son utilizados por el protocolo y otros por la aplicacién, Otras aplicaciones de Diameter Jas constituyen Mobik-tP, Mobil IPot y Mobile LP16, El protocolo de DMT se encuentra estrechamente conectado con In aplicacién CMS (Cryptegraphic Message Syntax para proveer seguridad a todas las aplicaciones, como si tuvieran diferentes funciones, todas ellas soportadas por el protocolo base [9] En la Figura 3. puede observarse la arquitectura de DMT representada por cl protocol base, las aplicaciones DMT y la aplicacién CMS [8] a Figura 3. Anquitectura de Diameter. DMT opera con una capa de transporte fiable a diferencia de RDS, dicha capa puede ser tanto TCP como SCIP (Stream Conirol Transmision Pro para el control del flujo, Mientras que TCP conocido, el SCYP es un protocol IP bastante nuevo, al nivel de UDP y TCP. SCTP fue propuesto ‘como estindar en el 2000 especifieado con el RFC 2960 [10], entre sus similitudes con TCP estin las siguientes: bien 1, Provee una conexién orientada a dos puntos extremos, 2. Ofrece transmisién confiable, asegurando que los datos son entregados en orden sin pérdidas © duplicacién, 3. Es fall diples. 4, Emplea mecanismo Windowing Pero oftece capacidaces que no provee TCP.1, Multiple flujo de datos entre los dos puntos terminales. 2. Bs orientado al mensaje, mantiene los mensajes de frontera y los entrega completos en trozos, 3. Comprende y hace uso de Mui: Homed Host con lo que se mejora la supesvivencia en las falas de red, aprovechando la redundancia y no la carga compartida, Por esto SCIP es el protocolo ideal para DMT [9] Formato del Paquete El paquete DMT tiene una longitud fija de 20 octetos seguidos de una cantidad variable de AVP. (4 El deader del mensaje de DMT contiene dos identificadotes de 32 bits, un identificador Hop- by Hop y un identificador End-f-End. es como se ilustra en la Figura 4, (L1]- El identificador Hop-by-Hop ayuda a hacer juego entre la peticién y su respuesta [9]. FI identificador End-to-End, en conjunto con la identidad del Host de origen es utilizado para identificar los mensajes de peticién duplicados [9] Ip sesice a. llocovece rage Ineo exes i Yehanes pane nenaens Figura 4. Head de Diameter, E] formato del header AVP de DMT es como Jo ilustra Ja Figura 5. [4]: Figura 5. Head AVP de DMT. El AVP Code, mis el VendorID, snicamente identifican el atributo, Los primeros 256 nimeros AVP con el Vendor ID en cero, son reservados para compatibilidad con RDS. EL AVP Data contiene informacién especifica del atributo. DMT define los siguientes tipos de datos: Integer32, Unsigued32, Integer64, Unsigned6’, Float32, Plhatb-4, Fioatt28, OctetString, and Grouped (9). Todos, los tipos de datos se explican a s{ mismos a dife- rencia del tipo Grouped que es un tipo de dato que contiene una secuencia de AVP [12] Identidad, Contenido de Mensaje y Routing de Diameter Cada proceso DMT ejecutindose en un Host ‘genera o se configura con una identidad Diameter. La identidad Diameter es un texto de sintaxis URI con una subcadena representando el FQDN (Fily Qualified Domain Nam) del Host, uno de los puertos usados para escuchar las conexiones entrantes, el transporte usado para escuchar las conexiones entrantes (TCP 0 SCTP), el protocolo AAA (DMT) yla seguridad del transporte (ninguno 0 TLS) [9]. Un ejemplo vilido de identidad de DMT es el siguiente: saa {hasta com:1812ransport=tcpprotocal=diameter Ta identidad Diameter de cualquier proceso tiene la ‘garantia de ser tinica ya que se carga el FQDN y el puerto pata la commnicacin entrante Por su parte, los mensajes DMT consisten de un header de longitud fija seguido por un némero variable de AVR (como se mencioné antetiormente), hay dos tipos de mensajes, as peticiones (request) y las respuestas (aurnerd). Existen muy pocas circunstancias,ST LshLhLhLhLhhLhLhLrLhLrLr cn las cuales una peticién es descartada en silencio, por lo tanto, el emisor de la peticién recibira en Ia mayoria de los casos una respuesta. Cada mensaje de respuesta lleva un AVP ResultCede cuyo valor es un entero que indica cuando una peticidn fue completamente satisfactoria y cuando ha ocurrido tun error, Cada mensaje DMT lleva una identidad DMT desde el origen del proceso en el AVP Origin- Hast y también el dominio del proceso DMTde origen en el AVP Origin-Readm (13). Contabilizacién Los mensajes de accounting, asi como su soporte, estin definidos como parte del protocolo base de DMT. BI protocolo para accounting esti basado en tun modelo directo de servidor que soporta el envio cn tiempo real de la informacién del accounting: Modelo directo de servidor significa que el cliente de DMT contabiliza la informacién recibida desde la direccién del servidor de accounting con respecto al registro de cumplimiento de las peticiones, La seguridad CMS (Content Management System), puede aplicarse a los mensajes de accounting para otorgarle a los datos una fuerte autenticacién c integridad en la informacién, El protocolo define algunos AVP que deben estar presentes en los mensajes de peticién para accounting en la sesién de un usuario, Adicionalmente, para las aplicaciones que requieren de miiltiples sesiones de accounting, ha sido definido un AVP Accounting Sub-Sesson-Id. Para las aplicaciones donde un usuario recibe servicios de diferentes dispositivos de acceso (cada uno con distintos Session-Id) como p. ej: Mobile IPrf, el AVP. Accountng-MultiSession-Id operado sobre RDS puede ser utilizado para correlacién [9} Servidor TACACS+ Historia TACACS acrénimo de Terminal Access Controller Access Control System, es un protocolo estandar de la industria especificado para reenviar la informacién de nombre y contrasena de un usuario aun servidor centralizado, El protocolo TACACS+ es la nueva vvetsién del protocolo TACACS referenciado en RFC 1492 [14] y desarrollado por la compafiia BBN para la MILNET, existe hoy en dia una implementacion de seguridad de tipo propietaria de la compaaia isco, la cual, ha sido ampliada y modificada varias veces mediante extensiones. TACACS+ ha sido mejorada de TACACS y XTACACS, ahora son dos protocolos totalmente diferentes al TACACS+ actual [15]. TACACS+ es un protocolo cliente servidor al igual que RDS cn donde un cliente NAS envia una peticién que es respondida por un servidor AAA [I6}, el componente fundamental de TACACS+ es la separacién de los procesos de authentication, anthorization y accounting [17]; con lo «que se permite que en las implementaciones no sea obligatorio el empleo de los tres [7]. Una copia del borrador RFC de TACACS+ puede encontearse para su descarga en [17]. Operacién de TACACS+ Cuando un usuatio intenta obtener acceso ASCII autenticindose en un servidor de red usando TACACS+, ocurten los siguientes procesos [15]: 4. Cuando la conexién seestablece el NAS contacta al demonio de TACACS+ para obtener una pantalla de acceso al sistema, Fl usuario indica su nombre de usuario y el NAS se comunica con el demonio TACACS+ para obtener una pantalla de contrasefia. Imego de indicar la contrasefia Ia informacién es enviada de nuevo al demonio para que la procese. BINAS recibe una de las siguientes posibilidades de respuesta: Accept: Bl usuatio es puede iniciar. wutenticado y el servicio Reject Ha fallado Ia autenticacién del usuatio, BI usuario puede ser rechazado o invitado a reintentar la conexién. rror: Un error sucede durante la autenticacién, Responde un mensaje de errory el servidor NAS intenta un método alternativo de autenticacién,Continue: Fl usuasio es invitado a suministrar informacién adicional para proceder con la autenticaci6 5. Bl acceso con PAP (Pasword Access Proto) es similar al acceso ASCII excepto porque el nombre de usuario y Ia contrasedia legan al NAS en un paquete del protocolo PAP. Luego de la autenticacién ef usuario debe pasar por una fase de autorizacién adicional, esta fase iinicamente se puede iniciar cuando el usuario ha sido autenticado. Sila autorizacién TACAS+ es necesaria, el demonio TACACS+ es contactado de nuevo y puede devolver tuna respuesta de aceptacién (aewpf) 0 techazo (rgied. Si la respuesta es de aceptacién, entonces, la respuesta contends datos en forma de atribuutos {que sein usados para direccionar el EXEC 0 la sesién de red para ese usuario, determinando los servicios que el usuario puede acceder. Los servicios incluyen los siguientes: Telnet, login Paint-o-Point (PPP), Sevial Line Internet Protocol (SLIP), EXEC, o bien, parimetros de conexién, incluyendo las conexiones de bast o la lista de direcciones de acceso de clientes, ysimeanss de usuario, Formato del paquete El paquete beader de TACACS+ siempre comienza con doce octetos y describe de forma clata los contenidos del resto del paquete [17]. En la Figura 6.,seaprecia la composicién del Jeaderen TACACS Figura 6, Header de TACACS+ Los contenidos del paquete se describen continuacién: INCENIC.. Gl ‘Major Version Es el mximero de la versién de TACACS+, ‘Minor Versior: Se entiende como la las revisiones del protocolo con las cuales guarda compatibilidad hacia atris, cuando se recibe un paquete con un rnjimero menor de versiéa del protocolo, que no es soportada, se genera de inmediato un error con cédigo de versién cerrada ‘Tipe: Se refiere al tipo de paquete. Entre los valores posibles estin: authorization, anthentcation y acounting, Seq_ne: Niimero de secuencia del paquete en la actual sesién, El primer paguete en la sesi6n debe tencr el niimero 1 y los siguientes paquetes deben inerementar este niimero en uno. Los clientes solamente envian paquetes con mimero impar y el servidor con niimero par. ‘Flags Es una bandera que indica si el cuerpo del mensaje que sigue al header est eneriptado 0 no. Swion_Iet LWemificador de sesién que no cabin durante la duracién de la misma Lengfh: Longitad total del cuerpo del paquete, no se incluye el header. El paquete nunca es enviado sin ésta informacion. BI paquete de cuerpo (budy packet) se define en el paquete beader las siguientes son las reglas generales que aplican al tipo de paquete body de TACACS* 1. La totalidad del paquete body esta protegido por el mecanismo de encriptacién indicado en el header 2. Cualquier variable de longitud de datos de un campo vaeio debe ser 0. 3, Campos de longitad fia que no sean utilizados pueden tener longitud 0. 4, Ninguno de los datos y campos de mensaje en el paquete TACACS+ deben terminar en nulo. 5. Todos los valores de longitud estén sin en orden al octeto de la red. 6. No debe estar relleno ningdn campo 0 el final del paquete.Autenticacién y Autorizacion Ta autenticacién de TACACS+ tiene tres paquetes: Start, Continue y Replay. Los dos primecos siempre son enviados por el cliente y el diltimo por el demonio de TACACS+ [15] La anthentcation inicin con el envio del mensaje Start porpartedel cliente al demonio,alliseespecificael tipo de autorizacién a tealizar, y ademés, puede contener un nombre de usuario y algin dato de autenticacién. El paquete Start es enviado tinicamente en el primer iar el servicio, mensaje en la sesiGn o al rei En respuesta al paquete Start el demonio envia Replay, lo mismo sucede si el mensaje es un Continue De esta manera la comunicacién se manticne porque la tinica forma de terminarla es con una sefial de interrupcién (aban), en cuyo caso, la sesin ¢s inmediatamente interrumpida, El proceso de authorization es una forma extendida de dar el servicio de autenticacién remota, la sesién sti definida como un simple par de mensajes: la peticiGn (Request) seguida por una respuesta (Response) El mensaje de peticién contiene un mimero fijo de campos que describen la autenticidad del usuario 0 del proceso, y un mimero variable de argumentos que describen el servicio y las opeiones para las cuales se pide la autorizacién. La respuesta contiene un grupo variable de argumentos de respuesta (AVP), os cuales, pueden restringir o modificar las acciones delos clientes. Los argumentos para ambos mensajes tanto la peticién como la respuesta pueden set especificados como mandatario u opeional. Un argumento opcional es aquel que puede ser 0 no usado y uno mandatasio es aquel que debe ser usado {18}. Contabilizacién EI proceso de aswunting es muy parecido al de autorizacién. El formato del paquete, también, es ‘muy similar. Hay una parte fija y una extensible, esta ‘iima, utiliza todos los mismos atributos AVP que cemplea la autosizacién pero agrega algunos mis. Conclusion Los servidores AAA deben adaptarse a las complejas cexigencias del mundo actual que condueen a nuevos servicios electronics y que demandan plataformas que sopotten nuevas aplicaciones como el transporte de voz sobre IP, fix sobre IP y la IP Mévil, que a su vez, petmitan llevar un control de ls actividades desarrolladas por los clientes y que soporten procesos de auditoria, De igual forma, es necesario ofrecer a los clientes sistemas seguros y confiables que incrementen la productividad con transacciones en tiempo real y que soporten los nuevos avances multimediales. Se vislumbra el renacer de las redes y de Internet, la siguiente generacién de redes (NGN — Next Generation Networks), basadas en los sistemas multimediales IP (IMS — IP Muti Systems) Los protocolos AAA tienen ahora un papel protagénico como nunca antes en el nuevo y cambiante escenario informético mundial porque eben integrat una amplia amalgama de desarrollos tecnoléigicos y nuevos conceptos que vinculen al mundo digital con el mundo real de manera eficiente yseguraINGE ry INCENIE,. Gl Referencias bibliograficas 1, RFC 2865, Remote Authentication Dial In User Service. April 2010. Ea: hetp://wwwierforg/efe/ Hfe2865.00¢ 2. Interlink Networks, The Beginnings and History of RADIUS, Ana Arbor, MI, March 2010, En: hutp:// ww winterlinknetworks.com/app_notes/History?200f%20RADIUS pdt 3. REC 2139, RADIUS Accounting. April 2010. En: heep:/ /srwwefaqs.org/tfes /rfc2139.atml 4, REC 3588, Diameter Base Protocol. September 2003. En: hitp://wwwtlc-editonongy/ rfe/sfe3588.0xt 5. Tuomimaki, J. Overview, details and analysis of RADIUS protocol, Helsinki, February 2010. En: berp:// swwvitml. kk. fi/Studies/T110.551 /2003/papers/12.pat 6. Interlink Networks, Introduction to Diameter, Ann Arbor, MI, February 2010. En: http://www: interlinknetworks.com/whitepapers/Inteoduction_to_Diameterpdf 7. Hakan Ventura, Diameter next generation’s AAA protocol, January 2010. En: hetp:/ /wwv:diva-portal otg/diva/getDocument?urn_nbn_se_liu_diva-1195-1__fulltext.pdf 8. REC 3127, Authorization, Authentication and Accounting: Protocol Evaluation. January 2010, En: hetp:/ /wwwietforgy/rfc/rfe3127 txt 9. Hewlett-Packard Company, Introduction to Diameter, March 2010. En: hetp://docshp.com/en/ T1428-90011/T1428-9001 L.paf 10. RFC txt 5 2960, Stream Control Transmission Protocol, April 2010. En: htspi/ /wwwiethorg,/#fe/xfc2960. 11, Cisco, Cisco AAA Implementation Case Study Internetworking Solutions Guide, San Jose, CA, USA, March 2010. En: hetp://wwwcisco.com/application/pdf/en/us/guest/products/ps499/e2001 / cemigration_09186a00800ead98, pdf 12. Liu, J; Jiang, S; Lin, H. Introduction to Diameter, January 2010. En: http:/ /wwwibm.com/developerworks/ wireless /library/wi-diameter/ 13, Mandin, J. Enhancement of 802.16e to Support EAP-based Authentication / Key Distribution, January 2010, In: hnips/ /wwwieceB02.0rg/ 16 /tge /contrib /C80216e-03_7112,pat 14, RFC 1492, An Access Control Protocol, Sometimes Called TACACS, Februaty 2010. En: hetpi/ /wwwfags ong/fes/rfc1492.htm] 15. Cisco, Configuring TACACS and Extended TACACS, March 2010. Ea: hetpi/ /wwwcisco.com/univercd/ cc/td/doc/product/softwate/ios| 13ed/113ed_cr/secur_c/septt2/setcacspaf 16, Juniper Nenworks, TACACS+ Overview, February 2010. Ea: huip:/ /wwwsjunipernet/techpubs/ software/ rx /junose6t/sweonfig- broadband /heml/tacacs-config2hteal 17. Carrel, Ds Grant, L. Cisco Systems, The TACACS+ Protocol Version 1.78, January 2010, In: fip://ftpeng, cisco.com/pub/tacacs/tac-tfe.1.78.xt 18. Cisco, TACACS+ and RADIUS Comparison, April 2010, In: hesp//wwwicisco.com/en/US/tech/tk59/ technologies_tech_note(1 862008009499 shtml