Network Working Group J. Peterson
Request for Comments: 4484 NeuStar
Category: Informational J. Polk
Cisco
D. Sicker
CU Boulder
H. Tschofenig
Siemens
August 2006
Network Working Group J. Peterson
Request for Comments: 4484 NeuStar
Category: Informational J. Polk
Cisco
D. Sicker
CU Boulder
H. Tschofenig
Siemens
August 2006
Trait-Based Authorization Requirements for the Session Initiation Protocol (SIP)
会话启动协议（SIP）基于特征的授权要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol (SIP). While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant in a session. This approach provides a richer framework for authorization, as well as allows greater privacy for users of an identity system.
本文档列出了一组与会话启动协议（SIP）基于特征的授权相关的需求。虽然基本SIP规范中描述了一些身份验证机制，但基于特征的授权提供了用于根据会话参与者的属性做出策略决策的信息。这种方法提供了一个更丰富的授权框架，并允许身份系统用户拥有更大的隐私。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Trait-Based Authorization Framework .............................4
4. Example Use Cases ...............................................7
4.1. Settlement for Services ....................................7
4.2. Associating Gateways with Providers ........................7
4.3. Permissions on Constrained Resources .......................8
4.4. Managing Priority and Precedence ...........................9
4.5. Linking Different Protocols ...............................10
5. Trait-Based Authorization Requirements .........................11
6. Security Considerations ........................................13
7. Acknowledgements ...............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................13
1. Introduction ....................................................2
2. Terminology .....................................................4
3. Trait-Based Authorization Framework .............................4
4. Example Use Cases ...............................................7
4.1. Settlement for Services ....................................7
4.2. Associating Gateways with Providers ........................7
4.3. Permissions on Constrained Resources .......................8
4.4. Managing Priority and Precedence ...........................9
4.5. Linking Different Protocols ...............................10
5. Trait-Based Authorization Requirements .........................11
6. Security Considerations ........................................13
7. Acknowledgements ...............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................13
This document explores requirements of the Session Initiation Protocol (SIP) [1] for enabling trait-based authorization. This effort stems from the recognition that when SIP requests are received by a User Agent Server (UAS), there are authorization requirements that are orthogonal to ascertaining of the identity of the User Agent Client (UAC). Supplemental authorization information might allow the UAS to implement non-identity-based policies that depend on further attributes of the principal that originated a SIP request.
本文档探讨了会话启动协议（SIP）[1]对启用基于特征的授权的要求。这项工作源于认识到，当用户代理服务器（UAS）接收到SIP请求时，存在与确定用户代理客户端（UAC）的身份正交的授权需求。补充授权信息可能允许UAS实施非基于身份的策略，该策略取决于发起SIP请求的主体的其他属性。
For example, in traditional SIP authorization architectures, the mere fact that a UAC has been authenticated by a UAS doesn't mean that the UAS will grant the UAC full access to its services or capabilities -- in most instances, a UAS will compare the authenticated identity of the UAC to some set of users that are permitted to make particular requests (as a way of making an authorization decision). However, in large communities of users with few preexisting relationships (such as federations of discrete service providers), it is unlikely that the authenticated identity of a UAC alone will give a UAS sufficient information to decide how to handle a given request.
例如，在传统的SIP授权架构中，UAC已通过UAS认证的事实并不意味着UAS将授予UAC对其服务或功能的完全访问权——在大多数情况下，UAS将UAC的认证身份与允许发出特定请求的某组用户进行比较（作为做出授权决策的一种方式）。然而，在先前关系很少的大型用户社区（如离散服务提供商的联合会）中，仅UAC的身份验证不太可能为UAS提供足够的信息来决定如何处理给定的请求。
Trait-based authorization entails an assertion by an authorization service of attributes associated with an identity. An assertion is a sort of document consisting of a set of these attributes that are wrapped within a digital signature provided by the party that generates the assertion (the operator of the authorization service). These attributes describe the 'trait' or 'traits' of the identity in question -- facts about the principal corresponding to that identity. For example, a given principal might be a faculty member at a
基于特征的授权需要授权服务断言与身份相关的属性。断言是一种文档，由一组属性组成，这些属性封装在生成断言的一方（授权服务的操作员）提供的数字签名中。这些属性描述了相关身份的“特征”或“特征”——与该身份对应的主体的事实。例如，某个校长可能是某个学校的教员
university. An assertion for that principal's identity might state that they have the 'trait' of 'is a faculty member', and the assertion would be issued (and signed) by a university. When a UAS receives a request with this trait assertion, if it trusts the signing university, it can make an authorization decision based on whether or not faculty members are permitted to make the request in question, rather than just looking at the identity of the UAC and trying to discern whether or not they are a faculty member through some external means. Thus, these assertions allow a UAS to authorize a SIP request without having to store or access attributes associated with the identity of the UAC itself. Even complex authorization decisions based the presence of multiple disjointed attributes are feasible; for example, a 'faculty' member could be part of the 'chemistry' department, and both of these traits could be used to make authorization decisions in a given federation.
大学校长身份的声明可能表明他们具有“是教员”的“特征”，并且声明将由大学发布（并签字）。当UAS收到带有此特征断言的请求时，如果它信任签名大学，它可以根据是否允许教员提出相关请求做出授权决定，而不是仅仅看UAC的身份，试图通过一些外部手段辨别他们是否是教员。因此，这些断言允许UAS授权SIP请求，而无需存储或访问与UAC自身身份相关联的属性。即使是基于多个分离属性的复杂授权决策也是可行的；例如，一名“教员”成员可以是“化学”系的一部分，而这两种特征都可以用于在给定的联盟中做出授权决策。
It is easy to see how traits can be used in a single administrative domain, for example, a single university, where all users are managed under the same administration. In order for traits to have a broader usage for services like SIP, which commonly are not bounded by administrative domains, domains that participate in a common authorization scheme must federate with one another. The concept of federation is integral to any trait-based authorization scheme. Domains that federate with one another agree on the syntax and semantics of traits -- without this consensus, trait-based authorization schemes would only be useful in an intradomain context. A federation is defined as a set of administrative domains that implement common policies regarding the use and applicability of traits for authorization decisions. Federation necessarily implies a trust relationship, and usual implies some sort of pre-shared keys or other means of cryptographic assurance that a particular assertion was generated by an authorization service that participates in the federation.
很容易看出traits是如何在单个管理域中使用的，例如，在一所大学中，所有用户都在同一个管理下管理。为了使traits能够更广泛地用于SIP等服务（通常不受管理域的限制），参与公共授权方案的域必须彼此联合。联邦的概念对于任何基于特征的授权方案都是不可或缺的。相互联合的域在特征的语法和语义上达成一致——如果没有这种一致，基于特征的授权方案将只在域内上下文中有用。联合体被定义为一组管理域，这些管理域实现关于授权决策特征的使用和适用性的公共策略。联合必然意味着信任关系，通常意味着某种预共享密钥或其他加密保证手段，即特定断言是由参与联合的授权服务生成的。
In fact, when trait-based authorization is used, an assertion of attributes can be presented to a UAS instead of the identity of user of the UAC. In many cases, a UAS has no need to know who, exactly, has made a request -- knowing the identity is only a means to the end of matching that identity to policies that actually depend on traits independent of identity. This fact allows trait-based authorization to offer a very compelling privacy and anonymity solution. Identity becomes one more attribute of an assertion that may or may not be disclosed to various destinations.
事实上，当使用基于特征的授权时，属性的断言可以呈现给UAS，而不是UAC用户的身份。在许多情况下，UAS不需要知道到底是谁提出了请求——知道身份只是将身份与实际上依赖于独立于身份的特征的政策相匹配的一种手段。这一事实使得基于特征的授权能够提供非常引人注目的隐私和匿名解决方案。身份成为断言的一个或多个属性，这些属性可能会或不会被披露给不同的目的地。
Trait-based authorization for SIP depends on authorization services that are trusted by both the UAC and the UAS that wish to share a session. For that reason, the authorization services described in this document are most applicable to clients either in a single
基于特征的SIP授权取决于UAC和希望共享会话的UAS都信任的授权服务。因此，本文档中描述的授权服务最适用于单个客户机
domain or in federated domains that have agreed to trust one another's authorization services. This could be common in academic environments, or business partnerships that wish to share attributes of principals with one another. Some trait-based authorization architectures have been proposed to provide single sign-on services across multiple providers.
域或已同意信任彼此的授权服务的联合域中。这可能在学术环境中很常见，或者在希望彼此共享校长属性的商业伙伴关系中也很常见。已经提出了一些基于特征的授权体系结构来跨多个提供商提供单点登录服务。
Although trait-based identity offers an alternative to traditional identity architectures, this effort should be considered complementary to the end-to-end cryptographic SIP identity effort [3]. An authentication service might also act as an authorization service, generating some sort of trait assertion token instead of an authenticated identity body.
尽管基于特征的身份提供了传统身份体系结构的替代方案，但这项工作应被视为是对端到端加密SIP身份工作的补充[3]。身份验证服务还可以充当授权服务，生成某种类型的特征断言令牌，而不是经过身份验证的标识体。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant SIP implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”将按照RFC 2119[2]中的描述进行解释，并表示符合SIP实施的要求级别。
A trait-based authorization architecture entails the existence of an authorization service. Devices must send requests to an authorization service in order to receive an assertion that can be used in the context of a given network request. Different network request types will often necessitate different or additional attributes in assertions from the authorization service.
基于特征的授权体系结构需要授权服务的存在。设备必须向授权服务发送请求，以便接收可在给定网络请求的上下文中使用的断言。不同的网络请求类型通常需要来自授权服务的断言中的不同或附加属性。
For the purposes of SIP, SIP requests might be supplied to an authorization service to provide the basis for an assertion. It could be the case that a user agent will take a particular SIP request, such as an INVITE, for which it wishes to acquire an assertion and forward this to the authorization service (in a manner similar to the way that an authenticated identity body is requested in [3]). User agents might also use a separate protocol to request an assertion. In either case, the client will need to authenticate itself to an authorization service before it receives an assertion. This authentication could use any of the standard mechanisms described in RFC 3261 [1], or use some other means of authentication.
出于SIP的目的，可以将SIP请求提供给授权服务，以提供断言的基础。可能的情况是，用户代理将接受特定的SIP请求，例如INVITE，它希望获取断言并将其转发给授权服务（以类似于[3]中请求认证身份主体的方式）。用户代理也可以使用单独的协议来请求断言。在这两种情况下，客户机都需要在收到断言之前向授权服务进行身份验证。此身份验证可以使用RFC 3261[1]中描述的任何标准机制，或者使用其他身份验证方法。
Once a SIP UA has an assertion, it will need some way to carry an assertion within in a SIP request. It's possible that this assertion could be provided by reference or by value. For example, a SIP UA could include a MIME body within a SIP request that contains the assertion; this would be inclusion by value. Alternatively, content
一旦SIP UA拥有断言，它将需要某种方式在SIP请求中携带断言。这个断言可能是通过引用或值提供的。例如，SIP UA可以在包含断言的SIP请求中包括MIME主体；这将是按值包含。或者，内容
indirection [4], or some new header, could be used to provide a URI (perhaps an HTTP URL) where interested parties could acquire the assertion; this is inclusion by reference.
间接寻址[4]或一些新的报头可用于提供URI（可能是HTTP URL），相关方可在其中获取断言；这是通过引用包含的。
The basic model is as follows:
基本模式如下：
+----------------+ | |
| +------------+ | Request | +------------+ |
| | Entity | |------------------------>| | Assertion | |
| | requesting | | | | Granting | |
| | authz | |<------------------------| | Entity | |
| | assertions | | Assertion | +------------+ |
| +------------+ | | ^ |
| | | | . Trust |
| | | | . Rel. |
| | | | v |
| | | | +------------+ |
| Transfer | | | Assertion | |
| | | | | Verifying | |
| | | | | Entity | |
| | | | +------------+ |
| | | | |
| v | +----------------+
| +------------+ | Service Request + ^ |
| | Entity | | Assertion | |
| | using authz| | -----------------------------+ |
| | assertion | | |
| +------------+ | <-------------------------------+
+----------------+ Response/Error
+----------------+ | |
| +------------+ | Request | +------------+ |
| | Entity | |------------------------>| | Assertion | |
| | requesting | | | | Granting | |
| | authz | |<------------------------| | Entity | |
| | assertions | | Assertion | +------------+ |
| +------------+ | | ^ |
| | | | . Trust |
| | | | . Rel. |
| | | | v |
| | | | +------------+ |
| Transfer | | | Assertion | |
| | | | | Verifying | |
| | | | | Entity | |
| | | | +------------+ |
| | | | |
| v | +----------------+
| +------------+ | Service Request + ^ |
| | Entity | | Assertion | |
| | using authz| | -----------------------------+ |
| | assertion | | |
| +------------+ | <-------------------------------+
+----------------+ Response/Error
The entity requesting authorization assertions (or the entity that gets some assertions granted) and the entity using these authorization assertions might be co-located in the same host or domain, or they might be entities in different domains that share a federate with one another. The same is true for the entity that grants these assertions to a particular entity and the entity that verifies these assertions.
请求授权断言的实体（或授予某些断言的实体）和使用这些授权断言的实体可能位于同一主机或域中，或者它们可能是彼此共享联邦成员的不同域中的实体。将这些断言授予特定实体的实体和验证这些断言的实体也是如此。
From a protocol point of view, it is worth noting that the process of obtaining some assertions might happen some time before the usage of these assertions. Furthermore, different protocols might be used and the assertions may have a lifetime that might allow that these assertions are presented to the verifying entity multiple times (during the lifetime of the assertion).
从协议的角度来看，值得注意的是，获取某些断言的过程可能发生在使用这些断言之前。此外，可能会使用不同的协议，并且断言的生命周期可能允许这些断言多次呈现给验证实体（在断言的生命周期内）。
Some important design decisions are associated with carrying assertions in a SIP request. If an assertion is carried by value, or uses a MIME-based content indirection system, then proxy servers will
一些重要的设计决策与SIP请求中的断言相关。如果断言由值携带，或者使用基于MIME的内容间接寻址系统，那么代理服务器将
be unable to inspect the assertion themselves. If the assertion were referenced in a header, however, it might be possible for the proxy to acquire and inspect the assertion itself. There are certainly architectures in which it would be meaningful for proxy servers to apply admissions controls based on assertions.
无法检查断言本身。但是，如果在头中引用了断言，那么代理可能会获取并检查断言本身。当然，在某些体系结构中，代理服务器应用基于断言的许可控制是有意义的。
It is also the case that carrying assertions by reference allows versatile access controls to be applied to the assertion itself. For instance, an HTTP URL where an assertion could be acquired could indicate a web server that challenged requests, and only allowed certain authorized sources to inspect the assertion, or that provided different versions of the assertion depending on who is asking. When a SIP UA initiates a request with privacy controls [5], a web server might provide only trait information ('faculty', 'student', or 'staff') to most queries, but provide more detailed information, including the identity of the originator of the SIP request, to certain privileged askers. The end-users that make requests should have some way to inform authorization services of the attributes that should be shared with particular destinations.
同样，通过引用携带断言允许对断言本身应用多种访问控制。例如，可以获取断言的HTTP URL可能表示对请求提出质疑的web服务器，并且只允许某些授权来源检查断言，或者根据请求者提供不同版本的断言。当SIP UA通过隐私控制发起请求[5]时，web服务器可能只向大多数查询提供特征信息（“教员”、“学生”或“员工”），但向某些特权询问者提供更详细的信息，包括SIP请求发起人的身份。发出请求的最终用户应该有某种方式通知授权服务应该与特定目的地共享的属性。
Assertions themselves might be scoped to a particular SIP transaction or SIP dialog, or they might have a longer lifetime. The recipient of an assertion associated with a SIP request needs to have some way to verify that the authorization service intended that this assertion could be used for the request in question. However, the format of assertions is not specified by these requirements.
断言本身的作用域可能是特定的SIP事务或SIP对话框，或者它们的生命周期可能更长。与SIP请求相关联的断言的接收者需要有某种方式来验证授权服务是否打算将此断言用于所讨论的请求。但是，断言的格式没有在这些需求中指定。
Trait assertions for responses to SIP requests are outside the scope of these requirements; it is not clear if there is any need for the recipient of a request to provide authorization data to the requestor.
SIP请求响应的特征断言超出了这些要求的范围；不清楚请求的接收者是否需要向请求者提供授权数据。
Trait-based authorization has significant applicability to SIP. There are numerous instances in which it is valuable to assert particular facts about a principal other than the principal's identity to aid the recipient of a request in making an authorization policy decision. For example, a telephony service provider might assert that a particular user is a 'customer' as a trait. An emergency services network might indicate that a particular user has a privileged status as a caller.
基于特征的授权对SIP具有重要的适用性。在许多情况下，断言委托人身份以外的关于委托人的特定事实是有价值的，以帮助请求接收者做出授权策略决策。例如，电话服务提供商可能会将某个特定用户作为一个特征断言为“客户”。紧急服务网络可能指示特定用户具有作为呼叫方的特权状态。
The following use cases are by no means exhaustive, but provide a few high-level examples of the sorts of services that trait-based authorization might provide. All of the cases below consider interdomain usage of authorization assertions.
以下用例绝非详尽无遗，但提供了一些基于特征的授权可能提供的服务种类的高级示例。下面的所有案例都考虑授权断言的域间使用。
When endpoints in two domains share real-time communications services, sometimes there is a need for the domains to exchange accounting and settlement information in real-time. The operators of valuable resources (for example, Public Switched Telephone Network (PSTN) trunking, conference bridges, or the like) in the called domain may wish to settle with the calling domain (either with the operators of the domain or a particular user), and some accounting operations might need to complete before a call is terminated. For example, a caller in one domain might want to access a conference bridge in another domain, and the called domain might wish to settle for the usage of the bridge with the calling domain. Or in a wireless context, a roaming user might want to use services in a visited network, and the visited network might need to understand how to settle with the user's home network for these services.
当两个域中的端点共享实时通信服务时，有时需要域实时交换记帐和结算信息。被叫域中的有价值资源（例如，公共交换电话网（PSTN）中继、会议网桥等）的运营商可能希望与主叫域（与域的运营商或特定用户）和解，并且一些计费操作可能需要在呼叫终止之前完成。例如，一个域中的调用方可能希望访问另一个域中的会议网桥，而被调用域可能希望与调用域一起使用该网桥。或者在无线上下文中，漫游用户可能希望使用到访网络中的服务，并且到访网络可能需要了解如何与用户的家庭网络解决这些服务。
Assuming that the calling domain constitutes some sort of commercial service capable of exchanging accounting information, the called domain may want to verify that the remote user has a billable account in good standing before allowing a remote user access to valuable resources. Moreover, the called domain may need to discover the network address of an accounting server and some basic information about how to settle with it.
假设主叫域构成某种能够交换会计信息的商业服务，则被叫域可能希望在允许远程用户访问有价值的资源之前验证远程用户是否拥有信誉良好的计费帐户。此外，被调用域可能需要发现记帐服务器的网络地址以及有关如何解决该问题的一些基本信息。
An authorization assertion created by the calling domain could provide the called domain with an assurance that a user's account can settle for a particular service. In some cases, no further information may be required to process a transaction, but if more specific accounting data is needed, traits could also communicate the network address of an accounting server, the settlement protocol that should be used, and so on.
由调用域创建的授权断言可以向被调用域提供一个保证，即用户的帐户可以结算特定的服务。在某些情况下，处理交易可能不需要进一步的信息，但如果需要更具体的会计数据，traits还可以通信会计服务器的网络地址、应使用的结算协议等。
Imagine a case where a particular telephone service provider has deployed numerous PSTN-SIP gateways. When calls come in from the PSTN, they are eventually proxied to various SIP user agents. Each SIP user agent server is interested to know the identity of the PSTN caller, of course, which could be given within SIP messages in any number of ways (in SIP headers, bodies, or what have you). However,
设想一个特定的电话服务提供商部署了许多PSTN-SIP网关的情况。当来自PSTN的呼叫进入时，它们最终被代理到各种SIP用户代理。当然，每个SIP用户代理服务器都有兴趣知道PSTN呼叫者的身份，这些身份可以在SIP消息中以任何方式给出（在SIP头、主体或您所拥有的内容中）。然而
in order for the recipient to be able to trust the identity (in this instance, the calling party's telephone number) stated in the call, they must first trust that the call originated from the gateway and that the gateway is operated by a known (and trusted) provider.
为了使接收者能够信任呼叫中所述的身份（在本例中为主叫方的电话号码），他们必须首先信任呼叫来自网关，并且网关由已知（且受信任）提供商操作。
There are a number of ways that a service provider might try to address this problem. One possibility would be routing all calls from gateways through a recognizable 'edge' proxy server (say, 'sip.example.com'). Accordingly, any SIP entity that received a request via the edge proxy server (assuming the use of hop-by-hop mutual cryptographic authentication) would know the service provider from whom the call originated. However, it is possible that requests from the originating service provider's edge proxy might be proxied again before reaching the destination user agent server, and thus in many cases the originating service provider's identity would be known only transitively. Moreover, in many architectures requests that did not originate from PSTN gateways could be sent through the edge proxy server. In the end analysis, the recipient of the request is less interested in knowing which carrier the request came from than in knowing that the request came from a gateway.
服务提供商可以通过多种方式解决此问题。一种可能是通过可识别的“边缘”代理服务器（比如“sip.example.com”）路由所有来自网关的呼叫。因此，通过边缘代理服务器接收请求的任何SIP实体（假设使用逐跳相互密码认证）都将知道发起呼叫的服务提供商。然而，来自始发服务提供商的边缘代理的请求可能在到达目的地用户代理服务器之前再次被代理，因此在许多情况下，始发服务提供商的身份将只能通过传递方式被知道。此外，在许多体系结构中，并非源自PSTN网关的请求可以通过边缘代理服务器发送。归根结底，与知道请求来自网关相比，请求的接收者对知道请求来自哪个运营商更感兴趣。
Another possible solution is to issue certificates to every gateway corresponding to the hostname of the gateway ('gateway1.example.com'). Gateways could therefore sign SIP requests directly, and this property could be preserved end-to-end. But depending on the public key infrastructure, this could, however, become costly for large numbers of gateways, and moreover a user agent server that receives the request has no direct assurance from a typical certificate that the host is in fact a gateway just because it happens to be named 'gateway1'.
另一种可能的解决方案是向与网关主机名（“gateway1.example.com”）对应的每个网关颁发证书。因此，网关可以直接对SIP请求进行签名，并且可以端到端保留此属性。但是，根据公钥基础设施的不同，对于大量网关来说，这可能会变得昂贵，而且接收请求的用户代理服务器无法直接从典型证书中保证主机实际上是网关，因为它恰好被命名为“gateway1”。
Trait-based authorization would enable the trait 'is a gateway' to be associated with an assertion that is generated by the service provider (i.e., signed by 'example.com'). Since these assertions would travel end-to-end from the originating service provider to the destination user agent server, SIP requests that carry them can pass through any number of intermediaries without discarding cryptographic authentication information. This mechanism also does not rely on hostname conventions to identify what constitutes a gateway and what does not -- it relies on an explicit and unambiguous attribute in an assertion.
基于特征的授权将使特征“是网关”与服务提供商生成的断言相关联（即，由“example.com”签名）。由于这些断言将端到端地从原始服务提供商传输到目标用户代理服务器，因此携带它们的SIP请求可以通过任意数量的中介，而不会丢弃加密身份验证信息。这种机制也不依赖主机名约定来识别网关的组成部分和不构成网关的部分——它依赖于断言中的明确属性。
Consider a scenario wherein two universities are making use of a videoconferencing service over a constrained-bandwidth resource. Both universities would like to enforce policies that determine how this constrained bandwidth will be allocated to members of their
考虑一个场景，其中两所大学正在使用受限的带宽资源上的视频会议服务。这两所大学都希望实施政策，确定如何将这种有限的带宽分配给其所在学校的成员
respective communities. For example, faculty members might have privileges to establish videoconferences during the day, while students might not. Faculty might also be able to add students to a particular videoconference dynamically, or otherwise moderate the content or attendance of the conference, whereas students might participate only more passively.
各自的社区。例如，教员可能有权在白天建立视频会议，而学生可能没有。教员还可以动态地将学生添加到特定的视频会议中，或者以其他方式调节会议的内容或出席率，而学生可能只是被动地参与。
Trait-based authorization is ideal for managing authorization decisions that are predicated on membership in a group. Rather than basing access on individual users, levels (or roles) could be assigned that would be honored by both universities, since they both participate in the same federation.
基于特征的授权非常适合管理基于组成员资格的授权决策。由于两所大学都参加同一个联合会，因此可以分配级别（或角色），而不是基于单个用户的访问权限。
If the federation honored the traits "faculty", "staff", and "student", they could be leveraged to ensure appropriate use of the network resource between universities participating in the federation. An assertion would then be attached to every request to establish a session that indicated the role of the requestor. Only if the requestor has the appropriate trait would the session request be granted. Ideally, these policies would be enforced by intermediaries (SIP proxy servers) that are capable of inspecting and verifying the assertions.
如果联合会尊重“教员”、“教职员工”和“学生”的特征，就可以利用这些特征确保在参与联合会的大学之间适当使用网络资源。然后，每个请求都会附加一个断言，以建立一个指示请求者角色的会话。只有当请求者具有适当的特征时，会话请求才会被批准。理想情况下，这些策略将由能够检查和验证断言的中介（SIP代理服务器）实施。
There is a significant amount of interest in the Internet telephony community in assigning certain calls a 'priority' based on the identity of the user, with the presumption that prioritized calls will be granted preferential treatment when network resources are scarce. Different domains might have different criteria for assigning priority, and it is unlikely that a domain would correlate the identity of a non-local user with the need for priority, even in situations where domains would like to respect one another's prioritization policies.
互联网电话社区对基于用户身份为某些呼叫分配“优先级”非常感兴趣，假定在网络资源稀缺时优先呼叫将获得优惠待遇。不同的域可能具有不同的优先级分配标准，并且域不太可能将非本地用户的身份与优先级需求相关联，即使在域希望尊重彼此的优先级策略的情况下也是如此。
Existing proposals have focused largely on adding a new header field to SIP that might carry a priority indicator. This use case does not challenge this strategy, but merely shows by way of example how this requirement might be met with a trait-based authorization system. As such, the limitations of the header field approach will not be contrasted here with a hypothetical trait-based system.
现有的提议主要集中在为SIP添加一个新的标题字段，该字段可能带有优先级指示器。这个用例并没有挑战这个策略，只是通过示例展示了如何使用基于特征的授权系统来满足这个需求。因此，本文不会将标题字段方法的局限性与假设的基于特征的系统进行对比。
An assertion created by a domain for a particular request might have an associated 'priority' attribute. Recipients of the request could inspect and verify the signature associated with the assertion to determine which domain had authenticated the user and made the
域为特定请求创建的断言可能具有关联的“优先级”属性。请求的接收者可以检查和验证与断言相关联的签名，以确定哪个域对用户进行了身份验证并进行了验证
priority assessment. If the assertion's creator is trusted by the evaluator, the given priority could be factored into any relevant request processing.
优先评估。如果断言的创建者受到评估器的信任，则可以将给定的优先级考虑到任何相关的请求处理中。
Cryptographic computations are expensive and computing authorization decisions might require a lot of time and multiple messages between the entity enforcing the decisions and the entity computing the authorization decision. Particularly in a mobile environment these entities are physically separated -- or not even in the same administrative domain. Accordingly, the notion of "single sign-on" is another potential application of authorization assertions and trait-based authorization -- a user is authenticated and authorized through one protocol, and can reuse the resulting authorization assertion in other, potential unrelated protocol exchanges.
密码计算是昂贵的，并且计算授权决策可能需要大量的时间和执行决策的实体与计算授权决策的实体之间的多条消息。特别是在移动环境中，这些实体在物理上是分离的——甚至不在同一个管理域中。因此，“单点登录”的概念是授权断言和基于特征的授权的另一个潜在应用——用户通过一个协议进行身份验证和授权，并且可以在其他潜在的无关协议交换中重用由此产生的授权断言。
For example, in some environments it is useful to make the authorization decision for a "high-level" service (such as a voice call). The authorization for the "voice call" itself might include authorization for SIP signaling and also for lower-level network functions, for example, a quality-of-service (QoS) reservation to improve the performance of real-time media sessions established by SIP. Since the SIP signaling protocol and the QoS reservation protocol are totally separate, it is necessary to link the authorization decisions of the two protocols. The authorization decision might be valid for a number of different protocol exchanges, for different protocols and for a certain duration or some other attributes.
例如，在某些环境中，为“高级”服务（如语音呼叫）做出授权决策非常有用。对“语音呼叫”本身的授权可以包括对SIP信令的授权，也可以包括对较低级别的网络功能的授权，例如，服务质量（QoS）预留，以改进由SIP建立的实时媒体会话的性能。由于SIP信令协议和QoS保留协议是完全独立的，因此有必要将这两个协议的授权决策链接起来。授权决策可能对许多不同的协议交换、不同的协议以及特定的持续时间或某些其他属性有效。
To enable this mechanism as part of the initial authorization step, an authorization assertion is returned to the end host of the SIP UAC (cryptographically protected). If QoS is necessary, the end host might reuse the returned assertion in the QoS signaling protocol. Any domains in the federation that would honor the assertion generated to authorize the SIP signaling would similarly honor the use of the assertion in the context of QoS. Upon the initial generation of the assertion by an authorization server, traits could be added that specify the desired level of quality that should be granted to the media associated with a SIP session.
为了作为初始授权步骤的一部分启用此机制，将向SIP UAC（受加密保护）的终端主机返回授权断言。如果需要QoS，终端主机可以在QoS信令协议中重用返回的断言。联合体中的任何域，如果支持为授权SIP信令而生成的断言，也同样支持在QoS上下文中使用该断言。在授权服务器最初生成断言时，可以添加特征，以指定应授予与SIP会话相关联的媒体的所需质量级别。
The following are the constraints and requirements for trait-based authorization in SIP:
以下是SIP中基于特征的授权的约束和要求：
1. The mechanism MUST support a way for SIP user agents to embed an authorization assertion in SIP requests. Assertions can be carried either by reference or by value.
1. 该机制必须支持SIP用户代理在SIP请求中嵌入授权断言的方法。断言可以通过引用或值进行。
2. The mechanism MUST allow SIP UACs to deliver to an authorization service those SIP requests that need to carry an assertion. The mechanism SHOULD also provide a way for SIP intermediaries to recognize that an assertion will be needed, and either forward requests to an authorization service themselves or notify the UAC of the need to do so.
2. 该机制必须允许SIP UAC将需要携带断言的SIP请求交付给授权服务。该机制还应为SIP中介机构提供一种方式，使其能够识别将需要断言，并将请求转发给授权服务本身，或通知UAC需要这样做。
3. Authorization services MUST be capable of delivering an assertion to a SIP UAC, either by reference or by value. It MAY also be possible for an authorization service to add assertions to requests itself, if the user profile permits this (for example, through the use of content-indirection as described in [4]).
3. 授权服务必须能够通过引用或值向SIP UAC传递断言。如果用户配置文件允许，授权服务也可以向请求本身添加断言（例如，通过使用[4]中描述的内容间接寻址）。
4. Authorization services MUST have a way to authenticate a SIP UAC.
4. 授权服务必须具有对SIP UAC进行身份验证的方法。
5. The assertions generated by authorization services MUST be capable of providing a set of values for a particular trait that a principal is entitled to claim.
5. 授权服务生成的断言必须能够为主体有权声明的特定特征提供一组值。
6. The mechanism MUST provide a way for authorized SIP intermediaries (e.g., authorized proxy servers) to inspect assertions.
6. 该机制必须为授权SIP中介（例如，授权代理服务器）提供一种检查断言的方法。
7. The mechanism MUST have a single baseline mandatory-to-implement authorization assertion scheme. The mechanism MUST also allow support of other assertion schemes, which would be optional to implement. One example of an assertion scheme is Security Assertion Markup Language (SAML) [6] and another is RFC 3281 X.509 Attribute Certificates [7].
7. 该机制必须有一个强制的基线来实现授权断言方案。该机制还必须允许支持其他断言方案，这些方案是可选的。断言方案的一个示例是安全断言标记语言（SAML）[6]，另一个示例是RFC 3281 X.509属性证书[7]。
8. The mechanism MUST ensure reference integrity between a SIP request and assertion. Reference integrity refers to the relationship between a SIP message and the assertion authorizing the message. For example, a reference integrity check would compare the sender of the message (as expressed in the SIP request, for example, in the "From" header field value) with the identity provided by the assertion. Reference integrity is necessary to prevent various sorts of relay and impersonation
8. 该机制必须确保SIP请求和断言之间的引用完整性。引用完整性是指SIP消息和授权消息的断言之间的关系。例如，引用完整性检查会将消息的发送者（如SIP请求中所表示的，例如“From”头字段值）与断言提供的标识进行比较。参考完整性对于防止各种中继和模拟是必要的
attacks. Note that reference integrity MAY apply on a per-message, per-transaction, or per-dialog basis.
攻击。请注意，引用完整性可能适用于每条消息、每条事务或每个对话框。
9. Assertion schemes used for this mechanism MUST be capable of asserting attributes and/or traits associated with the identity of the principal originating a SIP request. No specific traits or attributes are required by this specification.
9. 用于此机制的断言方案必须能够断言与发起SIP请求的主体的身份相关联的属性和/或特征。本规范不要求特定特征或属性。
10. The mechanism MUST support a means for end-users to specify policies to an authorization service for the distribution of their traits and/or attributes to various destinations.
10. 该机制必须支持最终用户向授权服务指定策略的方法，以便将其特征和/或属性分发到各个目的地。
11. The mechanism MUST provide a way of preventing unauthorized parties (either intermediaries or endpoints) from viewing the contents of assertions.
11. 该机制必须提供一种防止未授权方（中介或端点）查看断言内容的方法。
12. Assertion schemes MUST provide a way of selectively sharing the traits and/or attributes of the principal in question. In other words, it must be possible to show only some of the attributes of a given principal to particular recipients, based on the cryptographically- assured identity of the recipient.
12. 断言方案必须提供一种有选择地共享相关主体的特征和/或属性的方法。换句话说，必须能够根据接收者的加密保证身份，仅向特定接收者显示给定主体的某些属性。
13. It MUST be possible to provide an assertion that contains no identity -- that is, to present only attributes or traits of the principal making a request, rather than the identity of the principal.
13. 必须能够提供不包含标识的断言——也就是说，只显示发出请求的主体的属性或特征，而不是主体的标识。
14. The manner in which an assertion is distributed MUST permit cryptographic authentication and integrity properties to be applied to the assertion by the authorization service.
14. 断言的分发方式必须允许授权服务将加密身份验证和完整性属性应用于断言。
15. It MUST be possible for a UAS or proxy server to reject a request that lacks a present and valid authorization assertion, and to inform the sending UAC that it must acquire such an assertion in order to complete the request.
15. UAS或代理服务器必须能够拒绝缺少当前有效授权断言的请求，并通知发送UAC必须获取此类断言才能完成请求。
16. The recipient of a request containing an assertion MUST be able to ascertain which authorization service generated the assertion.
16. 包含断言的请求的接收者必须能够确定哪个授权服务生成了断言。
17. It MUST be possible for a UAS or proxy server to reject a request containing an assertion that does not provide any attributes or traits that are known to the recipient or that are relevant to the request in question.
17. UAS或代理服务器必须能够拒绝包含断言的请求，该断言不提供接收方已知的或与所述请求相关的任何属性或特征。
18. It SHOULD be possible for a UAC to attach multiple assertions to a single SIP request, in cases where multiple authorization services must provide assertions in order for a request to complete.
18. 在多个授权服务必须提供断言才能完成请求的情况下，UAC应该可以将多个断言附加到单个SIP请求。
The subject of this document is an authorization system for SIP that is not predicated on the distribution of end-users' identities, but rather shares traits of the users. As such, the bulk of this document discusses security.
本文档的主题是SIP授权系统，它不是基于最终用户身份的分布，而是共享用户的特征。因此，本文主要讨论安全性。
The distribution of authorization assertions requires numerous security properties. An authorization service must be able to sign assertions, or provide some similar cryptographic assurance that can provide non-repudiation for assertions. These requirements are further detailed in Section 3.
授权断言的分发需要许多安全属性。授权服务必须能够对断言进行签名，或者提供一些类似的加密保证，以提供断言的不可否认性。这些要求在第3节中进一步详细说明。
The authors thank Christopher Eagan and Mary Barnes for their valuable input.
作者感谢克里斯托弗·伊根和玛丽·巴恩斯的宝贵意见。
[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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[3] Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[4] Burger, E., Ed., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.
[4] Burger，E.，Ed.“会话初始化协议（SIP）消息中的内容间接寻址机制”，RFC 4483，2006年5月。
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[5] Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[6] Organization for the Advancement of Structured Industry Standards, "Security Assertion Markup Language v1.0", November 2002, <http://www.oasis-open.org>.
[6] 结构化行业标准促进组织，“安全断言标记语言v1.0”，2002年11月<http://www.oasis-open.org>.
[7] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[7] Farrell，S.和R.Housley，“用于授权的互联网属性证书配置文件”，RFC 3281，2002年4月。
Authors' Addresses
作者地址
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Suite 570 Richardson, TX 75802 US
詹姆斯M.波尔克思科系统2200美国德克萨斯州理查森市东总统乔治·布什收费公路570室75802
EMail: jmpolk@cisco.com
EMail: jmpolk@cisco.com
Douglas C. Sicker University of Colorado at Boulder ECOT 531 Boulder, CO 80309 US
道格拉斯C.ScEKER科罗拉多大学波尔得分校ECOT 531 Boulder，CO 80309美国
EMail: douglas.sicker@colorado.edu
EMail: douglas.sicker@colorado.edu
Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 Munich 81739 Germany
德国慕尼黑第6环汉内斯·茨霍芬尼西门子公司奥托·哈恩81739
EMail: Hannes.Tschofenig@siemens.com
EMail: Hannes.Tschofenig@siemens.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。