idnits 2.17.1 draft-ono-dispatch-attribute-validation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2011) is 4565 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) -- Looks like a reference, but probably isn't: '6' on line 327 -- Looks like a reference, but probably isn't: '7' on line 328 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA1' -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Dispatch K. Ono 3 Internet-Draft H. Schulzrinne 4 Intended status: Standards Track Columbia University 5 Expires: April 22, 2012 October 20, 2011 7 Referencing and Validating User Attributes 8 draft-ono-dispatch-attribute-validation-00.txt 10 Abstract 12 This document describes a mechanism for referencing and validating 13 user attributes in SIP communication. User attributes, such as an 14 organizational affiliation and role, are helpful for the recipients 15 of a communication request to decide whether or not to grant the 16 sender access to the recipient's resources, especially when the 17 sender identity is unknown to the recipients. This mechanism allows 18 the sender to claim her attributes to recipients using an attribute 19 reference identifier without needing to prove the sender identity. 20 This document defines a new SIP "Sender-References" header field to 21 convey one or more attribute reference identifiers. This mechanism 22 satisfies all the requirements for trait-based authorization defined 23 in RFC 4484, except that it provides only one assertion scheme. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 22, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Assumed Trust Relationships among AVS, Caller, and 63 Callee . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.2. ARIDs are Loosely Associated with the Owner's Identity 65 in SIP . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Differences between Our Requirements and the 68 Requirements for Trait-Based Authorization . . . . . . . . 7 69 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. Generating an ARID . . . . . . . . . . . . . . . . . . . . 9 71 5.2. Obtaining an ARID . . . . . . . . . . . . . . . . . . . . 10 72 5.3. Sending an ARID in a Communication Request . . . . . . . . 12 73 5.4. Validating an ARID to Retrieve User Attributes . . . . . . 12 74 6. Sender-References Header Field . . . . . . . . . . . . . . . . 14 75 7. Relationship to Existing Mechanisms . . . . . . . . . . . . . 14 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 8.1. Man in the Middle Attacks . . . . . . . . . . . . . . . . 17 78 8.2. Replay Attacks Using a Received ARID . . . . . . . . . . . 17 79 8.3. Denial of Service Attacks on the AVS . . . . . . . . . . . 18 80 8.4. Phishing Attacks on the AVS . . . . . . . . . . . . . . . 18 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 87 1. Introduction 89 Ascertaining a person's attributes is often useful to determine the 90 trustworthiness of the person when two people first meet each other. 91 These user attributes include, for example, an organizational 92 affiliation, a role in a professional society, age, holding 93 certificates or licenses, and being a customer of a bank, an 94 employee, or a student. If user attributes are available with a 95 communication request, these attributes can help the recipient 96 determine how to handle the communication request by estimating 97 whether the communication is important enough to be established. 99 A caller identifier (ID) authenticated by the SIP Identity mechanism 100 [RFC4474], when used alone, can be a helpful user attribute, but only 101 in limited cases. Only if a caller ID is in a SIP-URI [RFC3261] and 102 is authenticated by the domain of a trusted organization can the 103 caller ID be perceived as evidence that the caller belongs to the 104 trusted organization. However, if a caller ID in a SIP-URI belongs 105 to an untrusted domain regarding user admission policy, such as a 106 free voice over IP service provider, or if a caller ID does not 107 contain any domain name, such as a tel-URI [RFC3966], the caller ID 108 does not indicate the caller's trustworthiness to the callee who has 109 never seen the caller ID before. Thus, even if a caller has multiple 110 contact addresses, the caller needs to use a contact address issued 111 by a trusted domain for authorization purposes. To offer a flexible 112 choice of which contact address to use, our referencing mechanism 113 introduces another piece of information, an attribute reference ID 114 (ARID), that enables a caller to refer to her attributes without 115 needing to rely on the caller ID. A caller can use multiple ARIDs if 116 the caller wants to prove multiple attributes associated with 117 different organizations. This referencing mechanism, unlike the 118 caller ID, allows a caller to use multiple ARIDs to declare multiple 119 user attributes in a single communication request. 121 If an authenticated caller ID does not provide sufficient 122 information, the callee can look up further user attributes through 123 directory services. However, a reference integrity problem arises 124 when a directory service does not allow queriers to look up user 125 attributes by the user's contact address. Additionally, when a 126 directory service allows queries by a user's contact address, but is 127 offered by a third party, not the issuer of contact addresses, the 128 authenticity of the information is unreliable. For example, 129 DoctorFinder service offered by the American Medical Association 130 provides information about certified medical doctors. When making a 131 query, a querier cannot use the doctor's phone number, but needs to 132 use doctor's common name, street address or specialty, which is 133 available to the public. If a doctor makes a call (or sends an email 134 message) that includes such query information and a reference to the 135 DoctorFinder service, the callee (or the recipient) is not convinced 136 of the certainty. To solve this reference integrity problem, our 137 referencing mechanism allows an organization to generate a short- 138 lived ARID upon a caller request. This ARID is effective only for a 139 specific communication by limiting the lifetime and encoding 140 designated destinations, namely designated queriers. In addition, 141 the ARID can be used only for retrieving the attributes that the 142 caller selects to disclose to the specific queriers. 144 2. Terminology 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. Architecture 152 Figure 1 depicts an overview of the service architecture where an 153 attribute validation server (AVS) operates to reference and validate 154 user attributes for an organization. For each user, the AVS 155 maintains the username and credentials to authenticate the user for 156 remote access, in addition to other information such as a user number 157 and role which the organization assigns, the users's common name, 158 affiliation, street address, and electronic contact addresses. Note 159 that the AVS stores a user's contact addresses, but it neither 160 guarantees that the user owns the contact addresses nor can be 161 reached by their addresses. 163 We provide an example for illustration. Alice, a user of services 164 provided by the organization, "example.org", is about to make a call 165 to Bob at "bob@example.com". Alice first requests an ARID from the 166 AVS using HTTP [RFC2616] over TLS [RFC5246]. When sending the 167 request, Alice authenticates the AVS using its X.509 Public Key 168 Certificate (PKC) [RFC5280] which is delivered in the TLS handshake 169 and is signed by a trusted Certificate Authority (CA). In turn, when 170 generating an ARID for Alice, the AVS authenticates her using any 171 credentials supported by the AVS, such as a password or a client's 172 X.509 PKC. Upon successfully obtaining an ARID, Alice makes a call 173 to Bob using SIP [RFC3261] over TLS. The SIP INVITE request includes 174 the ARID. When Bob receives an ARID, he queries the validity of the 175 ARID to the AVS using HTTP over TLS. Bob authenticates the AVS using 176 its X.509 PKC in the same way that Alice does. Based on the query 177 results, Bob determines whether or not to answer the call from Alice 178 and adjusts his communication stance accordingly. 180 +------------------------+ 181 | Attribute | Database 182 | Validation |==[username, credentials, attributes] 183 | Server (AVS) | 184 | | 185 | attributes.example.org |<------------\ 186 +------------------------+ \ 3. Query 187 ^ \ ARID's validity 188 | \ via HTTP over TLS 189 | 1. \ 190 | Request and obtain an ARID \ 191 | via HTTP over TLS \ 192 | \ 193 +---------------+ +------------------+ 194 | UAC | 2. | UAS | 195 | | Send or call with ARID | | 196 | Alice | via SIP over TLS | Bob | 197 | +12345678 |------------------------->| bob@example.com | 198 +---------------+ +------------------+ 200 Figure 1: Architecture 202 3.1. Assumed Trust Relationships among AVS, Caller, and Callee 204 We assume that the AVS and the caller, Alice, trust each other 205 regarding the attribute validation service for an organization, 206 "example.org." They share Alice's username and credentials for 207 remote access, and her attributes. Alice trusts the AVS to properly 208 maintain her attributes and to disclose the attributes she selects 209 only to queriers whom she specifies. In turn, the AVS trusts Alice 210 as a user in the organization and trusts her attributes which it 211 knows first-hand, such as "Alice is an IEEE student member." 212 However, the AVS does not know the authenticity of her attributes 213 that are not issued by the organization, such as her common name, 214 affiliation, and contact addresses. 216 We also assume that Bob knows "example.org" as the domain name of an 217 organization that has a user admission policy he trusts, whether or 218 not he belongs to the organization. Bob also trusts the AVS to 219 properly perform its attribute validation service. 221 Alice finds Bob worth making a call and disclosing her attributes to 222 establish a communication with him. In turn, Bob does not have 223 sufficient information about Alice's trustworthiness based solely on 224 her identity in a SIP communication request. 226 3.2. ARIDs are Loosely Associated with the Owner's Identity in SIP 228 An ARID generated upon Alice's request can be used only to retrieve 229 her attributes, but the ARID is not tightly linked with her identity 230 used in a SIP communication request, namely the caller ID in a call. 231 When Bob receives an ARID in a SIP communication request where the 232 message integrity is protected by TLS, the callee can perceive the 233 ARID to be associated with the caller ID. Bob can loosely link an 234 ARID with the owner's identity only because of the fact that these 235 two pieces of information are sent in the same message. Other than 236 the presence of these two pieces of information in the same message, 237 there is no linkage between the ARID and the caller ID. Bob does not 238 need to provide Alice's caller ID to validate a received ARID. The 239 user attributes Bob retrieves upon the success of the validation do 240 not contain the owner's contact address. This loose linkage is a 241 natural consequence of the general fact that user attributes and the 242 user identifier in a communication are often issued separately by 243 different organizations or services. 245 This loose linkage, however, makes it difficult for Bob to detect 246 impersonation using a stolen ARID. Bob cannot detect this 247 impersonation by providing the AVS with the owner's caller ID or by 248 being presented the caller ID in user attributes. When issuing an 249 ARID, the AVS cannot easily authenticate her caller ID since the 250 caller ID is issued by a different administrative domain. 251 Additionally, Bob cannot always authenticate the caller ID. The 252 cases where no authentication of the caller ID is available include 253 where a caller ID is in a SIP-URI issued by the domain which does not 254 deploy the SIP Identity mechanism, where a caller ID is in a tel-URI 255 which is sent without any other authentication mechanisms, such as a 256 digital signature in S/MIME [RFC5751], and where a caller ID is 257 anonymized. Thus, although tightening this linkage can protect from 258 impersonation attacks, it makes the service deployment more difficult 259 and limits the caller's choice of caller IDs. 261 To mitigate the vulnerability to impersonation attacks using a stolen 262 ARID without tying an ARID to an authenticated caller ID, a 263 countermeasure is devised for each vulnerable target. To prevent a 264 man in the middle from eavesdropping on an ARID, all the connection 265 links to convey an ARID need to be protected with TLS. To detect 266 that an ARID was stolen from the owner, the recipients, or 267 intermediaries, such as a SIP proxy server, an ARID can be used to 268 retrieve user attributes only a limited number of times, for a 269 limited time period, and by limited queriers. Yet even with these 270 protections, this mechanism cannot prevent the owner of an ARID from 271 giving her own ARID to others. To keep this mechanism simple, we do 272 not include any additional mechanisms that discourage the owner from 273 giving her own ARID. As a result, this mechanism allows the owner of 274 an ARID to informally delegate her attributes to others without 275 proving the chain of authorizing delegation. However, a legitimate 276 recipient cannot impersonate Alice's attributes by forwarding a 277 received ARID. 279 4. Requirements 281 This section first identifies the requirements of a mechanism for 282 referencing and validating attributes, and then identifies 283 differences between these requirements and the requirements for 284 Trait-Based Authorization (TBA) for SIP [RFC4484]. 286 Our requirements are: 287 REQ-1: The mechanism must enable a user to prove one or more 288 attributes by presenting an attribute reference ID (ARID). 289 REQ-2: The mechanism must allow a user to prove her attributes in 290 one or more organizations in a single communication request. 291 REQ-3: The mechanism must allow a user to specify her attributes to 292 be disclosed for each communication session. 293 REQ-4: The mechanism must allow a user to restrict queriers who can 294 retrieve her attributes to the recipients of a communication 295 request. 296 REQ-5: This mechanism must adapt to various attribute policies; 297 thus, an ARID must be temporary rather than persistent. 298 REQ-6: The mechanism must allow the recipients of an ARID to easily 299 validate a received ARID. 300 REQ-7: The mechanism must prevent the recipients of an ARID from 301 impersonation by forwarding a received ARID. 302 REQ-8: The mechanism must protect user's private information, such 303 as communication history, even against an AVS. 304 REQ-9: This mechanism should provide flexibility for deployment; 305 thus, an ARID should be unique across different organizations 306 deployed on a single AVS. 308 We intentionally omit the following requirements: 309 o The mechanism does not need to prevent a user from giving her ARID 310 to others. 311 o The mechanism does not need to support a user who delegates the 312 ARID with proving the chain of authorizing delegation. 313 o The mechanism does not need to bind an ARID to the SIP signaling 314 path or SIP identity. 316 4.1. Differences between Our Requirements and the Requirements for 317 Trait-Based Authorization 319 Our requirements described above are similar to the TBA requirements 320 for SIP, but two differences exist. First, we do not require support 321 for optional assertion schemes other than an ARID defined in 322 Section 5 while the TBA includes the following requirement: 323 7. The mechanism MUST have a single baseline mandatory-to- 324 implement authorization assertion scheme. The mechanism MUST also 325 allow support of other assertion schemes, which would be optional 326 to implement. One example of an assertion scheme is Security 327 Assertion Markup Language (SAML) [6] and another is RFC 3281 X.509 328 Attribute Certificates [7]. 330 Our mechanism currently does not support other assertion schemes, 331 such as SAML [SAML] or X.509 Attribute Certificates (AC) [RFC5755], 332 as mentioned above. Such mechanisms that protect assertion integrity 333 by signing using the issuer's private key requires that recipients 334 verify the integrity using the issuer's public key in the application 335 layer. The recipients also need to authenticate the issuer of an 336 assertion. On the other hand, our mechanism relies on transport 337 layer security, namely TLS, to protect message integrity and 338 authenticate the issuer of an ARID. Although our mechanism does not 339 separately protect the integrity of user attributes or the linkage 340 between user attributes and their owner, our mechanism instead 341 protects the integrity of a whole message including these attributes. 342 As long as intermediaries such as an HTTP and SIP proxy servers can 343 be trusted to properly transfer messages for this attribute 344 referencing service, this security with TLS is simpler, and strong 345 enough against message tampering and server impersonation. 347 The second difference is that our requirements include an additional 348 requirement for protecting user's privacy described in REQ-8. 349 Although an authorization service or AVS needs to limit designated 350 queriers to the designated destinations of a SIP request, the 351 authorization service has to know neither user's communication 352 history nor plans containing routable contact addresses to do so even 353 for a short term during the lifetime of an assertion or ARID. Our 354 mechanism hashes contact addresses to prevent this unnecessary 355 disclosure of the private information of a user. 357 5. Procedures 359 Figure 2 illustrates message exchanges among a UAC, the UAS and the 360 AVS for the following procedures: 361 1. Obtaining an ARID; 362 2. Sending the ARID when making a call using SIP; 363 3. Validating the ARID to retrieve user attributes. 365 Before explaining each procedure, we describe how the AVS typically 366 generates an ARID. 368 Alice Bob 369 UAC AVS UAS 370 | | | 371 | F1. HTTP POST | | 372 |---------------------->| | 373 | F2. 200 OK with ARID | | 374 |<----------------------| | 375 | | | 376 | F3. SIP INVITE with ARID | 377 |----------------------------------------------->| 378 | | | 379 | | F4. HTTP GET with ARID | 380 | |<-----------------------| 381 | | F5. 200 OK | 382 | |----------------------->| 383 | F6. 200 OK | 384 |<-----------------------------------------------| 385 | F7. ACK | 386 |----------------------------------------------->| 387 | | 389 Note: SIP messages to/from SIP proxy servers are omitted since they are 390 not affected by this mechanism. 392 Figure 2: Message Exchanges 394 5.1. Generating an ARID 396 An ARID is a string of URL [RFC3986] characters generated by an AVS 397 upon a user's request. When a single AVS offers this attribute 398 service for multiple organizations, a subdomain or a path in the URL 399 of the AVS website is assigned to each organization as part of an 400 ARID to meet the requirement REQ-9. 402 We show two examples how an AVS generates an ARID. Note that the AVS 403 does not have to follow these generating mechanisms. The first 404 example is to hash a string of characters by SHA1 [SHA1]. The string 405 of characters is a user number concatenated with the timestamp, a 406 nonce, and hashed contact addresses of one or more desired queriers 407 (REQ-4,8) as shown below. Hashed contact addresses of one or more 408 desired queriers are sent from a user when the user requests an ARID, 409 as described in Section 5.2. The information other than these hashed 410 contact addresses is stored or generated on the AVS. 411 Generating an ARID by hash: 412 m = user number || timestamp || nonce || hashed querier's contact 413 address 415 If two queriers, querier_1 and querier_2, are specified, 416 m = user number || timestamp || nonce || hashed querier_1's 417 contact address;hashed querier_2's contact address 419 ARID = URL path/Hash(m) 421 Another example is to encrypt a string of characters with a symmetric 422 key of the AVS using AES [AES]. The string of characters is a user 423 number concatenated with a disclosure mode, the expiry time, hashed 424 contact addresses of desired queriers. The disclosure mode is 425 determined what attributes a user discloses to desired queriers 426 (REQ-3). The expiry time of an ARID needs to be shortly after the 427 time an ARID is generated, such as ten minutes later, to avoid replay 428 attacks (REQ-7). 429 An appropriate expiry time depends on the service type. For 430 synchronous communication services, such as a voice or video call 431 or real-time text chat, the lifetime needs to be short. For 432 asynchronous services, such as instant messaging, or email 433 communication, the lifetime needs to be longer, such as 24 hours. 434 Generating an ARID by encryption: 435 m = user number || disclosure mode || expiry time || salt|| hashed 436 querier's contact address 438 If two queriers, querier_1 and querier_2, are specified, 439 m = user_id || disclosure_mode || expiry time || salt || hashed 440 querier_1's contact address;hashed querier_2's contact address 442 ARID = URL path/Encrypt(m) 444 When selecting a method for generating an ARID, by hash or 445 encryption, they have the trade-off between the memory cost of 446 storing ARIDs with related data and the computational cost of 447 decrypting ARIDs. When generating an ARID by hash, the AVS needs to 448 store the generated ARID with associated data including the expiry 449 time, the nonce, the hashed contact addresses of desired queriers 450 which the user sent, and the disclosure mode which the user 451 specified. On the other hand, when generating an ARID by encryption, 452 the AVS only needs to remember the salt for decryption, but not any 453 generated ARIDs. Instead, it requires the computational cost of 454 decryption. 456 5.2. Obtaining an ARID 458 To obtain an ARID which can be used for a communication with Bob, 459 Alice first needs to connect to the AVS using a SIP UA which supports 460 this mechanism. When connecting, the SIP UAC MUST authenticate the 461 AVS using its X.509 PKC sent in the TLS handshake. In turn, the AVS 462 MUST authenticate Alice using her username and credentials. For user 463 authentication, HTTP Basic or Digest authentication [RFC2617], a 464 client's PKC, or other mechanisms SHOULD be used. Upon successful 465 user authentication, the SIP UAC MUST send the AVS an HTTP POST 466 request with setting hashed Bob's contact address as a desired 467 querier, and a disclosure mode in a message body, as shown in the 468 following example. Each hashed contact address of a desired querier 469 SHOULD be attached as a JSON [RFC4627] object, or MAY be in XML 470 [XML]. When a communication request has multiple destinations, such 471 as a conference call, multiple "destination" fields SHOULD be 472 included to contain multiple hashed contact addresses of the desired 473 queriers. 475 F1. HTTP POST sent from Alice to AVS: 477 POST /requestARID HTTP/1.1 478 HOST:attributes.example.org 479 Content-Type:application/json 481 {"destination":"2cf6a1eda3b5205005d25a7d5dcf13bb200fc26a",\ 482 "disclosure_mode":"details"} 484 Note: Mandatory HTTP or SIP headers unrelated to this mechanism 485 are not shown here and the following example messages. 487 Hashing the contact address of a desired querier is to limit 488 acceptable queriers without revealing communication history to the 489 AVS (REQ-8). The SIP UA supporting this mechanism MUST implement and 490 use SHA1, and MAY support any other hash algorithms. To prevent re- 491 identification based on hashed contact addresses collected on the 492 AVS, the SIP UAC MUST generate a salt, which is a random string of 493 characters, and concatenate it with a contact address as follows: 494 Hash(salt || contact address) 496 In the example above, the destination field, 497 "2cf6a1eda3b5205005d25a7d5dcf13bb200fc26a", is generated by 498 SHA1("dmvb1p03"||"sips:bob@example.com"). 500 When the AVS successfully generates an ARID for Alice, the AVS 501 responds to her with a 200 OK response including the ARID and its 502 expiry time in the same data format used in the received HTTP 503 request. The HTTP messages MUST be sent over TLS to protect message 504 confidentiality and integrity. In the following example, the ARID is 505 attached as a JSON object. The "arid" field consists of the URL of 506 the website for the ARID validation, 507 "https://attributes.example.org/", and the ARID, 508 "17750c5cbac9979171991d505d2e634e727d8d9b." 510 F2. 200 OK sent from AVS to Alice: 512 HTTP/1.1 200 OK 513 Content-Type:application/json 515 { "arid":"https://attributes.example.org/17750c5cbac997917199\ 516 1d505d2e634e727d8d9b", "expires":"2011-08-24T16:20:20Z" } 518 5.3. Sending an ARID in a Communication Request 520 When Alice makes a call to Bob with an ARID, she needs to specify the 521 ARID associated with the URL of the website for validating the ARID 522 in a SIP UA. The SIP UA MUST generate a new SIP header called 523 "Sender-Reference" including a URI, "type", "salt", and "hash_alg" 524 parameters to convey the ARID in the path of an HTTP URL, specify 525 this service, and the salt and the hash algorithm which were used for 526 hashing the querier's contact address described in Section 5.2, 527 respectively. If Alice wants to specify multiple ARIDs, this Sender- 528 References header field includes multiple set of an ARID and related 529 parameters concatenating a comma separator. The SIP UA then sends an 530 SIP INVITE request including the Sender-Reference as shown in the 531 following example. The INVITE request MUST be sent over TLS to 532 protect message confidentiality and integrity. 533 Instead of defining a new SIP header field, the existing Call-Info 534 header field can be set to an ARID by defining a new value of the 535 purpose parameter, such as "sender-attributes." However, to 536 convey a salt and the hash algorithm, we also need to define two 537 more parameters. To avoid complexing the Call-Info parameter 538 structure, we rather define a new SIP header field. 540 F3. SIP INVITE from Alice to Bob: 542 INVITE sips:bob@example.com SIP/2.0 543 From:Alice 544 To:Bob 545 Sender-References:;type="avs";\ 547 salt="dmvb1p03";hash_alg="SHA1" 549 5.4. Validating an ARID to Retrieve User Attributes 551 When Bob, the recipient of one or more ARIDs, wants to retrieve the 552 caller attributes, the SIP UAS needs to test the validity of the 553 ARIDs on the corresponding AVSes. By prompting Bob or based on his 554 preconfigured information, the SIP UAS first needs to determine 555 whether or not he trusts each domain name of the AVS in the Sender- 556 References header in received SIP INVITE request. Only for trusted 557 AVSes, the SIP UAS looks up the received ARIDs on the corresponding 558 AVSes to retrieve the caller's attributes by using an HTTP GET 559 request as shown in the following example. HTTP messages MUST sent 560 over TLS for security as well as messages between the SIP UAC the 561 AVS. Bob authenticates the AVS using its X.509 PKC delivered in the 562 TLS handshake. 564 For this validation, the SIP UAS MUST send the ARID found in the 565 Sender-References header field and a hashed querier's contact address 566 generated by the hash algorithm and salt also found in the Sender- 567 References header field. To generate a hashed querier's contact 568 address, the SIP UAS needs to know the original destination address 569 by extracting from the To header or by Bob's pre-configuration 570 especially when he enables call forwarding services. In the 571 following example, the hashed querier's contact address, 572 "2cf6a1eda3b5205005d25a7d5dcf13bb200fc26a", is generated by 573 SHA1("dmvb1p03"||"sips:bob@example.com"). This validation MAY be 574 invoked by a SIP inbound proxy on behalf of the UAS. 576 F4. HTTP GET from Bob to AVS: 578 GET /17750c5cbac9979171991d505d2e634e727d8d9b/\ 579 2cf6a1eda3b5205005d25a7d5dcf13bb200fc26a HTTP/1.1 580 HOST:attributes.example.org 582 If no AVSes are trusted by Bob, the SIP UAS MUST ignore the Sender- 583 Reference header field and stop any further validation process. If 584 the SIP UAS does not support a hash algorithm specified in the 585 Sender-References header field, or if the SIP UAS does not support 586 the header field, it SHOULD also ignore the header field and continue 587 normal processing of the received SIP request. 589 If the ARID is valid at the queried time and with the querier's 590 contact address, the AVS MUST respond to the querier with 200 OK in 591 HTTP having the attributes based on the disclosure mode which Alice 592 specifies in the message body, as shown in the following example. 593 The attributes SHOULD be attached as a JSON object or MAY be in XML. 594 If the query is done later than the expiry time, the AVS SHOULD 595 respond with 408 Request Timeout in HTTP. If the querier is not 596 included in the list of desired queriers specified earlier by Alice, 597 the AVS SHOULD respond with 403 Forbidden in HTTP. If the ARID is 598 invalid for other reasons, the AVS MUST respond with 404 Not Found in 599 HTTP. 601 F5. HTTP 200 OK from AVS to Bob: 603 HTTP/1.1 200 OK 604 Content-Type:application/json 606 { "user_status":"student member" } 607 If Bob receives a 200 OK in HTTP from the AVS, he is informed that 608 the ARID is valid and attached information is the caller's 609 attributes, for the example above, the caller is a student member in 610 "example.org". With any other responses, Bob knows nothing about the 611 caller's attributes. Based on this information, he determines 612 whether or not to answer the call and adjusts his communication 613 stance accordingly. 615 6. Sender-References Header Field 617 The SIP "Sender-References" header field is newly defined to provide 618 the reference information about the sender or the caller. The field 619 consists of one or more sender-ref information. Each sender-ref 620 information consists of three parts: an absolute URI, sender-ref- 621 type, and avs-params. The absolute URI contains the URI of the AVS 622 website including an ARID in the path. The sender-ref-type indicates 623 the service type of using this header field. For this referencing 624 service, it MUST be "avs." The avs-params consists of two 625 parameters: one is to specify a salt and another is for a hash 626 algorithm. Both parameters are used for hashing a contact address to 627 be presented for validation. 629 The syntax of the Sender-References header field in the ABNF 630 [RFC5234] is as follows: 632 Sender-References = "Sender-References" HCOLON sender-ref 633 *(COMMA sender-ref) 634 sender-ref = LAQUOT absoluteURI RAQUOT sender-ref-type 635 SEMI avs-params 636 sender-ref-type = "type" EQUAL ( "avs" / quoted-string ) 637 avs-params = salt-param SEMI hash-alg-param 638 salt-param = "salt" EQUAL quoted-string 639 hash-alg-param = "hash-alg" EQUAL ( "SHA1" / quoted-string ) 641 This Sender-References header field is optionally set in any SIP 642 requests and responses. 644 7. Relationship to Existing Mechanisms 646 This section discusses why this referencing mechanism does not use 647 existing mechanisms that provide an attribute assertion or third- 648 party authentication, such as an X.509 Attribute Certificate (AC), a 649 Security Assertion Markup Language (SAML) assertion, Vouch by 650 Reference [RFC5518], OAuth [RFC5849] or Kerberos [RFC4120]. The 651 following table compares our mechanism using an AVS with these 652 existing mechanisms in terms of the trust model they assume, whether 653 or not to need to bind the assertion to the sender ID, and applicable 654 services. 656 +-----------+----------+----------+----------+----------+-------+------+ 657 | | AVS | X.509 AC | SAML | VBR | OAuth | Ker- | 658 | | | | assertion| | | beros| 659 +-----------+----------+----------+----------+----------+-------+------+ 660 |trust model|described | the same as AVS | different | 661 | |in Sec 3.1| | from AVS | 662 +-----------+----------+----------+----------+----------+-------+------+ 663 |need for | no | yes | optional |yes, with | no | yes | 664 |binding to | | | |the sender| | | 665 |sender ID | | | |domain | | | 666 +-----------+----------+----------+----------+----------+-------+------+ 667 |apps. | SIP | any | any | email | Web | any | 668 +-----------+----------+----------+----------+----------+-------+------+ 669 apps. = applications 671 An X.509 Attribute Certificate (AC) provides a superset of features 672 we need for our equivalent trust model. However, an X.509 AC, unlike 673 our mechanism, requires the AC holder information, namely a user's 674 identity, to be bound to the user's attributes. This binding is 675 protected by being digitally signed with the AC issuer's private key. 676 However, the AC issuer does not always have the right to sign the 677 binding since the AC issuer cannot authenticate the user identity 678 issued by a different organization as described in Section 3.2. 679 Authenticating the user identity requires either the user's PKC or 680 other mechanisms, such as the SIP identity mechanism where the user 681 identity is a user identifier in SIP. These mechanisms are difficult 682 to deploy for each reason. Users' PKCs have not been widely deployed 683 because of difficulty in managing the pair of public and private keys 684 across multiple devices. The sender ID in SIP is usually issued by 685 an administrative domain different from the AC issuer. For these 686 reasons, we need a new mechanism to allow a looser linkage between 687 the sender ID and attributes. 689 Similar to an X.509 AC, a SAML assertion provides a superset of 690 features we need for our equivalent trust model. Unlike an X.509 AC, 691 a SAML assertion does not require the binding between user attributes 692 and the user identity. Including the user identity into a SAML 693 assertion is optional. To limit queriers, a SAML assertion can 694 restrict its audience by addressing the URIs of specific entities, 695 but they are currently not allowed to address by their hashed names. 696 Thus, with a minor modification in the form of the restricted 697 audience, we can use an XML-based SAML assertion to convey user 698 attributes instead of a JSON object described in Section 5.4. 699 However, using a SAML assertion requires a digital signature by its 700 issuer, which is an application layer protection against message 701 tampering and server impersonation. As discussed in Section 4.1, we 702 prefer a simple transport layer protection to an application layer 703 one, namely protecting a whole message by TLS rather than protecting 704 part of a message by a digital signature. 706 Vouch by Reference (VBR) defines a simple mechanism that vouches a 707 specific type of content claimed by the sender's domain of an email 708 message. This mechanism uses a new email "VBR-Info" header and a 709 DNS-based server of a third party certification service. If the 710 recipient finds a trusted domain from the certification service 711 providers set in the VBR-info header in a received email message, he 712 looks up an entry of the sender domain on the DNS-based server of a 713 trusted certification service provider. Since VBR assumes the same 714 trust model as ours, it is possible to extend this VBR mechanism to 715 vouch a user's attributes instead of certifying a specific content 716 type for the sender's domain. However, VBR requires the 717 authentication of the sender domain since the server domain is used 718 as a query key. Additionally, it is difficult for a DNS-based server 719 to restrict queriers for each record, mainly private attributes. 720 Consequently, we cannot apply VBR to referencing user attributes. 722 OAuth is a third-party authentication model for Web services. OAuth 723 uses three tokens to delegate limited permissions of user's resource 724 to another entity called a Consumer. With the OAuth terminology, a 725 caller is a User, the callee is a Consumer, and the AVS is a Service 726 Provider, which is a third-party authenticator. In OAuth, unlike our 727 trust model, the AVS and the callee share a Consumer ID and a key to 728 authenticate the Consumer when the AVS provides one of these three 729 tokens, a Request Token. An unauthorized Request Token is generated 730 upon the Consumer's request. After the Consumer is authorized by a 731 User, it is provided with an authorized Request Token. Since this 732 authorized Request Token has a restricted scope and limited lifetime 733 to access the Users' resources, this Request Token can be used to 734 query the caller's attributes once the caller authorizes that. 735 However, to obtain an authorized Request Token, the callee, who is a 736 Consumer in OAuth, needs to obtain an unauthorized Request Token from 737 the AVS beforehand. To resolve these differences in the trust models 738 and the procedures, it is possible to omit using both an unauthorized 739 and authorized Request Tokens. In addition, using the third token in 740 OAuth, an Access Token, which is exchanged with an authorized Request 741 Token, is not needed. Thus, we do not need unnecessary complexities 742 of using these three types of tokens. Rather, we prefer a simple 743 mechanism, using a single token for SIP. 745 Kerberos provides strong user-client authentication using a Key 746 Distribution Center (KDC). An Authentication Server in KDC 747 authenticates a user on behalf of a Service Server (SS), and a Ticket 748 Granting Server (TGS) issues a ticket which is effective only for a 749 session between the user and the SS for a limited time period. The 750 Kerberos features cover all our mechanism needs, but the trust model 751 is different. Kerberos assumes that the TGS and the SS share the 752 SS's secret key to allow the SS to verify a received ticket by 753 decrypting with the SS's key without connecting to the TGS. Since 754 using this ticket is a key feature in Kerberos, we cannot omit 755 sharing the SS's key with the TGS to resolve the difference in the 756 trust model. Because of this difference in assumed trust model, we 757 cannot use Kerberos for referencing and validating user attributes. 759 8. Security Considerations 761 8.1. Man in the Middle Attacks 763 Man in the middle attacks need to be prevented on the AVS, connection 764 links, and the recipients of an ARID. To prevent from impersonating 765 a user on the AVS, the AVS MUST authenticate a user using HTTP Basic 766 or Digest authentication, a client X.509 PKC or other mechanisms. To 767 prevent from eavesdropping and message tampering on connection links, 768 all connection links between UAC and the AVS, UAC and UAS, UAS and 769 the AVS MUST be protected using TLS. 771 To prevent from impersonating user attributes using a stolen ARID, 772 the AVS MUST limit queriers using a specific ARID based on the hashed 773 contact addresses the original requester of the ARID specifies. SIP 774 UAs MUST support SHA1 to hash a contact address. To mitigate the 775 damage of the impersonation in the case where an ARID is stolen with 776 one of these hashed contact addresses, the AVS MUST limit an ARID's 777 lifetime and MAY also limit the number of times it can be resolved. 778 Limiting the use times of an ARID strengthens security, but 779 reduces service applicability. When the originator of a 780 communication knows that the communication has multiple 781 recipients, she can specify these multiple destination addresses 782 as designated queriers. The AVS then limits the use times of an 783 ARID to one for each designated querier. However, the difficult 784 case exists where the originator cannot know the number of honest 785 recipients or their addresses, for example, using a forking proxy 786 at the destination side or using a list service that distributes 787 the same message to multiple registered destinations. 789 8.2. Replay Attacks Using a Received ARID 791 The recipient of an ARID can exploit impersonation just by forwarding 792 a received ARID to another user since this mechanism does not have a 793 tight link between the username of AVS and the caller ID as described 794 in Section 3.2 nor a link between the SIP signaling path and the 795 ARID. To prevent this replay or forwarding attack, the AVS MUST 796 limit queriers for each ARID based on the hashed contact addresses 797 that the original requester of the ARID specifies. This is the same 798 way as preventing impersonation using a stolen ARID described in 799 Section 8.1. 801 Suppose Bob, the recipient of Alice's ARID, forwards the ARID to 802 Carol when sending an instant message to her. In the message, Bob 803 instructs Carol to query his attributes using his hashed contact 804 address, instead of hers. By instructing this wrong way of query, 805 Bob fails in his attempt to masquerade as a user having Alice's 806 attributes. However, despite Alice's original designation, Carol can 807 retrieve Alice's attributes following Bob's wrong instruction, 808 resulting in raising Alice's privacy concerns. This privacy problem 809 is caused by Bob's misbehavior and unavoidable for any attribute 810 mechanisms which others can retrieve the attributes. 812 8.3. Denial of Service Attacks on the AVS 814 Another form of potential attacks is denial of service (DoS) attacks 815 by flooding requests to exhaust resources on the AVS. To mitigate 816 the damage from DoS attacks, we need to spare resources for valid 817 requests. For this purpose, the AVS MUST carefully configure TCP and 818 implement user authentication. To detect invalid requests as easily 819 as possible, this mechanism SHOULD use a light query protocol using 820 the RESTful API [REST], which sets a query key in the path of an HTTP 821 URL. 823 8.4. Phishing Attacks on the AVS 825 An evil website having a domain name confusingly similar to a well- 826 known AVS makes it possible to steal the password of a user for 827 remote access to the AVS. It is also possible for an evil website to 828 respond to any attribute queries with an HTTP 200 OK response with 829 forged user attributes attached to invalidate the attribute 830 validation service. To prevent these attacks, both a user and the 831 recipient of an ARID MUST use TLS when connecting to the AVS and MUST 832 ensure that the server's PKC has a valid signature for the valid 833 domain name. 835 9. IANA Considerations 837 This document defines a new SIP Sender-References header field. This 838 header field needs to be registered by the IANA in the SIP Parameters 839 registry under the Header Fields sub-registry. 841 10. References 843 10.1. Normative References 845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 846 Requirement Levels", BCP 14, RFC 2119, March 1997. 848 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 849 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 850 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 852 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 853 A., Peterson, J., Sparks, R., Handley, M., and E. 854 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 855 June 2002. 857 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 858 Resource Identifier (URI): Generic Syntax", STD 66, 859 RFC 3986, January 2005. 861 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 862 Specifications: ABNF", STD 68, RFC 5234, January 2008. 864 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 865 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 867 [SHA1] National Institute of Science and Technology, "Secure Hash 868 Standard", Federal Information Processing Standard 869 (FIPS) 180-2, August 2002. 871 10.2. Informative References 873 [AES] National Institute of Science and Technology, 874 "Specifications for the Advanced Encryption Standard", 875 Federal Information Processing Standard (FIPS) 197, 876 November 2001. 878 [REST] Fielding, R. and R. Taylor, "Principled design of the 879 modern Web architecture", ACM Transactions on Internet 880 Technology (TOIT) 2-2, May 2002, 881 . 883 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 884 Leach, P., Luotonen, A., and L. Stewart, "HTTP 885 Authentication: Basic and Digest Access Authentication", 886 RFC 2617, June 1999. 888 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 889 RFC 3966, December 2004. 891 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 892 Kerberos Network Authentication Service (V5)", RFC 4120, 893 July 2005. 895 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 896 Authenticated Identity Management in the Session 897 Initiation Protocol (SIP)", RFC 4474, August 2006. 899 [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, 900 "Trait-Based Authorization Requirements for the Session 901 Initiation Protocol (SIP)", RFC 4484, August 2006. 903 [RFC4627] Crockford, D., "The application/json Media Type for 904 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 906 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 907 Housley, R., and W. Polk, "Internet X.509 Public Key 908 Infrastructure Certificate and Certificate Revocation List 909 (CRL) Profile", RFC 5280, May 2008. 911 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 912 Reference", RFC 5518, April 2009. 914 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 915 Mail Extensions (S/MIME) Version 3.2 Message 916 Specification", RFC 5751, January 2010. 918 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 919 Attribute Certificate Profile for Authorization", 920 RFC 5755, January 2010. 922 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 923 April 2010. 925 [SAML] "Security Assertion Markup Language (SAML) V2.0", 926 March 2005, 927 . 929 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 930 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third 931 Edition)", W3C Recommendation REC-xml-20040204, 932 February 2004. 934 Authors' Addresses 936 Kumiko Ono 937 Department of Computer Science 938 Columbia University 939 New York, NY 10027 940 USA 942 Email: kumiko@cs.columbia.edu 944 Henning Schulzrinne 945 Department of Computer Science 946 Columbia University 947 New York, NY 10027 948 USA 950 Email: hgs@cs.columbia.edu