idnits 2.17.1 draft-lowekamp-p2psip-dsip-security-00.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 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 710. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 721. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 728. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 734. 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 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 (February 25, 2007) is 6269 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) == Outdated reference: A later version (-15) exists of draft-ietf-sip-certs-02 == Outdated reference: A later version (-04) exists of draft-willis-p2psip-concepts-03 ** Downref: Normative reference to an Informational draft: draft-willis-p2psip-concepts (ref. 'I-D.willis-p2psip-concepts') ** Downref: Normative reference to an Informational RFC: RFC 2104 ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 P2PSIP B. Lowekamp 3 Internet-Draft J. Deverick 4 Intended status: Standards Track SIPeerior 5 Expires: August 29, 2007 February 25, 2007 7 Authenticated Identity Extensions to dSIP 8 draft-lowekamp-p2psip-dsip-security-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 29, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document describes mechanisms to authenticate peer and resource 42 identities within a distributed SIP overlay. It makes use of 43 existing identity frameworks, modifying them as necessary to 44 accommodate the specific needs of a peer-to-peer environment. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.1. Security Models . . . . . . . . . . . . . . . . . . . . . 4 52 3.2. Security Process . . . . . . . . . . . . . . . . . . . . . 5 53 3.3. Example Message Flow . . . . . . . . . . . . . . . . . . . 6 54 4. Peer Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 55 4.1. Changes to RFC4474 . . . . . . . . . . . . . . . . . . . . 9 56 4.2. Resource Tickets . . . . . . . . . . . . . . . . . . . . . 9 57 4.3. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 10 58 4.4. Processing Requests . . . . . . . . . . . . . . . . . . . 10 59 4.5. Processing Responses . . . . . . . . . . . . . . . . . . . 10 60 5. Shared Secret . . . . . . . . . . . . . . . . . . . . . . . . 10 61 5.1. Validating Messages . . . . . . . . . . . . . . . . . . . 11 62 6. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 6.1. Selecting the Authenticating Identity for Messages . . . . 12 64 6.2. Validating Messages . . . . . . . . . . . . . . . . . . . 12 65 6.3. Fetching Certificates . . . . . . . . . . . . . . . . . . 13 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 67 7.1. Protecting the ID Namespace . . . . . . . . . . . . . . . 14 68 7.2. Protecting the resource namespace . . . . . . . . . . . . 14 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 70 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 73 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 75 Intellectual Property and Copyright Statements . . . . . . . . . . 17 77 1. Introduction 79 The distributed Session Initiation Protocol (dSIP) extends 80 traditional SIP by providing peer-to-peer registration and resource 81 location. While most security mechanisms for dSIP derive naturally 82 from its client-server counterpart, certain considerations must be 83 made for the peer-to-peer extensions provided by the protocol. 84 Joining peers should only be admitted into an overlay if they are 85 authorized members of that overlay. Resources should be 86 authenticated to ensure genuine communication among them. 88 Without such security measures in place, attackers can generate false 89 identities and become peers in the system, where they can interfere 90 with message routing and maintenance of the overlay structure. They 91 can also masquerade as other, valid users or resources in the 92 overlay, possibly generating false responses to resource requests. 94 The goal of dSIP is to scale gracefully from ad hoc groups of a few 95 people to an overlay of millions of peers across the globe. As such, 96 there is no one security model that fits the needs of all envisioned 97 environments; for the small network establishing a certificate chain 98 is difficult, while for a global network the unrestricted ability to 99 insert resources and devise useful Peer IDs is a clear invitation to 100 insecurity. To address this issue, the dSIP security extensions 101 offer two different security models. The first is based on a shared 102 secret key and is applicable to small environments where deployment 103 of more complicated schemes is impractical. The second is a public 104 key certificate system applicable to larger deployments in which the 105 administrative costs of public key management is preferable to the 106 scalability issues of shared secret keys. One of these models should 107 be selected according to the needs of the overlay and the anticipated 108 deployment scenario. 110 Both approaches make use of the Identity digest-string header 111 presented in RFC 4474. In that specification, this digest over 112 certain header fields and the message body is signed by an 113 authentication service for the domain in which the communication is 114 occurring. Because the concept of a specific, server-based, central 115 authentication service role is antithetical to the dSIP paradigm, 116 this approach modifies how the Identity header is signed when 117 messages are being constructed. Details on the changes as applicable 118 to each security model are presented in Section 3.1 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 Terminology defined in RFC 3261 [RFC3261] is used without definition. 128 We use also the terminology and definitions from Concepts and 129 Terminology for Peer to Peer SIP [I-D.willis-p2psip-concepts] and 130 dSIP: A P2P Approach to SIP Registration and Resource Location 131 [I-D.bryan-p2psip-dsip] extensively in this document. 133 3. Overview 135 Instead of violating the distributed nature of dSIP by implementing 136 the RFC 4474 authentication service as central server, the dSIP 137 Security Extensions require communication endpoints to sign and 138 validate correspondence directly. The method by which this is done 139 varies depending on the security model being used. In both models, 140 the Identity digest-string is generated without modification as 141 described in P2P Identity, but the protocol by which the digest is 142 signed (and by extension the verification protocol) changes. 143 Additionally, we modify the contents of the Identity-Info header as 144 necessary to provide message recipients required information to 145 validate incoming messages. For both security models, the details of 146 key and certificate provisioning are beyond the scope of this 147 document, and we assume that they are provided by some out of band 148 mechanism. 150 3.1. Security Models 152 The shared secret signature process is straightforward. After the 153 identity digest-string is generated, the endpoint encrypts it with 154 the shared secret key for the overlay, and populates the Identity 155 header with the encrypted value. It also injects a string 156 identifying the algorithm used to generate the Identity value in the 157 Identity-Info header. The recipient of the message can then generate 158 the same digest-string, and encrypt it with the same shared key and 159 algorithm, comparing the result to the value presented in the 160 Identity header of the message. If the value generated by the 161 recipient does not match the value contained in the Identity header, 162 the message should be considered unauthorized and rejected. 164 In the public key certificate model, each endpoint has a different 165 private key and a corresponding public key certificate issued by a 166 certificate authority for the overlay. When an endpoint prepares an 167 outbound message, it generates the identity digest-string and signs 168 it with its unique private key. In addition, it fills the Identity- 169 Info header with the sip URI of the certificate that the recipient 170 needs to verify the identity signature. When the recipient receives 171 the message, it may have a preloaded or cached copy of the necessary 172 certificate. If not, it can subscribe to the URI indicated in the 173 Identity-Info header using the SIP event notification extensions 174 defined in sip-certs [I-D.ietf-sip-certs] to fetch the needed 175 certificate. When the certificate arrives, the recipient must first 176 verify that it is signed by the CA for the overlay. Once the 177 validity of the certificate is confirmed, the recipient can use the 178 certificate to verify the signed digest-string in the Identity header 179 of the original message and accept or reject the message 180 appropriately. The fetched certificate may, as a matter of local 181 policy, be cached for future verifications. 183 3.2. Security Process 185 Generally speaking, there are two processes that are secured by this 186 approach: DHT maintenance and resource registrations and migrations. 187 The signatories for DHT maintenance are peers in the system. For 188 resource registrations, the resources themselves provide signatures. 189 This distinction is unimportant in the shared secret model, where the 190 same key is used to create all Identity headers. In the public key 191 certificate system, however, it is possible for peers and resources 192 to be issued different key-certificate pairs. It is also possible 193 for a resource to be bound to one or more peers, containing the peer 194 IDs as subjectAltNames in its certificate. In such a case, the same 195 key may be used to sign, and corresponding certificate used to 196 validate, both peer and resource communication, though in general 197 they are distinct. 199 DHT maintenance, including peer registrations, authenticate messages 200 by verifying that the Identity header was generated with the overlay 201 key, in the case of the shared-secret model. In the public-key 202 certificate model, receiving nodes verify that the header was 203 generated using the key associated with the specified peer ID as 204 assigned by the certificate authority for the overlay. 206 Resource registrations are identical to peer registrations in the 207 shared-secret model. In the certificate-based model, however, the 208 verification process uses the certificate for the resource indicated 209 in the From header, rather than the peer ID. 211 Once a resource is registered in the overlay, its signed registration 212 is included as a resource ticket in all responses to queries for that 213 resource. This resource ticket prevents subversive peers from 214 forging registrations directly, and limits them to attacks on the 215 routing or a simple DoS by not providing any registration information 216 to queries. This is particularly important as peers join and leave 217 the overlay; the resulting changes in the structure of the DHT 218 commonly result in resource migration among peers. Requiring that 219 the original, signed registration be included in responses inhibits 220 rogue peers' abilities to claim that they host resources not 221 legitimately migrated to them. 223 3.3. Example Message Flow 225 To illustrate the message flow generated by the security extensions, 226 consider a resource registration and query. Because it is the most 227 complex scenario, assume that the public key certificate model is 228 used, and that no certificates have been preloaded or cached by peers 229 in the system. 231 Peer 0 Peer 1 Peer 2 232 | | | 233 |(1) REGISTER | | 234 |------------------>| | 235 | resource r | | 236 | | | 237 |(2) SUBSCRIBE | | 238 |<------------------| | 239 | cert for r | | 240 | | | 241 |(3) NOTIFY | | 242 |------------------>| | 243 | cert for r | | 244 | | | 245 |(4) 200 | | 246 |<------------------| | 247 | | | 248 | |(5) REGISTER | 249 | |<------------------| 250 | | query r from s | 251 | | | 252 | |(6) SUBSCRIBE | 253 | |------------------>| 254 | | cert for s | 255 | | | 256 | |(7) NOTIFY | 257 | |<------------------| 258 | | cert for s | 259 | | | 260 | |(8) 200 | 261 | |------------------>| 262 | | response r | 263 | | | 264 |(9) SUBSCRIBE | | 265 |<--------------------------------------| 266 | cert for r | | 267 | | | 268 |(10) NOTIFY | | 269 |-------------------------------------->| 270 | cert for r | | 272 In (1), resource r is registered at peer 1. Since peer 1 does not 273 have a copy of r's certificate to verify the Identity header for r's 274 registration, it subscribes to the URI indicated by the Identity-Info 275 header of the REGISTER message. In this case, that header contains 276 the URI of peer 0. Peer 0, on receipt of the certificate 277 subscription request (2), issues a notification response (3) 278 containing r's certificate. At this point, peer 1 validates that the 279 certificate is signed by the overlay's certificate authority, then 280 uses the certificate to verify the Identity field in the original 281 registration for resource r. Because the signature is valid, peer 1 282 issues a 200 OK (4) to peer 0, indicating that r has been registered 283 successfully. 285 Later, resource s wishes to query resource r. After locating r as 286 described in dSIP and omitted from this diagram, s queries peer 1 (5) 287 for resource r. The REGISTER message used for this query contains a 288 signed digest-string that peer 1 must validate. Because peer 1 does 289 not have a copy of s's certificate, it subscribes to peer 2 (6), the 290 URI provided by resource s in the Identity-Info header. Resource s 291 at peer 2 responds with its certificate (7), allowing peer 1 to 292 verify the resource request. Once the verification is complete, peer 293 1 responds (8) to the resource query. Included in the response to 294 s's query is a copy of r's original registration at peer 1. In order 295 to trust that the response is valid, s must verify that the copy of 296 r's registration actually originated from r and has not yet expired. 297 It does so by subscribing (9) to peer 0 as indicated in by the 298 Identity-Info header of the encapsulated registration. Peer 0 299 responds with a copy of r's certificate (10), which s uses to verify 300 that the response it received from its query for resource r 301 ultimately originated from r's valid registration. 303 Note that the responses in steps (4) or (8) could also be 401 304 Unauthorized if the certificates received by the corresponding 305 notifications could not verify the requests in (1) and (5), 306 respectively. In the first case, this would result in a failed 307 registration for resource r. In the second, the query for r from 308 resource s would be refused. Finally, if the certificate retrieved 309 in (10) fails to verify the encapsulated copy of r's registration 310 received in (8), then s should treat the response as unauthorized and 311 discard it. 313 4. Peer Behavior 315 This draft applies to all messages sent between peers in a dSIP 316 overlay. Such messages are identifiable by the presence of the token 317 'dht' in the message's Require header. The provisions provided by 318 this document are not applicable to messages that do not satisfy this 319 prerequisite. If the overlay requires dSIP-identity security to be 320 used, then all messages sent that perform any dht or resource 321 maintenance or queries (any message with a Require: p2p) MUST include 322 the appropriate Identity and Identity-Info headers. Messages 323 received that do not contain an Identity header MUST be rejected with 324 a 428 Use Identity Header response code. Extensions defined in this 325 document MUST NOT appear in any message that does not include a "dht" 326 token in the Require header. 327 Because we interpret the Identity and Identity-Info headers from 328 RFC 4474 differently, we have to prevent implementations of 329 conventional RFC 4474 from being adversely affected. By requiring 330 that this specification only apply to messages with the Require 331 dht header, standard RFC 4474 implementations should not see the 332 modified messages. Whether or not this is satisfactory to address 333 the concern remains an open question. 335 4.1. Changes to RFC4474 337 dSIP-identity is an extension of RFC 4474 [RFC4474]. Unless this 338 draft specifies otherwise, all behavior described in RFC 4474 is 339 followed in generating the dSIP-identity headers. In particular, 340 digest-string is determined in the same manner. The two major 341 exceptions are: 342 Response Authentication: Unlike RFC 4474, responses MUST include an 343 Identity header used to validate the response. Although the 344 sender does not always know which peer will ultimately respond to 345 a request, it can assert that the response it receives originated 346 from an authorized member of the overlay. 347 Fetching Certificates: For certificate-based security, RFC 4474 348 specifies that implementations MUST support HTTP and HTTPS URIs in 349 the Identity-Info header. All peers compliant with this 350 specification MUST support HTTP and HTTPS URIs for retrieving 351 certificates from peers providing such a server. In addition, all 352 peers compliant with this specification MUST support the 353 "certificate" SIP Event Package from sip-certs 354 [I-D.ietf-sip-certs] both as subscriber and notifier. A peer MUST 355 NOT provide an HTTP or HTTPS URI for its Identity-Info unless it 356 knows that no NAT traversal techniques will be required to contact 357 that server (i.e. it knows its server has an unfirewalled port at 358 an address that is directly routable by all peers in the overlay). 359 Because this is difficult to know in advance, peers SHOULD rely on 360 the Event Package technique. 362 4.2. Resource Tickets 364 A peer receiving a resource registration for which it is responsible 365 stores the registration itself and additionally MUST store the 366 digest-string, Identity, and Identity-Info from the actual request 367 message used to send the registration. This information stored from 368 the request message will be known as a resource ticket. The resource 369 ticket MUST be returned in the body of any 200 OK response the 370 responsible peer returns in response to a query for the resource it 371 is responsible for. The ticket allows the querying entity to 372 validate that the actual resource performed the indicated 373 registration. 375 4.3. Sender Behavior 377 When sending a message, the sender implements the authentication 378 service described in RFC 4474 [RFC4474]. 380 4.4. Processing Requests 382 A peer MUST NOT perform any action that changes state or returns 383 information stored in the overlay without validating the Identity 384 signature of the request message. A peer MAY proxy or redirect a 385 request without validation, and it may return error codes indicating 386 an error in the request, such as 413, 414, 420, etc without 387 validating the request, however it MUST NOT process a DHT maintenance 388 request or resource registration that it is responsible for in any 389 way, including generating a 404, until it has completed validation of 390 the message's signature. 392 An important exception to the above rule is that in certificate-based 393 security schemes, a peer MUST NOT validate a SUBSCRIBE request for 394 the peer's certificate if it requires fetching the certificate of the 395 peer submitting the request. This exception avoids deadlock fetching 396 certificates. 398 4.5. Processing Responses 400 A peer MUST NOT perform any action based on a response without 401 validating the Identity signature of the response message. This 402 includes reacting to an error code such as 420 response that may be 403 generated without validating the corresponding request. 405 After validating the response message to a resource query, if the 406 result code is a 200 OK, the peer MUST confirm that the response 407 contains a resource ticket. The peer MUST then separately validate 408 the resource ticket. Because resource tickets are longer-lived than 409 standard messages, the peer SHOULD allow a longer validity period 410 with respect to the Date header of the message, although not in 411 excess of the Expires value of the resource ticket. 413 5. Shared Secret 415 To secure a small-scale network, perhaps an office environment or 416 small group of people who wish to communicate together, a shared 417 secret will suffice. Rather than relying on a domain certificate, 418 therefore, the Identity field consists of an HMAC-SHA1 [RFC2104] hash 419 of the digest-string. 421 Because shared secrets are shared between all peers in the overlay, 422 there is no need to fetch one, therefore Identity-Info stores only 423 the name of the algorithm used to sign the message. This requires a 424 change in the syntax of the Identity-Info header to allow the ident- 425 info parameter to be omitted: 427 Identity-Info = "Identity-Info" HCOLON ident-uri-info / 428 ( ident-info-params *( SEMI ident-info-params ) ) 429 ident-uri-info = ident-info *( SEMI ident-info-params ) 431 where ident-uri-info is the definition of Identity-Info from RFC 4474 432 and ident-info-params is used as the only element of Identity-Info 433 only when used for a security mechanism such as shared secret where 434 no certificates must be identified or retrieved. 436 Messages using shared secrets must contain an "alg" parameter. This 437 specification defines the value "hmac-sha1" for the "alg" parameter. 438 Messages MUST additionally contain the token "dSIP" as an ident-info- 439 extension to indicate the type of processing required to validate the 440 message. Therefore, the Identity-Info header will be 442 Identity-Info: alg=hmac-sha1;dSIP 444 5.1. Validating Messages 446 Validating messages signed with a shared secret is simple because all 447 messages are signed with the same shared secret. Therefore the 448 message can be validated without fetching any external information. 449 When validating a message, the receiver MUST verify that the Identity 450 header presents the correct 'hmac-sha1' hash obtained by hashing the 451 message's digest-string using the overlay's shared secret as the key. 452 Any message that provides incorrect Identity information MUST be 453 rejected with a 438 Invalid Identity Header response code. 455 6. Certificates 457 Certificate-based implementations of dSIP-identity require the 458 existence of a CA responsible for the overlay. Typically each user 459 registering for the overlay will receive a certificate for their 460 identity within the overlay (AoR) and a small number of PeerIDs as 461 subjectAltNames to identity peers they intend to use (allowing for 462 multiple PeerIDs for multiple UAs the user may wish to have on the 463 overlay simultaneously). The CA SHOULD issue such PeerIDs 464 consecutively to prevent a single user from controlling multiple 465 portions of the overlay. Other than consecutive PeerIDs assigned to 466 the same user, PeerIDs SHOULD be assigned uniformly across the 467 namespace. 469 Each peer must be provisioned with the CA's certificate as well as 470 its own private key and certificate, signed by the CA. 472 For peers providing their certificates to other peers through the 473 "certificate" SIP Event Package [I-D.ietf-sip-certs], ident-info in 474 Identity-Info typically will be the P2P URI of the peer. Peers 475 hosting resources with separate certificates MUST use different URIs 476 for each certificate, but each URI MUST contain the peerID of the 477 peer hosting that resource so that SUBSCRIBE messages can be routed 478 to the correct peer. 480 Messages sent using certificate-based dSIP-identity MUST include the 481 tokens 'alg=rsa-sha1' and 'dSIP' in the Identity-Info Header. This 482 is in addition to the URI from which the sender's certificate can be 483 retrieved. 485 6.1. Selecting the Authenticating Identity for Messages 487 All request messages MUST be signed with the identity specified in 488 the From header. For DHT maintenance (peer registration and 489 queries), this will also be the same as the PeerID header, i.e. the 490 identity of the peer originating the request. For resource 491 registrations and queries, this will be the identity of the resource 492 performing the operation. In the typical case, a UA will have a 493 single certificate that is used for both the user's identity and peer 494 ID, so these may be the same certificate. 496 All response messages MUST be signed with the identity specified in 497 the PeerID header, which identifies the peer generating the response 498 and authenticates the response as having been generated by an 499 authorized peer. The requesting peer might also validate that the 500 responding peer has an appropriate PeerID to be responsible for that 501 portion of the namespace, but such validation is outside the scope of 502 this draft and may have negative implications for resource caching or 503 other optimizations. 505 Note that a resource migration, which is a third party registration 506 used to move resources as the peers responsible for those resource 507 IDs change due to joining or exiting peers, is signed using the key 508 of the admitting or exiting peer and uses that peer's URI as it's 509 From address. The resource ticket MUST be included in the body of 510 that request. 512 6.2. Validating Messages 514 To validate a message, a peer first checks its certificate cache to 515 see whether it has a certificate corresponding to the authenticating 516 identity used to sign the message. If it does not, it MUST fetch the 517 certificate using the URI in Identity-Info and defer further 518 processing of the message until validation can be completed. A peer 519 MUST NOT validate a "certificate" SIP Event Package SUBSCRIBE request 520 for the peer's certificate if it does not already possess the 521 certificate of the subscribing peer. It MUST respond to such 522 requests without verification. 524 The peer MUST use the certificate corresponding to the authenticating 525 identity appropriate for the type of message, as described above in 526 Section 6.1. The peer MUST NOT use Identity-Info to determine which 527 certificate to use. If a certificate retrieved from the URI 528 specified in Identity-Info does not match the appropriate 529 authenticating identity or is not signed by the certificate authority 530 for the overlay, the peer MUST reject that message with a 438 Invalid 531 Identity Header response code. 533 After confirming that it has the correct certificate, the peer 534 follows the procedures specified in RFC 4474 [RFC4474] to verify the 535 signature. 537 6.3. Fetching Certificates 539 A peer uses the "certificate" SIP Event Package[I-D.ietf-sip-certs] 540 to fetch certificates. Because CA-signed certificates are long- 541 lived, the peer SHOULD issue the SUBSCRIBE with Expires header of 0 542 to specify only a single NOTIFY response is desired. 544 After receiving the NOTIFY response, the peer MUST verify that the 545 certificate received is signed by the overlay's CA. Certificates 546 that are not signed by the overlay's CA MUST immediately be discarded 547 and any message validations waiting for the certificates to be 548 fetched MUST immediately be rejected with a 437 Unsupported 549 Certificate response code. 551 7. Security Considerations 553 No security scheme is stronger than the security with which it is 554 administered. If the shared-secret passphrase for the HMAC security 555 scheme is discovered by an attacker, then the security of the entire 556 scheme is lost. Similarly, for the dSIP-identity security scheme, if 557 the CA is compromised and an attacker can generate arbitrary 558 certificates, the security of the scheme is compromised. Although it 559 is fundamental to the security of both of these schemes, the 560 provisioning of peers with either the shared secret passphrase or 561 with an private key and certificate is beyond the scope of this 562 draft. 564 The dSIP-identity security scheme secures the namespace, but if an 565 individual peer is compromised or if an attacker obtains a 566 certificate from the CA, then a number of subversive peers can still 567 appear in the overlay, compromising (not returning) registrations 568 they are responsible for and possibly subverting routing to other 569 compromised peers. To defend against such compromised peers, a 570 resource search must still consist of parallel searches for 571 replicated registrations. The ultimate reliability of such an 572 overlay is a statistical question based on the replication factor and 573 the percentage of compromised peers. 575 Because this protocol relies on digest-string from RFC 4474 576 [RFC4474], it provides the same message integrity, authentication, 577 and defense against replay attacks offered by that specification. It 578 also shares the same weaknesses, described in Section 13 of RFC 4474. 579 In particular, because Identity and Identity-Info headers can be 580 replaced by an attacker, it is up to the recipient to ensure that the 581 certificate used to sign this message matches the claimed sender of 582 the message and that the certificate is signed by the proper CA for 583 the particular overlay. 585 7.1. Protecting the ID Namespace 587 When used properly, both schemes sufficiently inhibit attackers 588 attempting to join the overlay. The dSIP-identity scheme, in 589 particular, further protects the ID namespace by reducing the impact 590 of compromising a single authorized peer of the overlay, whereas an 591 attacker compromising a single peer in the shared-secret scheme can 592 obtain the shared secret and thus compromise the entire namespace. 594 7.2. Protecting the resource namespace 596 The shared-secret scheme protects the overlay from unauthorized peers 597 joining the overlay, but it provides no protection from a compromised 598 peer inserting arbitrary resource registrations, performing a Sybil 599 attack[Sybil], or performing other attacks on the resources. 601 The dSIP-identity scheme prevents an attacker compromising a single 602 peer from being able to forge the registration for more than that 603 peer's resources. Furthermore, although a subversive peer can refuse 604 to return registration entries for resources for which it is 605 responsible or in response to requests routed through it (404 Not 606 Found responses), it cannot return forged registrations because it 607 cannot authenticate such registrations. Therefore parallel searches 608 for redundant registrations mitigate most of the affects of a 609 compromised peer. 611 Once a resource is registered, the corresponding Resource Ticket is 612 used in queries for that resource, migrated between peers, and 613 generally considered public knowledge. As it is inherently intended 614 to be replayed, the value selected in the Expires header of the 615 original registration must be chosen carefully to ensure that 616 responses to future queries do not direct the querier to a location 617 over which the resource no longer has control. 619 8. IANA Considerations 621 This document defines the "dSIP" token as an ident-info-extension to 622 the Identity-Info header. 624 9. Acknowledgments 626 A team of people have worked on the various drafts related to the 627 dSIP protocol and extensions thereof. The team consists of: David 628 Bryan, Eric Cooper, James Deverick, Cullen Jennings, Bruce Lowekamp, 629 Philip Matthews, and Marcia Zangrilli. 631 Thanks to all who have been actively participating in the P2PSIP 632 efforts. Special thanks to Spencer Dawkins, Enrico Marocco, and 633 Jean-Francois Wauthy for providing editorial feedback, and Henry 634 Sinnreich, Eric Rescorla, and Alan Johnston for various discussions 635 related to this work. 637 10. References 639 10.1. Normative References 641 [I-D.bryan-p2psip-dsip] 642 Bryan, D., Lowekamp, B., and C. Jennings, "dSIP: A P2P 643 Approach to SIP Registration and Resource Location", 644 Internet Draft draft-bryan-p2psip-dsip-00, February 2007. 646 [I-D.ietf-sip-certs] 647 Jennings, C., "Certificate Management Service for The 648 Session Initiation Protocol (SIP)", 649 draft-ietf-sip-certs-02 (work in progress), October 2006. 651 [I-D.willis-p2psip-concepts] 652 Willis, D., "Concepts and Terminology for Peer to Peer 653 SIP", draft-willis-p2psip-concepts-03 (work in progress), 654 October 2006. 656 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 657 Hashing for Message Authentication", RFC 2104, 658 February 1997. 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, March 1997. 663 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 664 A., Peterson, J., Sparks, R., Handley, M., and E. 665 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 666 June 2002. 668 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 669 Authenticated Identity Management in the Session 670 Initiation Protocol (SIP)", RFC 4474, August 2006. 672 10.2. Informative References 674 [Sybil] Douceur, J., "The Sybil Attack", March 2002. 676 Authors' Addresses 678 Bruce B. Lowekamp 679 SIPeerior 680 3000 Easter Circle 681 Williamsburg, VA 23188 682 USA 684 Phone: +1 757 565 0101 685 Email: lowekamp@sipeerior.com 687 James W. Deverick 688 SIPeerior 689 3000 Easter Circle 690 Williamsburg, VA 23188 691 USA 693 Phone: +1 757 565 0101 694 Email: jdeverick@sipeerior.com 696 Full Copyright Statement 698 Copyright (C) The IETF Trust (2007). 700 This document is subject to the rights, licenses and restrictions 701 contained in BCP 78, and except as set forth therein, the authors 702 retain all their rights. 704 This document and the information contained herein are provided on an 705 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 706 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 707 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 708 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 709 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 710 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 712 Intellectual Property 714 The IETF takes no position regarding the validity or scope of any 715 Intellectual Property Rights or other rights that might be claimed to 716 pertain to the implementation or use of the technology described in 717 this document or the extent to which any license under such rights 718 might or might not be available; nor does it represent that it has 719 made any independent effort to identify any such rights. Information 720 on the procedures with respect to rights in RFC documents can be 721 found in BCP 78 and BCP 79. 723 Copies of IPR disclosures made to the IETF Secretariat and any 724 assurances of licenses to be made available, or the result of an 725 attempt made to obtain a general license or permission for the use of 726 such proprietary rights by implementers or users of this 727 specification can be obtained from the IETF on-line IPR repository at 728 http://www.ietf.org/ipr. 730 The IETF invites any interested party to bring to its attention any 731 copyrights, patents or patent applications, or other proprietary 732 rights that may cover technology that may be required to implement 733 this standard. Please address the information to the IETF at 734 ietf-ipr@ietf.org. 736 Acknowledgment 738 Funding for the RFC Editor function is provided by the IETF 739 Administrative Support Activity (IASA).