idnits 2.17.1 draft-ietf-sip-certs-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 21, 2010) is 4956 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) == Missing Reference: 'RFCAAAA' is mentioned on line 1185, but not defined ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** Downref: Normative reference to an Informational RFC: RFC 5649 -- Obsolete informational reference (is this intentional?): RFC 2898 (Obsoleted by RFC 8018) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 4 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. Fischl, Ed. 5 Expires: March 25, 2011 Skype 6 September 21, 2010 8 Certificate Management Service for The Session Initiation Protocol (SIP) 9 draft-ietf-sip-certs-15 11 Abstract 13 This draft defines a Credential Service that allows Session 14 Initiation Protocol (SIP) User Agents (UAs) to use a SIP event 15 package to discover the certificates of other users. This mechanism 16 allows user agents that want to contact a given Address-of-Record 17 (AOR) to retrieve that AOR's certificate by subscribing to the 18 Credential Service, which returns an authenticated response 19 containing that certificate. The Credential Service also allows 20 users to store and retrieve their own certificates and private keys. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 25, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. UA Behavior with Certificates . . . . . . . . . . . . . . . . 9 72 5. UA Behavior with Credentials . . . . . . . . . . . . . . . . . 10 73 6. Event Package Formal Definition for "certificate" . . . . . . 11 74 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 11 75 6.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 11 76 6.3. Subscription Duration . . . . . . . . . . . . . . . . . . 11 77 6.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 11 78 6.5. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 12 79 6.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 12 80 6.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 12 81 6.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 13 82 6.9. Handling of Forked Requests . . . . . . . . . . . . . . . 13 83 6.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 13 84 6.11. State Agents and Lists . . . . . . . . . . . . . . . . . . 13 85 6.12. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 13 86 7. Event Package Formal Definition for "credential" . . . . . . . 14 87 7.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 14 88 7.2. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 14 89 7.3. Subscription Duration . . . . . . . . . . . . . . . . . . 14 90 7.4. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 14 91 7.5. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 15 92 7.6. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 15 93 7.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 15 94 7.8. Generation of PUBLISH Requests . . . . . . . . . . . . . . 16 95 7.9. Notifier Processing of PUBLISH Requests . . . . . . . . . 16 96 7.10. Subscriber Processing of NOTIFY Requests . . . . . . . . . 17 97 7.11. Handling of Forked Requests . . . . . . . . . . . . . . . 17 98 7.12. Rate of Notifications . . . . . . . . . . . . . . . . . . 17 99 7.13. State Agents and Lists . . . . . . . . . . . . . . . . . . 17 100 7.14. Behavior of a Proxy Server . . . . . . . . . . . . . . . . 18 101 8. Identity Signatures . . . . . . . . . . . . . . . . . . . . . 18 102 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 103 9.1. Encrypted Page Mode IM Message . . . . . . . . . . . . . . 18 104 9.2. Setting and Retrieving UA Credentials . . . . . . . . . . 19 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 106 10.1. Certificate Revocation . . . . . . . . . . . . . . . . . . 23 107 10.2. Certificate Replacement . . . . . . . . . . . . . . . . . 23 108 10.3. Trusting the Identity of a Certificate . . . . . . . . . . 23 109 10.3.1. Extra Assurance . . . . . . . . . . . . . . . . . . . 24 110 10.4. SACRED Framework . . . . . . . . . . . . . . . . . . . . . 25 111 10.5. Crypto Profiles . . . . . . . . . . . . . . . . . . . . . 25 112 10.6. User Certificate Generation . . . . . . . . . . . . . . . 26 113 10.7. Private Key Storage . . . . . . . . . . . . . . . . . . . 26 114 10.8. Compromised Authentication Service . . . . . . . . . . . . 27 115 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 116 11.1. Certificate Event Package . . . . . . . . . . . . . . . . 28 117 11.2. Credential Event Package . . . . . . . . . . . . . . . . . 28 118 11.3. Identity Algorithm . . . . . . . . . . . . . . . . . . . . 28 119 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 120 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 121 13.1. Normative References . . . . . . . . . . . . . . . . . . . 29 122 13.2. Informational References . . . . . . . . . . . . . . . . . 30 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 125 1. Introduction 127 [RFC3261], as amended by [RFC3853], provides a mechanism for end-to- 128 end encryption and integrity using S/MIME [RFC3851]. Several 129 security properties of [RFC3261] depend on S/MIME, and yet it has not 130 been widely deployed. One reason is the complexity of providing a 131 reasonable certificate distribution infrastructure. This 132 specification proposes a way to address discovery, retrieval, and 133 management of certificates for SIP deployments. Combined with the 134 SIP Identity [RFC4474] specification, this specification allows users 135 to have certificates that are not signed by any well known 136 certification authority while still strongly binding the user's 137 identity to the certificate. 139 In addition, this specification provides a mechanism that allows SIP 140 User Agents such as IP phones to enroll and get their credentials 141 without any more configuration information than they commonly have 142 today. The end user expends no extra effort. 144 2. Definitions 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 Certificate: A PKIX [RFC5280] style certificate containing a public 151 key and a list of identities in the SubjectAltName that are bound 152 to this key. The certificates discussed in this draft are 153 generally self-signed and use the mechanisms in the SIP Identity 154 [RFC4474] specification to vouch for their validity. Certificates 155 that are signed by a certification authority can also be used with 156 all the mechanisms in this draft, however, they need not be 157 validated by the receiver (although the receiver can validate them 158 for extra assurance; see Section 10.3.1). 159 Credential: For this document, credential means the combination of a 160 certificate and the associated private key. 161 Password Phrase: A password used to encrypt and decrypt a PKCS#8 162 private key. 164 3. Overview 166 The general approach is to provide a new SIP service referred to as a 167 "credential service" that allows SIP User Agents (UAs) to subscribe 168 to other users' certificates using a new SIP event package [RFC3265]. 169 The certificate is delivered to the subscribing UA in a corresponding 170 SIP NOTIFY request. An Authentication Service as described in the 171 SIP Identity [RFC4474] specification can be used to vouch for the 172 identity of the sender of the certificate by using the sender's proxy 173 domain certificate to sign the NOTIFY request. The Authentication 174 Service is vouching that the sender is allowed to populate the SIP 175 From header field value. The sender of the message is vouching that 176 this is an appropriate certificate for the user identified in the SIP 177 from header field value. The credential service can manage public 178 certificates as well as the user's private keys. Users can update 179 their credentials, as stored on the credential service, using a SIP 180 PUBLISH [RFC3903] request. The UA authenticates to the credential 181 service using a shared secret when a UA is updating a credential. 182 Typically the shared secret will be the same one that is used by the 183 UA to authenticate a REGISTER request with the Registrar for the 184 domain (usually with SIP Digest Authentication). 186 The following figure shows Bob publishing his credentials from one of 187 his User Agents (e.g. his laptop software client), retrieving his 188 credentials from another of his User Agents (e.g. his mobile phone), 189 and then Alice retrieving Bob's certificate and sending a message to 190 Bob. SIP 200-class responses are omitted from the diagram to make the 191 figure easier to understand. 193 example.com domain 194 ------------------ 195 Alice Proxy Auth Cred Bob1 Bob2 196 | | | | TLS Handshake | | 197 | [ Bob generates ] |<--------------------->| 198 | [ credentials and ] | PUBLISH (credential) | 199 | [ publishes them ] |<----------------------| 200 | | | | Digest Challenge | 201 | | | |---------------------->| 202 | | | | PUBLISH + Digest | 203 | | | |<----------------------| 204 | | | | | 205 | | | | time passes... | 206 | | | | | 207 | | | | TLS Handshake | 208 | [ Bob later gets ] |<---------------->| 209 | [ back his own ] | SUBSCRIBE | 210 | [ credentials ] | (credential) | 211 | [ at another ] |<-----------------| 212 | [ User Agent ] | SUBSCRIBE+Digest | 213 | | | |<-----------------| 214 | | | | NOTIFY | 215 | | | |----------------->| 216 | | | | Bob Decrypts key | 217 | | | | | 218 | | | | | 219 | SUBSCRIBE (certificate) | Alice fetches | 220 |---------->|----->|----->| Bob's cert | 221 | | |NOTIFY| | 222 | NOTIFY+Identity |<-----| | 223 |<----------+------| | Alice uses cert | 224 | | | | to encrypt | 225 | MESSAGE | | | message to Bob | 226 |---------->|------+------+----------------->| 228 Bob's UA (Bob2) does a TLS [RFC5246] handshake with the credential 229 server to authenticate that the UA is connected to the correct 230 credential server. Then Bob's UA publishes his newly created or 231 updated credentials. The credential server digest challenges the UA 232 to authenticate that the UA knows Bob's shared secret. Once the UA 233 is authenticated, the credential server stores Bob's credentials. 235 Another of Bob's User Agents (Bob1) wants to fetch its current 236 credentials. It does a TLS [RFC5246] handshake with the credential 237 server to authenticate that the UA is connected to the correct 238 credential server. Then Bob's UA subscribes for the credentials. 239 The credential server digest challenges the UA to authenticate that 240 the UA knows Bob's shared secret. Once the UA is authenticated, the 241 credential server sends a NOTIFY that contains Bob's credentials. 242 The private key portion of the credential may have been encrypted 243 with a secret that only Bob's UA (and not the credential server) 244 knows. In this case, once Bob's UA decrypts the private key it will 245 be ready to go. Typically Bob's UA would do this when it first 246 registered on the network. 248 Some time later Alice decides that she wishes to discover Bob's 249 certificate so that she can send him an encrypted message or so that 250 she can verify the signature on a message from Bob. Alice's UA sends 251 a SUBSCRIBE message to Bob's AOR. The proxy in Bob's domain routes 252 this to the credential server via an "authentication service" as 253 defined in [RFC4474]. The credential server returns a NOTIFY that 254 contains Bob's public certificate in the body. This is routed 255 through an authentication service that signs that this message really 256 can validly claim to be from the AOR "sip:bob@example.com". Alice's 257 UA receives the certificate and can use it to encrypt a message to 258 Bob. 260 It is critical to understand that the only way that Alice can trust 261 that the certificate really is the one for Bob and that the NOTIFY 262 has not been spoofed is for Alice to check that the Identity 263 [RFC4474] header field value is correct. 265 The mechanism described in this document works for both self-signed 266 certificates and certificates signed by well known certification 267 authorities. In order to deploy certificates signed by well known 268 certification authorities, certification authorities would have to 269 support adding SIP URIs to the SubjectAltName of the certificates 270 they generate. This is something which has been rarely implemented 271 by commercial certification authorities. However, most UAs would 272 only use self-signed certificates and would use an Authentication 273 Service as described in [RFC4474] to provide a strong binding of an 274 AOR to the certificates. 276 The mechanisms described in this draft allow for three different 277 styles of deployment: 279 1. Deployments where the credential server only stores certificates 280 and does not store any private key information. If the 281 deployment had users with multiple devices, some other scheme 282 (perhaps even manual provisioning) would be used to get the right 283 private keys onto all the devices that a user uses. 284 2. Deployments where the credential server stores certificates and 285 also stores an encrypted version of the private keys. The 286 credential server would not know or need the password phrase for 287 decrypting the private key. The credential server would help 288 move the private keys between devices but the user would need to 289 enter a password phrase on each device to allow that device to 290 decrypt (and encrypt) the private key information. 291 3. Deployments where the credential server generates and stores the 292 certificates and private keys. Deployments such as these may not 293 use password phrases. Consequently, the private keys are not 294 encrypted inside the PKCS#8 objects. This style of deployment 295 would often have the credential server, instead of the devices, 296 create the credentials. 298 4. UA Behavior with Certificates 300 When a User Agent wishes to discover some other user's certificate it 301 subscribes to the "certificate" SIP event package as described in 302 Section 6 to get the certificate. While the subscription is active, 303 if the certificate is updated, the Subscriber will receive the 304 updated certificate in a notification. 306 The Subscriber needs to decide how long it is willing to trust that 307 the certificate it receives is still valid. If the certificate is 308 revoked before it expires, the Notifier will send a notification with 309 an empty body to indicate that the certificate is no longer valid. 310 If the certificate is renewed before it expires, the Notifier will 311 send a notification with a body containing the new certificate. Note 312 that the Subscriber might not receive the notification if an attacker 313 blocks this traffic. The amount of time that the Subscriber caches a 314 certificate SHOULD be configurable. A default of one day is 315 RECOMMENDED. 317 Note that the actual duration of the subscription is unrelated to the 318 caching time or validity time of the corresponding certificate. 319 Allowing subscriptions to persist after a certificate is no longer 320 valid ensures that Subscribers receive the replacement certificate in 321 a timely fashion. The Notifier could return an immediate 322 notification with the certificate in response to subscribe and then 323 immediately terminate subscription, setting the reason parameter to 324 "probation". The Subscriber will have to periodically poll the 325 Notifier to verify validity of the certificate. 327 If the UA uses a cached certificate in a request and receives a 437 328 (Unsupported Certificate) response, it SHOULD remove the certificate 329 it used from the cache, attempt to fetch the certificate again. If 330 the certificate is changed, then the UA SHOULD retry the original 331 request again with the new certificate. This situation usually 332 indicates that the certificate was recently updated, and that the 333 Subscriber has not received a corresponding notification. If the 334 certificate fetched is the same as the one that was previously in the 335 cache, then the UA SHOULD NOT try the request again. This situation 336 can happened when the request was retargeted to a different user than 337 the original request. The 437 response is defined in [RFC4474]. 339 Note: A UA that has a presence list MAY want to subscribe to the 340 certificates of all the presentities in the list when the UA 341 subscribes to their presence, so that when the user wishes to 342 contact a presentity, the UA will already have the appropriate 343 certificate. Future specifications might consider the possibility 344 of retrieving the certificates along with the presence documents. 346 The details of how a UA deals with receiving encrypted messages is 347 outside the scope of this specification. It is worth noting that if 348 Charlie's UAS receives a request that is encrypted to Bob, it would 349 be valid and legal for that UA to send a 302 redirecting the call to 350 Bob. 352 5. UA Behavior with Credentials 354 UAs discover their own credentials by subscribing to their AOR with 355 an event type of credential as described in Section 7. After a UA 356 registers, it SHOULD retrieve its credentials by subscribing to them 357 as described in Section 6.5. 359 When a UA discovers its credential, the private key information might 360 be encrypted with a password phrase. The UA SHOULD request that the 361 user enter the password phrase on the device, and the UA MAY cache 362 this password phrase for future use. 364 There are several different cases in which a UA should generate a new 365 credential: 366 o If the UA receives a NOTIFY with no body for the credential 367 package. 368 o If the certificate has expired. 369 o If the certificate's notAfter date is within the next 600 seconds, 370 the UA SHOULD attempt to create replacement credentials. The UA 371 does this by waiting a random amount of time between 0 and 300 372 seconds. If no new credentials have been received in that time, 373 the UA creates new credentials to replace the expiring ones and 374 sends them in a PUBLISH request following the rules for modifying 375 event state from Section 4.4 of [RFC3903]. 376 o If the user of the device has indicated via the user interface 377 that they wish to revoke the current certificate and issue a new 378 one. 379 Credentials are created by creating a new key pair which will require 380 appropriate randomness as described in [RFC4086] and then creating a 381 certificate as described in Section 10.6. The UA MAY encrypt the 382 private key with a password phrase supplied by the user as specified 383 in Section 10.5. Next, the UA updates the user's credential by 384 sending a PUBLISH [RFC3903] request with the credentials or just the 385 certificate as described in Section 7.8. 387 If a UA wishes to revoke the existing certificate without publishing 388 a new one, it MUST send a PUBLISH with an empty body to the 389 credential server. 391 6. Event Package Formal Definition for "certificate" 393 6.1. Event Package Name 395 This document defines a SIP Event Package as defined in [RFC3265]. 396 The event-package token name for this package is: 398 certificate 400 6.2. SUBSCRIBE Bodies 402 This package does not define any SUBSCRIBE bodies. 404 6.3. Subscription Duration 406 Subscriptions to this event package can range from no time to weeks. 407 Subscriptions in days are more typical and are RECOMMENDED. The 408 default subscription duration for this event package is one day. 410 The credential service is encouraged to keep the subscriptions active 411 for AORs that are communicating frequently, but the credential 412 service MAY terminate the subscription at any point in time. 414 6.4. NOTIFY Bodies 416 The body of a NOTIFY request for this package MUST either be empty or 417 contain an application/pkix-cert body (as defined in [RFC2585]) that 418 contains the certificate, unless an Accept header field has 419 negotiated some other type. The Content-Disposition MUST be set to 420 "signal" as defined in [RFC3204]. 422 A future extension MAY define other NOTIFY bodies. If no "Accept" 423 header field is present in the SUBSCRIBE, the body type defined in 424 this document MUST be assumed. 426 Implementations which generate large notifications are reminded to 427 follow the message size restrictions for unreliable transports 428 articulated in Section 18.1.1 of SIP. 430 6.5. Subscriber Generation of SUBSCRIBE Requests 432 A UA discovers a certificate by sending a SUBSCRIBE request with an 433 event type of "certificate" to the AOR for which a certificate is 434 desired. In general, the UA stays subscribed to the certificate for 435 as long as it plans to use and cache the certificate, so that the UA 436 can be notified about changes or revocations to the certificate. 438 Subscriber User Agents will typically subscribe to certificate 439 information for a period of hours or days, and automatically attempt 440 to re-subscribe just before the subscription is completely expired. 442 When a user de-registers from a device (logoff, power down of a 443 mobile device, etc.), subscribers SHOULD unsubscribe by sending a 444 SUBSCRIBE request with an Expires header field of zero. 446 6.6. Notifier Processing of SUBSCRIBE Requests 448 When a SIP credential server receives a SUBSCRIBE request with the 449 certificate event-type, it is not necessary to authenticate the 450 subscription request. The Notifier MAY limit the duration of the 451 subscription to an administrator-defined period of time. The 452 duration of the subscription does not correspond in any way to the 453 period for which the certificate will be valid. 455 When the credential server receives a SUBSCRIBE request for a 456 certificate, it first checks to see if it has credentials for the 457 requested URI. If it does not have a certificate, it returns a 458 NOTIFY request with an empty message body. 460 6.7. Notifier Generation of NOTIFY Requests 462 Immediately after a subscription is accepted, the Notifier MUST send 463 a NOTIFY with the current certificate, or an empty body if no 464 certificate is available for the target user. In either case it 465 forms a NOTIFY with the From header field value set to the value of 466 the To header field in the SUBSCRIBE request. This server sending 467 the NOTIFY needs either to implement an Authentication Service (as 468 described in SIP Identity [RFC4474]) or else the server needs to be 469 set up such that the NOTIFY request will be sent through an 470 Authentication Service. Sending the NOTIFY request through the 471 Authentication Service requires the SUBSCRIBE request to have been 472 routed through the Authentication Service, since the NOTIFY is sent 473 within the dialog formed by the subscription. 475 6.8. Subscriber Processing of NOTIFY Requests 477 The resulting NOTIFY will contain an application/pkix-cert body that 478 contains the requested certificate. The UA MUST follow the 479 procedures in Section 10.3 to decide if the received certificate can 480 be used. The UA needs to cache this certificate for future use. The 481 maximum length of time it should be cached for is discussed in 482 Section 10.1. The certificate MUST be removed from the cache if the 483 certificate has been revoked (if a NOTIFY with an empty body is 484 received), or if it is updated by a subsequent NOTIFY. The UA MUST 485 check that the NOTIFY is correctly signed by an Authentication 486 Service as described in [RFC4474]. If the identity asserted by the 487 Authentication Service does not match the AOR that the UA subscribed 488 to, the certificate in the NOTIFY is discarded and MUST NOT be used. 490 6.9. Handling of Forked Requests 492 This event package does not permit forked requests. At most one 493 subscription to this event type is permitted per resource. 495 6.10. Rate of Notifications 497 Notifiers SHOULD NOT generate NOTIFY requests more frequently than 498 once per minute. 500 6.11. State Agents and Lists 502 The credential server described in this section which serves 503 certificates is a state agent as defined in [RFC3265] and 504 implementations of the credential server MUST be implemented as a 505 state agent. 507 Implementers MUST NOT use the event list extension [RFC4662] with 508 this event type. It is not possible to make such an approach work, 509 because the Authentication service would have to simultaneously 510 assert several different identities. 512 6.12. Behavior of a Proxy Server 514 There are no additional requirements on a SIP Proxy, other than to 515 transparently forward the SUBSCRIBE and NOTIFY requests as required 516 in SIP. This specification describes the Proxy, Authentication 517 service, and credential service as three separate services, but it is 518 certainly possible to build a single SIP network element that 519 performs all of these services at the same time. 521 7. Event Package Formal Definition for "credential" 523 7.1. Event Package Name 525 This document defines a SIP Event Package as defined in [RFC3265]. 526 The event-package token name for this package is: 528 credential 530 7.2. SUBSCRIBE Bodies 532 This package does not define any SUBSCRIBE bodies. 534 7.3. Subscription Duration 536 Subscriptions to this event package can range from hours to one week. 537 Subscriptions in days are more typical and are RECOMMENDED. The 538 default subscription duration for this event package is one day. 540 The credential service SHOULD keep subscriptions active for UAs that 541 are currently registered. 543 7.4. NOTIFY Bodies 545 An implementation compliant to this specification MUST support the 546 multipart/mixed type (see [RFC2046]). This allows a notification to 547 contain multiple resource documents including at a minimum the 548 application/pkix-cert body with the certificate and an application/ 549 pkcs8 body that has the associated private key information for the 550 certificate. The application/pkcs8 media type is defined in 551 [RFC5958]. 553 The absence of an Accept header in the SUBSCRIBE indicates support 554 for multipart/mixed and the content types application/pkix-cert and 555 application/pkcs8. If an Accept header is present, these types MUST 556 be included, in additional to any other types supported by the 557 client. 559 The application/pkix-cert body is a DER encoded X.509v3 certificate 560 [RFC2585]. The application/pkcs8 body contains a DER-encoded 561 [RFC5958] object that contains the private key. The PKCS#8 objects 562 MUST be of type PrivateKeyInfo. The integrity and confidentiality of 563 the PKCS#8 objects is provided by the TLS transport. The transport 564 encoding of all the MIME bodies is binary. 566 7.5. Subscriber Generation of SUBSCRIBE Requests 568 A Subscriber User Agent will subscribe to its credential information 569 for a period of hours or days and will automatically attempt to re- 570 subscribe before the subscription has completely expired. 572 The Subscriber SHOULD subscribe to its credentials whenever a new 573 user becomes associated with the device (a new login). The 574 subscriber SHOULD also renew its subscription immediately after a 575 reboot, or when the subscriber's network connectivity has just been 576 re-established. 578 The UA needs to authenticate with the credential service for these 579 operations. The UA MUST use TLS to directly connect to the server 580 acting as the credential service or to a server that is authoritative 581 for the domain of the credential service. The UA MUST NOT connect 582 through an intermediate proxy to the credential service. The UA may 583 be configured with a specific name for the credential service; 584 otherwise normal SIP routing is used. As described in RFC 3261, the 585 TLS connection needs to present a certificate that matches the 586 expected name of the server to which the connection was formed, so 587 that the UA knows it is talking to the correct server. Failing to do 588 this may result in the UA publishing its private key information to 589 an attacker. The credential service will authenticate the UA using 590 the usual SIP Digest mechanism, so the UA can expect to receive a SIP 591 challenge to the SUBSCRIBE or PUBLISH requests. 593 7.6. Notifier Processing of SUBSCRIBE Requests 595 When a credential service receives a SUBSCRIBE for a credential, the 596 credential service has to authenticate and authorize the UA and 597 validate that adequate transport security is being used. Only a UA 598 that can authenticate as being able to register as the AOR is 599 authorized to receive the credentials for that AOR. The Credential 600 Service MUST digest challenge the UA to authenticate the UA and then 601 decide if it is authorized to receive the credentials. If 602 authentication is successful, the Notifier MAY limit the duration of 603 the subscription to an administrator-defined period of time. The 604 duration of the subscription MUST NOT be larger than the length of 605 time for which the certificate is still valid. The Expires header 606 field SHOULD be set so that it is not longer than the notAfter date 607 in the certificate. 609 7.7. Notifier Generation of NOTIFY Requests 611 Once the UA has authenticated with the credential service and the 612 subscription is accepted, the credential service MUST immediately 613 send a Notify request. The Authentication Service is applied to this 614 NOTIFY request in the same way as the certificate subscriptions. If 615 the credential is revoked, the credential service MUST terminate any 616 current subscriptions and force the UA to re-authenticate by sending 617 a NOTIFY with its Subscription-State header field set to "terminated" 618 and a reason parameter of "deactivated". (This causes a Subscriber 619 to retry the subscription immediately.) This is so that if a secret 620 for retrieving the credentials gets compromised, the rogue UA will 621 not continue to receive credentials after the compromised secret has 622 been changed. 624 Any time the credentials for this URI change, the credential service 625 MUST send a new NOTIFY to any active subscriptions with the new 626 credentials. 628 The notification MUST be sent over TLS so that it is integrity 629 protected and the TLS needs to be directly connected between the UA 630 and the credential service with no intermediaries. 632 7.8. Generation of PUBLISH Requests 634 A user agent SHOULD be configurable to control whether it publishes 635 the credential for a user or just the user's certificate. 637 When publishing just a certificate, the body contains an application/ 638 pkix-cert. When publishing a credential, the body contains a 639 multipart/mixed containing both an application/pkix-cert and an 640 application/pkcs8 body. 642 When the UA sends the PUBLISH [RFC3903] request, it needs to do the 643 following: 644 o The UA MUST use TLS to directly connect to the server acting as 645 the credential service or to a server that is authoritative for 646 the domain of the credential service. The UA MUST NOT connect 647 through an intermediate proxy to the credential service. 648 o The Expires header field value in the PUBLISH request SHOULD be 649 set to match the time for which the certificate is valid. 650 o If the certificate includes Basic Constraints, it SHOULD set the 651 cA flag to false. 653 7.9. Notifier Processing of PUBLISH Requests 655 When the credential service receives a PUBLISH to update credentials, 656 it MUST authenticate and authorize this request the same way as for 657 subscriptions for credentials. If the authorization succeeds, then 658 the credential service MUST perform the following check on the 659 certificate: 661 o The notBefore validity time MUST NOT be in the future. 662 o The notAfter validity time MUST be in the future. 663 o If a cA Basic Constraint flag is set in the certificate, it is set 664 to false. 665 If all of these succeed, the credential service updates the 666 credential for this URI, processes all the active certificates and 667 credential subscriptions to this URI, and generates a NOTIFY request 668 with the new credential or certificate. Note the SubjectAltName 669 SHOULD NOT be checked as that would restrict which certificates could 670 be used and offers no additional security guarantees. 672 If the Subscriber submits a PUBLISH request with no body and 673 Expires=0, this revokes the current credentials. Watchers of these 674 credentials will receive update with no body indicating that they 675 MUST stop any previously stored credentials. Note that subscriptions 676 to the certificate package are NOT terminated; each subscriber to the 677 certificate package receives a notification with an empty body. 679 7.10. Subscriber Processing of NOTIFY Requests 681 When the UA receives a valid NOTIFY request, it should replace its 682 existing credentials with the new received ones. If the UA cannot 683 decrypt the PKCS#8 object, it MUST send a 437 (Unsupported 684 Certificate) response. Later if the user provides a new password 685 phrase for the private key, the UA can subscribe to the credentials 686 again and attempt to decrypt with the new password phrase. 688 7.11. Handling of Forked Requests 690 This event package does not permit forked requests. 692 7.12. Rate of Notifications 694 Notifiers SHOULD NOT generate NOTIFY requests more frequently than 695 once per minute. 697 7.13. State Agents and Lists 699 The credential server described in this section which serves 700 credentials is a state agent and implementations of the credential 701 server MUST be implemented as a state agent. 703 Implementers MUST NOT use the event list extension [RFC4662] with 704 this event type. 706 7.14. Behavior of a Proxy Server 708 The behavior is identical to behavior described for certificate 709 subscriptions described in Section 6.12. 711 8. Identity Signatures 713 The [RFC4474] Authentication service defined an signature algorithm 714 based on SHA-1 called rsa-sha1. This specification adds an signature 715 algorithm that is roughly the same but based on SHA-256 and called 716 rsa-sha256. 718 When using the rsa-sha256 algorithm, the signature MUST be computed 719 in exactly the same way as described in section 9 of [RFC4474] with 720 the exception that instead of using sha1WithRSAEncryption, the 721 computation is done using sha256WithRSAEncryption as described in 722 [RFC5754]. 724 Implementations of this specification MUST implement both rsa-sha1 725 and rsa-sha256. The IANA registration for rsa-sha256 is defined in 726 Section 11.3. 728 9. Examples 730 In all these examples, large parts of the messages are omitted to 731 highlight what is relevant to this draft. The lines in the examples 732 that are prefixed by $ represent encrypted blocks of data. 734 9.1. Encrypted Page Mode IM Message 736 In this example, Alice sends Bob an encrypted page mode instant 737 message. Alice does not already have Bob's public key from previous 738 communications, so she fetches Bob's public key from Bob's credential 739 service: 741 SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0 742 ... 743 Event: certificate 745 The credential service responds with the certificate in a NOTIFY. 747 NOTIFY alice@atlanta.example.com SIP/2.0 748 Subscription-State: active; expires=7200 749 .... 750 From: ;tag=1234 751 Identity: ".... stuff removed ...." 752 Identity-Info: ;alg=rsa-sha256 753 .... 754 Event: certificate 755 Content-Type: application/pkix-cert 756 Content-Disposition: signal 758 < certificate data > 760 Next, Alice sends a SIP MESSAGE message to Bob and can encrypt the 761 body using Bob's public key as shown below. 763 MESSAGE sip:bob@biloxi.example.com SIP/2.0 764 ... 765 Content-Type: application/pkcs7-mime 766 Content-Disposition: render 768 $ Content-Type: text/plain 769 $ 770 $ < encrypted version of "Hello" > 772 9.2. Setting and Retrieving UA Credentials 774 When Alice's UA wishes to publish Alice's certificate and private key 775 to the credential service, it sends a PUBLISH request like the one 776 below. This must be sent over a TLS connection directly to the 777 domain of the credential service. The credential service presents a 778 certificate where the SubjectAltName contains an entry that matches 779 the domain name in the request line of the PUBLISH request and digest 780 challenges the request to authenticate her. 782 PUBLISH sips:alice@atlanta.example.com SIP/2.0 783 ... 784 Event: credential 785 Content-Type: multipart/mixed;boundary=boundary 786 Content-Disposition: signal 788 --boundary 789 Content-ID: 123 790 Content-Type: application/pkix-cert 792 < Public certificate for Alice > 793 --boundary 794 Content-ID: 456 795 Content-Type: application/pkcs8 797 < Private Key for Alice > 798 --boundary 800 If one of Alice's UAs subscribes to the credential event, the UA will 801 be digest challenged, and the NOTIFY will include a body similar to 802 the one in the PUBLISH section above. 804 10. Security Considerations 806 The high level message flow from a security point of view is 807 summarized in the following figure. The 200 responses are removed 808 from the figure as they do not have much to do with the overall 809 security. 811 In this figure, authC refers to authentication and authZ refers to 812 authorization. 814 Alice Server Bob UA 815 | | TLS Handshake | 1) Client authC/Z server 816 | |<---------------->| 817 | | PUBLISH | 2) Client sends request 818 | |<-----------------| (write credential) 819 | | Digest Challenge | 3) Server challenges client 820 | |----------------->| 821 | | PUBLISH + Digest | 4) Server authC/Z client 822 | |<-----------------| 823 | | time... | 824 | | | 825 | | TLS Handshake | 5) Client authC/Z server 826 | |<---------------->| 827 | | SUBSCRIBE | 6) Client sends request 828 | |<-----------------| (read credential) 829 | | Digest Challenge | 7) Server challenges client 830 | |----------------->| 831 | | SUBSCRIBE+Digest | 8) Server authC/Z client 832 | |<-----------------| 833 | | NOTIFY | 9) Server returns credential 834 | |----------------->| 835 | | 836 | SUBSCRIBE | 10) Client requests certificate 837 |---------->| 838 | | 839 |NOTIFY+AUTH| 11) Server returns user's certificate and signs that 840 |<----------| it is valid using certificate for the domain 841 | | 843 When the UA, labeled Bob, first created a credential for Bob, it 844 would store this on the credential server. The UA authenticated the 845 Server using the certificates from the TLS handshake. The Server 846 authenticated the UA using a digest style challenge with a shared 847 secret. 849 The UA, labeled Bob, wishes to request its credentials from the 850 server. First it forms a TLS connection to the Server, which 851 provides integrity and privacy protection and also authenticates the 852 server to Bob's UA. Next the UA requests its credentials using a 853 SUBSCRIBE request. The Server digest challenges this to authenticate 854 Bob's UA. The server and Bob's UA have a shared secret that is used 855 for this. If the authentication is successful, the server sends the 856 credentials to Bob's UA. The private key in the credentials may have 857 been encrypted using a shared secret that the server does not know. 859 A similar process would be used for Bob's UA to publish new 860 credentials to the server. Bob's UA would send a PUBLISH request 861 containing the new credentials. When this happened, all the other 862 UAs that were subscribed to Bob's credentials would receive a NOTIFY 863 with the new credentials. 865 Alice wishes to find Bob's certificate and sends a SUBSCRIBE to the 866 server. The server sends the response in a NOTIFY. This does not 867 need to be sent over a privacy or integrity protected channel, as the 868 Authentication service described in [RFC4474] provides integrity 869 protection of this information and signs it with the certificate for 870 the domain. 872 This whole scheme is highly dependent on trusting the operators of 873 the credential service and trusting that the credential service will 874 not be compromised. The security of all the users will be 875 compromised if the credential service is compromised. 877 Note: There has been significant discussion of the topic of 878 avoiding deployments in which the credential servers store the 879 private keys, even in some encrypted form that the credential 880 server does not know how to decrypt. Various schemes were 881 considered to avoid this but they all result in either moving the 882 problem to some other server, which does not seem to make the 883 problem any better, or having a different credential for each 884 device. For some deployments where each user has only one device 885 this is fine but for deployments with multiple devices, it would 886 require that when Alice went to contact Bob, Alice would have to 887 provide messages encrypted for all of Bob's devices. The sipping 888 working group did consider this architecture and decided it was 889 not appropriate due both to the information it revealed about the 890 devices and users and the amount of signaling required to make it 891 work. 893 This specification requires that TLS be used for the SIP 894 communications to place and retrieve a UA's private key. This 895 provides security in two ways: 896 1. Confidentiality is provided for the digest authentication 897 exchange, thus protecting it from dictionary attacks. 898 2. Confidentiality is provided for the private key, thus protecting 899 it from being exposed to passive attackers. 900 In order to prevent man-in-the-middle attacks, TLS clients MUST check 901 that the SubjectAltName of the certificate for the server they 902 connected to exactly matches the server they were trying to connect 903 to. The connection must be directly connected to the correct server 904 or any intermediaries in the TLS path can compromise the certificate 905 and instead provide a certificate for which the attacker knows the 906 private key. This may lead the UA that relies on this compromised 907 certificate to lose confidential information. Failing to use TLS or 908 selecting a poor cipher suite (such as NULL encryption) may result in 909 credentials, including private keys, being sent unencrypted over the 910 network and will render the whole system useless. 912 The correct checking of chained certificates as specified in TLS 913 [RFC5246] is critical for the client to authenticate the server. If 914 the client does not authenticate that it is talking to the correct 915 credential service, a man in the middle attack is possible. 917 10.1. Certificate Revocation 919 If a particular credential needs to be revoked, the new credential is 920 simply published to the credential service. Every device with a copy 921 of the old credential or certificate in its cache will have a 922 subscription and will rapidly (order of seconds) be notified and 923 replace its cache. Clients that are not subscribed will subscribe 924 when they next need to use the certificate and will get the new 925 certificate. 927 It is possible that an attacker could mount a DOS attack such that 928 the UA that had cached a certificate did not receive the NOTIFY with 929 its revocation. To protect against this attack, the UA needs to 930 limit how long it caches certificates. After this time, the UA would 931 invalidate the cached information even though no NOTIFY had ever been 932 received due to the attacker blocking it. 934 The duration of this cached information is in some ways similar to a 935 device deciding how often to check a CRL list. For many 936 applications, a default time of 1 day is suggested, but for some 937 applications it may be desirable to set the time to zero so that no 938 certificates are cached at all and the credential is checked for 939 validity every time the certificate is used. 941 The UA MUST NOT cache the certificates for a period longer than that 942 of the subscription duration. This is to avoid the UA using invalid 943 cached credentials when the notifier of the new credentials has been 944 prevented from updating the UA. 946 10.2. Certificate Replacement 948 The UAs in the system replace the certificates close to the time that 949 the certificates would expire. If a UA has used the same key pair to 950 encrypt a very large volume of traffic, the UA MAY choose to replace 951 the credential with a new one before the normal expiration. 953 10.3. Trusting the Identity of a Certificate 955 When a UA wishes to discover the certificate for 956 sip:alice@example.com, the UA subscribes to the certificate for 957 alice@example.com and receives a certificate in the body of a SIP 958 NOTIFY request. The term original URI is used to describe the URI 959 that was in the To header field value of the SUBSCRIBE request. So 960 in this case the original URI would be sip:alice@example.com. 962 If the certificate is signed by a trusted certification authority, 963 and one of the names in the SubjectAltName matches the original URI, 964 then this certificate MAY be used but only for exactly the original 965 URI and not for other identities found in the SubjectAltName. 966 Otherwise, there are several steps the UA MUST perform before using 967 this certificate. 968 o The From header field in the NOTIFY request MUST match the 969 original URI that was subscribed to. 970 o The UA MUST check the Identity header field as described in the 971 Identity [RFC4474] specification to validate that bodies have not 972 been tampered with and that an Authentication Service has 973 validated this From header field. 974 o The UA MUST check the validity time of the certificate and stop 975 using the certificate if it is invalid. (Implementations are 976 reminded to verify both the notBefore and notAfter validity 977 times.) 978 o The certificate MAY have several names in the SubjectAltName but 979 the UA MUST only use this certificate when it needs the 980 certificate for the identity asserted by the Authentication 981 Service in the NOTIFY. This means that the certificate should 982 only be indexed in the certificate cache by the AOR that the 983 Authentication Service asserted and not by the value of all the 984 identities found in the SubjectAltName list. 985 These steps result in a chain of bindings that result in a trusted 986 binding between the original AOR that was subscribed to and a public 987 key. The original AOR is forced to match the From. The 988 Authentication Service validates that this request did come from the 989 identity claimed in the From header field value and that the bodies 990 in the request that carry the certificate have not been tampered 991 with. The certificate in the body contains the public key for the 992 identity. Only the UA that can authenticate as this AOR, or devices 993 with access to the private key of the domain, can tamper with this 994 body. This stops other users from being able to provide a false 995 public key. This chain of assertion from original URI, to From, to 996 body, to public key is critical to the security of the mechanism 997 described in this specification. If any of the steps above are not 998 followed, this chain of security will be broken and the system will 999 not work. 1001 10.3.1. Extra Assurance 1003 Although the certificates used with this document need not be 1004 validatable to a trust anchor via PKIX [RFC5280] procedures, 1005 certificates which can be validated may also be distributed via this 1006 mechanism. Such certificates potentially offer an additional level 1007 of security because they can be used with the secure (and partially 1008 isolated) certification authority user verification and key issuance 1009 toolset, rather than depending on the security of generic SIP 1010 implementations. 1012 When a relying party receives a certificate which is not self-signed, 1013 it MAY attempt to validate it using the rules in Section 6 of 1014 [RFC5280]. If the certificate validates successfully and the names 1015 correctly match the user's AOR (see Section 10.6), then the 1016 implementation SHOULD provide some indication that the certificate 1017 has been validated with an external authority. In general, failure 1018 to validate a certificate via this mechanism SHOULD NOT be used as a 1019 reason to reject the certificate. However, if the certificate is 1020 revoked, then the implementation SHOULD reject it. 1022 10.4. SACRED Framework 1024 This specification includes a mechanism that allows end users to 1025 share the same credentials across different end-user devices. This 1026 mechanism is based on the one presented in the SACRED Framework 1027 [RFC3760]. While this mechanism is fully described in this document, 1028 the requirements and background are more thoroughly discussed in 1029 [RFC3760]. 1031 Specifically, Section 7.5, Section 7.6 and Section 7.9 follow the 1032 cTLS architecture described in section 4.2.2 of [RFC3760]. The 1033 client authenticates the server using the server's TLS certificate. 1034 The server authenticates the client using a SIP digest transaction 1035 inside the TLS session. The TLS sessions form a strong session key 1036 that is used to protect the credentials being exchanged. 1038 10.5. Crypto Profiles 1040 Credential Services SHOULD implement the server name indication 1041 extensions in [RFC4366]. As specified in [RFC5246], Credential 1042 Services MUST support the TLS cipher suite 1043 TLS_RSA_WITH_AES_128_CBC_SHA. In addition, they MUST support the TLS 1044 cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256 as specified in 1045 [RFC5246]. If additional cipher suites are supported, then 1046 implementations MUST NOT negotiate a cipher suite that employs NULL 1047 encryption, integrity, or authentication algorithms. 1049 Implementations of TLS typically support multiple versions of the 1050 Transport Layer Security protocol as well as the older Secure Sockets 1051 Layer (SSL) protocol. Because of known security vulnerabilities, 1052 clients and servers MUST NOT request, offer, or use SSL 2.0. See 1053 Appendix E.2 of [RFC5246]for further details. 1055 The PKCS#8 in the clients MUST implement PBES2 with a key derivation 1056 algorithm of PBKDF2 using HMAC with SHA-256 [RFC5754] and an 1057 encryption algorithm of id-aes128-wrap-pad as defined in [RFC5649]. 1058 Some pre-standard deployments of this specification used DES-EDE2- 1059 CBC-Pad as defined in [RFC2898] so, for some implementations, it may 1060 be desirable to also support that algorithm. A different passphrase 1061 SHOULD be used for the PKCS#8 encryption than is used for 1062 authentication of the client. It is important to choose an 1063 sufficiently strong passphrases. Specific advice on the passphrase 1064 can be found in section 6 of [RFC5958]. 1066 10.6. User Certificate Generation 1068 The certificates need to be consistent with [RFC5280]. The 1069 sha1WithRSAEncryption and sha256WithRSAEncryption algorithm for the 1070 signatureAlgorithm MUST be implemented. The Issuers SHOULD be the 1071 same as the subject. Given the ease of issuing new certificates with 1072 this system, the Validity can be relatively short. A Validity of one 1073 year or less is RECOMMENDED. The SubjectAltName must have a URI type 1074 that is set to the SIP URL corresponding to the user AOR. It MAY be 1075 desirable to put some randomness into the length of time for which 1076 the certificates are valid so that it does not become necessary to 1077 renew all the certificates in the system at the same time. 1079 When creating a new key pair for a certificate, it is critical to 1080 have appropriate randomness as described in [RFC4086]. This can be 1081 challenging on some embedded devices such as some IP Phones and 1082 implementors should pay particular attention to this point. 1084 It is worth noting that a UA can discover the current time by looking 1085 at the Date header field value in the 200 response to a REGISTER 1086 request. 1088 10.7. Private Key Storage 1090 The protection afforded private keys is a critical security factor. 1091 On a small scale, failure of devices to protect the private keys will 1092 permit an attacker to masquerade as the user or decrypt their 1093 personal information. As noted in the SACRED Framework, when stored 1094 on an end user device, such as a diskette or hard drive, credentials 1095 SHOULD NOT be in the clear. It is RECOMMENDED that private keys be 1096 stored securely in the device, more specifically encrypting them 1097 using tamper-resistant hardware encryption and exposing them only 1098 when required: for example, the private key is decrypted when needed 1099 to generate a digital signature, and re-encrypted immediately to 1100 limit exposure in the RAM for a short period of time. Some 1101 implementations may limit access to private keys by prompting users 1102 for a PIN prior to allowing access to the private key. 1104 On the server side, the protection of unencrypted PKCS#8 objects is 1105 equally important. A server failing to protect the private keys 1106 would be catastrophic as attackers with access to unencrypted PKCS#8 1107 object could masquerade as any user whose private key was not 1108 encrypted. Therefore, it is also recommended that the private keys 1109 be stored securely in the server, more specifically encrypting them 1110 using tamper-resistant hardware encryption and exposing them only 1111 when required. 1113 FIPS 140-2 [FIPS-140-2] provides useful guidance on secure storage. 1115 10.8. Compromised Authentication Service 1117 One of this worst attacks against this system would be if the 1118 Authentication Service were compromised. This attack is somewhat 1119 analogous to a certification authority being compromised in 1120 traditional PKI systems. The attacker could make a fake certificate 1121 for which it knows the private key, use it to receive any traffic for 1122 a given use, and then re-encrypt that traffic with the correct key 1123 and forward the communication to the intended receiver. The attacker 1124 would thus become a man in the middle in the communications. 1126 There is not too much that can be done to protect against this. A UA 1127 MAY subscribe to its own certificate under some other identity to try 1128 to detect whether the credential server is handing out the correct 1129 certificates. It will be difficult to do this in a way that does not 1130 allow the credential server to recognize the user's UA. 1132 The UA MAY also save the fingerprints of the cached certificates and 1133 warn users when the certificates change significantly before their 1134 expiry date. 1136 The UA MAY also allow the user to see the fingerprints for the cached 1137 certificates so that they can be verified by some other out of band 1138 means. 1140 11. IANA Considerations 1142 This specification defines two new event packages that IANA is 1143 requested to add the registry at: 1144 http://www.iana.org/assignments/sip-events 1146 11.1. Certificate Event Package 1148 To: ietf-sip-events@iana.org 1149 Subject: Registration of new SIP event package 1151 Package Name: certificate 1153 Is this registration for a Template Package: No 1155 Published Specification(s): This document 1157 New Event header parameters: This package defines no 1158 new parameters 1160 Person & email address to contact for further information: 1161 Cullen Jennings 1163 11.2. Credential Event Package 1165 To: ietf-sip-events@iana.org 1166 Subject: Registration of new SIP event package 1168 Package Name: credential 1170 Is this registration for a Template Package: No 1172 Published Specification(s): This document 1174 Person & email address to contact for further information: 1175 Cullen Jennings 1177 11.3. Identity Algorithm 1179 IANA will add the following entry to the "Identity-Info Algorithm 1180 Parameter Values" registry. Note to RFC Editor: Please replace 1181 RFCAAAA with the number for this RFC. 1183 'alg' Parameter Name Reference 1184 ---------------------- --------- 1185 rsa-sha256 [RFCAAAA] 1187 12. Acknowledgments 1189 Many thanks to Eric Rescorla, Russ Housley, Jim Schaad, Rohan Mahy 1190 and Sean Turner for significant help, discussion, and text. Many 1191 others provided useful comments and text, including Kumiko Ono, Peter 1192 Gutmann, Yaron Pdut, Aki Niemi, Magnus Nystrom, Paul Hoffman, Adina 1193 Simu, Dan Wing, Mike Hammer, Pasi Eronen, Alexey Melnikov, Tim Polk, 1194 John Elwell, Jonathan Rosenberg and Lyndsay Campbell. 1196 13. References 1198 13.1. Normative References 1200 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1201 Extensions (MIME) Part Two: Media Types", RFC 2046, 1202 November 1996. 1204 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1205 Requirement Levels", BCP 14, RFC 2119, March 1997. 1207 [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1208 Infrastructure Operational Protocols: FTP and HTTP", 1209 RFC 2585, May 1999. 1211 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, 1212 F., Watson, M., and M. Zonoun, "MIME media types for ISUP 1213 and QSIG Objects", RFC 3204, December 2001. 1215 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1216 A., Peterson, J., Sparks, R., Handley, M., and E. 1217 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1218 June 2002. 1220 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1221 Event Notification", RFC 3265, June 2002. 1223 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1224 for Event State Publication", RFC 3903, October 2004. 1226 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1227 Authenticated Identity Management in the Session 1228 Initiation Protocol (SIP)", RFC 4474, August 2006. 1230 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1231 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1233 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1234 Housley, R., and W. Polk, "Internet X.509 Public Key 1235 Infrastructure Certificate and Certificate Revocation List 1236 (CRL) Profile", RFC 5280, May 2008. 1238 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 1239 Requirements for Security", BCP 106, RFC 4086, June 2005. 1241 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 1242 and T. Wright, "Transport Layer Security (TLS) 1243 Extensions", RFC 4366, April 2006. 1245 [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic 1246 Message Syntax", RFC 5754, January 2010. 1248 [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard 1249 (AES) Key Wrap with Padding Algorithm", RFC 5649, 1250 September 2009. 1252 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 1253 August 2010. 1255 13.2. Informational References 1257 [RFC2898] Kaliski, B., "PKCS #5: Password-Based Cryptography 1258 Specification Version 2.0", RFC 2898, September 2000. 1260 [RFC3760] Gustafson, D., Just, M., and M. Nystrom, "Securely 1261 Available Credentials (SACRED) - Credential Server 1262 Framework", RFC 3760, April 2004. 1264 [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail 1265 Extensions (S/MIME) Version 3.1 Message Specification", 1266 RFC 3851, July 2004. 1268 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1269 Requirement for the Session Initiation Protocol (SIP)", 1270 RFC 3853, July 2004. 1272 [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session 1273 Initiation Protocol (SIP) Event Notification Extension for 1274 Resource Lists", RFC 4662, August 2006. 1276 [FIPS-140-2] 1277 NIST, "Security Requirements for Cryptographic Modules", 1278 June 2005, . 1281 Authors' Addresses 1283 Cullen Jennings 1284 Cisco Systems 1285 170 West Tasman Drive 1286 San Jose, CA 95134 1287 USA 1289 Phone: +1 408 421-9990 1290 Email: fluffy@cisco.com 1292 Jason Fischl (editor) 1293 Skype 1294 2145 Hamilton Ave. 1295 San Jose, CA 95125 1296 USA 1298 Phone: +1-415-202-5192 1299 Email: jason.fischl@skype.net