rfc3702.Authentication, Authorization, and Accounting Requirements for the Session Initiation Protoc
authentication server 表说明
authentication server 表说明认证服务器（Authentication Server）是一种安全服务器，用于验证用户的身份并授权其访问特定资源。
它是用户认证过程中的关键部分，负责验证用户提供的身份凭据，并检查其是否有权访问所请求的资源。
认证服务器在许多应用程序和系统中起着重要的作用，包括网站、移动应用程序、电子邮件服务、计算机网络等。
认证服务器的作用是将用户的身份与相应的访问权限进行关联，并确保只有经过身份验证和授权的用户才能访问受保护的资源。
它通过以下步骤实现认证和授权的过程：1.身份验证（Authentication）：当用户尝试访问受保护的资源时，他们需要提供有效的身份凭据，例如用户名和密码。
认证服务器会验证这些凭据的有效性，并确认用户是否是其声明的身份。
这可以通过与保存在数据库或目录服务器中的用户凭据进行比较来完成。
2.授权（Authorization）：一旦用户的身份得到验证，认证服务器会根据其权限级别分配相应的访问权限。
用户可能被分配为管理员、普通用户或其他角色，并被授予相应的权限。
这些权限可以是对特定资源的读取、写入或其他操作的权限。
3.令牌生成（Token Generation）：认证服务器还负责生成安全令牌（Token），用于在后续的请求中验证用户的身份和授权。
令牌通常是一段加密的字符串，其中包含关于用户身份和权限的信息。
在用户进行进一步的请求时，他们需要将令牌包含在请求中，以便认证服务器进行验证。
认证服务器具有以下特点和优势：1.安全性：认证服务器通过对用户提供的身份凭证进行验证，减小了系统遭受未经授权访问和攻击的风险。
它使用密码哈希、加密和其他安全机制来保护用户凭证的传输和存储。
2.中心化管理：认证服务器允许集中管理用户的身份和权限信息。
通过将这些信息存储在单独的服务器中，可以简化整个系统的管理和维护。
当用户需要修改其身份或权限时，只需在认证服务器上进行相应的更改即可。
华为交换机AAA配置与管理
华为交换机AAA配置与管理AAA配置与管理一、基础1、AAA是指：authentication（认证）、authorization （授权）、accounting（计费）的简称，是网络安全的一种管理机制；Authentication是本地认证/授权，authorization 和accounting是由远处radius（远程拨号认证系统）服务或hwtacacs（华为终端访问控制系统）服务器完成认证/授权；AAA是基于用户进行认证、授权、计费的，而NAC方案是基于接入设备接口进行认证的。
在实际应用中，可以使用AAA的一种或两种服务。
2、AAA基本架构：C/S结构，AAA客户端（也叫NAS-网络接入服务器）是使能了aaa功能的网络设备（可以是一台或多台、不一定是接入设备）3、AAA基于域的用户管理：通过域来进行AAA用户管理，每个域下可以应用不同的认证、授权、计费以及radius或hwtacacs服务器模板，相当于对用户进行分类管理缺省情况下，设备存在配置名为default（全局缺省普通域）和default_admin（全局缺省管理域），均不能删除，只能5、hwtacacs协议Hwtacacs是在tacacs（rfc1492）基础上进行了功能增强的安全协议，与radius协议类似，主要用于点对点PPP和VPDN （virtual private dial-up network，虚拟私有拨号网络）接入用户及终端用户的认证、授权、计费。
与radius相比，具有更加可靠的传输和加密特性，更加适合于安全控制。
Hwtacacs协议与其他厂商支持的tacacs+协议的认证流程和实现方式是一致的，能够完全兼容tacacs+协议6、华为设备对AAA特性的支持支持本地、radius、 hwtacacs三种任意组合本地认证授权：优点是速度快，可降低运营成本；缺点是存储信息量受设备硬件条件限制RADIUS认证、计费：优点防止非法用户对网络的攻击相对较高；缺点是不支持单独授权功能，必须与认证功能一起，使用了认证功能就使用了授权功能Hwtacacs认证、授权、计费：认证、授权、计费室单独进行的，可以单独配置使用，在大型网络中可以部署多台hwtacacs服务器；还支持在一个方案中使用多协议模式，如本地认证常用于radius认证和hwtacacs认证的备用认证方案，本地授权作为hwtacacs授权的备用授权方案等二、本地方式认证和授权配置配置流程为：配置AAA方案——配置本地用户——配置业务方案——配置域的AAA方案一、配置AAA方案配置AAA方案就是配置AAA中的认证、授权、计费，用于“域的aaa方案”中绑定这些方案使用（所配置的各种方案只有在域中绑定后才能得到应用）认证方案：1、进入AAA视图[Huawei]aaa2、设置一个AAA认证方案名[Huawei-aaa]authentication-scheme test13、设置认证模式为本地认证（缺省为本地认证）[Huawei-aaa-authen-test1]authentication-mode ?hwtacacs HWTACACSlocalLocalnone Noneradius RADIUS4、配置当前认证模板对用户提升级别进行认证时采用的认证模式（可选，默认为本地认证）[Huawei-aaa-authen-test1]authentication-super ?hwtacacs HWTACACSnone Noneradius RADIUSsuper Super（本地认证模式）5、配置用户名和域名解析的方向（可选，缺省从左向右）[Huawei-aaa]domainname-parse-direction ?left-to-right Configure the left to right direction of domainname parsingright-to-leftConfigure the right to left direction of domainname parsing授权方案：1、创建一个授权方案[Huawei-aaa]authorization-scheme tets12、配置本地授权模式[Huawei-aaa-author-tets1]authorization-mode ?hwtacacs Use HWTACACS authorization methodif-authenticated Use authorization method which lets user(s) authorized if user(s) not authenticated by none authentication methodlocal Use local authorization methodnone Use none authorization method3、设置授权服务器下发的用户授权信息的生效模式（可选，缺省为overlay模式）[Huawei-aaa]authorization-modify ？Modify 修改模式，新下发的授权信息覆盖上一次下发的所有属性类别的授权信息 Overlay 覆盖模式，新下发的授权信息覆盖前次下发的所有用户授权信息# 模拟器未能模拟二、配置本地用户采用本地方式进行认证授权时，需要在本地设备配置用户的认证和授权信息，如用于认证的用户名、密码、用于授权的优先级、用户组、允许接入的服务器类型、可建立连接数、访问目录等1、设置本地用户名和密码[Huawei-aaa]local-user test password simple 1472582、设置本地用户的级别[Huawei-aaa]local-user test privilege level 153、设备本地用户加入用户组（可选，先配置好用户组[Huawei-aaa]local-user test user-group teset #模拟器无法模拟4、设置本地用户断开超时时间[Huawei-aaa]local-user test idle-timeout 6005、设备本地用户用于何种类型的服务[Huawei-aaa]local-user test service-type ?8021x 802.1x userbind Bind authentication userftp FTP user http Http userppp PPP user ssh SSH usertelnet Telnet userterminal Terminal userweb Web authentication userx25-pad X25-pad user6、本地用户作为FTP使用时设置访问目录[Huawei-aaa]local-user test ftp-directory ？STRING<1-58>flash:flash:/7、设置本地用户状态[Huawei-aaa]local-user test state ?active Permit the user(s) to deal with the authen requestblock Forbid the user(s) to deal with the authen request （拒绝该用户认证请求）8、设备本地用户访问时最大连接数（缺省不限制）[Huawei-aaa]local-user test access-limit 109、设置本地账号锁定功能（连续登陆失败达到次数后锁定和解锁、重试等参数）[Huawei-aaa]local-aaa-user wrong-passwordretry-interval 5（重试时间间隔）retry-time 3 （连续认证失败的最大次数block-time 10（账号被锁定时间）10、修改账号密码<Huawei>local-user change-password三、配置业务方案（可选）“业务方案”也是一种授权方案，它是专门针对一些IP业务（如管理员权限、DHCP服务、DNS服务、策略路由）所进行的授权，也称为“业务授权方案”。
httpstaus汇总
httpstaus汇总常见HTTP状态码1.2.3.4.5.6.7.8.9.10.11.12.100 Continue初始的请求已经接受，客户应当继续发送请求的其余部分101 Switching Protocols服务器将遵从客户的请求转换到另外⼀种协议200 OK⼀切正常，对GET和POST请求的应答⽂档跟在后⾯201 Created服务器已经创建了⽂档，Location头给出了它的URL。
202 Accepted已经接受请求，但处理尚未完成。
203 Non-Authoritative Information⽂档已经正常地返回，但⼀些应答头可能不正确，因为使⽤的是⽂档的拷贝204 No Content没有新⽂档，浏览器应该继续显⽰原来的⽂档。
如果⽤户定期地刷新页⾯，⽽Servlet可以确定⽤户⽂档⾜够新，这个状态代码是很有⽤的205 Reset Content没有新的内容，但浏览器应该重置它所显⽰的内容。
⽤来强制浏览器清除表单输⼊内容206 Partial Content客户发送了⼀个带有Range头的GET请求，服务器完成了它300 Multiple Choices客户请求的⽂档可以在多个位置找到，这些位置已经在返回的⽂档内列出。
如果服务器要提出优先选择，则应该在Location应答头指明。
301 Moved Permanently客户请求的⽂档在其他地⽅，新的URL在Location头中给出，浏览器应该⾃动地访问新的URL。
302 Found类似于301，但新的URL应该被视为临时性的替代，⽽不是永久性的。
303 See Other类似于301/302，不同之处在于，如果原来的请求是POST，Location头指定的重定向⽬标⽂档应该通过GET提取304 Not Modified客户端有缓冲的⽂档并发出了⼀个条件性的请求（⼀般是提供If-Modified-Since头表⽰客户只想⽐指定⽇期更新的⽂档）。
请求头authorization 认证原理
请求头authorization 认证原理请求头authorization 认证原理背景介绍在进行网络通信时，身份认证是非常重要的一环。
而HTTP请求头的Authorization字段旨在提供一种安全的方式来验证请求的发送者身份。
本文将深入探讨Authorization认证的原理和相关应用。
什么是请求头AuthorizationAuthorization是HTTP请求头的一部分，用于向服务器提供身份验证信息。
当我们向服务器发送请求时，可以在请求头中包含Authorization字段来提供身份验证凭据。
认证原理的基础概念1. 客户端和服务器的通信在进行身份验证过程中，存在一个客户端（通常是浏览器、应用程序等）和一个服务器（存储用户信息和处理验证请求）之间的通信过程。
2. 用户名和密码为了证明用户的身份，需要用户提供正确的用户名和密码组合。
3. 加密算法为了保证身份验证信息的安全性，加密算法是必不可少的。
常见的加密算法包括MD5、SHA1等。
基本认证流程基本的Authorization认证流程如下：1.客户端向服务器发送请求。
2.服务器返回需要进行身份验证的响应。
3.客户端将用户名和密码进行Base64编码，并将编码后的字符串放入请求头的Authorization字段中。
4.服务器验证身份凭据，并返回相应的响应结果。
常见的Authorization认证方案1. Basic认证Basic认证是最简单和最常见的认证方案之一。
其基本流程如下：1.客户端将用户名和密码使用:连接，并进行Base64编码。
2.客户端将编码后的字符串放入请求头的Authorization字段中，格式为Basic 编码后的字符串。
3.服务器将请求头中的Authorization字段进行解码并验证身份凭据。
2. Bearer认证Bearer认证是OAuth 中使用的一种认证方案，主要用于API访问的身份验证。
其基本流程如下：1.客户端通过OAuth 协议获取访问令牌（Access Token）。
avp的工作原理
avp的工作原理AVP的工作原理什么是AVPAVP指的是“Attribute-Value Pair”，即属性-值对。
AVP是一种在计算机网络中广泛使用的数据结构，用于在通信协议中传输各种类型的数据。
AVP的结构AVP由三个部分组成：属性名（Attribute）、属性标志（Flags）和属性值（Value）。
属性名用于描述所传输的数据的类型，属性标志用于定义该AVP的属性特性，属性值则是具体的数据内容。
AVP的传输在通信协议中，AVP通常以二进制形式传输，按照一定的规则进行编码和解码。
编码过程将AVP的结构转换为二进制格式，而解码过程将二进制数据转换为AVP的结构。
AVP的应用AVP在各种通信协议中起到重要作用。
常见的应用包括：1.AAA协议中的AVP：AAA（Authentication,Authorization, and Accounting）是一种用于认证、授权和计费的协议，其中使用AVP传输认证和授权信息。
2.DIAMETER协议中的AVP：DIAMETER是一种用于认证、授权和计费的协议，它在AAA协议的基础上进行了扩展，其中使用AVP传输各种类型的数据。
3.RADIUS协议中的AVP：RADIUS（RemoteAuthentication Dial-In User Service）是一种用于远程用户身份认证和计费的协议，其中使用AVP传输用户相关的信息。
AVP的工作原理AVP的工作原理可以总结为以下几个关键步骤：1.配置：在通信协议中定义要传输的AVP的结构以及编码规则。
2.编码：将AVP的结构按照协议定义的编码规则转换为二进制数据。
3.传输：将编码后的AVP通过网络传输到目标设备。
4.解码：目标设备接收到二进制数据后，按照协议定义的解码规则将其转换为AVP的结构。
5.处理：目标设备根据AVP的属性名和属性值进行相应的处理操作。
总结AVP作为一种广泛应用的数据结构，在网络通信中发挥了重要的作用。
aaa认证
1.1 什么AAAAAA（Authentication Authorization Accounting）是一种提供认证、授权和计费的技术。
●∙∙认证（Authentication）：验证用户是否可以获得访问权，确定哪些用户可以访问网络。
●∙∙授权（Authorization）：授权用户可以使用哪些服务。
●∙∙计费（Accounting）：记录用户使用网络资源的情况。
1.2 AAA的基本架构AAA通常采用“客户端—服务器”结构。
这种结构既具有良好的可扩展性，又便于集中管理用户信息。
如下图所示认证AAA支持以下认证方式：●∙∙不认证：对用户非常信任，不对其进行合法检查，一般情况下不采用这种方式。
●∙∙本地认证：将用户信息（包括本地用户的用户名、密码和各种属性）配置在网络接入服务器上。
本地认证的优点是速度快，可以为运营降低成本；缺点是存储信息量受设备硬件条件限制。
●∙∙远端认证：将用户信息（包括本地用户的用户名、密码和各种属性）配置在认证服务器上。
AAA支持通过RADIUS（Remote Authentication Dial In User Service）协议或HWTACACS （HuaWei Terminal Access Controller Access Control System）协议进行远端认证。
网络接入服务器NAS（Network Access Server）作为客户端，与RADIUS 服务器或HWTACACS服务器通信。
如果在一个认证方案中采用多种认证模式，将按照配置的顺序进行认证。
当配置的认证方式是先远端认证后本地认证时如果登录的帐号在远端服务器上没有创建，但是在本地是存在的，经过远端认证时，将被认为认证失败，不再转入本地认证。
只有在远端认证服务器无响应时，才会转入本地认证。
如果选用了不认证（none）或本地认证（local），它必须作为最后一种认证模式。
授权AAA支持以下授权方式：不授权：不对用户进行授权处理。
CISCO AAA命令详解
AAA详解收藏Authentication:用于验证用户的访问，如login access,ppp network access等。
Authorization:在Autentication成功验证后，Authorization用于限制用户可以执行什么操作，可以访问什么服务。
Accouting:记录Authentication及Authorization的行为。
Part I. 安全协议1>Terminal Access Controller Access Control System Plus (TACACS+)Cisco私有的协议。
加密整个发给tacacs+ server的消息，用户的keys。
支持模块化AAA，可以将不同的AAA功能分布于不同的AAA Server甚至不同的安全协议，从而可以实现不同的AAA Server/安全协议实现不同的AAA功能。
配置命令：Router(config)# tacacs-server host IP_address [single-connection] [port {port_#}] [timeout {seconds}] [key {encryption_key}]Router(config)# tacacs-server key {encryption_key} 注：(1)single-connection:为Router与AAA Server的会话始终保留一条TCP链接，而不是默认的每次会话都打开/关闭TCP链接。
(2)配置两个tacacs-server host命令可以实现tacacs+的冗余，如果第一个server fail了，第二个server可以接管相应的服务。
第一个tacacs-server host命令指定的server为主，其它为备份。
(3)配置inbound acl时需要permit tacacs+的TCP port 49。
(4) 如果两个tacacs-server使用不同的key,则需要在tacacs-server host命令中指定不同的encryption_key,否则可以使用tacacs-server key统一定制。
华为交换机AAA配置与管理系统
AAA配置与管理一、基础1、AAA是指：authentication（认证）、authorization（授权）、accounting（计费）的简称，是网络安全的一种管理机制；Authentication是本地认证/授权，authorization和accounting是由远处radius（远程拨号认证系统）服务或hwtacacs（华为终端访问控制系统）服务器完成认证/授权；AAA是基于用户进行认证、授权、计费的，而NAC 方案是基于接入设备接口进行认证的。
在实际应用中，可以使用AAA的一种或两种服务。
2、AAA基本架构：C/S结构，AAA客户端（也叫NAS-网络接入服务器）是使能了aaa功能的网络设备（可以是一台或多台、不一定是接入设备）3、AAA基于域的用户管理：通过域来进行AAA用户管理，每个域下可以应用不同的认证、授权、计费以及radius或hwtacacs服务器模板，相当于对用户进行分类管理缺省情况下，设备存在配置名为default（全局缺省普通域）和default_admin（全局缺省管理域），均不能删除，只能修改，都属于本地认证；default为接入用户的缺省域，default_admin为管理员账号域（如http、ssh、telnet、terminal、ftp用户）的缺省域。
用户所属域是由域分隔符后的字符串来决定的，域分隔符可以是@、|、%等符号，如user@就表示属于huawei域，如果用户名不带@，就属于系统缺省default域。
自定义域可以被配置为全局缺省普通域或全局缺省管理域，但域下配置的授权信息较AAA服务器的授权信息优先级低，通常是两者配置的授权信息一致。
4、radius协议Radius通过认证授权来提供接入服务、通过计费来收集、记录用户对网络资源的使用。
定义UDP 1812、1813作为认证（授权）、计费端口Radius服务器维护三个数据库：Users:存储用户信息（用户名、口令、使用的协议、IP地址等）Clients:存储radius客户端信息（接入设备的共享密钥、IP地址）Dictionary：存储radius协议中的属性和属性值含义Radius客户端与radius服务器之间通过共享密钥来对传输数据加密，但共享密钥不通过网络来传输。
基于tacacs+服务器的aaa认证原理
基于tacacs+服务器的aaa认证原理一、什么是tacacs+服务器tacacs+服务器是指Terminal Access Controller Access Control System Plus的缩写，它是一种网络认证协议，用于提供对路由器、交换机、防火墙等网络设备的认证、授权和审计功能。
tacacs+服务器通过客户端-服务器模型实现对用户的身份验证和访问控制，是实现AAA（认证、授权、审计）功能的重要组成部分之一。
二、tacacs+服务器的工作原理1. 认证（Authentication）tacacs+服务器首先对用户提交的用户名和密码进行验证，以确定用户的身份是否合法。
当用户在网络设备上登入时，设备会将用户提交的认证请求发送到tacacs+服务器，服务器通过比对用户输入的用户名和密码与服务器中保存的信息进行验证，如果验证成功则用户被授权访问网络设备，否则被拒绝。
2. 授权（Authorization）一旦用户身份验证成功，tacacs+服务器会根据用户的账号权限和网络设备的访问策略，对用户所能执行的操作进行授权。
授权过程包括确定用户的访问权限、设备的访问控制策略等，以保证用户在设备上的操作受到严格的控制和限制。
3. 审计（Accounting）tacacs+服务器会记录用户的每一次登入和操作行为，以便对用户在网络设备上的操作进行审计和监控。
这些审计日志可用于追踪用户的行为和识别潜在的安全威胁，同时也可以用于合规性监管和资源管理。
三、tacacs+服务器的优势1. 安全性tacacs+服务器支持对用户进行灵活的身份验证，并且能够提供细粒度的访问控制，能够确保只有经过合法身份验证的用户才能够访问网络设备。
tacacs+服务器支持加密传输，能够保障用户认证信息的安全性。
2. 高可用性tacacs+服务器支持集裙部署和负载均衡，能够提供高可用性的认证服务，避免单点故障，确保网络设备的稳定运行。
和SIP有关的RFC
RFC 3680 SIP Event Package for Registrations
RFC 3702 Authentication, Authorization, and Accounting Requirements for the SIP
RFC 3515 The Session Initiation Protocol (SIP) Refer Method
RFC 3578 Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the SIP
RFC 4244 An Extension to the SIP for Request History Information
RFC 4245 High-Level Requirements for Tightly Coupled SIP Conferencing
RFC 4320 Actions Addressing Identified Issues with the SIP's Non-INVITE Transaction
RFC 3581 An Extension to the SIP for Symmetric Response Routing
RFC 3603 Private SIP Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture.
AAA系统的简称
AAA系统的简称：认证(Authentication)：验证用户的身份与可使用的网络服务；授权(Authorization)：依据认证结果开放网络服务给用户；计帐(Accounting)：记录用户对各种网络服务的用量，并提供给计费系统。
AAA-----身份验证(Authentication)、授权(Authorization)和统计(Accounting) Cisco开发的一个提供网络安全的系统。
奏见authentication。
authorization和acco unting常用的AAA协议是Radius，参见RFC 2865，RFC 2866。
另外还有HWTACACS协议（Huawei Terminal Access Controller Access C ontrol System）协议。
HWTACACS是华为对TACACS进行了扩展的协议HWTACACS是在TACACS（RFC1492）基础上进行了功能增强的一种安全协议。
该协议与RADIUS协议类似，主要是通过“客户端—服务器”模式与HWTACACS 服务器通信来实现多种用户的AAA功能。
HWTACACS与RADIUS的不同在于：l RADIUS基于UDP协议，而HWTACACS基于TCP协议。
l RADIUS的认证和授权绑定在一起，而HWTACACS的认证和授权是独立的。
l RADIUS只对用户的密码进行加密，HWTACACS可以对整个报文进行加密。
认证方案与认证模式AAA支持本地认证、不认证、RADIUS认证和HWTACACS认证四种认证模式，并允许组合使用。
组合认证模式是有先后顺序的。
例如，authentication-mode radius local表示先使用RADIUS认证，RADIUS认证没有响应再使用本地认证。
当组合认证模式使用不认证时，不认证（none）必须放在最后。
例如：authenti cation-mode radius local none。
AAA与RADIUS 协议
AAA与RADIUS 协议(2010-06-09 00:03:15)转载▼分类：核心网-PS标签：aaaradius协议认证授权AAA的概念AAA是Authentication（认证）、Authorization（授权）和Accounting（计费）的简称。
它提供对用户进行认证、授权和计费三种安全功能。
具体如下：a、认证（Authentication）：认证用户是否可以获得访问权，确定哪些用户可以访问网络。
b、授权（Authorization）：授权用户可以使用哪些服务。
c、计费（Accounting）：记录用户使用网络资源的情况。
AAA一般采用客户／服务器结构，客户端运行于被管理的资源侧，服务器上则集中存放用户信息。
这种结构既具有良好的可扩展性，又便于用户信息的集中管理。
计费网关主要使用aaa 中的认证功能对终端用户进行认证管理。
Radius 协议Radius 是Remote Authentication Dial-in User Service（远程认证拨号用户服务）的简称，作为一种分布式的客户机／服务器系统，能提供aaa 功能。
RADIUS原来的初衷是用来管理使用串口和调制解调器的大量分散用户。
radius 技术可以保护网络不受未授权访问的干扰，常被用在既要求较高安全性、又要求维持远程用户访问的各种网络环境中。
Radius 服务包括三个组成部分：a、协议：rfc2865、2866 协议基于udp／ip 层定义了radius 帧格式及消息传输机制，并定义了1812 作为认证端口，1813 作为计费端口。
b、服务器：radius 服务器运行在中心计算机或工作站上，包含了相关的用户认证和网络服务访问信息。
c、客户端：位于拨号访问服务器NAS（network access server）侧，可以遍布整个网络。
radius 基于客户／服务器模型，NAS（如路由器）作为Radius 客户端，负责传输用户信息到指定的radius 服务器，然后根据从服务器返回的信息进行相应处理（如接入／挂断用户）。
AAA简介
1.AAA and EAP简介3.1 AAAAAA指的是Authentication（鉴别），Authorization（授权），Accounting（计费）。
自网络诞生以来，认证、授权以及计费体制（AAA）就成为其运营的基础。
网络中各类资源的使用，需要由认证、授权和计费进行管理。
其中，鉴别（Authentication）指用户在使用网络系统中的资源时对用户身份的确认。
这一过程，通过与用户的交互获得身份信息（诸如用户名—口令组合、生物特征获得等），然后提交给认证服务器；后者对身份信息与存储在数据库里的用户信息进行核对处理，然后根据处理结果确认用户身份是否正确。
例如，GSM移动通信系统能够识别其网络内网络终端设备的标志和用户标志。
授权（Authorization）网络系统授权用户以特定的方式使用其资源，这一过程指定了被认证的用户在接入网络后能够使用的业务和拥有的权限，如授予的IP地址等。
仍以GSM移动通信系统为例，认证通过的合法用户，其业务权限（是否开通国际电话主叫业务等）则是用户和运营商在事前已经协议确立的。
计费（Accounting）网络系统收集、记录用户对网络资源的使用，以便向用户收取资源使用费用，或者用于审计等目的。
以互联网接入业务供应商ISP为例，用户的网络接入使用情况可以按流量或者时间被准确记录下来。
RADIUS是一种C/S结构的协议，它的客户端最初就是NAS（Net Access Server）服务器，现在任何运行RADIUS客户端软件的计算机都可以成为RADIUS的客户端。
RADIUS 协议认证机制灵活，可以采用PAP、CHAP或者Unix登录认证等多种方式。
RADIUS是一种可扩展的协议，它进行的全部工作都是基于Attribute-Length-Value的向量进行的。
RADIUS 的基本工作原理是:用户接入NAS，NAS向RADIUS服务器使用Access-Require数据包提交用户信息，包括用户名、密码等相关信息，其中用户密码是经过MD5加密的，双方使用共享密钥，这个密钥不经过网络传播；RADIUS服务器对用户名和密码的合法性进行检验，必要时可以提出一个Challenge，要求进一步对用户认证，也可以对NAS进行类似的认证；如果合法，给NAS返回Access-Accept数据包，允许用户进行下一步工作，否则返回Access-Reject数据包，拒绝用户访问；如果允许访问，NAS向RADIUS服务器提出计费请求Account-Require，RADIUS服务器响应Account-Accept，对用户的计费开始，同时用户可以进行自己的相关操作。
php authorization函数代码示例
php authorization函数代码示例PHP是一种流行的服务端脚本语言，它具有许多强大的功能。
其中之一是能够提供Authorization函数，用于对Web资源进行访问控制。
本文将围绕PHP Authorization函数代码示例进行介绍和讲解。
PHP Authorization函数通过使用HTTP协议的Authorization头来控制对Web资源的访问。
这个头部包含一个加密和解密后的用户名和密码，以及其他相关的信息。
接下来，我们将分步骤地介绍PHP Authorization函数的使用。
第一步，启用Apache的.htaccess文件。
这个文件存放于网站的根目录下，并且它可以配置如何安全性地访问文件资源。
我们需要在这个文件中编写如下代码片段：```phpAuthUserFile /var/www/html/.htpasswdAuthName "Restricted Area"AuthType BasicRequire valid-user```这段代码用来设置认证文件的路径、认证区域名称，以及要求所有访问此区域的用户都必须进行身份认证。
此代码中的“/var/www/html/.htpasswd”是一个存储用户名和密码的文件。
第二步，创建.htpasswd文件。
在这个文件中，我们将使用bcrypt算法对用户名和密码进行加密。
我们可以使用htpasswd命令来创建这个文件。
运行以下命令：```phphtpasswd -c /var/www/html/.htpasswd username```其中，“username”是你想要进行认证的用户名。
第三步，编写PHP页面并添加Authentication代码。
在需要进行认证的页面中，需要添加以下代码段以启用PHP的认证功能：```php<?php//HTTP Authenticationif (!isset($_SERVER["PHP_AUTH_USER"])) {/* 认证失败 */header('WWW-Authenticate: Basic realm="My Realm"');header('HTTP/1.0 401 Unauthorized');echo '您必须输入用户名和密码才能访问此页面！';exit;} else {if ($_SERVER["PHP_AUTH_USER"] == "username" &&$_SERVER["PHP_AUTH_PW"] == "password") {/* 成功认证 */echo "<p>=== Welcome {$_SERVER['PHP_AUTH_USER']}!===</p>";} else {/* 认证失败 */header('WWW-Authenticate: Basic realm="My Realm"');header('HTTP/1.0 401 Unauthorized');echo '用户名或密码不正确！';exit;}}>```这段代码会检查是否设置了PHP_AUTH_USER服务器变量。
H3C-RADIUS配置
目录1 AAA配置1.1 AAA简介1.2 RADIUS协议简介1.2.1 客户端/服务器模式1.2.2 安全和认证机制1.2.3 RADIUS的基本消息交互流程1.2.4 RADIUS报文结构1.2.5 RADIUS扩展属性1.3 HWTACACS协议简介1.3.1 HWTACACS协议与RADIUS协议的区别1.3.2 HWTACACS的基本消息交互流程1.4 协议规范1.5 AAA配置任务简介1.6 配置AAA1.6.1 配置准备1.6.2 创建ISP域1.6.3 配置ISP域的属性1.6.4 配置ISP域的AAA认证方案1.6.5 配置ISP域的AAA授权方案1.6.6 配置ISP域的AAA计费方案1.6.7 配置本地用户的属性1.6.8 配置用户组的属性1.6.9 配置强制切断用户连接1.6.10 AAA显示与维护1.7 配置RADIUS1.7.1 创建RADIUS方案1.7.2 配置RADIUS认证/授权服务器1.7.3 配置RADIUS计费服务器及相关参数1.7.4 配置RADIUS报文的共享密钥1.7.5 配置RADIUS报文的超时重传次数最大值1.7.6 配置支持的RADIUS服务器的类型1.7.7 配置RADIUS服务器的状态1.7.8 配置发送给RADIUS服务器的数据相关属性1.7.9 配置RADIUS服务器的定时器1.7.10 配置RADIUS服务器的安全策略服务器1.7.11 使能RADIUS客户端的监听端口1.7.12 RADIUS显示和维护1.8 配置HWTACACS1.8.1 创建HWTACACS方案1.8.2 配置HWTACACS认证服务器1.8.3 配置HWTACACS授权服务器1.8.4 配置HWTACACS计费服务器1.8.5 配置HWTACACS报文的共享密钥1.8.6 配置发送给HWTACACS服务器的数据相关属性1.8.7 配置HWTACACS服务器的定时器1.8.8 HWTACACS显示和维护1.9 AAA典型配置举例1.9.1 Telnet/SSH用户通过RADIUS服务器认证、授权、计费的应用配置1.9.2 FTP/Telnet用户本地认证、授权、计费配置1.9.3 PPP用户通过HWTACACS服务器认证、授权、计费的应用配置1.10 AAA常见配置错误举例1.10.1 RADIUS认证/授权失败1.10.2 RADIUS报文传送失败1.10.3 RADIUS计费功能异常1.10.4 HWTACACS常见配置错误举例1 AAA配置1.1 AAA简介AAA是Authentication、Authorization、Accounting（认证、授权、计费）的简称，是网络安全的一种管理机制，提供了认证、授权、计费三种安全功能。
authentication 和authorization -回复
authentication 和authorization -回复Authentication 和Authorization 是现代网络安全中两个重要的概念。
虽然它们经常同时出现，但它们代表着不同的概念和功能。
在本文中，我们将一步一步回答有关Authentication 和Authorization 的问题，以便更好地理解它们的意义和区别。
第一部分：Authentication（认证）Authentication 是用于验证用户身份的过程。
在网络安全中，它是确保用户是他们声称的身份的关键。
认证的目标是验证用户提供的身份凭证（例如用户名和密码）是否与系统中存储的凭证匹配。
认证是确保只有授权用户可以访问受保护资源的第一道门槛。
第一个问题：为什么需要认证？在一个网络环境中，有许多资源是受保护的，例如个人电子邮件、银行账户等。
如果没有认证过程，任何人都可以访问这些资源，这将导致严重的安全威胁和信息泄露。
通过认证过程，系统可以确认用户的身份，并确保只有经过验证的用户可以访问资源。
第二个问题：常见的认证方式有哪些？常见的认证方式包括用户名和密码、指纹识别、面部识别、智能卡等。
用户名和密码是最常见的认证方式，用户通过提供唯一的用户名和与之关联的密码来验证自己的身份。
指纹识别和面部识别使用生物特征来验证用户的身份，而智能卡则依靠嵌入式芯片中存储的用户信息来进行认证。
第三个问题：认证的流程是怎样的？认证流程通常由以下步骤组成：1. 用户提供身份凭证：用户通过输入用户名和密码等身份凭证来开始认证过程。
2. 凭证验证：系统将用户提供的凭证与系统中存储的凭证进行比对，确定用户的身份是否有效。
3. 认证结果：认证结果将返回给用户，如果用户的身份验证成功，他们将被允许访问受保护资源。
4. 会话管理：认证成功后，系统会为用户创建一个会话，以便在一定时间内保持用户的登录状态。
第二部分：Authorization（授权）Authorization 是在通过认证之后，确定用户可以访问的资源和操作权限的过程。
authentication 和authorization -回复
authentication 和authorization -回复Authentication和Authorization在计算机科学中被广泛应用于信息安全领域。
这两个概念经常一起被提及，但它们实际上是两个不同但相互关联的概念。
在本文中，我将详细解释Authentication和Authorization的概念及其重要性。
首先，我们先来了解Authentication是什么。
Authentication是验证某个实体的身份是否合法和真实的过程。
实体可以是一个用户、一个设备或一个应用程序。
在计算机系统中，身份验证是非常重要的，因为它可以帮助确认实体是否有权访问某个资源或执行某个操作。
常见的身份验证方式包括用户名密码、指纹识别、面部识别等。
Authentication的主要目的是确认一个实体是谁，并确保实体拥有合法的身份。
通过身份验证，系统可以确定一个用户是否为合法用户，从而防止未经授权的访问和潜在的安全威胁。
身份验证通常发生在用户登录系统时，系统会要求用户提供凭据（如账户和密码），以验证用户的身份。
接下来，我们将重点讨论Authorization。
Authorization是授予或拒绝实体访问特定资源或执行特定操作的过程。
在计算机系统中，资源可以是文件、数据库、网络服务等。
授权是基于系统管理员或拥有特定权限的用户所规定的策略。
这些策略定义了哪些实体具有访问资源的权限以及可以执行哪些操作。
Authorization的目的是确保实体在访问资源时遵循系统所规定的权限和策略。
通过授权，系统可以限制某个用户对特定资源的访问权限，从而保护敏感信息和防止数据泄露。
在许多情况下，权限通常是根据用户角色或组来分类的。
例如，在一个公司的网络环境中，普通员工可能只有对公共文件夹的读权限，而管理层则可能具有对整个网络的完全访问权限。
要实现Authentication和Authorization，系统通常会使用各种安全技术和协议。
jwt验证流程
JWT验证流程什么是JWTJWT（JSON Web Token）是一种开放标准（RFC 7519），用于在各方之间传输声明。
JWT通常被用于身份验证（Authentication）和授权（Authorization）场景，可以安全地传输用户身份信息和权限。
JWT由三部分组成，用点号（.）分隔：1.头部（Header）：包含算法和类型信息2.载荷（Payload）：包含要发送的数据3.签名（Signature）：对头部和载荷进行签名以验证数据的完整性JWT验证的基本流程JWT验证的基本流程可以分为以下几步：1. 用户登录用户向服务器提供用户名和密码进行登录。
2. 服务器验证服务器验证用户提供的用户名和密码是否正确。
3. 服务器生成JWT如果用户名和密码通过验证，服务器会生成一个JWT并返回给用户。
4. JWT传输服务器将生成的JWT发送给客户端，通常通过在HTTP响应的头部设置Authorization字段的值为Bearer JWT。
5. 客户端保存JWT客户端在接收到JWT后，将其保存在本地，通常存储在Cookie或本地存储中。
6. 客户端发送JWT客户端在每次请求服务器时，将JWT带在请求的头部，通过Authorization字段将JWT发送给服务器。
请求头的格式如下：Authorization: Bearer JWT7. 服务器验证JWT服务器接收到请求后，会从请求的头部中获取JWT，并进行验证。
验证的过程包括以下几步：1.从JWT中解析出头部和载荷；2.通过头部中指定的算法和密钥，对头部和载荷进行验证，确保JWT的完整性；3.验证签名是否正确；4.如果验证通过，可以进一步解析载荷中的数据。
例如，可以从载荷中获取用户的相关信息。
8. 服务器响应如果JWT验证通过，服务器会继续处理请求，并返回相应的数据。
如果JWT验证失败，服务器会返回相应的错误信息。
JWT验证的优势和注意事项优势•简洁、轻量：JWT是一种轻量级的解决方案，信息以JSON格式存储在JWT 中，可以轻松地在各方之间传输。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Network Working Group J. Loughney Request for Comments: 3702 Nokia Category: Informational G. Camarillo Ericsson February 2004 Authentication, Authorization, and AccountingRequirements for the Session Initiation Protocol (SIP)Status of this MemoThis memo provides information for the Internet community. It doesnot specify an Internet standard of any kind. Distribution of thismemo is unlimited.Copyright NoticeCopyright (C) The Internet Society (2004). All Rights Reserved. AbstractAs Session Initiation Protocol (SIP) services are deployed on theInternet, there is a need for authentication, authorization, andaccounting of SIP sessions. This document sets out the basicrequirements for this work.Table of Contents1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 41.3. Requirements Language. . . . . . . . . . . . . . . . . . 42. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Common Requirements. . . . . . . . . . . . . . . . . . . 5 2.1.1. Communication within the Same Domain . . . . . . 5 2.1.2. Communication between Different Domains. . . . . 5 2.1.3. Discovery. . . . . . . . . . . . . . . . . . . . 5 2.1.4. Ability to Integrate Different Networks,Services and Users . . . . . . . . . . . . . . . 5 2.1.5. Updating SIP Server Entries. . . . . . . . . . . 5 2.1.6. SIP Session Changes. . . . . . . . . . . . . . . 5 2.1.7. Reliable Transfer of Protocol Messages . . . . . 5 2.1.8. Call Setup Times . . . . . . . . . . . . . . . . 6 2.1.9. Security . . . . . . . . . . . . . . . . . . . . 6 2.2. Authentication Requirements. . . . . . . . . . . . . . . 6 2.2.1. Authentication Based on SIP Requests . . . . . . 6 2.2.2. Flexible Authentication of SIP Requests. . . . . 6 Loughney & Camarillo Informational [Page 1]2.3. Authorization Requirements . . . . . . . . . . . . . . . 6 2.3.1. Ability to Authorize SIP Requests. . . . . . . . 7 2.3.2. Information Transfer . . . . . . . . . . . . . . 7 2.3.3. User De-authorization. . . . . . . . . . . . . . 7 2.3.4. User Re-authorization. . . . . . . . . . . . . . 7 2.3.5. Support for Credit Control . . . . . . . . . . . 7 2.4. Accounting Requirements. . . . . . . . . . . . . . . . . 8 2.4.1. Separation of Accounting Information . . . . . . 8 2.4.2. Accounting Information Related to SessionProgression. . . . . . . . . . . . . . . . . . . 8 2.4.3. Accounting Information Not Related to SessionProgression. . . . . . . . . . . . . . . . . . . 9 2.4.4. Support for One-Time and Session-basedAccounting Records . . . . . . . . . . . . . . . 9 2.4.5. Support for Accounting on Different MediaComponents . . . . . . . . . . . . . . . . . . . 9 2.4.6. Configuration of Accounting GenerationParameters. . . . . . . . . . . . . . . . . . . 92.4.7. Support for Arbitrary Correlations . . . . . . . 93. Scenarios. . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. WLAN Roaming Using Third Party Service Providers . . . . 113.2. Conditional Authorization. . . . . . . . . . . . . . . . 124. Security Considerations. . . . . . . . . . . . . . . . . . . . 125. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 126. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Normative References . . . . . . . . . . . . . . . . . . 136.2. Informative References . . . . . . . . . . . . . . . . . 137. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 148. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 1. IntroductionThe AAA working group is chartered to work on authentication,authorization, and accounting solutions for the Internet. This work consists of a base protocol, applications, end-to-end securityapplication, and a general architecture for providing these services [3]. The AAA working group has specified applicability of AAA-based solutions for a number of protocols (e.g., AAA requirements forMobile IP [4]).SIP is a signalling protocol for creating, modifying, and terminating different types of sessions, such as Internet phone calls, multimedia distribution, and multimedia conferences [1]. SIP sessions haveneeds for session authentication, authorization, and accounting(AAA).Loughney & Camarillo Informational [Page 2]In order to authenticate and authorize users, it is typically moreconvenient for SIP entities to communicate with an AAA sever than to attempt to store user credentials and profiles locally. SIP entities use the SIP-AAA interface to access the AAA server.This document provides requirements for the interface between SIPentities and AAA servers. While accounting requirements arediscussed, this document does not cover SIP charging or billingmechanisms.One possible use of this document would be to create an AAAapplication for SIP. Any protocol meeting the requirements outlined by this document could be used. Possible candidates, among others,are Diameter [3] and XML-based protocols following the web-servicesmodel.1.1. RADIUSThe main purpose of this document is to provide input to designersworking on AAA applications using new protocols, such as Diameter and XML-based protocols. Nevertheless, a few limited RADIUS [5]extensions may meet some of the requirements in this document (forinstance, some of the authentication requirements). We expect thatwhile RADIUS with these limited extensions will meet particularfunctional requirements, it will not meet other importantrequirements. The following are some requirements that are notexpected to be met by RADIUS:1. Section2.1.3: RADIUS does not support a discovery feature.2. Section 2.1.7: RADIUS does not support reliable messagedelivery.The following list contains the requirements that can be met byRADIUS or RADIUS extensions.1. Section2.1.2: Communication between domains does not scalewell in RADIUS. As a result, inter-domain communications aretypically handled using a proxy architecture [6].2. Section 2.1.5: RADIUS clients would need to support DynamicAuthorization [7].3. Section 2.1.9: RADIUS clients would need to rely on a lower-layer security protocol, such as IPSec, to perform mutualauthentication.Loughney & Camarillo Informational [Page 3]4. Section 2.3.3: RADIUS clients would need to support DynamicAuthorization [7].5. Section 2.3.4: RADIUS clients would need to support DynamicAuthorization [7].1.2. Terminology and AcronymsAAA: Authentication, Authorization, and AccountingAccounting: The collection of resource consumption data for thepurposes of capacity and trend analysis, cost allocation,auditing, and billing. Accounting management requires thatresource consumption be measured, rated, assigned, andcommunicated between appropriate parties [8].Accounting with credit control: The application checks the end user’s account for coverage for the requested service event chargeprior to execution of that service event.Home AAA Server: Server where user with which the user maintains anaccount relationship.SIP: Session Initiation ProtocolSIP proxies: SIP proxies are nodes which forward SIP requests andresponses, as well as make policy decisions.UAC: User Agent ClientUAS: User Agent Server1.3. Requirements LanguageIn this document, the key words "MUST", "MUST NOT", "REQUIRED","SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [2].2. RequirementsIn this section, we list the requirements. Protocol solutions arenot required to satisfy requirements for services that they do notsupport. For example, a solution that provides authenticationservices but not accounting services does not need to fulfill theaccounting requirements. It is expected that solutions will fulfill the general requirements, plus the requirements for the specificservices they are providing.Loughney & Camarillo Informational [Page 4]Section 2.1 lists general requirements, Section 2.2 listsrequirements related to authentication, Section 2.3 listsrequirements related to authorization, and Section 2.4 listsrequirements related to accounting.2.1. Common RequirementsThis section outlines general requirements on the SIP-AAA interface.2.1.1. Communication within the Same DomainThe SIP-AAA interface MUST support communications between a SIPentity and an AAA server that belong to the same domain.2.1.2. Communication between Different DomainsThe SIP-AAA interface MUST support communications between a SIPentity in one domain and an AAA server in another domain. This MAYinvolve a proxy or a redirect server architecture between bothentities.2.1.3. DiscoveryWith the information contained in the SIP messages, the SIP-AAAinterface SHOULD be able to deduce the particular AAA server that has to be queried.2.1.4. Ability to Integrate Different Networks, Services and UsersThe basic AAA architecture MUST be access independent. Serviceproviders have to be able to provide AAA services for SIP,irrespective of access method or technology.2.1.5. Updating SIP Server EntriesWhen required, the SIP-AAA interface MUST allow the AAA server toupdate the information that a SIP entity has about a user.2.1.6. SIP Session ChangesThe SIP-AAA interface MUST allow a SIP entity to inform the AAAserver about changes in the SIP session that may affect theauthorization, authentication, or accounting for that SIP session.2.1.7. Reliable Transfer of Protocol MessagesThe SIP-AAA interface SHOULD provide a reliable transfer of AAAprotocol messages between the SIP entity and the AAA server.Loughney & Camarillo Informational [Page 5]2.1.8. Call Setup TimesAAA SHOULD NOT unduly burden call setup times where appropriate. It may be reasonable to support some delay during registration, butdelay during on-going sessions (especially real-time) is problematic.2.1.9. SecurityThe SIP-AAA interface is a potential target of an attack. Aneavesdropper may attempt to obtain confidential data by sniffingmessages. Additionally, an active attacker may attempt to modify,insert, or replay messages between the SIP entity and the AAA server. Attackers may also attempt to impersonate legitimate SIP entities or AAA servers.To address these threats, the SIP-AAA interface MUST supportconfidentiality, data origin authentication, integrity, and replayprotection. In addition to this, bi-directional authenticationbetween the SIP entity and the AAA server MUST be supported as well.2.2. Authentication RequirementsThis section outlines requirements on the SIP-AAA interface relatedto authentication.2.2.1. Authentication Based on SIP RequestsThe home AAA server MUST be able to authenticate a user based on any SIP request, except CANCELs and ACKs for non-2xx final responses.CANCELs and ACKs for non-2xx final responses are hop-by-hoprequests that can be generated by proxies that do not have theuser’s credentials.2.2.2. Flexible Authentication of SIP RequestsThe SIP-AAA interface MUST be flexible enough to accommodate avariety of authentication mechanisms used to authenticate SIPrequests. In particular, the SIP-AAA interface MUST be able toaccommodate all the authentication mechanisms mandated by the SIPspecifications (e.g., Digest authentication).2.3. Authorization RequirementsThis section outlines requirements on the SIP-AAA interface relatedto authorization.Loughney & Camarillo Informational [Page 6]2.3.1. Ability to Authorize SIP RequestsThe SIP-AAA interface MUST allow AAA servers to authorize any SIPrequest, except CANCELs and ACKs for non-2xx final responses.CANCELs and ACKs for non-2xx final responses are hop-by-hoprequests that can be generated by proxies. SIP servers receiving a CANCEL or a ACK for a non-2xx final response do not challengethem, as they would do with an end-to-end request. Instead, they check at the transport or network layer that the entity sendingthe CANCEL or the ACK is the same as the one that generated therequest being canceled or acked.2.3.2. Information TransferThe SIP-AAA interface MUST allow transferring a wide range or set of information to be used to make an authorization decision. Inparticular, the SIP-AAA interface MUST allow an AAA server that ismaking an authorization decision to deliver the user profile to theSIP entity. Such a user profile may provide further informationabout the authorization decision to the SIP entity.For instance, a SIP proxy receives an INVITE from user A addressed to user B. The SIP proxy queries an AAA server and gets the followinganswer: user A is authorized to call user B, as long as the requests are routed through a particular SIP proxy server C. In this case,the SIP proxy needs to use SIP loose routing techniques to forwardthe INVITE so that it traverses SIP proxy C before reaching user B. 2.3.3. User De-authorizationThe SIP-AAA interface MUST allow the AAA server to inform a SIPentity when a particular user is no longer authorized to perform aparticular task, even if it is an ongoing task.2.3.4. User Re-authorizationThe SIP-AAA interface MUST allow the AAA server to inform a SIPentity that a particular authorization has been refreshed, andtherefore, the user is still authorized to perform a particular task.2.3.5. Support for Credit ControlThe SIP-AAA interface MUST support credit control. That is, the AAA server has to be able to check the end user’s account for coveragefor the requested service event charge before authorizing executionof that service event. Note that this requirement is related toaccounting as well.Loughney & Camarillo Informational [Page 7]Credit control is useful to implement prepaid services where allchargeable events related to a specific account are withheld from the end user when the credit of that account is exhausted or expired.2.4. Accounting RequirementsThis section outlines requirements on the SIP-AAA interface relatedto accounting. Accounting is more than simple charging. Accounting may be a simple list of services accessed, servers accessed, duration of session, etc. Charging for SIP sessions can be extremely complex and requires some additional study. It is not the intent of thissection to focus on charging.The information available to be accounted is different at SIPproxies and at SIP UAs. When end-to-end encryption is used,proxies do not have access to some parts of the SIP messages,while UAs have access to the whole messages. In addition to this, UAs typically have information about the session itself (e.g.,number of audio packets exchanged during an audio session).Therefore, even if the SIP-AAA interface provides a means totransfer a wide range of data, some SIP nodes may not have access to it. In order to design a network, it is important to analyzewhich SIP nodes will be able to generate the desired accountrecords.2.4.1. Separation of Accounting InformationAAA accounting messages MUST be able to provide granular information based on different parameters.For example, it should be possible to separate "session duration"information from other information generated via additional services (e.g., 3-way calling). Separating accounting information makes itpossible to provide accounting information to different parties based upon different aspects of the session.2.4.2. Accounting Information Related to Session ProgressionThere MUST be support in the SIP-AAA interface for accountingtransfers where the information contained in the accounting data has a direct bearing on the establishment, progression, and terminationof a session (e.g., reception of a BYE request).Loughney & Camarillo Informational [Page 8]2.4.3. Accounting Information Not Related to Session ProgressionThere MUST be support in the SIP-AAA interface for accountingtransfers where the information contained in the accounting data does NOT have a direct bearing on the establishment, progression, andtermination of a session (e.g., an instant MESSAGE that is notrelated to any session).2.4.4. Support for One-Time and Session-based Accounting RecordsThe SIP-AAA interface MUST allow SIP servers to provide relevantaccounting information for billing and inter-network settlementpurposes to the AAA servers. Both one-time event accounting records and session based (START, INTERIM, STOP records) accounting MUST besupported.2.4.5. Support for Accounting on Different Media ComponentsThe SIP-AAA interface MUST support accounting per media component(e.g., voice and video). That is, the SIP-AAA interface MUST be able to provide the AAA server with the types (e.g., voice and video) ofthe media streams of a given session.Note, however, that some SIP entities do not have access to thisinformation, which is typically carried in session descriptions. An example of a SIP entity with access to this information is a SIP UA(e.g., a gateway towards the PSTN).The SIP-AAA interface MUST enable different parties to be charged per media component.2.4.6. Configuration of Accounting Generation ParametersThe SIP-AAA interface MUST allow AAA servers to communicateparameters for accounting generation.2.4.7. Support for Arbitrary CorrelationsSome networks need to be able to relate accounting information tosome aspect of the SIP messages involved. So, the SIP-AAA interface MUST allow the AAA server to correlate a particular AAA session with any aspect of the SIP messages. For example, an AAA server thatreceives accounting information about a SIP dialog may be interested in knowing the Call-ID of the SIP dialog.Loughney & Camarillo Informational [Page 9]3. ScenariosThis section outlines some possible scenarios for SIP and AAAinteraction. These are purely illustrative examples and do notimpose any requirements.Figure 1 shows the typical call flow between a SIP proxy thatcommunicates to an AAA server that performs authentication andauthorization. All the examples are based on this flow.SIP SIP AAAUAC Proxy Server| | ||---METHOD---->| || |--Is it OK?-->|| | || |<-----OK------|| | || | |Figure 1: Call flow over the SIP-AAA interfaceThe SIP proxy receives a request with certain credentials. The SIPUAC that generated the request may have included the credentialsafter having been challenged by the proxy using a 407 (ProxyAuthentication Required) response. The SIP proxy sends a request to the AAA server asking if it is OK to provide a particular service for this request. The service may be simply routing forward the request or may consist of a more complex service. The AAA server checks that the credentials are correct (authentication), and checks the userprofile. The user profile indicates that it is OK to provide theservice, and responds to the SIP proxy. The SIP proxy provides theservice requested by the SIP UAC.Loughney & Camarillo Informational [Page 10]3.1. WLAN Roaming Using Third Party Service ProvidersUser A wants to establish a voice session over the Internet with user B. User A wants its SIP signalling to be routed through SIP proxy C, because it provides a call log service (i.e., SIP proxy C sends anemail to user A once a month with the duration of all the calls made during the month).SIP AAAUser A Proxy C Server User B| | | ||----INVITE----->| | || | | ||<-----407-------| | || | | ||------ACK------>| | || | | ||----INVITE----->| | || |---Is this OK?-->| || | | || |<------OK--------| || | | || |---------INVITE------------------>|| | | || |-Accounting msg->| || | | |Figure 2: WLAN roaming userUser A accesses the Internet using a WLAN access outside his homedomain. User A, user B, SIP proxy C, and the home AAA server of user A are all in different domains.SIP proxy C challenges the initial INVITE from user A with a 407(Proxy Authentication Required) response, and user A reissues theINVITE including his credentials. SIP proxy C consults user A’s home AAA server, which confirms that the credentials belong to user A and that SIP proxy C can go ahead and provide its service for that call. SIP proxy C routes the INVITE forward towards user B and sends anaccounting message to the AAA server, which will be used later tocharge user A for the service provided by SIP proxy C.Loughney & Camarillo Informational [Page 11]3.2. Conditional AuthorizationUser A is not in his home domain, but he still uses SIP proxy C(which is in user’s A home domain) as the outbound proxy for anINVITE. SIP proxy C consults the home AAA server, which indicatesthat requests from user A have to be routed through SIP proxy D. SIP proxy C uses SIP loose routing so that the INVITE traverses D before reaching its destination. SIP proxy D will provide a call logservice for user A.SIP AAA SIPUser A Proxy C Server Proxy D| | | ||----INVITE----->| | || | | ||<-----407-------| | || | | ||------ACK------>| | || | | ||----INVITE----->| | || |------Is this OK?---->| || | | || |<-OK if routed thru D-| || | | || |---------INVITE------------------>|| | | |Figure 3: Conditional Authorization4. Security ConsiderationsSecurity is a critical requirement of the SIP-AAA Interface. Section 2.1.9 describes the threats and security requirements. Sections 2.2 and 2.3 elaborate on the authentication and authorizationrequirements.5. AcknowledgementsThe authors would like to thank the participants of the SIP interimmeeting, May 2002 for their comments. The authors would also thankHarri Hakala, Mary Barns, Pete McCann, Jari Arkko, Aki Niemi, JuhaHeinanen, Henry Sinnreich, Allison Mankin, and Bernard Aboba fortheir comments.The authors would like to thank the authors of the "AAA Requirements for IP Telephony/Multimedia" document, as it provided a basis forsome of the information contained in this document.Loughney & Camarillo Informational [Page 12]6. References6.1. Normative References[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:Session Initiation Protocol", RFC 3261, June 2002.[2] Bradner, S., "Key words for use in RFCs to indicate RequirementLevels", BCP 14, RFC 2119, March 1997.6.2. Informative References[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,"Diameter Base Protocol", RFC 3588, September 2003.[4] Glass, S., Hiller, T., Jacobs, S. and C. Perkins, "Mobile IPAuthentication, Authorization, and Accounting Requirements", RFC 2977, October 2000.[5] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "RemoteAuthentication Dial in User Service (RADIUS)", RFC 2865, June2000.[6] Aboba, B. and J. Vollbrecht, "Proxy Chaining and PolicyImplementation in Roaming", RFC 2607, June 1999.[7] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba,"Dynamic Authorization Extensions to Remote Authentication Dialin User Service (RADIUS)", RFC 3576, July 2003.[8] Aboba, B., Arkko, J. and D. Harrington, "Introduction toAccounting Management", RFC 2975, October 2000.Loughney & Camarillo Informational [Page 13]7. Authors’ AddressesJohn LoughneyNokiaItamerenkatu 11-1300180 HelsinkiFinlandEMail: John.Loughney@Gonzalo CamarilloEricssonAdvanced Signalling Research Lab.FIN-02420 JorvasFinlandEMail: Gonzalo.Camarillo@Loughney & Camarillo Informational [Page 14]8. Full Copyright StatementCopyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 andexcept as set forth therein, the authors retain all their rights.This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHEREPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OFTHE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual PropertyThe IETF takes no position regarding the validity or scope of anyIntellectual Property Rights or other rights that might be claimedto pertain to the implementation or use of the technologydescribed in this document or the extent to which any licenseunder such rights might or might not be available; nor does itrepresent that it has made any independent effort to identify anysuch rights. Information on the procedures with respect torights in RFC documents can be found in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and anyassurances of licenses to be made available, or the result of anattempt made to obtain a general license or permission for the useof such proprietary rights by implementers or users of thisspecification can be obtained from the IETF on-line IPR repositoryat /ipr.The IETF invites any interested party to bring to its attentionany copyrights, patents or patent applications, or otherproprietary rights that may cover technology that may be requiredto implement this standard. Please address the information to theIETF at ietf-ipr@.AcknowledgementFunding for the RFC Editor function is currently provided by theInternet Society.Loughney & Camarillo Informational [Page 15]。