idnits 2.17.00 (12 Aug 2021) /tmp/idnits52512/draft-ietf-sipping-certs-02.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 (July 17, 2005) is 6152 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: draft-ietf-sip-identity has been published as RFC 4474 ** 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) == Outdated reference: draft-ietf-simple-event-list has been published as RFC 4662 Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP C. Jennings 3 Internet-Draft Cisco Systems 4 Expires: January 18, 2006 J. Peterson 5 NeuStar, Inc. 6 July 17, 2005 8 Certificate Management Service for The Session Initiation Protocol (SIP) 9 draft-ietf-sipping-certs-02 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 January 18, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This draft defines a Credential Service that allows SIP User Agents 43 to use a SIP package to discover the certificates of other users. 44 This mechanism allows user agents that want to contact a given 45 Address-of-Record (AOR) to retrieve that AOR's certificate by 46 subscribing to the Credential Service. The Credential Service also 47 allows users to store and retrieve their own certificates and private 48 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 . . . . . . . . . . . . . . . . . 9 61 7.3 SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 12 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 the credential server only stores 252 certificates and does not store any private key information. If 253 the 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 the private keys between devices but the user would need 261 to 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 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. 350 o If the user of the device has indicated via the user interface 351 that they wish to revoke the current certificate and issue a new 352 one. 353 Credentials are created by creating a new key pair which will require 354 appropriate randomness, and then creating a certificate as described 355 in Section 10.6. The UA MAY encrypt the private key with a password 356 phrase supplied by the user. Then the UA updates the user's 357 credential by sending a PUBLISH [3] request with the credentials or 358 just the certificate as described in Section 8.9. 360 If a UA wishes to revoke the existing certificate without publishing 361 a new one, it MUST send a PUBLISH with an empty body to the 362 credential server. 364 6. Credential Service Behavior 366 The credential service stores credentials for users and can provide 367 the credentials to other user agents belonging to the same user, and 368 certificates to any user agent. The credentials are indexed by a URI 369 that corresponds to the AOR of the user. When a UA requests a public 370 certificate with a SUBSCRIBE, the server sends the UA the certificate 371 in a NOTIFY and sends a subsequent NOTIFY any time the certificate 372 changes. When a credential is requested, the credential service 373 digest challenges the requesting UA to authenticate it so that the 374 credential service can verify that the UA is authorized to receive 375 the requested credentials. When a credential is published, the 376 credential service digest challenges the requesting UA to 377 authenticate it so that the credential service can verify that the UA 378 is authorized to change the credentials. This behavior is defined in 379 Section 7 and Section 8. 381 7. Event Package Formal Definition for "certificate" 383 7.1 Event Package Name 385 This document defines a SIP Event Package as defined in RFC 3265 [4]. 386 The event-package token name for this package is: 388 certificate 390 7.2 Event Package Parameters 392 This package does not define any event package parameters. 394 7.3 SUBSCRIBE Bodies 396 This package does not define any SUBSCRIBE bodies. 398 7.4 Subscription Duration 400 Subscriptions to this event package can range from no time to weeks. 401 Subscriptions in days are more typical and are RECOMMENDED. The 402 default subscription duration for this event package is one day. 404 The credential service is encouraged to keep the subscriptions active 405 for AORs that are communicating frequently, but the credential 406 service MAY terminate the subscription at any point in time. 408 7.5 NOTIFY Bodies 410 The body of a NOTIFY request for this package MUST either be empty or 411 contain an application/pkix-cert body (as defined in [10]) that 412 contains the certificate, unless an Accept header has negotiated some 413 other type. The Content-Disposition MUST be set to "signal". 415 A future extension MAY define other NOTIFY bodies. If no "Accept" 416 header is present in the SUBSCRIBE, the body type defined in this 417 document MUST be assumed. 419 Implementations which generate large notifications are reminded to 420 follow the message size restrictions for unreliable transports 421 articulated in Section 18.1.1 of SIP. 423 7.6 Subscriber Generation of SUBSCRIBE Requests 425 A UA discovers a certificate by sending a SUBSCRIBE request with an 426 event type of "certificate" to the AOR for which a certificate is 427 desired. In general, the UA stays subscribed to the certificate for 428 as long as it plans to use and cache the certificate, so that the UA 429 can be notified about changes or revocations to the certificate. 431 Subscriber User Agents will typically subscribe to certificate 432 information for a period of hours or days, and automatically attempt 433 to re-subscribe just before the subscription is completely expired. 435 When a user de-registers from a device (logoff, power down of a 436 mobile device, etc.), subscribers SHOULD unsubscribe by sending a 437 SUBSCRIBE request with an Expires header of zero. 439 7.7 Notifier Processing of SUBSCRIBE Requests 441 When a SIP credential server receives a SUBSCRIBE request with the 442 certificate event-type, it is not necessary to authenticate the 443 subscription request. The Notifier MAY limit the duration of the 444 subscription to an administrator-defined period of time. The 445 duration of the subscription does not correspond in any way to the 446 period for which the certificate will be valid. 448 When the credential server receives a SUBSCRIBE request for a 449 certificate, it first checks to see if it has credentials for the 450 requested URI. If it does not have a certificate, it returns a 451 NOTIFY request with an empty message body. 453 7.8 Notifier Generation of NOTIFY Requests 455 Immediately after a subscription is accepted, the Notifier MUST send 456 a NOTIFY with the current certificate, or an empty body if no 457 certificate is available for the target user. In either case it 458 forms a NOTIFY with the From header field value set to the value of 459 the To header field in the SUBSCRIBE request. This server sending 460 the NOTIFY needs either to implement an Authentication Service (as 461 described in SIP Identity [2]) or else the server needs to be set up 462 such that the NOFIFY request will be sent through an Authentication 463 Service. Sending the NOTIFY request through the the Authentication 464 Service requires the SUBSCRIBE request to have been routed through 465 the Authentication Service, since the NOTIFY is sent within the 466 dialog formed by the subscription. 468 7.9 Subscriber Processing of NOTIFY Requests 470 The resulting NOTIFY will contain an application/pkix-cert body that 471 contains the requested certificate. The UA MUST follow the 472 procedures in Section 10.3 to decide if the received certificate can 473 be used. The UA needs to cache this certificate for future use. The 474 maximum length of time it should be cached for is discussed in 475 Section 10.1. The certificate MUST be removed from the cache if the 476 certificate has been revoked (if a NOTIFY with an empty body is 477 received), or if it is updated by a subsequent NOTIFY. The UA MUST 478 check that the NOTIFY is correctly signed by an Authentication 479 Service as described in [2]. If the identity asserted by the 480 Authentication Service does not match the AOR that the UA subscribed 481 to, the certificate in the NOTIFY is discarded and MUST NOT be used. 483 7.10 Handling of Forked Requests 485 This event package does not permit forked requests. At most one 486 subscription to this event type is permitted per resource. 488 7.11 Rate of Notifications 490 Notifiers SHOULD NOT generate NOTIFY requests more frequently than 491 once per minute. 493 7.12 State Agents and Lists 495 Implementers MUST NOT implement state agents for this event type. 496 Likewise, implementations MUST NOT use the event list extension [19] 497 with this event type. It is not possible to make such an approach 498 work, because the Authentication service would have to simultaneously 499 assert several different identities. 501 7.13 Behavior of a Proxy Server 503 There are no additional requirements on a SIP Proxy, other than to 504 transparently forward the SUBSCRIBE and NOTIFY requests as required 505 in SIP. This specification describes the Proxy, Authentication 506 service, and credential service as three separate services, but it is 507 certainly possible to build a single SIP network element that 508 performs all of these services at the same time. 510 8. Event Package Formal Definition for "credential" 512 8.1 Event Package Name 514 This document defines a SIP Event Package as defined in RFC 3265 [4]. 515 The event-package token name for this package is: 517 credential 519 8.2 Event Package Parameters 521 This package defines the "etag" Event header parameter which is valid 522 only in NOTIFY requests. It contains a token which represents the 523 SIP etag value at the time the notification was sent. Considering 524 how infrequently credentials are updated, this hint is very likely to 525 be the correct etag to use in the SIP-If-Match header in a SIP 526 PUBLISH request to update the current credentials. 528 etag-param = "etag" EQUAL token 530 8.3 SUBSCRIBE Bodies 532 This package does not define any SUBSCRIBE bodies. 534 8.4 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 8.5 NOTIFY Bodies 545 The NOTIFY MUST contain a multipart/mixed (see [14]) body that 546 contains both an application/pkix-cert body with the certificate and 547 an application/pkcs8 body that has the associated private key 548 information for the certificate. The Content-Disposition MUST be set 549 to "signal" as defined in [16]. 551 A future extension MAY define other NOTIFY bodies. If no "Accept" 552 header is present in the SUBSCRIBE, the body type defined in this 553 document MUST be assumed. 555 The application/pkix-cert body is a DER encoded X.509v3 certificate 556 [10]. The application/pkcs8 body contains a DER-encoded PKCS#8 [1] 557 object that contains the private key. The PKCS#8 objects MUST be of 558 type PrivateKeyInfo. The integrity and confidentiality of the PKCS#8 559 objects is provided by the TLS transport. The transport encoding of 560 all the MIME bodies is binary. 562 8.6 Subscriber Generation of SUBSCRIBE Requests 564 A Subscriber User Agent will subscribe to its credential information 565 for a period of hours or days and will automatically attempt to re- 566 subscribe before the subscription has completely expired. 568 The Subscriber SHOULD subscribe to its credentials whenever a new 569 user becomes associated with the device (a new login). The 570 subscriber SHOULD also renew its subscription immediately after a 571 reboot, or when the subscriber's network connectivity has just been 572 re-established. 574 The UA needs to authenticate with the credential service for these 575 operations. The UA MUST use TLS to connect to the server. The UA 576 may be configured with a specific name for the credential service; 577 otherwise normal SIP routing is used. As described in RFC 3261, the 578 TLS connection needs to present a certificate that matches the 579 expected name of the server to which the connection was formed, so 580 that the UA knows it is talking to the correct server. Failing to do 581 this may result in the UA publishing its private key information to 582 an attacker. The credential service will authenticate the UA using 583 the usual SIP Digest mechanism, so the UA can expect to receive a SIP 584 challenge to the SUBSCRIBE or PUBLISH requests. 586 8.7 Notifier Processing of SUBSCRIBE Requests 588 When a credential service receives a SUBSCRIBE for a credential, the 589 credential service has to authenticate and authorize the UA and 590 validate that adequate transport security is being used. Only a UA 591 that can authenticate as being able to register as the AOR is 592 authorized to receive the credentials for that AOR. The credential 593 Service MUST digest challenge the UA to authenticate the UA and then 594 decide if it is authorized to receive the credentials. If 595 authentication is successful, the Notifier MAY limit the duration of 596 the subscription to an administrator-defined period of time. The 597 duration of the subscription MUST not be larger than the length of 598 time for which the certificate is still valid. The Expires header 599 should be set appropriately. 601 8.8 Notifier Generation of NOTIFY Requests 603 Once the UA has authenticated with the credential service and the 604 subscription is accepted, the credential service MUST immediately 605 send a Notify request. The Notifier SHOULD include the current etag 606 value in the "etag" Event package parameter in the NOTIFY request. 607 The Authentication Service is applied to this NOTIFY request in the 608 same way as the certificate subscriptions. If the credential is 609 revoked, the credential service MUST terminate any current 610 subscriptions and force the UA to re-authenticate by sending a NOTIFY 611 with its Subscription-State header set to "terminated" and a reason 612 parameter of "deactivated". (This causes a Subscriber to retry the 613 subscription immediately.) This is so that if a secret for 614 retrieving the credentials gets compromised, the rogue UA will not 615 continue to receive credentials after the compromised secret has been 616 changed. 618 Any time the credentials for this URI change, the credential service 619 MUST send a new NOTIFY to any active subscriptions with the new 620 credentials. 622 8.9 Generation of PUBLISH Requests 624 A user agent SHOULD be configurable to control whether it publishes 625 the credential for a user or just the user's certificate. 627 When publishing just a certificate, the body contains an application/ 628 pkix-cert. When publishing a credential, the body contains a 629 multipart/mixed containing both an application/pkix-cert and an 630 application/pkcs8 body. 632 When the UA sends the PUBLISH [3] request, it needs to do the 633 following: 634 o The Expires header field value in the PUBLISH request SHOULD be 635 set to match the time for which the certificate is valid. 636 o If the certificate includes Basic Constraints, it SHOULD set the 637 CA flag to false. 638 o The PUBLISH request SHOULD include a SIP-If-Match header field 639 with the previous etag from the subscription. This prevents 640 multiple User Agents for the same AOR from publishing conflicting 641 credentials. Note that UAs replace credentials that are about to 642 expire at a random time (described in Section 5), reducing the 643 chance of publishing conflicting credentials even without using 644 the etag. 646 8.10 Notifier Processing of PUBLISH Requests 648 When the credential service receives a PUBLISH to update credentials, 649 it MUST authenticate and authorize this request the same way as for 650 subscriptions for credentials. If the authorization succeeds, then 651 the credential service MUST perform the following check on the the 652 certificate: 653 o One of the names in the SubjectAltName of the certificate matches 654 the authorized user making the request. 655 o The notBefore validity time MUST NOT be in the future. 656 o The notAfter validity time MUST be in the future. 657 o If an CA Basic Constraint is set in the certificate, it is set to 658 false. 659 If all of these succeed, the credential service updates the 660 credential for this URI, processes all the active certificates and 661 credential subscriptions to this URI, and generates a NOTIFY request 662 with the new credential or certificate. 664 If the Subscriber submits a PUBLISH request with no body, this 665 revokes the current credentials and causes all subscriptions to the 666 credential package to be deactivated as described in the previous 667 section. (Note that subscriptions to the certificate package are NOT 668 terminated; each subscriber to the certificate package receives a 669 notification with an empty body.) 671 8.11 Subscriber Processing of NOTIFY Requests 673 When the UA receives a valid NOTIFY request, it should replace its 674 existing credentials with the new received ones. If the UA cannot 675 decrypt the PKCS#8 object, it MUST send a 437 (Unsupported 676 Certificate) response. Later if the user provides a new password 677 phrase for the private key, the UA can subscribe to the credentials 678 again and attempt to decrypt with the new password phrase. 680 8.12 Handling of Forked Requests 682 This event package does not permit forked requests. 684 8.13 Rate of Notifications 686 Notifiers SHOULD NOT generate NOTIFY requests more frequently than 687 once per minute. 689 8.14 State Agents and Lists 691 Implementers MUST NOT implement state agents for this event type. 692 Likewise, implementations MUST NOT use the event list extension [19] 693 with this event type. 695 8.15 Behavior of a Proxy Server 697 The behavior is identical to behavior described for certificate 698 subscriptions described in Section 7.13. 700 9. Examples 702 In all these examples, large parts of the messages are omitted to 703 highlight what is relevant to this draft. The lines in the examples 704 that are prefixed by $ represent encrypted blocks of data. 706 9.1 Encrypted Page Mode IM Message 708 In this example, Alice sends Bob an encrypted page mode instant 709 message. Alice does not already have Bob's public key from previous 710 communications, so she fetches Bob's public key from Bob's credential 711 service: 713 SUBSCRIBE sip:bob@biloxi.example.com SIP/2.0 714 ... 715 Event: certificate 717 The credential service responds with the certificate in a NOTIFY. 719 NOTIFY alice@atlanta.example.com SIP/2.0 720 Subscription-State: active; expires=7200 721 .... 722 From: ;tag=1234 723 Identity: "NJguAbpmYXjnlxFmlOkumMI+MZXjB2iV/NW5xsFQqzD/p4yiovrJBqhd3T 724 ZkegnsmoHryzk9gTBH7Gj/erixEFIf82o3Anmb+CIbrgdl03gGaD6ICvkp 725 VqoMXZZjdvSpycyHOhh1cmUx3b9Vr3pZuEh+cB01pbMQ8B1ch++iMjw=" 726 Identity-Info: ;alg=rsa-sha1 727 .... 728 Event: certificate 729 Content-Type: application/pkix-cert 730 Content-Disposition: signal 732 < certificate data > 734 Next, Alice sends a SIP MESSAGE message to Bob and can encrypt the 735 body using Bob's public key as shown below. Although outside the 736 scope of this document, it is worth noting that instant messages 737 often have common plain text like "Hi", so that setting up symmetric 738 keys for extended session mode IM conversations will likely increase 739 efficiency, as well as reducing the likelihood of compromising the 740 asymmetric key in the certificate. 742 MESSAGE sip:bob@biloxi.example.com SIP/2.0 743 ... 744 Content-Type: application/pkcs7-mime 745 Content-Disposition: render 747 $ Content-Type: text/plain 748 $ 749 $ < encrypted version of "Hello" > 751 9.2 Setting and Retrieving UA Credentials 753 When Alice's UA wishes to publish Alice's public and private keys to 754 the credential service, it sends a PUBLISH request like the one 755 below. This must be sent over a TLS connection in which the other 756 end of the connection presents a certificate that matches the 757 credential service for Alice and digest challenges the request to 758 authenticate her. 760 PUBLISH sips:alice@atlanta.example.com SIP/2.0 761 ... 762 Content-Type: multipart/mixed;boundary=boundary 763 Content-Disposition: signal 765 --boundary 766 Content-ID: 123 767 Content-Type: application/pkix-cert 769 < Public certificate for Alice > 770 --boundary 771 Content-ID: 456 772 Content-Type: application/pkcs8 774 < Private Key for Alice > 775 --boundary 777 If one of Alice's UAs subscribes to the credential event, the UA will 778 be digest challenged, and the NOTIFY will include a body similar to 779 the one in the PUBLISH section above. 781 10. Security Considerations 783 The high level message flow from a security point of view is 784 summarized in the following figure. The 200 responses are removed 785 from the figure as they do not have much to do with the overall 786 security. 788 Alice Server Bob UA 789 | | TLS Handshake | 1) Client authC/Z server 790 | |<---------------->| 791 | | PUBLISH | 2) Client sends request 792 | |<-----------------| (write credential) 793 | | Digest Challenge | 3) Server challenges client 794 | |----------------->| 795 | | PUBLISH + Digest | 4) Server authC/Z client 796 | |<-----------------| 797 | | time... | 798 | | | 799 | | TLS Handshake | 5) Client authC/Z server 800 | |<---------------->| 801 | | SUBSCRIBE | 6) Client sends request 802 | |<-----------------| (read credential) 803 | | Digest Challenge | 7) Server challenges client 804 | |----------------->| 805 | | SUBSCRIBE+Digest | 8) Server authC/Z client 806 | |<-----------------| 807 | | NOTIFY | 9) Server returns credential 808 | |----------------->| 809 | | 810 | SUBSCRIBE | 10) Client requests certificate 811 |---------->| 812 | | 813 |NOTIFY+AUTH| 11) Server returns user's certificate and signs that 814 |<----------| it is valid using certificate for the domain 815 | | 817 When the UA, labeled Bob, first created a credential for Bob, it 818 would store this on the the credential server. The UA authenticated 819 the Server using the certificates from the TLS handshake. The Server 820 authenticated the UA using a digest style challenge with a shared 821 secret. 823 The UA, labeled Bob, wishes to request its credentials from the 824 server. First it forms a TLS connection to the Server, which 825 provides integrity and privacy protection and also authenticates the 826 server to Bob's UA. Next the UA requests its credentials using a 827 SUBSCRIBE request. The Server digest challenges this to authenticate 828 Bob's UA. The server and Bob's UA have a shared secret that is used 829 for this. If the authentication is successful, the server sends the 830 credentials to Bob's UA. The private key in the credentials may have 831 been encrypted using a shared secret that the server does not know. 833 A similar process would be used for Bob's UA to publish new 834 credentials to the server. The SUBSCRIBE request would change to a 835 PUBLISH request and there would not be an NOTIFY. When this 836 happened, all the other UAs that were subscribed to Bob's credentials 837 would receive a new NOTIFY with the new credentials. 839 Alice wishes to find Bob's certificate and sends a SUBSCRIBE to the 840 server. The server sends the response in NOTIFY. This does not need 841 to be sent over a privacy or integrity protected channel, as the 842 Authentication service described in [2] provides integrity protection 843 of this information and signs it with the certificate for the domain. 845 This whole scheme is highly dependent on trusting the operators of 846 the credential service and trusting that the credential service will 847 not be compromised. The security of all the users will be 848 compromised if the credential service is compromised. 850 Note: There has been significant discussion of the topic of 851 avoiding deployments in which the credential servers store the 852 private keys, even in some encrypted form that the credential 853 server does not know how to decrypt. Various schemes were 854 considered to avoid this but they all result in either moving the 855 problem to some other server, which does not seem to make the 856 problem any better, or having a different credential for each 857 device. For some deployments where each user has only one device 858 this is fine but for deployments with multiple devices, it would 859 require that when Alice went to contact Bob, Alice would have to 860 provide messages encrypted for all of Bob's devices. The sipping 861 working group did consider this architecture and decided it was 862 not appropriate due both to the information it revealed about the 863 devices and users and the amount of signaling required to make it 864 work. 866 This specification requires the TLS session to be used for SIP 867 communications to the credential service. As specified in RFC 3261, 868 TLS clients MUST check that the SubjectAltName of the certificate for 869 the server they connected to exactly matches the server they were 870 trying to connect to. Failing to use TLS or selecting a poor cipher 871 suite (such as NULL encryption) will result in credentials, including 872 private keys, being sent unencrypted over the network and will render 873 the whole system useless. Implementations really must use TLS or 874 there is no point in implementing any of this. 876 The correct checking of chained certificates as specified in TLS [11] 877 is critical for the client to authenticate the server. If the client 878 does not authenticate that it is talking to the correct credential 879 service, a man in the middle attack is possible. 881 10.1 Certificate Revocation 883 If a particular credential needs to be revoked, the new credential is 884 simply published to the credential service. Every device with a copy 885 of the old credential or certificate in its cache will have a 886 subscription and will rapidly (order of seconds) be notified and 887 replace its cache. Clients that are not subscribed will subscribe 888 when they next need to use the certificate and will get the new 889 certificate. 891 It is possible that an attacker could mount a DOS attack such that 892 the UA that had cached a certificate did not receive the NOTIFY with 893 its revocation. To protect against this attack, the UA needs to 894 limit how long it caches certificates. After this time, the UA would 895 invalidate the cached information even though no NOTIFY had ever been 896 received due to the attacker blocking it. 898 The duration of this cached information is in some ways similar to a 899 device deciding how often to check a CRL list. For many 900 applications, a default time of 1 day is suggested, but for some 901 applications it may be desirable to set the time to zero so that no 902 certificates are cached at all and the credential is checked for 903 validity every time the certificate is used. 905 10.2 Certificate Replacement 907 The UAs in the system replace the certificates close to the time that 908 the certificates would expire. If a UA has used the same key pair to 909 encrypt a very large volume of traffic, the UA MAY choose to replace 910 the credential with a new one before the normal expiration. 912 10.3 Trusting the Identity of a Certificate 914 When a UA wishes to discover the certificate for 915 sip:alice@example.com, the UA subscribes to the certificate for 916 alice@example.com and receives a certificate in the body of a SIP 917 NOTIFY request. The term original URI is used to describe the URI 918 that was in the To header field value of the SUBSCRIBE request. So 919 in this case the original URI would be sip:alice@example.com. 921 If the certificate is signed by a trusted CA, and one of the names in 922 the SubjectAltName matches the original URI, then this certificate 923 MAY be used but only for exactly the original URI and not for other 924 identities found in the SubjectAltName. Otherwise, there are several 925 steps the UA MUST perform before using this certificate. 926 o The From header in the NOTIFY request MUST match the original URI 927 that was subscribed to. 928 o The UA MUST check the Identity header as described in the Identity 929 [2] specification to validate that bodies have not been tampered 930 with and that an Authentication Service has validated this From 931 header. 933 o The UA MUST check the validity time of the certificate and stop 934 using the certificate if it is invalid. (Implementations are 935 reminded to verify both the notBefore and notAfter validity 936 times.) 937 o The certificate MAY have several names in the SubjectAltName but 938 the UA MUST only use this certificate when it needs the 939 certificate for the identity asserted by the Authentication 940 Service in the NOTIFY. This means that the certificate should 941 only be indexed in the certificate cache by the AOR that the 942 Authentication Service asserted and not by the value of all the 943 identities found in the SubjectAltName list. 944 These steps result in a chain of bindings that result in a trusted 945 binding between the original AOR that was subscribed to and a public 946 key. The original AOR is forced to match the From. The 947 Authentication Service validates that this request did come from the 948 identity claimed in the From header field value and that the bodies 949 in the request that cary the certificate have not been tampered with. 950 The certificate in the body contains the public key for the identity. 951 Only the UA that can authenticate as this AOR, or devices with access 952 to the private key of the domain, can tamper with this body. This 953 stops other users from being able to provide a false public key. 954 This chain of assertion from original URI, to From, to body, to 955 public key is critical to the security of the mechanism described in 956 this specification. If any of the steps above are not followed, this 957 chain of security will be broken and the system will 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 (2005). 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.