idnits 2.17.1 draft-peterson-sipping-role-authz-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 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 (September 2003) is 7526 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? == Outdated reference: A later version (-05) exists of draft-ietf-sip-content-indirect-mech-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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: March 1, 2004 J. Polk 5 Cisco 6 D. Sicker 7 CU Boulder 8 September 2003 10 Trait-based Authorization Requirements for the Session Initiation 11 Protocol (SIP) 12 draft-peterson-sipping-role-authz-01 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on March 1, 2004. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This document lays out a set of requirements related to trait-based 44 authorization for the Session Initiation Protocol. While some 45 authentication mechanisms are described in the base SIP 46 specification, trait-based authorization provides information used to 47 make policy decisions based on the attributes of a participant in a 48 session. This approach provides a richer framework for 49 authorization, as well as allow greater privacy for users of an 50 identity system. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Trait-based Authorization Framework . . . . . . . . . . . . . 4 57 4. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 6 58 4.1 Accounting for Services . . . . . . . . . . . . . . . . . . . 6 59 4.2 Associating Gateways with Providers . . . . . . . . . . . . . 7 60 4.3 Permissions on Constrained Resources . . . . . . . . . . . . . 8 61 4.4 Managing Priority and Precedence . . . . . . . . . . . . . . . 8 62 5. Trait-based Authorization Requirements . . . . . . . . . . . . 9 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 Normative References . . . . . . . . . . . . . . . . . . . . . 11 66 Informative References . . . . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 68 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 70 1. Introduction 72 This document explores requirements of the Session Initiation 73 Protocol [1] for enabling trait-based authorization. This effort 74 stems from the recognition that when SIP requests are received by a 75 User Agent Server (UAS), there are authorization requirements that 76 are orthogonal to ascertaining of the identity of the User Agent 77 Client (UAC). Supplemental authorization information might allow the 78 UAS to implement non-identity-based policies that depend on further 79 attributes of the principal that originated a SIP request. 81 For example, in traditional SIP authorization architectures, the mere 82 fact that a UAC has been authenticated by a UAS doesn't mean that the 83 UAS will grant the UAC full access to its services or capabilities - 84 in most instances, a UAS will compare the authenticated identity of 85 the UAC to some set of users that are permitted to make particular 86 requests (as a way of making an authorization decision). However, in 87 large communities of users with few pre-existing relationships (such 88 as federations of discrete service providers), it is unlikely that 89 the authenticated identity of a UAC alone will give a UAS sufficient 90 information to decide how to handle a given request. 92 Trait-based authorization entails an assertion by an authorization 93 service of attributes associated with an identity. An assertion is a 94 sort of document consisting of a set of these attributes which are 95 wrapped within a digital signature provided by the party that 96 generates the assertion (the operator of the authorization service). 97 These attributes describe the 'trait' or 'traits' of the identity in 98 question - facts about the principal corresponding to that identity. 99 For example, a given principal might be a faculty member at a 100 university. An assertion for that principal's identity might state 101 that they have the 'trait' of 'is a faculty member', and the 102 assertion would be issued (and signed) by a university. When a UAS 103 receives a request with this trait assertion, if it trusts the 104 signing university, it can make an authorization decision based on 105 whether or not faculty members are permitted to make the request in 106 question, rather than just looking at the identity of the UAC and 107 trying to discern whether or not they are a faculty member through 108 some external means. Thus, these assertions allow a UAS to authorize 109 a SIP request without having to store or access attributes associated 110 with the identity of the UAC itself. Even complex authorization 111 decisions based the presence of multiple disjointed attributes are 112 feasible; for example, a 'faculty' member could be part of the 113 'chemistry' department, and both of these traits could be used to 114 make authorization decisions in a given federation. 116 In fact, when trait-based authorization is used, an assertion of 117 attributes can be presented to a UAS instead of the identity of user 118 of the UAC. In many cases, a UAS has no need to know who, exactly, 119 has made a request - knowing the identity is only a means to the end 120 of matching that identity to policies that actually depend on traits 121 independent of identity. This fact allows trait-based authorization 122 to offer a very compelling privacy and anonymity solution. Identity 123 becomes one more attribute of an assertion that may or may not be 124 disclosed to various destinations. 126 Trait-based authorization for SIP depends on authorization services 127 that are trusted by both the UAC and the UAS that wish to share a 128 session. For that reason, the authorization services described in 129 this document are most applicable to either clients in a single 130 domain, or in federated domains that have agreed to trust one 131 another's authorization services. This could be common in academic 132 environments, or business partnerships that wish to share attributes 133 of principals with one another. Some trait-based authorization 134 architectures have been proposed to provide single sign-on services 135 across multiple providers. 137 Although trait-based identity offers an alternative to traditional 138 identity architectures, this effort should be considered 139 complementary to the end-to-end cryptographic SIP identity effort 140 [3]. An authentication service might also act as an authorization 141 service, generating some sort of trait assertion token instead of an 142 authenticated identity body. 144 2. Terminology 146 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 147 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 148 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 149 described in RFC2119 [2] and indicate requirement levels for 150 compliant SIP implementations. 152 3. Trait-based Authorization Framework 154 A trait-based authorization architecture entails the existence of an 155 authorization service. Devices must send requests to an 156 authorization service in order to receive an assertion that can be 157 used in the context of a given network request. Different network 158 request types will often necessitate different or additional 159 attributes in assertions from the authorization service. 161 For the purposes of SIP, SIP requests might be supplied to an 162 authorization service to provide the basis for an assertion. It 163 could be the case that a user agent will take a particular SIP 164 request, such as an INVITE, for which it wishes to acquire an 165 assertion and forward this to the authorization service (in a manner 166 similar to the way that an authenticated identity body is requested 167 in [3]). User agents might also use a separate protocol to request 168 an assertion. In either case, the client will need to authenticate 169 itself to an authorization service before it receives an assertion. 170 This authentication could use any of the standard mechanisms 171 described in RFC3261 [1], or use some other means of authentication. 173 Once a SIP UA has an assertion, it will need some way to carry an 174 assertion within in a SIP request. It's possible that this assertion 175 could be provided by reference or by value. For example, a SIP UA 176 could include a MIME body within a SIP request that contains the 177 assertion; this would be inclusion by value. Alternatively, content 178 indirection [4], or some new header, could be used to provide a URI 179 (perhaps an HTTP URL) where interested parties could acquire the 180 assertion; this is inclusion by reference. 182 Some important design decisions are associated with carrying 183 assertions in a SIP request. If an assertion is carried by value, or 184 uses a MIME-based content indirection system, then proxy servers will 185 be unable to inspect the assertion themselves. If the assertion were 186 referenced in a header, however, it might be possible for the proxy 187 to acquire and inspect the assertion itself. There are certainly 188 architectures in which it would be meaningful for proxy servers to 189 apply admissions controls based on assertions. 191 It is also the case that carrying assertions by reference allows 192 versatile access controls to be applied to the assertion itself. For 193 instance, an HTTP URL where an assertion could be acquired could 194 indicate a web server that challenged requests, and only allowed 195 certain authorized sources to inspect the assertion, or which 196 provided different versions of the assertion depending on who is 197 asking. When a SIP UA initiates a request with privacy controls [5], 198 a web server might provide only trait information ('faculty', 199 'student', or 'staff') to most queries, but provide more detailed 200 information, including the identity of the originator of the SIP 201 request, to certain privileged askers. The end-users that makes 202 requests should have some way to inform authorization services of the 203 attributes that should be shared with particular destinations. 205 Assertions themselves might be scoped to a particular SIP 206 transaction, SIP dialog, or possibly have a longer lifetime. The 207 recipient of an assertion associated with a SIP request needs to have 208 some way to verify that the authorization service intended that this 209 assertion could be used for the request in question. However, the 210 format of assertions is not specified by these requirements. 212 Trait assertions for responses to SIP requests are outside the scope 213 of these requirements; it is not clear if there is any need for the 214 recipient of a request to provide authorization data to the 215 requestor. 217 Trait-based authorization has significant applicability to SIP. 218 There are numerous instances in which it is valuable to assert 219 particular facts about a principal other than the principal's 220 identity to aid the recipient of a request in making an authorization 221 policy decision. For example, a telephony service provider might 222 assert that a particular user is a 'customer' as a trait. An 223 emergency services network might indicate that a particular user has 224 a privileged status as a caller. 226 4. Example Use Cases 228 The following use cases are by no means exhaustive, but provide a few 229 high-level examples of the sorts of services that trait-based 230 authorization might provide. All of the cases below consider 231 interdomain usage of authorization assertions. 233 4.1 Accounting for Services 235 When endpoints in two domains share real-time communications 236 services, sometimes there is a need for the domains to exchange 237 accounting information in real-time. The operators of valuable 238 resources (for example, PSTN trunking, conference bridges, or the 239 like) in the called domain may wish to settle with the calling domain 240 (either with the operators of the domain, or a particular user), and 241 some accounting operations might need to complete before a call is 242 terminated. 244 Assuming that the calling domain constitutes some sort of commercial 245 service capable of exchanging accounting information, the called 246 domain may want to verify that the remote user has a billable account 247 in good standing before allowing a remote user access to valuable 248 resources. Moreover, the called domain may need to discover the 249 network address of an accounting server and some basic information 250 about how to settle with it. 252 An authorization assertion created by the calling domain could 253 provide the called domain with an assurance that a user's account can 254 settle for a particular service. In some cases, no further 255 information may be required to process a transaction, but if more 256 specific accounting data is needed, traits could also communicate the 257 network address of an accounting server, the settlement protocol that 258 should be used, and so on. 260 4.2 Associating Gateways with Providers 262 Imagine a case where a particular telephone service provider has 263 deployed numerous PSTN-SIP gateways. When calls come in from the 264 PSTN, they are eventually proxied to various SIP user agents. Each 265 SIP user agent server is interested to know the identity of the PSTN 266 caller, of course, which could be given within SIP messages in any 267 number of ways (in SIP headers, bodies, or what have you). However, 268 in order for the recipient to be able to trust the identity (in this 269 instance, the calling party's telephone number) stated in the call, 270 they must first trust that the call originated from the gateway, and 271 that the gateway is operated by a known (and trusted) provider. 273 There are a number of ways that a service provider might try to 274 address this problem. One possibility would be routing all calls 275 from gateways through a recognizable 'edge' proxy server (say, 276 'sip.mci.com'). Accordingly, any SIP entity that received a request 277 via the edge proxy server (assuming the use of hop-by-hop mutual 278 cryptographic authentication) would know the service provider from 279 whom the call originated. However, it is possible that requests from 280 the originating service provider's edge proxy might be proxied again 281 before reaching the destination user agent server, and thus in many 282 cases the originating service provider's identity would be known only 283 transitively. Moreover, in many architectures requests that did not 284 originate from PSTN gateways could be sent through the edge proxy 285 server. In the end analysis, the recipient of the request is less 286 interested in knowing which carrier the request came from than in 287 knowing that the request came from a gateway. 289 Another possible solution is to issue certificates to every gateway 290 corresponding to the hostname of the gateway ('gateway1.mci.com'). 291 Gateways could therefore sign SIP requests directly, and this 292 property could be preserved end-to-end. But depending on the public 293 key infrastructure, this could however become costly for large 294 numbers of gateways, and moreover a user agent server that receives 295 the request has no direct assurance from a typical certificate that 296 the host is in fact a gateway just because it happens to be named 297 'gateway1'. 299 Trait-based authorization would enable the trait 'is a gateway' to be 300 associated with an assertion that is generated by the service 301 provider (i.e. signed by 'mci.com'). Since these assertions would 302 travel end-to-end from the originating service provider to the 303 destination user agent server, SIP requests which carry them can pass 304 through any number of intermediaries without discarding cryptographic 305 authentication information. This mechanism also does not rely on 306 hostname conventions to identity what constitutes a gateway and what 307 does not - it relies on an explicit and unambiguous attribute in an 308 assertion. 310 4.3 Permissions on Constrained Resources 312 Consider a scenario wherein two universities are making use of a 313 videoconferencing service over a constrained bandwidth resource. 314 Both universities would like to enforce policies that determine how 315 this constrained bandwidth will be allocated to members of their 316 respective communities. For example, faculty members might have 317 privileges to connect videoconferences during the day, while students 318 might not. Faculty might also be able to add students to a 319 particular videoconference dynamically, or otherwise moderate the 320 content or attendance of the conference, whereas students might 321 participate only more passively. 323 Trait-based authorization is ideal for managing authorization 324 decisions that are predicated on membership in a group. Rather than 325 basing access on individual users, levels (or roles) could be 326 assigned that would be honored by both universities. 328 Attributes could be established for "faculty", "staff", and "student" 329 to ensure appropriate use of the resource. An assertion would then 330 be attached to every request to establish a session that indicated 331 the role of the requestor. Only if the requestor has the appropriate 332 trait would the session request be granted. Ideally, these policies 333 would be enforced by intermediaries (SIP proxy servers) that are 334 capable of inspecting and verifying the assertions. 336 4.4 Managing Priority and Precedence 338 There is a significant amount of interest in the Internet telephony 339 community in assigning certain calls a 'priority' based on the 340 identity of the user, with the presumption that prioritized calls 341 will be granted preferential treatment when network resources are 342 scarce. Different domains might have different criteria for 343 assigning priority, and it is unlikely that a domain would correlate 344 the identity of a non-local user with the need for priority, even in 345 situations where domains would like to respect one another's 346 prioritization policies. 348 Existing proposals have focused largely on adding a new header field 349 to SIP that might carry a priority indicator. This use case does not 350 challenge this strategy, but merely shows by way of example how this 351 requirement might be met with a trait-based authorization system. As 352 such, the limitations of the header field approach will not be 353 contrasted here with a hypothetical trait-based system. 355 An assertion created by a domain for a particular request might have 356 an associated 'priority' attribute. Recipients of the request could 357 inspect and verify the signature associated with the assertion to 358 determine which domain had authenticated the user and made the 359 priority assessment. If the assertion's creator is trusted by the 360 evaluator, the given priority could be factored into any relevant 361 request processing. 363 5. Trait-based Authorization Requirements 365 The following are the constraints and requirements for trait-based 366 authorization in SIP: 368 1. The mechanism must support a way for SIP user agents to carry an 369 authorization assertion in SIP requests. Assertions can be 370 carried either by reference or by value. 372 2. The mechanism must allow SIP UACs to deliver to an authorization 373 service those SIP requests that need to carry an assertion. The 374 mechanism should also provide a way for SIP intermediaries to 375 recognize that an assertion will be needed, and either forward 376 requests to an authorization service themselves, or notify the 377 UAC of the need to do so. 379 3. Authorization services must be capable of delivering an 380 assertion to a SIP UAC, either by reference or by value. It may 381 also be possible for an authorization service to add assertions 382 to requests itself, if the user profile permits this (for 383 example, through the use of content-indirection as described in 384 [4]). 386 4. Authorization services must have a way to authenticate a SIP 387 UAC. 389 5. The assertions generated by authorization services must be 390 capable of providing a set of values for a particular trait that 391 a principal is entitled to claim. 393 6. Proxy servers should have a way to inspect assertions associated 394 with a SIP request. 396 7. The mechanism must have a single baseline mandatory-to- 397 implement authorization assertion scheme. The mechanism must 398 also allow support of other assertion schemes, which would be 399 optional to implement. One example of an assertion scheme is 400 SAML [6]. 402 8. Assertion schemes used for this mechanism must have reference 403 integrity with a SIP request in order to prevent replay attacks. 405 Note that this reference integrity may apply on a per-message, 406 per-transaction, or per-dialog basis. 408 9. Assertion schemes used for this mechanism must be capable of 409 asserting attributes and/or traits associated with the identity 410 of the principal originating a SIP request. No specific traits 411 or attributes are required by this specification. 413 10. The mechanism must support a means for end-users to specify 414 policies to an authorization service for the distribution of 415 their traits and/or attributes to various destinations. 417 11. An assertion must have security properties that can prevent 418 unauthorized parties from viewing the contents of the assertion. 420 12. Assertion schemes must provide a way of selectively sharing the 421 traits and/or attributes of the principal in question. In other 422 words, it must be possible to show only some of the attributes 423 of a given principal to particular recipients, based on the 424 cryptographically- assured identity of the recipient. 426 13. It must be possible to provide an assertion that contains no 427 identity - that is, to present only attributes or traits of the 428 principal making a request, rather than the identity of the 429 principal. 431 14. The manner in which an assertion is distributed must permit 432 cryptographic authentication and integrity properties to be 433 applied to the assertion by the authorization service. 435 15. It must be possible for a UAS or proxy server to reject a 436 request that lacks an authorization assertion, and to notify the 437 UAC that it must acquire such an assertion in order to complete 438 the request. 440 16. The recipient of a request containing an assertion must be able 441 to ascertain which authorization service generated the 442 assertion. 444 17. A legitimate recipient of a request containing an assertion 445 (either a UAS or a proxy server) must be capable of inspecting 446 an assertion, and 448 18. It must be possible for a UAS or proxy server to reject a 449 request containing an assertion that does not provide any 450 attributes or traits that are known to the recipient, or that 451 are relevant to the request in question. 453 6. Security Considerations 455 The subject of this document is an authorization system for SIP that 456 is not predicated on the distribution of end-users' identities, but 457 rather shares traits of the users. As such, the bulk of this 458 document discusses security. 460 The distribution of authorization assertions requires numerous 461 security properties. An authorization service must be able to sign 462 assertions, or provide some similar cryptographic assurance that can 463 provide non-repudiation for assertions. These requirements are 464 further detailed in Section 3. 466 7. IANA Considerations 468 This document introduces no considerations for the IANA. 470 Normative References 472 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 473 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 474 Session Initiation Protocol", RFC 3261, May 2002. 476 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 477 levels", RFC 2119, March 1997. 479 Informative References 481 [3] Peterson, J., "Enhancements for Authenticated Identity 482 Management in the Session Initiation Protocol (SIP)", draft- 483 ietf-sip-peterson-identity-01 (work in progress), July 2002. 485 [4] Olson, S., "A Mechanism for Content Indirection in SIP 486 Messages", draft-ietf-sip-content-indirect-mech-01 (work in 487 progress), November 2002. 489 [5] Peterson, J., "A Privacy Mechanism for the Session Initiation 490 Protocol (SIP)", RFC 3323, November 2002. 492 [6] Organization for the Advancement of Structured Industry 493 Standards, "Security Assertion Markup Language v1.0", November 494 2002, . 496 Authors' Addresses 498 Jon Peterson 499 NeuStar, Inc. 500 1800 Sutter St 501 Suite 570 502 Concord, CA 94520 503 US 505 Phone: +1 925/363-8720 506 EMail: jon.peterson@neustar.biz 507 URI: http://www.neustar.biz/ 509 James M. Polk 510 Cisco Systems 511 2200 East President George Bush Turnpike 512 Suite 570 513 Richardson, TX 75802 514 US 516 EMail: jmpolk@cisco.com 518 Douglas C. Sicker 519 University of Colorado at Boulder 520 ECOT 531 521 Boulder, CO 80309 522 US 524 EMail: douglas.sicker@colorado.edu 526 Full Copyright Statement 528 Copyright (C) The Internet Society (2003). All Rights Reserved. 530 This document and translations of it may be copied and furnished to 531 others, and derivative works that comment on or otherwise explain it 532 or assist in its implementation may be prepared, copied, published 533 and distributed, in whole or in part, without restriction of any 534 kind, provided that the above copyright notice and this paragraph are 535 included on all such copies and derivative works. However, this 536 document itself may not be modified in any way, such as by removing 537 the copyright notice or references to the Internet Society or other 538 Internet organizations, except as needed for the purpose of 539 developing Internet standards in which case the procedures for 540 copyrights defined in the Internet Standards process must be 541 followed, or as required to translate it into languages other than 542 English. 544 The limited permissions granted above are perpetual and will not be 545 revoked by the Internet Society or its successors or assigns. 547 This document and the information contained herein is provided on an 548 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 549 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 550 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 551 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 552 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 554 Acknowledgement 556 Funding for the RFC Editor function is currently provided by the 557 Internet Society.