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