idnits 2.17.00 (12 Aug 2021) /tmp/idnits43463/draft-ietf-sip-certs-05.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1276. 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 (January 31, 2008) is 5224 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) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3268 (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track J. Peterson 5 Expires: August 1, 2008 NeuStar, Inc. 6 J. Fischl, Ed. 7 CounterPath Solutions, Inc. 8 January 31, 2008 10 Certificate Management Service for The Session Initiation Protocol (SIP) 11 draft-ietf-sip-certs-05 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 9, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This draft defines a Credential Service that allows Session 45 Initiation Protocol (SIP) User Agents (UAs) to use a SIP event 46 package to discover the certificates of other users. This mechanism 47 allows user agents that want to contact a given Address-of-Record 48 (AOR) to retrieve that AOR's certificate by subscribing to the 49 Credential Service, which returns an authenticated response 50 containing that certificate. The Credential Service also allows 51 users to store and retrieve their own certificates and private keys. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. UA Behavior with Certificates . . . . . . . . . . . . . . . . 8 59 5. UA Behavior with Credentials . . . . . . . . . . . . . . . . . 9 60 6. Event Package Formal Definition for "certificate" . . . . . . 10 61 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 10 62 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 10 63 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 10 64 6.4. Subscription Duration . . . . . . . . . . . . . . . . . . 10 65 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 10 66 6.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 11 67 6.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 11 68 6.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 11 69 6.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 12 70 6.10. Handling of Forked Requests . . . . . . . . . . . . . . . 12 71 6.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 12 72 6.12. State Agents and Lists . . . . . . . . . . . . . . . . . . 12 73 6.13. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 12 74 7. Event Package Formal Definition for "credential" . . . . . . . 13 75 7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 13 76 7.2. Event Package Parameters . . . . . . . . . . . . . . . . . 13 77 7.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 13 78 7.4. Subscription Duration . . . . . . . . . . . . . . . . . . 13 79 7.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 13 80 7.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 14 81 7.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 14 82 7.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 14 83 7.9. Generation of PUBLISH Requests . . . . . . . . . . . . . . 15 84 7.10. Notifier Processing of PUBLISH Requests . . . . . . . . . 15 85 7.11. Subscriber Processing of NOTIFY Requests . . . . . . . . . 16 86 7.12. Handling of Forked Requests . . . . . . . . . . . . . . . 16 87 7.13. Rate of Notifications . . . . . . . . . . . . . . . . . . 16 88 7.14. State Agents and Lists . . . . . . . . . . . . . . . . . . 16 89 7.15. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 17 90 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 8.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 17 92 8.2. Setting and Retrieving UA Credentials . . . . . . . . . . 18 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 94 9.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 21 95 9.2. Certificate Replacement . . . . . . . . . . . . . . . . . 21 96 9.3. Trusting the Identity of a Certificate . . . . . . . . . . 21 97 9.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 22 98 9.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 23 99 9.6. User Certificate Generation . . . . . . . . . . . . . . . 23 100 9.7. Compromised Authentication Service . . . . . . . . . . . . 23 101 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 102 10.1. Certificate Event Package . . . . . . . . . . . . . . . . 24 103 10.2. Credential Event Package . . . . . . . . . . . . . . . . . 24 104 10.3. PKCS#8 . . . . . . . . . . . . . . . . . . . . . . . . . . 25 105 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 107 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 108 12.2. Informational References . . . . . . . . . . . . . . . . . 28 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 110 Intellectual Property and Copyright Statements . . . . . . . . . . 30 112 1. Introduction 114 SIP [RFC3261] provides a mechanism [RFC3853] for end-to-end 115 encryption and integrity using S/MIME [RFC3851]. Several security 116 properties of SIP depend on S/MIME, and yet it has not been widely 117 deployed. One reason is the complexity of providing a reasonable 118 certificate distribution infrastructure. This specification proposes 119 a way to address discovery, retrieval, and management of certificates 120 for SIP deployments. Combined with the SIP Identity [RFC4474] 121 specification, this specification allows users to have certificates 122 that are not signed by any well known certificate authority while 123 still strongly binding the user's identity to the certificate. 125 In addition, this specification provides a mechanism that allows SIP 126 User Agents such as IP phones to enroll and get their credentials 127 without any more configuration information than they commonly have 128 today. The end user expends no extra effort. 130 2. Definitions 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 Certificate: A PKIX [RFC3280] style certificate containing a public 137 key and a list of identities in the SubjectAltName that are bound 138 to this key. The certificates discussed in this draft are 139 generally self signed and use the mechanisms in the SIP Identity 140 [RFC4474] specification to vouch for their validity. Certificates 141 that are signed by a certificate authority can also be used with 142 all the mechanisms in this draft, but it is expected that they are 143 used purely as a key carrier and that their validity is not 144 checked. 145 Credential: For this document, credential means the combination of a 146 certificate and the associated private key. 147 password phrase: A password used to encrypt a PKCS#8 private key. 149 3. Overview 151 The general approach is to provide a new SIP service referred to as a 152 "credential service" that allows SIP User Agents (UAs) to subscribe 153 to other users' certificates using a new SIP event package [RFC3265]. 154 The certificate is delivered to the subscribing UA in a corresponding 155 SIP NOTIFY request. The identity of the certificate can be vouched 156 for using the Authentication Service from the SIP Identity [RFC4474] 157 specification, which uses the domain's certificate to sign the NOTIFY 158 request. The credential service can manage public certificates as 159 well as the user's private keys. Users can update their credentials, 160 as stored on the credential service, using a SIP PUBLISH [RFC3903] 161 request. The UA authenticates to the credential service using a 162 shared secret when a UA is updating a credential. Typically the 163 shared secret will be the same one that is used by the UA to 164 authenticate a REGISTER request with the Registrar for the domain 165 (usually with SIP Digest Authentication). 167 The following figure shows Bob publishing his credentials from one of 168 his User Agents (e.g. his laptop software client), retrieving his 169 credentials from another of his User Agents (e.g. his mobile phone), 170 and then Alice retrieving Bob's certificate and sending a message to 171 Bob. SIP 200-class responses are omitted from the diagram to make the 172 figure easier to understand. 174 example.com domain 175 ------------------ 176 Alice Proxy Auth Cred Bob1 Bob2 177 | | | | TLS Handshake | | 178 | [ Bob generates ] |<--------------------->| 179 | [ credentials and ] | PUBLISH (credential) | 180 | [ publishes them ] |<----------------------| 181 | | | | Digest Challenge | 182 | | | |---------------------->| 183 | | | | PUBLISH + Digest | 184 | | | |<----------------------| 185 | | | | | 186 | | | | time passes... | 187 | | | | | 188 | | | | TLS Handshake | 189 | [ Bob later gets ] |<---------------->| 190 | [ back his own ] | SUBSCRIBE | 191 | [ credentials ] | (credential) | 192 | [ at another ] |<-----------------| 193 | [ User Agent ] | SUBSCRIBE+Digest | 194 | | | |<-----------------| 195 | | | | NOTIFY | 196 | | | |----------------->| 197 | | | | Bob Decrypts key | 198 | | | | | 199 | | | | | 200 | SUBSCRIBE (certificate) | Alice fetches | 201 |---------->|----->|----->| Bob's cert | 202 | | |NOTIFY| | 203 | NOTIFY+Identity |<-----| | 204 |<----------+------| | Alice uses cert | 205 | | | | to encrypt | 206 | MESSAGE | | | message to Bob | 207 |---------->|------+------+----------------->| 209 Bob's UA (Bob2) does a TLS [RFC4366] handshake with the credential 210 server to authenticate that the UA is connected to the correct 211 credential server. Then Bob's UA publishes his newly created or 212 updated credentials. The credential server digest challenges the UA 213 to authenticate that the UA knows Bob's shared secret. Once the UA 214 is authenticated, the credential server stores Bob's credentials. 216 Another of Bob's User Agents (Bob1) wants to fetch its current 217 credentials. It does a TLS [RFC4366] handshake with the credential 218 server to authenticate that the UA is connected to the correct 219 credential server. Then Bob's UA subscribes for the credentials. 220 The credential server digest challenges the UA to authenticate that 221 the UA knows Bob's shared secret. Once the UA is authenticated, the 222 credential server sends a NOTIFY that contains Bob's credentials. 223 The private key portion of the credential may have been encrypted 224 with a secret that only Bob's UA (and not the credential server) 225 knows. In this case, once Bob's UA decrypts the private key it will 226 be ready to go. Typically Bob's UA would do this when it first 227 registered on the network. 229 Some time later Alice decides that she wishes to discover Bob's 230 certificate so that she can send him an encrypted message or so that 231 she can verify the signature on a message from Bob. Alice's UA sends 232 a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes 233 this to the credential server via an "authentication service" as 234 defined in [RFC4474]. The credential server returns a NOTIFY that 235 contains Bob's public certificate in the body. This is routed 236 through an authentication service that signs that this message really 237 can validly claim to be from the AOR "sip:bob@example.com". Alice's 238 UA receives the certificate and can use it to encrypt a message to 239 Bob. 241 It is critical to understand that the only way that Alice can trust 242 that the certificate really is the one for Bob and that the NOTIFY 243 has not been spoofed is for Alice to check that the Identity 244 [RFC4474] header field value is correct. 246 The mechanism described in this document works for both self signed 247 certificates and certificates signed by well known certificate 248 authorities. However, most UAs would only use self signed 249 certificates and would use an Authentication Service as described in 250 [RFC4474] to provide a strong binding of an AOR to the certificates. 252 The mechanisms described in this draft allow for three different 253 styles of deployment: 255 1. Deployments where the credential server only stores certificates 256 and does not store any private key information. If the 257 deployment had users with multiple devices, some other scheme 258 (perhaps even manual provisioning) would be used to get the right 259 private keys onto all the devices that a user uses. 260 2. Deployments where the credential server stores certificates and 261 also stores an encrypted version of the private keys. The 262 credential server would not know or need the password phrase for 263 decrypting the private key. The credential server would help 264 move the private keys between devices but the user would need to 265 enter a password phrase on each device to allow that device to 266 decrypt (and encrypt) the private key information. 267 3. Deployments where the credential server stores the certificates 268 and private keys and also knows the password phrase for 269 decrypting the private keys. Deployments such as these may not 270 even use password phrases, in which case the private keys are not 271 encrypted inside the PKCS#8 objects. This style of deployment 272 would often have the credential server, instead of the devices, 273 create the credentials. 275 4. UA Behavior with Certificates 277 When a User Agent wishes to discover some other user's certificate it 278 subscribes to the "certificate" SIP event package as described in 279 Section 6 to get the certificate. While the subscription is active, 280 if the certificate is updated, the Subscriber will receive the 281 updated certificate in a notification. 283 The Subscriber needs to decide how long it is willing to trust that 284 the certificate it receives is still valid. If the certificate is 285 revoked before it expires, the Notifier will send a notification with 286 an empty body to indicate that the certificate is no longer valid. 287 However, the Subscriber might not receive the notification if an 288 attacker blocks this traffic. The amount of time that the Subscriber 289 caches a certificate SHOULD be configurable. A default of one day is 290 RECOMMENDED. 292 Note that the actual duration of the subscription is unrelated to the 293 caching time or validity time of the corresponding certificate. 294 Allowing subscriptions to persist after a certificate is no longer 295 valid ensures that Subscribers receive the replacement certificate in 296 a timely fashion. In some cases, the Notifier will not allow 297 unauthenticated subscriptions to persist. The Notifier could return 298 an immediate notification with the certificate in response to 299 subscribe and then immediately terminate subscription, setting the 300 reason parameter to "probation". The Subscriber will have to 301 periodically poll the Notifier to verify validity of the certificate. 303 If the UA uses a cached certificate in a request and receives a 437 304 (Unsupported Certificate) response, it SHOULD remove the certificate 305 it used from the cache, attempt to fetch the certificate again. If 306 the certificate is changed, then the UA SHOULD retry the original 307 request again with the new certificate. This situation usually 308 indicates that the certificate was recently updated, and that the 309 Subscriber has not received a corresponding notification. If the 310 certificate fetched is the same as the one that was previously in the 311 cache, then the UA SHOULD NOT try the request again. This situation 312 can happened when the request was retargeted to a different user than 313 the original request. The 437 response is defined in [RFC4474]. 315 Note: A UA that has a presence list MAY want to subscribe to the 316 certificates of all the presentities in the list when the UA 317 subscribes to their presence, so that when the user wishes to 318 contact a presentity, the UA will already have the appropriate 319 certificate. Future specifications might consider the possibility 320 of retrieving the certificates along with the presence documents. 322 The details of how a UA deals with receiving encrypted messages is 323 outside the scope of this specification. It is worth noting that if 324 Charlie's UAS receives a request that is encrypted to Bob, it would 325 be valid and legal for that UA to send a 302 redirecting the call to 326 Bob. 328 5. UA Behavior with Credentials 330 UAs discover their own credentials by subscribing to their AOR with 331 an event type of credential as described in Section 7. After a UA 332 registers, it SHOULD retrieve its credentials by subscribing to them 333 as described in Section 6.6. 335 When a UA discovers its credential, the private key information might 336 be encrypted with a password phrase. The UA SHOULD request that the 337 user enter the password phrase on the device, and the UA MAY cache 338 this password phrase for future use. 340 There are several different cases in which a UA should generate a new 341 credential: 342 o If the UA receives a NOTIFY with no body for the credential 343 package. 344 o If the certificate has expired. 345 o If the certificate's notAfter date is within the next 600 seconds, 346 the UA SHOULD attempt to create replacement credentials. The UA 347 does this by waiting a random amount of time between 0 and 300 348 seconds. If no new credentials have been received in that time, 349 the UA creates new credentials to replace the expiring ones and 350 sends them in a PUBLISH request (with a SIP-If-Match header field 351 set to the current etag). This makes credential collisions both 352 unlikely and harmless. 353 o If the user of the device has indicated via the user interface 354 that they wish to revoke the current certificate and issue a new 355 one. 356 Credentials are created by creating a new key pair which will require 357 appropriate randomness, and then creating a certificate as described 358 in Section 9.6. The UA MAY encrypt the private key with a password 359 phrase supplied by the user. Next, the UA updates the user's 360 credential by sending a PUBLISH [RFC3903] request with the 361 credentials or just the certificate as described in Section 7.9. 363 If a UA wishes to revoke the existing certificate without publishing 364 a new one, it MUST send a PUBLISH with an empty body to the 365 credential server. 367 6. Event Package Formal Definition for "certificate" 369 6.1. Event Package Name 371 This document defines a SIP Event Package as defined in [RFC3265]. 372 The event-package token name for this package is: 374 certificate 376 6.2. Event Package Parameters 378 This package defines the "etag" Event header parameter which is valid 379 only in NOTIFY requests. It contains a token which represents the 380 SIP etag value at the time the notification was sent. Considering 381 how infrequently credentials are updated, this hint is very likely to 382 be the correct etag to use in the SIP-If-Match header in a SIP 383 PUBLISH request to update the current credentials. 385 6.3. SUBSCRIBE Bodies 387 This package does not define any SUBSCRIBE bodies. 389 6.4. Subscription Duration 391 Subscriptions to this event package can range from no time to weeks. 392 Subscriptions in days are more typical and are RECOMMENDED. The 393 default subscription duration for this event package is one day. 395 The credential service is encouraged to keep the subscriptions active 396 for AORs that are communicating frequently, but the credential 397 service MAY terminate the subscription at any point in time. 399 6.5. NOTIFY Bodies 401 The body of a NOTIFY request for this package MUST either be empty or 402 contain an application/pkix-cert body (as defined in [RFC2585]) that 403 contains the certificate, unless an Accept header field has 404 negotiated some other type. The Content-Disposition MUST be set to 405 "signal" as defined in [RFC3204]. 407 A future extension MAY define other NOTIFY bodies. If no "Accept" 408 header field is present in the SUBSCRIBE, the body type defined in 409 this document MUST be assumed. 411 Implementations which generate large notifications are reminded to 412 follow the message size restrictions for unreliable transports 413 articulated in Section 18.1.1 of SIP. 415 6.6. Subscriber Generation of SUBSCRIBE Requests 417 A UA discovers a certificate by sending a SUBSCRIBE request with an 418 event type of "certificate" to the AOR for which a certificate is 419 desired. In general, the UA stays subscribed to the certificate for 420 as long as it plans to use and cache the certificate, so that the UA 421 can be notified about changes or revocations to the certificate. 423 Subscriber User Agents will typically subscribe to certificate 424 information for a period of hours or days, and automatically attempt 425 to re-subscribe just before the subscription is completely expired. 427 When a user de-registers from a device (logoff, power down of a 428 mobile device, etc.), subscribers SHOULD unsubscribe by sending a 429 SUBSCRIBE request with an Expires header field of zero. 431 6.7. Notifier Processing of SUBSCRIBE Requests 433 When a SIP credential server receives a SUBSCRIBE request with the 434 certificate event-type, it is not necessary to authenticate the 435 subscription request. The Notifier MAY limit the duration of the 436 subscription to an administrator-defined period of time. The 437 duration of the subscription does not correspond in any way to the 438 period for which the certificate will be valid. 440 When the credential server receives a SUBSCRIBE request for a 441 certificate, it first checks to see if it has credentials for the 442 requested URI. If it does not have a certificate, it returns a 443 NOTIFY request with an empty message body. 445 6.8. Notifier Generation of NOTIFY Requests 447 Immediately after a subscription is accepted, the Notifier MUST send 448 a NOTIFY with the current certificate, or an empty body if no 449 certificate is available for the target user. In either case it 450 forms a NOTIFY with the From header field value set to the value of 451 the To header field in the SUBSCRIBE request. This server sending 452 the NOTIFY needs either to implement an Authentication Service (as 453 described in SIP Identity [RFC4474]) or else the server needs to be 454 set up such that the NOTIFY request will be sent through an 455 Authentication Service. Sending the NOTIFY request through the 456 Authentication Service requires the SUBSCRIBE request to have been 457 routed through the Authentication Service, since the NOTIFY is sent 458 within the dialog formed by the subscription. 460 6.9. Subscriber Processing of NOTIFY Requests 462 The resulting NOTIFY will contain an application/pkix-cert body that 463 contains the requested certificate. The UA MUST follow the 464 procedures in Section 9.3 to decide if the received certificate can 465 be used. The UA needs to cache this certificate for future use. The 466 maximum length of time it should be cached for is discussed in 467 Section 9.1. The certificate MUST be removed from the cache if the 468 certificate has been revoked (if a NOTIFY with an empty body is 469 received), or if it is updated by a subsequent NOTIFY. The UA MUST 470 check that the NOTIFY is correctly signed by an Authentication 471 Service as described in [RFC4474]. If the identity asserted by the 472 Authentication Service does not match the AOR that the UA subscribed 473 to, the certificate in the NOTIFY is discarded and MUST NOT be used. 475 6.10. Handling of Forked Requests 477 This event package does not permit forked requests. At most one 478 subscription to this event type is permitted per resource. 480 6.11. Rate of Notifications 482 Notifiers SHOULD NOT generate NOTIFY requests more frequently than 483 once per minute. 485 6.12. State Agents and Lists 487 The certificate server described in this section which serves 488 certificates is a state agent and implementations of the 489 certificate server MUST be implemented as a state agent. 491 Implementers MUST NOT use the event list extension [RFC4662] with 492 this event type. It is not possible to make such an approach work, 493 because the Authentication service would have to simultaneously 494 assert several different identities. 496 6.13. Behavior of a Proxy Server 498 There are no additional requirements on a SIP Proxy, other than to 499 transparently forward the SUBSCRIBE and NOTIFY requests as required 500 in SIP. This specification describes the Proxy, Authentication 501 service, and credential service as three separate services, but it is 502 certainly possible to build a single SIP network element that 503 performs all of these services at the same time. 505 7. Event Package Formal Definition for "credential" 507 7.1. Event Package Name 509 This document defines a SIP Event Package as defined in [RFC3265]. 510 The event-package token name for this package is: 512 credential 514 7.2. Event Package Parameters 516 This package defines the "etag" Event header parameter which is valid 517 only in NOTIFY requests. It contains a token which represents the 518 SIP etag value at the time the notification was sent. Considering 519 how infrequently credentials are updated, this hint is very likely to 520 be the correct etag to use in the SIP-If-Match header field in a SIP 521 PUBLISH request to update the current credentials. 523 etag-param = "etag" EQUAL token 525 7.3. SUBSCRIBE Bodies 527 This package does not define any SUBSCRIBE bodies. 529 7.4. Subscription Duration 531 Subscriptions to this event package can range from hours to one week. 532 Subscriptions in days are more typical and are RECOMMENDED. The 533 default subscription duration for this event package is one day. 535 The credential service SHOULD keep subscriptions active for UAs that 536 are currently registered. 538 7.5. NOTIFY Bodies 540 The NOTIFY MUST contain a multipart/mixed (see [RFC2046]) body that 541 contains both an application/pkix-cert body with the certificate and 542 an application/pkcs8 body that has the associated private key 543 information for the certificate. The Content-Disposition MUST be set 544 to "signal" as defined in [RFC3204]. 546 A future extension MAY define other NOTIFY bodies. If no "Accept" 547 header field is present in the SUBSCRIBE, the body type defined in 548 this document MUST be assumed. 550 The application/pkix-cert body is a DER encoded X.509v3 certificate 551 [RFC2585]. The application/pkcs8 body contains a DER-encoded PKCS#8 552 [PKCS.8.1993] object that contains the private key. The PKCS#8 553 objects MUST be of type PrivateKeyInfo. The integrity and 554 confidentiality of the PKCS#8 objects is provided by the TLS 555 transport. The transport encoding of all the MIME bodies is binary. 557 7.6. Subscriber Generation of SUBSCRIBE Requests 559 A Subscriber User Agent will subscribe to its credential information 560 for a period of hours or days and will automatically attempt to re- 561 subscribe before the subscription has completely expired. 563 The Subscriber SHOULD subscribe to its credentials whenever a new 564 user becomes associated with the device (a new login). The 565 subscriber SHOULD also renew its subscription immediately after a 566 reboot, or when the subscriber's network connectivity has just been 567 re-established. 569 The UA needs to authenticate with the credential service for these 570 operations. The UA MUST use TLS to connect to the server. The UA 571 may be configured with a specific name for the credential service; 572 otherwise normal SIP routing is used. As described in RFC 3261, the 573 TLS connection needs to present a certificate that matches the 574 expected name of the server to which the connection was formed, so 575 that the UA knows it is talking to the correct server. Failing to do 576 this may result in the UA publishing its private key information to 577 an attacker. The credential service will authenticate the UA using 578 the usual SIP Digest mechanism, so the UA can expect to receive a SIP 579 challenge to the SUBSCRIBE or PUBLISH requests. 581 7.7. Notifier Processing of SUBSCRIBE Requests 583 When a credential service receives a SUBSCRIBE for a credential, the 584 credential service has to authenticate and authorize the UA and 585 validate that adequate transport security is being used. Only a UA 586 that can authenticate as being able to register as the AOR is 587 authorized to receive the credentials for that AOR. The credential 588 Service MUST digest challenge the UA to authenticate the UA and then 589 decide if it is authorized to receive the credentials. If 590 authentication is successful, the Notifier MAY limit the duration of 591 the subscription to an administrator-defined period of time. The 592 duration of the subscription MUST NOT be larger than the length of 593 time for which the certificate is still valid. The Expires header 594 field SHOULD be set so that it is not longer than the notAfter date 595 in the certificate. 597 7.8. Notifier Generation of NOTIFY Requests 599 Once the UA has authenticated with the credential service and the 600 subscription is accepted, the credential service MUST immediately 601 send a Notify request. The Notifier SHOULD include the current etag 602 value in the "etag" Event package parameter in the NOTIFY request. 603 The Authentication Service is applied to this NOTIFY request in the 604 same way as the certificate subscriptions. If the credential is 605 revoked, the credential service MUST terminate any current 606 subscriptions and force the UA to re-authenticate by sending a NOTIFY 607 with its Subscription-State header field set to "terminated" and a 608 reason parameter of "deactivated". (This causes a Subscriber to 609 retry the subscription immediately.) This is so that if a secret for 610 retrieving the credentials gets compromised, the rogue UA will not 611 continue to receive credentials after the compromised secret has been 612 changed. 614 Any time the credentials for this URI change, the credential service 615 MUST send a new NOTIFY to any active subscriptions with the new 616 credentials. 618 7.9. Generation of PUBLISH Requests 620 A user agent SHOULD be configurable to control whether it publishes 621 the credential for a user or just the user's certificate. 623 When publishing just a certificate, the body contains an application/ 624 pkix-cert. When publishing a credential, the body contains a 625 multipart/mixed containing both an application/pkix-cert and an 626 application/pkcs8 body. 628 When the UA sends the PUBLISH [RFC3903] request, it needs to do the 629 following: 630 o The Expires header field value in the PUBLISH request SHOULD be 631 set to match the time for which the certificate is valid. 632 o If the certificate includes Basic Constraints, it SHOULD set the 633 CA flag to false. 634 o The PUBLISH request SHOULD include a SIP-If-Match header field 635 with the previous etag from the subscription. This prevents 636 multiple User Agents for the same AOR from publishing conflicting 637 credentials. Note that UAs replace credentials that are about to 638 expire at a random time (described in Section 5), reducing the 639 chance of publishing conflicting credentials even without using 640 the etag. 642 7.10. Notifier Processing of PUBLISH Requests 644 When the credential service receives a PUBLISH to update credentials, 645 it MUST authenticate and authorize this request the same way as for 646 subscriptions for credentials. If the authorization succeeds, then 647 the credential service MUST perform the following check on the 648 certificate: 650 o One of the names in the SubjectAltName of the certificate matches 651 the authorized user making the request. 652 o The notBefore validity time MUST NOT be in the future. 653 o The notAfter validity time MUST be in the future. 654 o If a CA Basic Constraint is set in the certificate, it is set to 655 false. 656 If all of these succeed, the credential service updates the 657 credential for this URI, processes all the active certificates and 658 credential subscriptions to this URI, and generates a NOTIFY request 659 with the new credential or certificate. 661 If the Subscriber submits a PUBLISH request with no body, this 662 revokes the current credentials and causes all subscriptions to the 663 credential package to be deactivated as described in the previous 664 section. (Note that subscriptions to the certificate package are NOT 665 terminated; each subscriber to the certificate package receives a 666 notification with an empty body.) 668 7.11. Subscriber Processing of NOTIFY Requests 670 When the UA receives a valid NOTIFY request, it should replace its 671 existing credentials with the new received ones. If the UA cannot 672 decrypt the PKCS#8 object, it MUST send a 437 (Unsupported 673 Certificate) response. Later if the user provides a new password 674 phrase for the private key, the UA can subscribe to the credentials 675 again and attempt to decrypt with the new password phrase. 677 7.12. Handling of Forked Requests 679 This event package does not permit forked requests. 681 7.13. Rate of Notifications 683 Notifiers SHOULD NOT generate NOTIFY requests more frequently than 684 once per minute. 686 7.14. State Agents and Lists 688 The credential server described in this section which serves 689 credentials is a state agent and implementations of the credential 690 server MUST be implemented as a state agent. 692 Implementers MUST NOT use the event list extension [RFC4662] with 693 this event type. 695 7.15. Behavior of a Proxy Server 697 The behavior is identical to behavior described for certificate 698 subscriptions described in Section 6.13. 700 8. Examples 702 In all these examples, large parts of the messages are omitted to 703 highlight what is relevant to this draft. The lines in the examples 704 that are prefixed by $ represent encrypted blocks of data. 706 8.1. Encrypted Page Mode IM Message 708 In this example, Alice sends Bob an encrypted page mode instant 709 message. Alice does not already have Bob's public key from previous 710 communications, so she fetches Bob's public key from Bob's credential 711 service: 713 SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0 714 ... 715 Event: certificate 717 The credential service responds with the certificate in a NOTIFY. 719 NOTIFY alice@atlanta.example.com SIP/2.0 720 Subscription-State: active; expires=7200 721 .... 722 From: ;tag=1234 723 Identity: "NJguAbpmYXjnlxFmlOkumMI+MZXjB2iV/NW5xsFQqzD/p4yiovrJBqhd3T 724 ZkegnsmoHryzk9gTBH7Gj/erixEFIf82o3Anmb+CIbrgdl03gGaD6ICvkp 725 VqoMXZZjdvSpycyHOhh1cmUx3b9Vr3pZuEh+cB01pbMQ8B1ch++iMjw=" 726 Identity-Info: ;alg=rsa-sha1 727 .... 728 Event: certificate 729 Content-Type: application/pkix-cert 730 Content-Disposition: signal 732 < certificate data > 734 Next, Alice sends a SIP MESSAGE message to Bob and can encrypt the 735 body using Bob's public key as shown below. 737 MESSAGE sip:bob@biloxi.example.com SIP/2.0 738 ... 739 Content-Type: application/pkcs7-mime 740 Content-Disposition: render 742 $ Content-Type: text/plain 743 $ 744 $ < encrypted version of "Hello" > 746 8.2. Setting and Retrieving UA Credentials 748 When Alice's UA wishes to publish Alice's public and private keys to 749 the credential service, it sends a PUBLISH request like the one 750 below. This must be sent over a TLS connection directly to the 751 domain of the credential service. The credential service presents a 752 certificate where the subjectAltName contains an entry that matches 753 the domain name in the request line of the PUBLISH request and digest 754 challenges the request to authenticate her. 756 PUBLISH sips:alice@atlanta.example.com SIP/2.0 757 ... 758 Event: credential 759 Content-Type: multipart/mixed;boundary=boundary 760 Content-Disposition: signal 762 --boundary 763 Content-ID: 123 764 Content-Type: application/pkix-cert 766 < Public certificate for Alice > 767 --boundary 768 Content-ID: 456 769 Content-Type: application/pkcs8 771 < Private Key for Alice > 772 --boundary 774 If one of Alice's UAs subscribes to the credential event, the UA will 775 be digest challenged, and the NOTIFY will include a body similar to 776 the one in the PUBLISH section above. 778 9. Security Considerations 780 The high level message flow from a security point of view is 781 summarized in the following figure. The 200 responses are removed 782 from the figure as they do not have much to do with the overall 783 security. 785 In this figure, authC refers to authentication and authZ refers to 786 authorization. 788 Alice Server Bob UA 789 | | TLS Handshake | 1) Client authC/Z server 790 | |<---------------->| 791 | | PUBLISH | 2) Client sends request 792 | |<-----------------| (write credential) 793 | | Digest Challenge | 3) Server challenges client 794 | |----------------->| 795 | | PUBLISH + Digest | 4) Server authC/Z client 796 | |<-----------------| 797 | | time... | 798 | | | 799 | | TLS Handshake | 5) Client authC/Z server 800 | |<---------------->| 801 | | SUBSCRIBE | 6) Client sends request 802 | |<-----------------| (read credential) 803 | | Digest Challenge | 7) Server challenges client 804 | |----------------->| 805 | | SUBSCRIBE+Digest | 8) Server authC/Z client 806 | |<-----------------| 807 | | NOTIFY | 9) Server returns credential 808 | |----------------->| 809 | | 810 | SUBSCRIBE | 10) Client requests certificate 811 |---------->| 812 | | 813 |NOTIFY+AUTH| 11) Server returns user's certificate and signs that 814 |<----------| it is valid using certificate for the domain 815 | | 817 When the UA, labeled Bob, first created a credential for Bob, it 818 would store this on the credential server. The UA authenticated the 819 Server using the certificates from the TLS handshake. The Server 820 authenticated the UA using a digest style challenge with a shared 821 secret. 823 The UA, labeled Bob, wishes to request its credentials from the 824 server. First it forms a TLS connection to the Server, which 825 provides integrity and privacy protection and also authenticates the 826 server to Bob's UA. Next the UA requests its credentials using a 827 SUBSCRIBE request. The Server digest challenges this to authenticate 828 Bob's UA. The server and Bob's UA have a shared secret that is used 829 for this. If the authentication is successful, the server sends the 830 credentials to Bob's UA. The private key in the credentials may have 831 been encrypted using a shared secret that the server does not know. 833 A similar process would be used for Bob's UA to publish new 834 credentials to the server. Bob's UA would send a PUBLISH request 835 containing the new credentials. When this happened, all the other 836 UAs that were subscribed to Bob's credentials would receive a NOTIFY 837 with the new credentials. 839 Alice wishes to find Bob's certificate and sends a SUBSCRIBE to the 840 server. The server sends the response in a NOTIFY. This does not 841 need to be sent over a privacy or integrity protected channel, as the 842 Authentication service described in [RFC4474] provides integrity 843 protection of this information and signs it with the certificate for 844 the domain. 846 This whole scheme is highly dependent on trusting the operators of 847 the credential service and trusting that the credential service will 848 not be compromised. The security of all the users will be 849 compromised if the credential service is compromised. 851 Note: There has been significant discussion of the topic of 852 avoiding deployments in which the credential servers store the 853 private keys, even in some encrypted form that the credential 854 server does not know how to decrypt. Various schemes were 855 considered to avoid this but they all result in either moving the 856 problem to some other server, which does not seem to make the 857 problem any better, or having a different credential for each 858 device. For some deployments where each user has only one device 859 this is fine but for deployments with multiple devices, it would 860 require that when Alice went to contact Bob, Alice would have to 861 provide messages encrypted for all of Bob's devices. The sipping 862 working group did consider this architecture and decided it was 863 not appropriate due both to the information it revealed about the 864 devices and users and the amount of signaling required to make it 865 work. 867 This specification requires that TLS be used for the SIP 868 communications to place and retrieve a UA's private key. This 869 provides security in two ways: 870 1. Confidentiality is provided for the digest authentication 871 exchange, thus protecting it from dictionary attacks. 872 2. Confidentiality is provided for the private key, thus protecting 873 it from being exposed to passive attackers. 874 In order to prevent man-in-the-middle attacks, TLS clients MUST check 875 that the SubjectAltName of the certificate for the server they 876 connected to exactly matches the server they were trying to connect 877 to. Failing to use TLS or selecting a poor cipher suite (such as 878 NULL encryption) may result in credentials, including private keys, 879 being sent unencrypted over the network and will render the whole 880 system useless. 882 The correct checking of chained certificates as specified in TLS 883 [RFC4366] is critical for the client to authenticate the server. If 884 the client does not authenticate that it is talking to the correct 885 credential service, a man in the middle attack is possible. 887 9.1. Certificate Revocation 889 If a particular credential needs to be revoked, the new credential is 890 simply published to the credential service. Every device with a copy 891 of the old credential or certificate in its cache will have a 892 subscription and will rapidly (order of seconds) be notified and 893 replace its cache. Clients that are not subscribed will subscribe 894 when they next need to use the certificate and will get the new 895 certificate. 897 It is possible that an attacker could mount a DOS attack such that 898 the UA that had cached a certificate did not receive the NOTIFY with 899 its revocation. To protect against this attack, the UA needs to 900 limit how long it caches certificates. After this time, the UA would 901 invalidate the cached information even though no NOTIFY had ever been 902 received due to the attacker blocking it. 904 The duration of this cached information is in some ways similar to a 905 device deciding how often to check a CRL list. For many 906 applications, a default time of 1 day is suggested, but for some 907 applications it may be desirable to set the time to zero so that no 908 certificates are cached at all and the credential is checked for 909 validity every time the certificate is used. 911 9.2. Certificate Replacement 913 The UAs in the system replace the certificates close to the time that 914 the certificates would expire. If a UA has used the same key pair to 915 encrypt a very large volume of traffic, the UA MAY choose to replace 916 the credential with a new one before the normal expiration. 918 9.3. Trusting the Identity of a Certificate 920 When a UA wishes to discover the certificate for 921 sip:alice@example.com, the UA subscribes to the certificate for 922 alice@example.com and receives a certificate in the body of a SIP 923 NOTIFY request. The term original URI is used to describe the URI 924 that was in the To header field value of the SUBSCRIBE request. So 925 in this case the original URI would be sip:alice@example.com. 927 If the certificate is signed by a trusted CA, and one of the names in 928 the SubjectAltName matches the original URI, then this certificate 929 MAY be used but only for exactly the original URI and not for other 930 identities found in the SubjectAltName. Otherwise, there are several 931 steps the UA MUST perform before using this certificate. 932 o The From header field in the NOTIFY request MUST match the 933 original URI that was subscribed to. 934 o The UA MUST check the Identity header field as described in the 935 Identity [RFC4474] specification to validate that bodies have not 936 been tampered with and that an Authentication Service has 937 validated this From header field. 938 o The UA MUST check the validity time of the certificate and stop 939 using the certificate if it is invalid. (Implementations are 940 reminded to verify both the notBefore and notAfter validity 941 times.) 942 o The certificate MAY have several names in the SubjectAltName but 943 the UA MUST only use this certificate when it needs the 944 certificate for the identity asserted by the Authentication 945 Service in the NOTIFY. This means that the certificate should 946 only be indexed in the certificate cache by the AOR that the 947 Authentication Service asserted and not by the value of all the 948 identities found in the SubjectAltName list. 949 These steps result in a chain of bindings that result in a trusted 950 binding between the original AOR that was subscribed to and a public 951 key. The original AOR is forced to match the From. The 952 Authentication Service validates that this request did come from the 953 identity claimed in the From header field value and that the bodies 954 in the request that carry the certificate have not been tampered 955 with. The certificate in the body contains the public key for the 956 identity. Only the UA that can authenticate as this AOR, or devices 957 with access to the private key of the domain, can tamper with this 958 body. This stops other users from being able to provide a false 959 public key. This chain of assertion from original URI, to From, to 960 body, to public key is critical to the security of the mechanism 961 described in this specification. If any of the steps above are not 962 followed, this chain of security will be broken and the system will 963 not work. 965 9.4. SACRED Framework 967 This specification includes a mechanism that allows end users to 968 share the same credentials across different end-user devices. This 969 mechanism is based on the one presented in the SACRED Framework 970 [RFC3760]. While this mechanism is fully described in this document, 971 the requirements and background are more thoroughly discussed in 972 [RFC3760]. 974 Specifically, Section 7.6, Section 7.7 and Section 7.10 follow the 975 cTLS architecture described in section 4.2.2 of [RFC3760]. The 976 client authenticates the server using the server's TLS certificate. 977 The server authenticates the client using a SIP digest transaction 978 inside the TLS session. The TLS sessions form a strong session key 979 that is used to protect the credentials being exchanged. 981 9.5. Crypto Profiles 983 Credential services SHOULD implement the server name indication 984 extensions in [RFC4366] and they MUST support a TLS profile of 985 TLS_RSA_WITH_AES_128_CBC_SHA as described in [RFC3268] as a profile 986 of TLS_RSA_WITH_3DES_EDE_CBC_SHA. 988 The PKCS#8 in the clients MUST implement PBES2 with a key derivation 989 algorithm of PBKDF2 using HMAC with SHA1 and an encryption algorithm 990 of DES-EDE2-CBC-Pad as defined in [RFC2898]. It is RECOMMENDED that 991 this profile be used when using PKCS#8. A different passphrase 992 SHOULD be used for the PKCS#8 encryption than is used for server 993 authentication. 995 9.6. User Certificate Generation 997 The certificates should be consistent with [RFC3280]. A 998 signatureAlgorithm of sha1WithRSAEncryption MUST be implemented. The 999 Issuers SHOULD be the same as the subject. Given the ease of issuing 1000 new certificates with this system, the Validity can be relatively 1001 short. A Validity of one year or less is RECOMMENDED. The 1002 subjectAltName must have a URI type that is set to the SIP URL 1003 corresponding to the user AOR. It MAY be desirable to put some 1004 randomness into the length of time for which the certificates are 1005 valid so that it does not become necessary to renew all the 1006 certificates in the system at the same time. 1008 It is worth noting that a UA can discover the current time by looking 1009 at the Date header field value in the 200 response to a REGISTER 1010 request. 1012 9.7. Compromised Authentication Service 1014 One of this worst attacks against this system would be if the 1015 Authentication Service were compromised. This attack is somewhat 1016 analogous to a CA being compromised in traditional PKI systems. The 1017 attacker could make a fake certificate for which it knows the private 1018 key, use it to receive any traffic for a given use, and then re- 1019 encrypt that traffic with the correct key and forward the 1020 communication to the intended receiver. The attacker would thus 1021 become a man in the middle in the communications. 1023 There is not too much that can be done to protect against this. A UA 1024 MAY subscribe to its own certificate under some other identity to try 1025 to detect whether the credential server is handing out the correct 1026 certificates. It will be difficult to do this in a way that does not 1027 allow the credential server to recognize the user's UA. 1029 The UA MAY also save the fingerprints of the cached certificates and 1030 warn users when the certificates change significantly before their 1031 expiry date. 1033 The UA MAY also allow the user to see the fingerprints for the cached 1034 certificates so that they can be verified by some other out of band 1035 means. 1037 10. IANA Considerations 1039 This specification defines two new event packages that IANA is 1040 requested to add the registry at: 1041 http://www.iana.org/assignments/sip-events 1042 It also defines a new mime type that IANA is requested to add to the 1043 registry at: 1044 http://www.iana.org/assignments/media-types/application 1046 10.1. Certificate Event Package 1048 To: ietf-sip-events@iana.org 1049 Subject: Registration of new SIP event package 1051 Package Name: certificate 1053 Is this registration for a Template Package: No 1055 Published Specification(s): This document 1057 New Event header parameters: This package defines no 1058 new parameters 1060 Person & email address to contact for further information: 1061 Cullen Jennings 1063 10.2. Credential Event Package 1064 To: ietf-sip-events@iana.org 1065 Subject: Registration of new SIP event package 1067 Package Name: credential 1069 Is this registration for a Template Package: No 1071 Published Specification(s): This document 1073 New Event header parameters: "etag" 1075 Person & email address to contact for further information: 1076 Cullen Jennings 1078 10.3. PKCS#8 1079 To: ietf-types@iana.org 1080 Subject: Registration of MIME media type application/pkcs8 1082 MIME media type name: application 1084 MIME subtype name: pkcs8 1086 Required parameters: None 1088 Optional parameters: None 1090 Encoding considerations: binary 1092 Security considerations: Carries a cryptographic private key 1094 Interoperability considerations: 1095 The PKCS#8 object inside this MIME type MUST be DER-encoded 1097 Published specification: 1098 RSA Laboratories, "Private-Key Information Syntax Standard, 1099 Version 1.2", PKCS 8, November 1993. 1101 Applications which use this media type: Any MIME-compliant transport 1103 Additional information: 1104 Magic number(s): None 1105 File extension(s): .p8 1106 Macintosh File Type Code(s): none 1108 Person & email address to contact for further information: 1109 Cullen Jennings 1111 Intended usage: COMMON 1113 Author/Change controller: 1114 the IESG 1116 11. Acknowledgments 1118 Many thanks to Eric Rescorla, Jim Schaad, Rohan Mahy for significant 1119 help and discussion. Many others provided useful comments, including 1120 Kumiko Ono, Peter Gutmann, Russ Housley, Yaron Pdut, Aki Niemi, 1121 Magnus Nystrom, Paul Hoffman, Adina Simu, Dan Wing, Mike Hammer and 1122 Lyndsay Campbell. Rohan Mahy, John Elwell, and Jonathan Rosenberg 1123 provided detailed review and text. 1125 12. References 1127 12.1. Normative References 1129 [PKCS.8.1993] 1130 RSA Laboratories, "Private-Key Information Syntax 1131 Standard, Version 1.2", PKCS 8, November 1993. 1133 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1134 Extensions (MIME) Part Two: Media Types", RFC 2046, 1135 November 1996. 1137 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1138 Requirement Levels", BCP 14, RFC 2119, March 1997. 1140 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1141 Infrastructure Operational Protocols: FTP and HTTP", 1142 RFC 2585, May 1999. 1144 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 1145 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 1146 and QSIG Objects", RFC 3204, December 2001. 1148 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1149 A., Peterson, J., Sparks, R., Handley, M., and E. 1150 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1151 June 2002. 1153 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1154 Event Notification", RFC 3265, June 2002. 1156 [RFC3268] Chown, P., "Advanced Encryption Standard (AES) 1157 Ciphersuites for Transport Layer Security (TLS)", 1158 RFC 3268, June 2002. 1160 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 1161 X.509 Public Key Infrastructure Certificate and 1162 Certificate Revocation List (CRL) Profile", RFC 3280, 1163 April 2002. 1165 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1166 for Event State Publication", RFC 3903, October 2004. 1168 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1169 and T. Wright, "Transport Layer Security (TLS) 1170 Extensions", RFC 4366, April 2006. 1172 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1173 Authenticated Identity Management in the Session 1174 Initiation Protocol (SIP)", RFC 4474, August 2006. 1176 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 1177 Specification Version 2.0", RFC 2898, September 2000. 1179 This reference is normative. The mechanisms used in this 1180 specification from RFC2898 are stable and sutable for use 1181 in a standards track specification. RFC2898 has been used 1182 as a normative reference in several prior standards track 1183 documents including RFC3185, RFC3370, RFC3962, and 1184 RFC4656. 1186 12.2. Informational References 1188 [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely 1189 Available Credentials (SACRED) - Credential Server 1190 Framework", RFC 3760, April 2004. 1192 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1193 Extensions (S/MIME) Version 3.1 Message Specification", 1194 RFC 3851, July 2004. 1196 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1197 Requirement for the Session Initiation Protocol (SIP)", 1198 RFC 3853, July 2004. 1200 [RFC4662] Roach, A., Rosenberg, J., and B. Campbell, "A Session 1201 Initiation Protocol (SIP) Event Notification Extension for 1202 Resource Lists", RFC 4662, August 2006. 1204 Authors' Addresses 1206 Cullen Jennings 1207 Cisco Systems 1208 170 West Tasman Drive 1209 MS: SJC-21/2 1210 San Jose, CA 95134 1211 USA 1213 Phone: +1 408 421-9990 1214 Email: fluffy@cisco.com 1215 Jon Peterson 1216 NeuStar, Inc. 1217 1800 Sutter St 1218 Suite 570 1219 Concord, CA 94520 1220 US 1222 Phone: +1 925/363-8720 1223 Email: jon.peterson@neustar.biz 1224 URI: http://www.neustar.biz/ 1226 Jason Fischl (editor) 1227 CounterPath Solutions, Inc. 1228 Suite 300 1229 One Bentall Centre 1230 505 Burrard Street 1231 Vancouver, BC V7X 1M3 1232 Canada 1234 Phone: +1 604 320-3344 1235 Email: jason@counterpath.com 1236 URI: http://www.counterpath.com 1238 Full Copyright Statement 1240 Copyright (C) The IETF Trust (2008). 1242 This document is subject to the rights, licenses and restrictions 1243 contained in BCP 78, and except as set forth therein, the authors 1244 retain all their rights. 1246 This document and the information contained herein are provided on an 1247 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1248 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1249 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1250 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1251 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1252 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1254 Intellectual Property 1256 The IETF takes no position regarding the validity or scope of any 1257 Intellectual Property Rights or other rights that might be claimed to 1258 pertain to the implementation or use of the technology described in 1259 this document or the extent to which any license under such rights 1260 might or might not be available; nor does it represent that it has 1261 made any independent effort to identify any such rights. Information 1262 on the procedures with respect to rights in RFC documents can be 1263 found in BCP 78 and BCP 79. 1265 Copies of IPR disclosures made to the IETF Secretariat and any 1266 assurances of licenses to be made available, or the result of an 1267 attempt made to obtain a general license or permission for the use of 1268 such proprietary rights by implementers or users of this 1269 specification can be obtained from the IETF on-line IPR repository at 1270 http://www.ietf.org/ipr. 1272 The IETF invites any interested party to bring to its attention any 1273 copyrights, patents or patent applications, or other proprietary 1274 rights that may cover technology that may be required to implement 1275 this standard. Please address the information to the IETF at 1276 ietf-ipr@ietf.org. 1278 Acknowledgment 1280 Funding for the RFC Editor function is provided by the IETF 1281 Administrative Support Activity (IASA).