idnits 2.17.1 draft-ietf-sipping-trait-authz-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 674. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 651. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 664. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 680), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2005) is 7007 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- No information found for draft-ietf-sip-peterson-identity - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING WG J. Peterson 3 Internet-Draft NeuStar 4 Expires: August 17, 2005 J. Polk 5 Cisco 6 D. Sicker 7 CU Boulder 8 H. Tschofenig 9 Siemens 10 February 16, 2005 12 Trait-based Authorization Requirements for the Session Initiation 13 Protocol (SIP) 14 draft-ietf-sipping-trait-authz-01 16 Status of this Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 and any of which I become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 17, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). All Rights Reserved. 45 Abstract 47 This document lays out a set of requirements related to trait-based 48 authorization for the Session Initiation Protocol. While some 49 authentication mechanisms are described in the base SIP 50 specification, trait-based authorization provides information used to 51 make policy decisions based on the attributes of a participant in a 52 session. This approach provides a richer framework for 53 authorization, as well as allow greater privacy for users of an 54 identity system. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Trait-based Authorization Framework . . . . . . . . . . . . . 5 61 4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 7 62 4.1 Settlement for Services . . . . . . . . . . . . . . . . . 7 63 4.2 Associating Gateways with Providers . . . . . . . . . . . 8 64 4.3 Permissions on Constrained Resources . . . . . . . . . . . 9 65 4.4 Managing Priority and Precedence . . . . . . . . . . . . . 10 66 4.5 Linking Different Protocols . . . . . . . . . . . . . . . 10 67 5. Trait-based Authorization Requirements . . . . . . . . . . . . 11 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 73 8.2 Informative References . . . . . . . . . . . . . . . . . . . 13 74 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 75 Intellectual Property and Copyright Statements . . . . . . . . 16 77 1. Introduction 79 This document explores requirements of the Session Initiation 80 Protocol [1] for enabling trait-based authorization. This effort 81 stems from the recognition that when SIP requests are received by a 82 User Agent Server (UAS), there are authorization requirements that 83 are orthogonal to ascertaining of the identity of the User Agent 84 Client (UAC). Supplemental authorization information might allow the 85 UAS to implement non-identity-based policies that depend on further 86 attributes of the principal that originated a SIP request. 88 For example, in traditional SIP authorization architectures, the mere 89 fact that a UAC has been authenticated by a UAS doesn't mean that the 90 UAS will grant the UAC full access to its services or capabilities - 91 in most instances, a UAS will compare the authenticated identity of 92 the UAC to some set of users that are permitted to make particular 93 requests (as a way of making an authorization decision). However, in 94 large communities of users with few pre-existing relationships (such 95 as federations of discrete service providers), it is unlikely that 96 the authenticated identity of a UAC alone will give a UAS sufficient 97 information to decide how to handle a given request. 99 Trait-based authorization entails an assertion by an authorization 100 service of attributes associated with an identity. An assertion is a 101 sort of document consisting of a set of these attributes which are 102 wrapped within a digital signature provided by the party that 103 generates the assertion (the operator of the authorization service). 104 These attributes describe the 'trait' or 'traits' of the identity in 105 question - facts about the principal corresponding to that identity. 106 For example, a given principal might be a faculty member at a 107 university. An assertion for that principal's identity might state 108 that they have the 'trait' of 'is a faculty member', and the 109 assertion would be issued (and signed) by a university. When a UAS 110 receives a request with this trait assertion, if it trusts the 111 signing university, it can make an authorization decision based on 112 whether or not faculty members are permitted to make the request in 113 question, rather than just looking at the identity of the UAC and 114 trying to discern whether or not they are a faculty member through 115 some external means. Thus, these assertions allow a UAS to authorize 116 a SIP request without having to store or access attributes associated 117 with the identity of the UAC itself. Even complex authorization 118 decisions based the presence of multiple disjointed attributes are 119 feasible; for example, a 'faculty' member could be part of the 120 'chemistry' department, and both of these traits could be used to 121 make authorization decisions in a given federation. 123 It is easy to see how traits can be used in a single administrative 124 domain, for example a single university, where all users are managed 125 under the same administration. In order for traits to have a broader 126 usage for services like SIP, which commonly are not bounded by 127 administrative domains, domains that participate in an common 128 authorization scheme must federate with one another. The concept of 129 federation is integral to any trait-based authorization scheme. 130 Domains that federate with one another agree on the syntax and 131 semantics of traits - without this consensus, trait-based 132 authorization schemes would only be useful in an intradomain context. 133 A federation is defined as a set of administrative domains that 134 implement common policies regarding the use and applicability of 135 traits for authorization decisions. Federation necessarily implies a 136 trust relationship, and usual implies some sort of pre-shared keys or 137 other means of cryptographic assurance that a particular assertion 138 was generated by an authorization service that participates in the 139 federation. 141 In fact, when trait-based authorization is used, an assertion of 142 attributes can be presented to a UAS instead of the identity of user 143 of the UAC. In many cases, a UAS has no need to know who, exactly, 144 has made a request - knowing the identity is only a means to the end 145 of matching that identity to policies that actually depend on traits 146 independent of identity. This fact allows trait-based authorization 147 to offer a very compelling privacy and anonymity solution. Identity 148 becomes one more attribute of an assertion that may or may not be 149 disclosed to various destinations. 151 Trait-based authorization for SIP depends on authorization services 152 that are trusted by both the UAC and the UAS that wish to share a 153 session. For that reason, the authorization services described in 154 this document are most applicable to either clients in a single 155 domain, or in federated domains that have agreed to trust one 156 another's authorization services. This could be common in academic 157 environments, or business partnerships that wish to share attributes 158 of principals with one another. Some trait-based authorization 159 architectures have been proposed to provide single sign-on services 160 across multiple providers. 162 Although trait-based identity offers an alternative to traditional 163 identity architectures, this effort should be considered 164 complementary to the end-to-end cryptographic SIP identity effort 165 [3]. An authentication service might also act as an authorization 166 service, generating some sort of trait assertion token instead of an 167 authenticated identity body. 169 2. Terminology 171 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 172 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 173 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 174 described in RFC2119 [2] and indicate requirement levels for 175 compliant SIP implementations. 177 3. Trait-based Authorization Framework 179 A trait-based authorization architecture entails the existence of an 180 authorization service. Devices must send requests to an 181 authorization service in order to receive an assertion that can be 182 used in the context of a given network request. Different network 183 request types will often necessitate different or additional 184 attributes in assertions from the authorization service. 186 For the purposes of SIP, SIP requests might be supplied to an 187 authorization service to provide the basis for an assertion. It 188 could be the case that a user agent will take a particular SIP 189 request, such as an INVITE, for which it wishes to acquire an 190 assertion and forward this to the authorization service (in a manner 191 similar to the way that an authenticated identity body is requested 192 in [3]). User agents might also use a separate protocol to request 193 an assertion. In either case, the client will need to authenticate 194 itself to an authorization service before it receives an assertion. 195 This authentication could use any of the standard mechanisms 196 described in RFC3261 [1], or use some other means of authentication. 198 Once a SIP UA has an assertion, it will need some way to carry an 199 assertion within in a SIP request. It's possible that this assertion 200 could be provided by reference or by value. For example, a SIP UA 201 could include a MIME body within a SIP request that contains the 202 assertion; this would be inclusion by value. Alternatively, content 203 indirection [4], or some new header, could be used to provide a URI 204 (perhaps an HTTP URL) where interested parties could acquire the 205 assertion; this is inclusion by reference. 207 The basic model is as follows: 209 +----------------+ 210 +----------------+ | | 211 | +------------+ | Request | +------------+ | 212 | | Entity | |------------------------>| | Assertion | | 213 | | requesting | | | | Granting | | 214 | | authz | |<------------------------| | Entity | | 215 | | assertions | | Assertion | +------------+ | 216 | +------------+ | | ^ | 217 | | | | . Trust | 218 | | | | . Rel. | 219 | | | | v | 220 | | | | +------------+ | 221 | Transfer | | | Assertion | | 222 | | | | | Verifying | | 223 | | | | | Entity | | 224 | | | | +------------+ | 225 | | | | | 226 | v | +----------------+ 227 | +------------+ | Service Request + ^ | 228 | | Entity | | Assertion | | 229 | | using authz| | -----------------------------+ | 230 | | assertion | | | 231 | +------------+ | <-------------------------------+ 232 +----------------+ Response/Error 234 The entity requesting authorization assertions (or the entity which 235 gets some assertions granted) and the entity using these 236 authorization assertions might be co-located in the same host or 237 domain, or they might be entities in different domains that share a 238 federate with one another. The same is true for the entity which 239 grants these assertions to a particular entity and the entity which 240 verifies these assertions. 242 From a protocol point of view, it is worth noting that the process of 243 obtaining some assertions might happen some time before the usage of 244 these assertions. Furthermore, different protocols might be used and 245 the assertions may have a lifetime which might allow that these 246 assertions are presented to the verifying entity multiple times 247 (during the lifetime of the assertion). 249 Some important design decisions are associated with carrying 250 assertions in a SIP request. If an assertion is carried by value, or 251 uses a MIME-based content indirection system, then proxy servers will 252 be unable to inspect the assertion themselves. If the assertion were 253 referenced in a header, however, it might be possible for the proxy 254 to acquire and inspect the assertion itself. There are certainly 255 architectures in which it would be meaningful for proxy servers to 256 apply admissions controls based on assertions. 258 It is also the case that carrying assertions by reference allows 259 versatile access controls to be applied to the assertion itself. For 260 instance, an HTTP URL where an assertion could be acquired could 261 indicate a web server that challenged requests, and only allowed 262 certain authorized sources to inspect the assertion, or which 263 provided different versions of the assertion depending on who is 264 asking. When a SIP UA initiates a request with privacy controls [5], 265 a web server might provide only trait information ('faculty', 266 'student', or 'staff') to most queries, but provide more detailed 267 information, including the identity of the originator of the SIP 268 request, to certain privileged askers. The end-users that makes 269 requests should have some way to inform authorization services of the 270 attributes that should be shared with particular destinations. 272 Assertions themselves might be scoped to a particular SIP 273 transaction, SIP dialog, or possibly have a longer lifetime. The 274 recipient of an assertion associated with a SIP request needs to have 275 some way to verify that the authorization service intended that this 276 assertion could be used for the request in question. However, the 277 format of assertions is not specified by these requirements. 279 Trait assertions for responses to SIP requests are outside the scope 280 of these requirements; it is not clear if there is any need for the 281 recipient of a request to provide authorization data to the 282 requestor. 284 Trait-based authorization has significant applicability to SIP. 285 There are numerous instances in which it is valuable to assert 286 particular facts about a principal other than the principal's 287 identity to aid the recipient of a request in making an authorization 288 policy decision. For example, a telephony service provider might 289 assert that a particular user is a 'customer' as a trait. An 290 emergency services network might indicate that a particular user has 291 a privileged status as a caller. 293 4. Example Use Cases 295 The following use cases are by no means exhaustive, but provide a few 296 high-level examples of the sorts of services that trait-based 297 authorization might provide. All of the cases below consider 298 interdomain usage of authorization assertions. 300 4.1 Settlement for Services 302 When endpoints in two domains share real-time communications 303 services, sometimes there is a need for the domains to exchange 304 accounting and settlement information in real-time. The operators of 305 valuable resources (for example, PSTN trunking, conference bridges, 306 or the like) in the called domain may wish to settle with the calling 307 domain (either with the operators of the domain, or a particular 308 user), and some accounting operations might need to complete before a 309 call is terminated. For example, a caller in one domain might want 310 to access a conference bridge in another domain, and the called 311 domain might wish to settle for the usage of the bridge with the 312 calling domain. Or in a wireless context, a roaming user might want 313 to use services in a visited network, and the visited network might 314 need to understand how to settle with the user's home network for 315 these services. 317 Assuming that the calling domain constitutes some sort of commercial 318 service capable of exchanging accounting information, the called 319 domain may want to verify that the remote user has a billable account 320 in good standing before allowing a remote user access to valuable 321 resources. Moreover, the called domain may need to discover the 322 network address of an accounting server and some basic information 323 about how to settle with it. 325 An authorization assertion created by the calling domain could 326 provide the called domain with an assurance that a user's account can 327 settle for a particular service. In some cases, no further 328 information may be required to process a transaction, but if more 329 specific accounting data is needed, traits could also communicate the 330 network address of an accounting server, the settlement protocol that 331 should be used, and so on. 333 4.2 Associating Gateways with Providers 335 Imagine a case where a particular telephone service provider has 336 deployed numerous PSTN-SIP gateways. When calls come in from the 337 PSTN, they are eventually proxied to various SIP user agents. Each 338 SIP user agent server is interested to know the identity of the PSTN 339 caller, of course, which could be given within SIP messages in any 340 number of ways (in SIP headers, bodies, or what have you). However, 341 in order for the recipient to be able to trust the identity (in this 342 instance, the calling party's telephone number) stated in the call, 343 they must first trust that the call originated from the gateway, and 344 that the gateway is operated by a known (and trusted) provider. 346 There are a number of ways that a service provider might try to 347 address this problem. One possibility would be routing all calls 348 from gateways through a recognizable 'edge' proxy server (say, 349 'sip.mci.com'). Accordingly, any SIP entity that received a request 350 via the edge proxy server (assuming the use of hop-by-hop mutual 351 cryptographic authentication) would know the service provider from 352 whom the call originated. However, it is possible that requests from 353 the originating service provider's edge proxy might be proxied again 354 before reaching the destination user agent server, and thus in many 355 cases the originating service provider's identity would be known only 356 transitively. Moreover, in many architectures requests that did not 357 originate from PSTN gateways could be sent through the edge proxy 358 server. In the end analysis, the recipient of the request is less 359 interested in knowing which carrier the request came from than in 360 knowing that the request came from a gateway. 362 Another possible solution is to issue certificates to every gateway 363 corresponding to the hostname of the gateway ('gateway1.mci.com'). 364 Gateways could therefore sign SIP requests directly, and this 365 property could be preserved end-to-end. But depending on the public 366 key infrastructure, this could however become costly for large 367 numbers of gateways, and moreover a user agent server that receives 368 the request has no direct assurance from a typical certificate that 369 the host is in fact a gateway just because it happens to be named 370 'gateway1'. 372 Trait-based authorization would enable the trait 'is a gateway' to be 373 associated with an assertion that is generated by the service 374 provider (i.e. signed by 'mci.com'). Since these assertions would 375 travel end-to-end from the originating service provider to the 376 destination user agent server, SIP requests which carry them can pass 377 through any number of intermediaries without discarding cryptographic 378 authentication information. This mechanism also does not rely on 379 hostname conventions to identity what constitutes a gateway and what 380 does not - it relies on an explicit and unambiguous attribute in an 381 assertion. 383 4.3 Permissions on Constrained Resources 385 Consider a scenario wherein two universities are making use of a 386 videoconferencing service over a constrained bandwidth resource. 387 Both universities would like to enforce policies that determine how 388 this constrained bandwidth will be allocated to members of their 389 respective communities. For example, faculty members might have 390 privileges to establish videoconferences during the day, while 391 students might not. Faculty might also be able to add students to a 392 particular videoconference dynamically, or otherwise moderate the 393 content or attendance of the conference, whereas students might 394 participate only more passively. 396 Trait-based authorization is ideal for managing authorization 397 decisions that are predicated on membership in a group. Rather than 398 basing access on individual users, levels (or roles) could be 399 assigned that would be honored by both universities, since they both 400 participate in the same federation. 402 If the federation honored the traits "faculty", "staff", and 403 "student", they could be leveraged to ensure appropriate use of the 404 network resource between universities participating in the 405 federation. An assertion would then be attached to every request to 406 establish a session that indicated the role of the requestor. Only 407 if the requestor has the appropriate trait would the session request 408 be granted. Ideally, these policies would be enforced by 409 intermediaries (SIP proxy servers) that are capable of inspecting and 410 verifying the assertions. 412 4.4 Managing Priority and Precedence 414 There is a significant amount of interest in the Internet telephony 415 community in assigning certain calls a 'priority' based on the 416 identity of the user, with the presumption that prioritized calls 417 will be granted preferential treatment when network resources are 418 scarce. Different domains might have different criteria for 419 assigning priority, and it is unlikely that a domain would correlate 420 the identity of a non-local user with the need for priority, even in 421 situations where domains would like to respect one another's 422 prioritization policies. 424 Existing proposals have focused largely on adding a new header field 425 to SIP that might carry a priority indicator. This use case does not 426 challenge this strategy, but merely shows by way of example how this 427 requirement might be met with a trait-based authorization system. As 428 such, the limitations of the header field approach will not be 429 contrasted here with a hypothetical trait-based system. 431 An assertion created by a domain for a particular request might have 432 an associated 'priority' attribute. Recipients of the request could 433 inspect and verify the signature associated with the assertion to 434 determine which domain had authenticated the user and made the 435 priority assessment. If the assertion's creator is trusted by the 436 evaluator, the given priority could be factored into any relevant 437 request processing. 439 4.5 Linking Different Protocols 441 Cryptographic computations are expensive and computing authorization 442 decisions might require a lot of time and multiple messages between 443 the entity enforcing the decisions and the entity computing the 444 authorization decision. Particularly in a mobile environment these 445 entities are physically separated - or not even in the same 446 administrative domain. Accordingly, the notion of "single sign-on" 447 is another potential application of authorization assertions, and 448 trait-based authorization - a user is authenticated and authorized 449 through one protocol, and can reuse the resulting authorization 450 assertion in other, potential unrelated protocol exchanges. 452 For example, in some environments it is useful to make the 453 authorization decision for a "high-level" service (such a voice 454 call). The authorization for the "voice call" itself might include 455 authorization for SIP signaling and also for lower level network 456 functions, for example a quality-of-service (QoS) reservation to 457 improve the performance of real-time media sessions established by 458 SIP. Since the SIP signaling protocol and the QoS reservation 459 protocol are totally separate, it is necessary to link the 460 authorization decisions of the two protocols. The authorization 461 decision might be valid for a number of different protocol exchanges, 462 for different protocols and for a certain duration or some other 463 attributes. 465 To enable this mechanism as part of the initial authorization step an 466 authorization assertion is returned to the end host of the SIP UAC 467 (cryptographically protected). If QoS is necessary, the end host 468 might reuse the returned assertion in the QoS signaling protocol. 469 Any domains in the federation that would honor the assertion 470 generated to authorize the SIP signaling would similar honor the use 471 of the assertion in the context of QoS. Upon the initial generation 472 of the assertion by an authorization server, traits could be added 473 that specify the desire level of quality that should be granted to 474 the media associated with a SIP session. 476 5. Trait-based Authorization Requirements 478 The following are the constraints and requirements for trait-based 479 authorization in SIP: 480 1. The mechanism MUST support a way for SIP user agents to embed an 481 authorization assertion in SIP requests. Assertions can be 482 carried either by reference or by value. 483 2. The mechanism MUST allow SIP UACs to deliver to an authorization 484 service those SIP requests that need to carry an assertion. The 485 mechanism SHOULD also provide a way for SIP intermediaries to 486 recognize that an assertion will be needed, and either forward 487 requests to an authorization service themselves, or notify the 488 UAC of the need to do so. 489 3. Authorization services MUST be capable of delivering an assertion 490 to a SIP UAC, either by reference or by value. It MAY also be 491 possible for an authorization service to add assertions to 492 requests itself, if the user profile permits this (for example, 493 through the use of content-indirection as described in [4]). 495 4. Authorization services MUST have a way to authenticate a SIP UAC. 496 5. The assertions generated by authorization services MUST be 497 capable of providing a set of values for a particular trait that 498 a principal is entitled to claim. 499 6. The mechanism MUST provide a way for authorized SIP 500 intermediaries (e.g. authorized proxy servers) to inspect 501 assertions. 502 7. The mechanism MUST have a single baseline mandatory-to- implement 503 authorization assertion scheme. The mechanism MUST also allow 504 support of other assertion schemes, which would be optional to 505 implement. One example of an assertion scheme is SAML [6]. 506 8. The mechanism MUST ensure reference integrity between a SIP 507 request and assertion. Reference integrity refers to the 508 relationship between a SIP message and the assertion authorizing 509 the message. For example, a reference integrity check would 510 compare the sender of the message (as expressed in the SIP 511 request, for example in the "From" header field value) with the 512 identity provided by the assertion. Reference integrity is 513 necessary to prevent various sorts of relay and impersonation 514 attacks. Note that reference integrity MAY apply on a 515 per-message, per-transaction, or per-dialog basis. 516 9. Assertion schemes used for this mechanism MUST be capable of 517 asserting attributes and/or traits associated with the identity 518 of the principal originating a SIP request. No specific traits 519 or attributes are required by this specification. 520 10. The mechanism MUST support a means for end-users to specify 521 policies to an authorization service for the distribution of 522 their traits and/or attributes to various destinations. 523 11. The mechanism MUST provide a way of preventing unauthorized 524 parties (either intermediaries or endpoints) from viewing the 525 contents of assertions. 526 12. Assertion schemes MUST provide a way of selectively sharing the 527 traits and/or attributes of the principal in question. In other 528 words, it must be possible to show only some of the attributes 529 of a given principal to particular recipients, based on the 530 cryptographically- assured identity of the recipient. 531 13. It MUST be possible to provide an assertion that contains no 532 identity - that is, to present only attributes or traits of the 533 principal making a request, rather than the identity of the 534 principal. 535 14. The manner in which an assertion is distributed MUST permit 536 cryptographic authentication and integrity properties to be 537 applied to the assertion by the authorization service. 538 15. It MUST be possible for a UAS or proxy server to reject a 539 request that lacks a present and valid authorization assertion, 540 and to inform the sending UAC that it must acquire such an 541 assertion in order to complete the request. 543 16. The recipient of a request containing an assertion MUST be able 544 to ascertain which authorization service generated the 545 assertion. 546 17. It MUST be possible for a UAS or proxy server to reject a 547 request containing an assertion that does not provide any 548 attributes or traits that are known to the recipient, or that 549 are relevant to the request in question. 550 18. It SHOULD be possible for a UAC to attach multiple assertions to 551 a single SIP request, in cases where multiple authorization 552 services must provide assertions in order for a request to 553 complete. 555 6. Security Considerations 557 The subject of this document is an authorization system for SIP that 558 is not predicated on the distribution of end-users' identities, but 559 rather shares traits of the users. As such, the bulk of this 560 document discusses security. 562 The distribution of authorization assertions requires numerous 563 security properties. An authorization service must be able to sign 564 assertions, or provide some similar cryptographic assurance that can 565 provide non-repudiation for assertions. These requirements are 566 further detailed in Section 3. 568 7. IANA Considerations 570 This document introduces no considerations for the IANA. 572 8. References 574 8.1 Normative References 576 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 577 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 578 Session Initiation Protocol", RFC 3261, May 2002. 580 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 581 levels", RFC 2119, March 1997. 583 8.2 Informative References 585 [3] Peterson, J., "Enhancements for Authenticated Identity 586 Management in the Session Initiation Protocol (SIP)", 587 draft-ietf-sip-peterson-identity-04 (work in progress), February 588 2005. 590 [4] Burger, E., "A Mechanism for Content Indirection in SIP 591 Messages", draft-ietf-sip-content-indirect-mech-05 (work in 592 progress), October 2004. 594 [5] Peterson, J., "A Privacy Mechanism for the Session Initiation 595 Protocol (SIP)", RFC 3323, November 2002. 597 [6] Organization for the Advancement of Structured Industry 598 Standards, "Security Assertion Markup Language v1.0", November 599 2002, . 601 Authors' Addresses 603 Jon Peterson 604 NeuStar, Inc. 605 1800 Sutter St 606 Suite 570 607 Concord, CA 94520 608 US 610 Phone: +1 925/363-8720 611 EMail: jon.peterson@neustar.biz 612 URI: http://www.neustar.biz/ 614 James M. Polk 615 Cisco Systems 616 2200 East President George Bush Turnpike 617 Suite 570 618 Richardson, TX 75802 619 US 621 EMail: jmpolk@cisco.com 623 Douglas C. Sicker 624 University of Colorado at Boulder 625 ECOT 531 626 Boulder, CO 80309 627 US 629 EMail: douglas.sicker@colorado.edu 630 Hannes Tschofenig 631 Siemens AG 632 Otto-Hahn-Ring 6 633 Munich 81739 634 Germany 636 EMail: Hannes.Tschofenig@siemens.com 638 Appendix A. Acknowledgments 640 The authors thank Christopher Eagan for his valuable input. 642 Intellectual Property Statement 644 The IETF takes no position regarding the validity or scope of any 645 Intellectual Property Rights or other rights that might be claimed to 646 pertain to the implementation or use of the technology described in 647 this document or the extent to which any license under such rights 648 might or might not be available; nor does it represent that it has 649 made any independent effort to identify any such rights. Information 650 on the procedures with respect to rights in RFC documents can be 651 found in BCP 78 and BCP 79. 653 Copies of IPR disclosures made to the IETF Secretariat and any 654 assurances of licenses to be made available, or the result of an 655 attempt made to obtain a general license or permission for the use of 656 such proprietary rights by implementers or users of this 657 specification can be obtained from the IETF on-line IPR repository at 658 http://www.ietf.org/ipr. 660 The IETF invites any interested party to bring to its attention any 661 copyrights, patents or patent applications, or other proprietary 662 rights that may cover technology that may be required to implement 663 this standard. Please address the information to the IETF at 664 ietf-ipr@ietf.org. 666 Disclaimer of Validity 668 This document and the information contained herein are provided on an 669 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 670 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 671 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 672 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 673 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 674 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 676 Copyright Statement 678 Copyright (C) The Internet Society (2005). This document is subject 679 to the rights, licenses and restrictions contained in BCP 78, and 680 except as set forth therein, the authors retain all their rights. 682 Acknowledgment 684 Funding for the RFC Editor function is currently provided by the 685 Internet Society.