idnits 2.17.1 draft-ietf-sipcore-sec-flows-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 9, 2011) is 4824 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 1181 ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Informational K. Ono 5 Expires: August 13, 2011 Columbia University 6 R. Sparks 7 B. Hibbard, Ed. 8 Tekelec 9 February 9, 2011 11 Example call flows using Session Initiation Protocol (SIP) security 12 mechanisms 13 draft-ietf-sipcore-sec-flows-09 15 Abstract 17 This document shows example call flows demonstrating the use of 18 Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail 19 Extensions (S/MIME) in Session Initiation Protocol (SIP). It also 20 provides information that helps implementers build interoperable SIP 21 software. To help facilitate interoperability testing, it includes 22 certificates used in the example call flows and processes to create 23 certificates for testing. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on August 13, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4 62 2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8 63 2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10 64 3. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12 65 3.1. TLS with Server Authentication . . . . . . . . . . . . . . 12 66 3.2. MESSAGE Transaction Over TLS . . . . . . . . . . . . . . . 13 67 4. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 15 68 4.1. MESSAGE Request with Signed Body . . . . . . . . . . . . . 15 69 4.2. MESSAGE Request with Encrypted Body . . . . . . . . . . . 20 70 4.3. MESSAGE Request with Encrypted and Signed Body . . . . . . 22 71 5. Observed Interoperability Issues . . . . . . . . . . . . . . . 29 72 6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 31 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 74 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 75 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36 76 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 37 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 78 11.1. Normative References . . . . . . . . . . . . . . . . . . . 40 79 11.2. Informative References . . . . . . . . . . . . . . . . . . 41 80 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 43 81 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 44 82 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 48 83 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 51 84 B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 51 85 B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 58 86 B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 66 87 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 73 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 90 1. Introduction 92 This document is informational and is not normative on any aspect of 93 SIP. 95 SIP with TLS ([RFC5246]) implementations are becoming very common. 96 Several implementations of the S/MIME ([RFC5751]) portion of SIP 97 ([RFC3261]) are also becoming available. After several 98 interoperability events, it is clear that it is difficult to write 99 these systems without any test vectors or examples of "known good" 100 messages to test against. Furthermore, testing at the events is 101 often hindered due to the lack of a commonly trusted certificate 102 authority to sign the certificates used in the events. This document 103 addresses both of these issues by providing messages that give 104 detailed examples that implementers can use for comparison and that 105 can also be used for testing. In addition, this document provides a 106 common certificate and private key that can be used to set up a mock 107 Certificate Authority (CA) that can be used during the SIP 108 interoperability events. Certificate requests from the users will be 109 signed by the private key of the mock CA. The document also provides 110 some hints and clarifications for implementers. 112 A simple SIP call flow using SIPS URIs and TLS is shown in Section 3. 113 The certificates for the hosts used are shown in Section 2.2, and the 114 CA certificates used to sign these are shown in Section 2.1. 116 The text from Section 4.1 through Section 4.3 shows some simple SIP 117 call flows using S/MIME to sign and encrypt the body of the message. 118 The user certificates used in these examples are shown in 119 Section 2.3. These host certificates are signed with the same mock 120 CA private key. 122 Section 5 presents a partial list of items that implementers should 123 consider in order to implement systems that will interoperate. 125 Scripts and instructions to make certificates that can be used for 126 interoperability testing are presented in Appendix A, along with 127 methods for converting these to various formats. The certificates 128 used while creating the examples and test messages in this document 129 are made available in Appendix B. 131 Binary copies of various messages in this document that can be used 132 for testing appear in Appendix C. 134 2. Certificates 136 2.1. CA Certificates 138 The certificate used by the CA to sign the other certificates is 139 shown below. This is a X509v3 certificate. Note that the X.509v3 140 Basic Constraints in the certificate allows it to be used as a CA, 141 certificate authority. This certificate is not used directly in the 142 TLS call flow; it is used only to verify user and host certificates. 144 Version: 3 (0x2) 145 Serial Number: 146 96:a3:84:17:4e:ef:8a:4c 147 Signature Algorithm: sha1WithRSAEncryption 148 Issuer: C=US, ST=California, L=San Jose, O=sipit, 149 OU=Sipit Test Certificate Authority 150 Validity 151 Not Before: Jan 27 18:36:05 2011 GMT 152 Not After : Jan 3 18:36:05 2111 GMT 153 Subject: C=US, ST=California, L=San Jose, O=sipit, 154 OU=Sipit Test Certificate Authority 155 Subject Public Key Info: 156 Public Key Algorithm: rsaEncryption 157 RSA Public Key: (2048 bit) 158 Modulus (2048 bit): 159 00:ab:1f:91:61:f1:1c:c5:cd:a6:7b:16:9b:b7:14: 160 79:e4:30:9e:98:d0:ec:07:b7:bd:77:d7:d1:f5:5b: 161 2c:e2:ee:e6:b1:b0:f0:85:fa:a5:bc:cb:cc:cf:69: 162 2c:4f:fc:50:ef:9d:31:2b:c0:59:ea:fb:64:6f:1f: 163 55:a7:3d:fd:70:d2:56:db:14:99:17:92:70:ac:26: 164 f8:34:41:70:d9:c0:03:91:6a:ba:d1:11:8f:ac:12: 165 31:de:b9:19:70:8d:5d:a7:7d:8b:19:cc:40:3f:ae: 166 ff:de:1f:db:94:b3:46:77:6c:ae:ae:ff:3e:d6:84: 167 5b:c2:de:0b:26:65:d0:91:c7:70:4b:c7:0a:4a:bf: 168 c7:97:04:dd:ba:58:47:cb:e0:2b:23:76:87:65:c5: 169 55:34:10:ab:27:1f:1c:f8:30:3d:b0:9b:ca:a2:81: 170 72:4c:bd:60:fe:f7:21:fe:0b:db:0b:db:e9:5b:01: 171 36:d4:28:15:6b:79:eb:d0:91:1b:21:59:b8:0e:aa: 172 bf:d5:b1:6c:70:37:a3:3f:a5:7d:0e:95:46:f6:f6: 173 58:67:83:75:42:37:18:0b:a4:41:39:b2:2f:6c:80: 174 2c:78:ec:a5:0f:be:9c:10:f8:c0:0b:0d:73:99:9e: 175 0d:d7:97:50:cb:cc:45:34:23:49:41:85:22:24:ad: 176 29:c3 177 Exponent: 65537 (0x10001) 178 X509v3 extensions: 179 X509v3 Subject Key Identifier: 180 95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 181 X509v3 Authority Key Identifier: 183 95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 185 X509v3 Basic Constraints: 186 CA:TRUE 187 Signature Algorithm: sha1WithRSAEncryption 188 06:5f:9e:ae:a0:9a:bc:b5:b9:5b:7e:97:33:cc:df:63:98:98: 189 94:cb:0d:66:a9:83:e8:aa:58:2a:59:a1:9e:47:31:a6:af:5c: 190 3f:a2:25:86:f8:df:05:92:b7:db:69:a1:69:72:87:66:c5:ab: 191 35:89:01:37:19:c9:74:eb:09:d1:3f:88:7b:24:13:42:ca:2d: 192 fb:45:e6:cc:4b:f8:21:78:f3:f5:97:ec:09:92:24:a2:f0:e6: 193 94:8d:97:4a:00:94:00:bd:25:b8:17:2c:52:53:5d:cc:5c:48: 194 a4:a1:1d:2d:f6:50:55:13:a4:d3:b2:a2:f4:f1:b9:6d:48:5e: 195 5c:f3:de:e0:fc:59:09:a1:d9:14:61:65:bf:d8:3f:b9:ba:2e: 196 7c:ed:5c:24:9b:6b:ca:aa:5f:f1:c1:1e:b0:a8:da:82:0f:fb: 197 4c:71:3b:4d:7b:38:c8:e3:8a:2a:19:34:44:26:0b:ea:f0:47: 198 38:46:28:65:04:e2:01:52:dd:ec:3d:e5:f5:53:74:77:74:75: 199 6d:c6:d9:c2:0a:ac:3b:b8:98:5c:55:53:34:74:52:a8:26:b1: 200 2f:30:22:d0:8b:b7:f3:a0:dd:68:07:33:d5:ae:b7:81:b2:94: 201 58:72:4e:7c:c6:72:2f:bd:6c:69:fb:b5:17:a8:2a:8d:d7:2c: 202 91:06:c8:0c 204 The certificate content shown above and throughout this document was 205 rendered by the OpenSSL "x509" tool. These dumps are included only 206 as informative examples. Output may vary among future revisions of 207 the tool. At the time of this document's publication, there were 208 some irregularities in the presentation of Distinguished Names (DN). 209 In particular, note that in the "Issuer" and "Subject" fields, it 210 appears the intent is to present DNs in Lightweight Directory Access 211 Protocol (LDAP) format. If this was intended, the spaces should have 212 been omitted after the delimiting commas, and the elements should 213 have been presented in order of most-specific to least-specific. 214 Please refer to Appendix A of [RFC4514]. Using the "Issuer" DN from 215 above as an example and following guidelines in [RFC4514], it should 216 have instead appeared as: 218 Issuer: OU=Sipit Test Certificate Authority,O=sipit,L=San Jose, 219 ST=California,C=US 221 The ASN.1 parse of the CA certificate is shown below. 223 0:l= 949 cons: SEQUENCE 224 4:l= 669 cons: SEQUENCE 225 8:l= 3 cons: cont [ 0 ] 226 10:l= 1 prim: INTEGER :02 227 13:l= 9 prim: INTEGER :96A384174EEF8A4C 228 24:l= 13 cons: SEQUENCE 229 26:l= 9 prim: OBJECT :sha1WithRSAEncryption 230 37:l= 0 prim: NULL 231 39:l= 112 cons: SEQUENCE 232 41:l= 11 cons: SET 233 43:l= 9 cons: SEQUENCE 234 45:l= 3 prim: OBJECT :countryName 235 50:l= 2 prim: PRINTABLESTRING :US 236 54:l= 19 cons: SET 237 56:l= 17 cons: SEQUENCE 238 58:l= 3 prim: OBJECT :stateOrProvinceName 239 63:l= 10 prim: UTF8STRING 240 43 61 6c 69 66 6f 72 6e-69 61 California 241 75:l= 17 cons: SET 242 77:l= 15 cons: SEQUENCE 243 79:l= 3 prim: OBJECT :localityName 244 84:l= 8 prim: UTF8STRING 245 53 61 6e 20 4a 6f 73 65- San Jose 246 94:l= 14 cons: SET 247 96:l= 12 cons: SEQUENCE 248 98:l= 3 prim: OBJECT :organizationName 249 103:l= 5 prim: UTF8STRING 250 73 69 70 69 74 sipit 251 110:l= 41 cons: SET 252 112:l= 39 cons: SEQUENCE 253 114:l= 3 prim: OBJECT :organizationalUnitName 254 119:l= 32 prim: UTF8STRING 255 53 69 70 69 74 20 54 65-73 74 20 43 65 72 74 69 Sipit Test Certi 256 66 69 63 61 74 65 20 41-75 74 68 6f 72 69 74 79 ficate Authority 257 153:l= 32 cons: SEQUENCE 258 155:l= 13 prim: UTCTIME :110127183605Z 259 170:l= 15 prim: GENERALIZEDTIME :21110103183605Z 260 187:l= 112 cons: SEQUENCE 261 189:l= 11 cons: SET 262 191:l= 9 cons: SEQUENCE 263 193:l= 3 prim: OBJECT :countryName 264 198:l= 2 prim: PRINTABLESTRING :US 265 202:l= 19 cons: SET 266 204:l= 17 cons: SEQUENCE 267 206:l= 3 prim: OBJECT :stateOrProvinceName 268 211:l= 10 prim: UTF8STRING 269 43 61 6c 69 66 6f 72 6e-69 61 California 270 223:l= 17 cons: SET 271 225:l= 15 cons: SEQUENCE 272 227:l= 3 prim: OBJECT :localityName 273 232:l= 8 prim: UTF8STRING 274 53 61 6e 20 4a 6f 73 65- San Jose 275 242:l= 14 cons: SET 276 244:l= 12 cons: SEQUENCE 277 246:l= 3 prim: OBJECT :organizationName 278 251:l= 5 prim: UTF8STRING 279 73 69 70 69 74 sipit 280 258:l= 41 cons: SET 281 260:l= 39 cons: SEQUENCE 282 262:l= 3 prim: OBJECT :organizationalUnitName 283 267:l= 32 prim: UTF8STRING 284 53 69 70 69 74 20 54 65-73 74 20 43 65 72 74 69 Sipit Test Certi 285 66 69 63 61 74 65 20 41-75 74 68 6f 72 69 74 79 ficate Authority 286 301:l= 290 cons: SEQUENCE 287 305:l= 13 cons: SEQUENCE 288 307:l= 9 prim: OBJECT :rsaEncryption 289 318:l= 0 prim: NULL 290 320:l= 271 prim: BIT STRING 291 00 30 82 01 0a 02 82 01-01 00 ab 1f 91 61 f1 1c .0...........a.. 292 c5 cd a6 7b 16 9b b7 14-79 e4 30 9e 98 d0 ec 07 ...{....y.0..... 293 b7 bd 77 d7 d1 f5 5b 2c-e2 ee e6 b1 b0 f0 85 fa ..w...[,........ 294 a5 bc cb cc cf 69 2c 4f-fc 50 ef 9d 31 2b c0 59 .....i,O.P..1+.Y 295 ea fb 64 6f 1f 55 a7 3d-fd 70 d2 56 db 14 99 17 ..do.U.=.p.V.... 296 92 70 ac 26 f8 34 41 70-d9 c0 03 91 6a ba d1 11 .p.&.4Ap....j... 297 8f ac 12 31 de b9 19 70-8d 5d a7 7d 8b 19 cc 40 ...1...p.].}...@ 298 3f ae ff de 1f db 94 b3-46 77 6c ae ae ff 3e d6 ?.......Fwl...>. 299 84 5b c2 de 0b 26 65 d0-91 c7 70 4b c7 0a 4a bf .[...&e...pK..J. 300 c7 97 04 dd ba 58 47 cb-e0 2b 23 76 87 65 c5 55 .....XG..+#v.e.U 301 34 10 ab 27 1f 1c f8 30-3d b0 9b ca a2 81 72 4c 4..'...0=.....rL 302 bd 60 fe f7 21 fe 0b db-0b db e9 5b 01 36 d4 28 .`..!......[.6.( 303 15 6b 79 eb d0 91 1b 21-59 b8 0e aa bf d5 b1 6c .ky....!Y......l 304 70 37 a3 3f a5 7d 0e 95-46 f6 f6 58 67 83 75 42 p7.?.}..F..Xg.uB 305 37 18 0b a4 41 39 b2 2f-6c 80 2c 78 ec a5 0f be 7...A9./l.,x.... 306 9c 10 f8 c0 0b 0d 73 99-9e 0d d7 97 50 cb cc 45 ......s.....P..E 307 34 23 49 41 85 22 24 ad-29 c3 02 03 01 00 01 4#IA."$.)...... 308 595:l= 80 cons: cont [ 3 ] 309 597:l= 78 cons: SEQUENCE 310 599:l= 29 cons: SEQUENCE 311 601:l= 3 prim: OBJECT :X509v3 Subject Key Identifier 312 606:l= 22 prim: OCTET STRING 313 04 14 95 45 7e 5f 2b ea-65 98 12 91 04 f3 63 c7 ...E~_+.e.....c. 314 68 9a 58 16 77 27 h.X.w' 315 630:l= 31 cons: SEQUENCE 316 632:l= 3 prim: OBJECT :X509v3 Authority Key Identifier 317 637:l= 24 prim: OCTET STRING 318 30 16 80 14 95 45 7e 5f-2b ea 65 98 12 91 04 f3 0....E~_+.e..... 319 63 c7 68 9a 58 16 77 27- c.h.X.w' 320 663:l= 12 cons: SEQUENCE 321 665:l= 3 prim: OBJECT :X509v3 Basic Constraints 322 670:l= 5 prim: OCTET STRING 323 30 03 01 01 ff 0.... 324 677:l= 13 cons: SEQUENCE 325 679:l= 9 prim: OBJECT :sha1WithRSAEncryption 326 690:l= 0 prim: NULL 327 692:l= 257 prim: BIT STRING 328 00 06 5f 9e ae a0 9a bc-b5 b9 5b 7e 97 33 cc df .._.......[~.3.. 329 63 98 98 94 cb 0d 66 a9-83 e8 aa 58 2a 59 a1 9e c.....f....X*Y.. 330 47 31 a6 af 5c 3f a2 25-86 f8 df 05 92 b7 db 69 G1..\?.%.......i 331 a1 69 72 87 66 c5 ab 35-89 01 37 19 c9 74 eb 09 .ir.f..5..7..t.. 332 d1 3f 88 7b 24 13 42 ca-2d fb 45 e6 cc 4b f8 21 .?.{$.B.-.E..K.! 333 78 f3 f5 97 ec 09 92 24-a2 f0 e6 94 8d 97 4a 00 x......$......J. 334 94 00 bd 25 b8 17 2c 52-53 5d cc 5c 48 a4 a1 1d ...%..,RS].\H... 335 2d f6 50 55 13 a4 d3 b2-a2 f4 f1 b9 6d 48 5e 5c -.PU........mH^\ 336 f3 de e0 fc 59 09 a1 d9-14 61 65 bf d8 3f b9 ba ....Y....ae..?.. 337 2e 7c ed 5c 24 9b 6b ca-aa 5f f1 c1 1e b0 a8 da .|.\$.k.._...... 338 82 0f fb 4c 71 3b 4d 7b-38 c8 e3 8a 2a 19 34 44 ...Lq;M{8...*.4D 339 26 0b ea f0 47 38 46 28-65 04 e2 01 52 dd ec 3d &...G8F(e...R..= 340 e5 f5 53 74 77 74 75 6d-c6 d9 c2 0a ac 3b b8 98 ..Stwtum.....;.. 341 5c 55 53 34 74 52 a8 26-b1 2f 30 22 d0 8b b7 f3 \US4tR.&./0".... 342 a0 dd 68 07 33 d5 ae b7-81 b2 94 58 72 4e 7c c6 ..h.3......XrN|. 343 72 2f bd 6c 69 fb b5 17-a8 2a 8d d7 2c 91 06 c8 r/.li....*..,... 344 0c . 346 2.2. Host Certificates 348 The certificate for the host example.com is shown below. Note that 349 the Subject Alternative Name is set to example.com and is a DNS type. 350 The certificates for the other hosts are shown in Appendix B. 352 Version: 3 (0x2) 353 Serial Number: 354 96:a3:84:17:4e:ef:8a:4f 355 Signature Algorithm: sha1WithRSAEncryption 356 Issuer: C=US, ST=California, L=San Jose, O=sipit, 357 OU=Sipit Test Certificate Authority 358 Validity 359 Not Before: Feb 7 19:32:17 2011 GMT 360 Not After : Jan 14 19:32:17 2111 GMT 361 Subject: C=US, ST=California, L=San Jose, O=sipit, CN=example.com 362 Subject Public Key Info: 363 Public Key Algorithm: rsaEncryption 364 RSA Public Key: (2048 bit) 365 Modulus (2048 bit): 366 00:dd:74:06:02:10:c2:e7:04:1f:bc:8c:b6:24:e7: 367 9b:94:a3:48:37:85:9e:6d:83:12:84:50:1a:8e:48: 368 b1:fa:86:8c:a7:80:b9:be:52:ec:a6:ca:63:47:84: 369 ad:f6:74:85:82:16:7e:4e:36:40:0a:74:2c:20:a9: 370 6a:0e:6a:7f:35:cf:70:71:63:7d:e9:43:67:81:4c: 371 ea:b5:1e:b7:4c:a3:35:08:7b:21:0d:2a:73:07:63: 372 9d:8d:75:bf:1f:d4:8e:e6:67:60:75:f7:ea:0a:7a: 374 6c:90:af:92:45:e0:62:05:9a:8a:10:98:dc:7c:54: 375 8b:e4:61:95:3b:04:fc:10:50:ef:80:45:ba:5e:84: 376 97:76:c1:20:25:c1:92:1d:89:0a:f7:55:62:64:fa: 377 e8:69:a2:62:4c:67:d3:08:d9:61:b5:3d:16:54:b6: 378 b7:44:8d:59:2b:90:d4:e9:fb:c7:7d:87:58:c3:12: 379 ac:33:78:00:50:ba:07:05:b3:b9:01:1a:63:55:6c: 380 e1:7a:ec:a3:07:ae:3b:02:83:a1:69:e0:c3:dc:2d: 381 61:e9:b2:e3:b3:71:c8:a6:cf:da:fb:3e:99:c7:e5: 382 71:b9:c9:17:d4:ed:bc:a0:47:54:09:8c:6e:6d:53: 383 9a:2c:c9:68:c6:6f:f1:3d:91:1a:24:43:77:7d:91: 384 69:4b 385 Exponent: 65537 (0x10001) 386 X509v3 extensions: 387 X509v3 Subject Alternative Name: 388 DNS:example.com, URI:sip:example.com 389 X509v3 Basic Constraints: 390 CA:FALSE 391 X509v3 Subject Key Identifier: 392 CC:06:59:5B:8B:5E:D6:0D:F2:05:4D:1B:68:54:1E:FC:F9:43:19:17 393 X509v3 Authority Key Identifier: 394 95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 396 X509v3 Key Usage: 397 Digital Signature, Non Repudiation, Key Encipherment 398 X509v3 Extended Key Usage: 399 TLS Web Server Authentication, 1.3.6.1.5.5.7.3.20 400 Signature Algorithm: sha1WithRSAEncryption 401 6a:9a:d1:db:00:4b:90:86:b0:53:ea:6f:30:31:89:1e:9b:09: 402 14:bd:6f:b9:02:aa:6f:58:ee:30:03:b8:a1:fd:b3:41:72:ff: 403 b3:0d:cb:76:a7:17:c6:57:38:06:13:e5:f3:e4:30:17:4d:f7: 404 97:b5:f3:74:e9:81:f8:f4:55:a3:0d:f5:82:38:c3:98:43:52: 405 1f:84:cd:1a:b4:a3:45:9f:3d:e2:31:fd:cb:a2:ad:ed:60:7d: 406 fa:d2:aa:49:2f:41:a9:80:01:bb:ed:b6:75:c9:97:69:7f:0c: 407 91:60:f1:c4:5a:36:e8:5c:ac:e1:a8:e7:9a:55:e5:e0:cd:01: 408 f4:de:93:f4:38:6c:c1:71:d2:fd:cd:1b:5d:25:eb:90:7b:31: 409 41:e7:37:0e:e5:c0:01:48:91:f7:34:dd:c6:1f:74:e6:34:34: 410 e6:cd:93:0f:3f:ce:94:ad:91:d9:e2:72:b1:9f:1d:d3:a5:7d: 411 5e:e2:a4:56:c5:b1:71:4d:10:0a:5d:a6:56:e6:57:1f:48:a5: 412 5c:75:67:ea:ab:35:3e:f6:b6:fa:c1:f3:8a:c1:80:71:32:18: 413 6c:33:b5:fa:16:5a:16:e1:a1:6c:19:67:f5:45:68:64:6f:b2: 414 31:dc:e3:5a:1a:b2:d4:87:89:96:fd:87:ba:38:4e:0a:19:07: 415 03:4b:9b:b1 417 The example host certificate above, as well as all the others 418 presented in this document, are signed directly by a root CA. These 419 certificate chains have a length equal to two: the root CA and the 420 host certificate. Non-root CAs exist and may also sign certificates. 422 The certificate chains presented by hosts with certificates signed by 423 non-root CAs will have a length greater than two. For more details 424 on how certificate chains are validated, see Sections 6.1 and 6.2 of 425 [RFC5280]. 427 2.3. User Certificates 429 User certificates are used by many applications to establish user 430 identity. The user certificate for fluffy@example.com is shown 431 below. Note that the Subject Alternative Name has a list of names 432 with different URL types such as a sip, im, or pres URL. This is 433 necessary for interoperating with a Common Profile for Instant 434 Messaging (CPIM) gateway. In this example, example.com is the domain 435 for fluffy. The message could be coming from any host in 436 *.example.com, and the AOR in the user certificate would still be the 437 same. The others are shown in Appendix B.1. These certificates make 438 use of the Extended Key Usage (EKU) extension discussed in [RFC5924]. 439 Note that the X509v3 Extended Key Usage attribute refers to the SIP 440 OID introduced in [RFC5924], which is 1.3.6.1.5.5.7.3.20 442 Version: 3 (0x2) 443 Serial Number: 444 96:a3:84:17:4e:ef:8a:4d 445 Signature Algorithm: sha1WithRSAEncryption 446 Issuer: C=US, ST=California, L=San Jose, O=sipit, 447 OU=Sipit Test Certificate Authority 448 Validity 449 Not Before: Feb 7 19:32:17 2011 GMT 450 Not After : Jan 14 19:32:17 2111 GMT 451 Subject: C=US, ST=California, L=San Jose, O=sipit, 452 CN=fluffy 453 Subject Public Key Info: 454 Public Key Algorithm: rsaEncryption 455 RSA Public Key: (2048 bit) 456 Modulus (2048 bit): 457 00:a3:2c:59:0c:e9:bc:e4:ec:d3:9e:fb:99:02:ec: 458 b1:36:3a:b7:d3:1d:4d:c3:3a:b6:ae:50:bd:5f:55: 459 08:77:8c:7e:a4:e9:f0:68:31:28:8f:23:32:56:19: 460 c3:22:97:a7:6d:fd:a7:22:2a:01:b5:af:61:bd:5f: 461 7e:c1:14:e5:98:29:b4:34:4e:38:8a:26:ee:0d:da: 462 db:27:b9:78:d6:ac:ac:04:78:32:98:c2:75:e7:6a: 463 b7:2d:b3:3c:e3:eb:97:a5:ef:8b:59:42:50:17:7b: 464 fe:a7:81:af:37:a7:e7:e3:1f:b0:8d:d0:72:2f:6c: 465 14:42:c6:01:68:e1:8f:fd:56:4d:7d:cf:16:dc:aa: 466 05:61:0b:0a:ca:ca:ec:51:ec:53:6e:3d:2b:00:80: 467 fe:35:1b:06:0a:61:13:88:0b:44:f3:cc:fd:2b:0e: 468 b4:a2:0b:a0:97:84:14:2e:ee:2b:e3:2f:c1:1a:9e: 469 86:9a:78:6a:a2:4c:57:93:e7:01:26:d3:56:0d:bd: 471 b0:2f:f8:da:c7:3c:01:dc:cb:2d:31:8c:6c:c6:5c: 472 b4:63:e8:b2:a2:40:11:bf:ad:f8:6d:12:01:97:1d: 473 47:f8:6a:15:8b:fb:27:96:73:44:46:34:d7:24:1c: 474 cf:56:8d:d4:be:d6:94:5b:f0:a6:67:e3:dd:cf:b4: 475 f2:d5 476 Exponent: 65537 (0x10001) 477 X509v3 extensions: 478 X509v3 Subject Alternative Name: 479 URI:sip:fluffy@example.com, URI:im:fluffy@example.com, 480 URI:pres:fluffy@example.com 481 X509v3 Basic Constraints: 482 CA:FALSE 483 X509v3 Subject Key Identifier: 484 85:97:09:B8:D3:55:37:24:8A:DC:DE:E3:91:72:E4:22:CF:98:87:52 485 X509v3 Authority Key Identifier: 486 95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27 488 X509v3 Key Usage: 489 Digital Signature, Non Repudiation, Key Encipherment 490 X509v3 Extended Key Usage: 491 E-mail Protection, 1.3.6.1.5.5.7.3.20 492 Signature Algorithm: sha1WithRSAEncryption 493 a8:a9:8f:d8:8a:0b:88:ed:ff:4f:bf:e5:cd:8f:9e:7b:b8:e6: 494 f2:2c:aa:e3:23:5b:9a:71:5e:fd:20:a3:dd:d9:d3:c1:f2:e8: 495 f0:be:77:db:33:cc:8a:7b:4f:91:2b:8d:d6:f7:14:c3:8d:e0: 496 60:d3:34:50:bc:be:67:22:cd:f5:74:7b:f4:9a:68:a2:52:2b: 497 81:2f:46:d3:09:9f:25:c3:20:e8:10:d5:ef:38:7b:d1:17:d4: 498 f1:d7:54:67:56:f1:13:cf:2f:fc:8b:83:fc:14:e7:01:82:59: 499 83:cc:b1:8d:f0:c7:da:4e:b1:dc:cc:54:cf:6c:3b:47:47:59: 500 87:d9:16:ec:af:af:e1:12:13:23:1e:0a:db:f5:b5:ff:5d:ab: 501 15:0e:e3:25:91:00:0e:90:db:d8:07:11:90:81:01:3a:48:a8: 502 aa:9e:b0:62:d3:36:f0:0c:b7:2f:a7:17:92:52:36:29:14:0a: 503 d6:65:86:67:73:74:6e:aa:3c:ee:47:38:1e:c8:6e:06:81:85: 504 1c:2e:f0:b6:04:7d:6c:38:db:81:9c:b8:07:e3:07:be:f5:2f: 505 09:68:63:04:6b:87:0e:36:b9:a1:a3:fb:c8:30:0c:a0:63:8d: 506 6d:ab:0a:f8:44:b0:78:19:1a:38:7e:fa:6a:a1:d4:4b:4b:75: 507 75:bf:6f:09 509 Versions of these certificates that do not make use of EKU are also 510 included in Appendix B.2 512 3. Callflow with Message Over TLS 514 3.1. TLS with Server Authentication 516 The flow below shows the edited SSLDump output of the host 517 example.com forming a TLS [RFC5246] connection to example.net. In 518 this example mutual authentication is not used. Note that the client 519 proposed three protocol suites including TLS_RSA_WITH_AES_128_CBC_SHA 520 defined in [RFC5246]. The certificate returned by the server 521 contains a Subject Alternative Name that is set to example.net. A 522 detailed discussion of TLS can be found in SSL and TLS [EKR-TLS]. 523 For more details on the SSLDump tool, see the SSLDump Manual 524 [ssldump-manpage]. 526 This example does not use the Server Extended Hello (see [RFC5246]). 528 New TCP connection #1: example.com(50738) <-> example.net(5061) 529 1 1 0.0004 (0.0004) C>SV3.1(101) Handshake 530 ClientHello 531 Version 3.1 532 random[32]= 533 4c 09 5b a7 66 77 eb 43 52 30 dd 98 4d 09 23 d3 534 ff 81 74 ab 04 69 bb 79 8c dc 59 cd c2 1f b7 ec 535 cipher suites 536 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 537 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 538 TLS_DHE_RSA_WITH_AES_256_SHA 539 TLS_RSA_WITH_AES_256_CBC_SHA 540 TLS_DSS_RSA_WITH_AES_256_SHA 541 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 542 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA 543 TLS_DHE_RSA_WITH_AES_128_CBC_SHA 544 TLS_RSA_WITH_AES_128_CBC_SHA 545 TLS_DHE_DSS_WITH_AES_128_CBC_SHA 546 TLS_ECDHE_RSA_WITH_DES_192_CBC3_SHA 547 TLS_ECDH_RSA_WITH_DES_192_CBC3_SHA 548 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 549 TLS_RSA_WITH_3DES_EDE_CBC_SHA 550 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA 551 TLS_ECDHE_RSA_WITH_RC4_128_SHA 552 TLS_ECDH_RSA_WITH_RC4_128_SHA 553 TLS_RSA_WITH_RC4_128_SHA 554 TLS_RSA_WITH_RC4_128_MD5 555 TLS_DHE_RSA_WITH_DES_CBC_SHA 556 TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA 557 TLS_RSA_WITH_DES_CBC_SHA 558 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA 559 TLS_DHE_DSS_WITH_DES_CBC_SHA 560 TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA 561 TLS_RSA_EXPORT_WITH_RC4_40_MD5 562 compression methods 563 NULL 564 1 2 0.0012 (0.0007) S>CV3.1(48) Handshake 565 ServerHello 566 Version 3.1 567 random[32]= 568 4c 09 5b a7 30 87 74 c7 16 98 24 d5 af 35 17 a7 569 ef c3 78 0c 94 d4 94 d2 7b a6 3f 40 04 25 f6 e0 570 session_id[0]= 572 cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA 573 compressionMethod NULL 574 1 3 0.0012 (0.0000) S>CV3.1(1858) Handshake 575 Certificate 576 1 4 0.0012 (0.0000) S>CV3.1(14) Handshake 577 CertificateRequest 578 certificate_types rsa_sign 579 certificate_types dss_sign 580 certificate_types unknown value 581 ServerHelloDone 582 1 5 0.0043 (0.0031) C>SV3.1(7) Handshake 583 Certificate 584 1 6 0.0043 (0.0000) C>SV3.1(262) Handshake 585 ClientKeyExchange 586 1 7 0.0043 (0.0000) C>SV3.1(1) ChangeCipherSpec 587 1 8 0.0043 (0.0000) C>SV3.1(48) Handshake 588 1 9 0.0129 (0.0085) S>CV3.1(170) Handshake 589 1 10 0.0129 (0.0000) S>CV3.1(1) ChangeCipherSpec 590 1 11 0.0129 (0.0000) S>CV3.1(48) Handshake 591 1 12 0.0134 (0.0005) C>SV3.1(32) application_data 592 1 13 0.0134 (0.0000) C>SV3.1(496) application_data 593 1 14 0.2150 (0.2016) S>CV3.1(32) application_data 594 1 15 0.2150 (0.0000) S>CV3.1(336) application_data 595 1 16 12.2304 (12.0154) S>CV3.1(32) Alert 596 1 12.2310 (0.0005) S>C TCP FIN 597 1 17 12.2321 (0.0011) C>SV3.1(32) Alert 599 3.2. MESSAGE Transaction Over TLS 601 Once the TLS session is set up, the following MESSAGE request (as 602 defined in [RFC3428] is sent from fluffy@example.com to 603 kumiko@example.net. Note that the URI has a SIPS URL and that the 604 VIA indicates that TLS was used. In order to format this document, 605 the convention from [RFC4475] is used to break long 606 lines. The actual message does not contain the line breaks contained 607 within those tags. 609 MESSAGE sips:kumiko@example.net:5061 SIP/2.0 610 611 Via: SIP/2.0/TLS 192.0.2.2:15001; 612 branch=z9hG4bK-d8754z-c785a077a9a8451b-1---d8754z-; 613 rport=50738 614 615 Max-Forwards: 70 616 To: 617 From: ;tag=1a93430b 618 Call-ID: OTZmMDE2OWNlYTVjNDkzYzBhMWRlMDU4NDExZmU4ZTQ. 619 CSeq: 4308 MESSAGE 620 621 Accept: multipart/signed, text/plain, application/pkcs7-mime, 622 application/sdp, multipart/alternative 623 624 Content-Type: text/plain 625 Content-Length: 6 627 Hello! 629 When a User Agent (UA) goes to send a message to example.com, the UA 630 can see if it already has a TLS connection to example.com and if it 631 does, it may send the message over this connection. A UA should have 632 some scheme for reusing connections as opening a new TLS connection 633 for every message results in awful performance. Implementers are 634 encouraged to read [RFC5923] and [RFC3263]. 636 The response is sent from example.net to example.com over the same 637 TLS connection. It is shown below. 639 SIP/2.0 200 OK 640 641 Via: SIP/2.0/TLS 192.0.2.2:15001; 642 branch=z9hG4bK-d8754z-c785a077a9a8451b-1---d8754z-; 643 rport=50738 644 645 To: ;tag=0d075510 646 From: ;tag=1a93430b 647 Call-ID: OTZmMDE2OWNlYTVjNDkzYzBhMWRlMDU4NDExZmU4ZTQ. 648 CSeq: 4308 MESSAGE 649 Content-Length: 0 651 4. Callflow with S/MIME-secured Message 653 4.1. MESSAGE Request with Signed Body 655 Below is an example of a signed message. The values on the Content- 656 Type line (multipart/signed) and on the Content-Disposition line have 657 been broken across lines to fit on the page, but they are not broken 658 across lines in actual implementations. 660 MESSAGE sip:kumiko@example.net SIP/2.0 661 662 Via: SIP/2.0/TCP 192.0.2.2:15001; 663 branch=z9hG4bK-d8754z-3a922b6dc0f0ff37-1---d8754z-; 664 rport=50739 665 666 Max-Forwards: 70 667 To: 668 From: ;tag=ef6bad5e 669 Call-ID: N2NiZjI0NjRjNDQ0MTY1NDRjNWNmMGU1MDA2MDRhYmI. 670 CSeq: 8473 MESSAGE 671 672 Accept: multipart/signed, text/plain, application/pkcs7-mime, 673 application/sdp, multipart/alternative 674 675 676 Content-Type: multipart/signed;boundary=3b515e121b43a911; 677 micalg=sha1;protocol="application/pkcs7-signature" 678 679 Content-Length: 774 681 --3b515e121b43a911 682 Content-Type: text/plain 683 Content-Transfer-Encoding: binary 685 Hello! 686 --3b515e121b43a911 687 Content-Type: application/pkcs7-signature;name=smime.p7s 688 689 Content-Disposition: attachment;handling=required; 690 filename=smime.p7s 691 692 Content-Transfer-Encoding: binary 694 ***************** 695 * BINARY BLOB 1 * 696 ***************** 697 --3b515e121b43a911-- 698 It is important to note that the signature ("BINARY BLOB 1") is 699 computed over the MIME headers and body, but excludes the multipart 700 boundary lines. The value on the Message-body line ends with CRLF. 701 The CRLF is included in the boundary and is not part of the signature 702 computation. To be clear, the signature is computed over data 703 starting with the "C" in the "Content-Type" and ending with the "!" 704 in the "Hello!". 706 Content-Type: text/plain 707 Content-Transfer-Encoding: binary 709 Hello! 711 Following is the ASN.1 parsing of encrypted contents referred to 712 above as "BINARY BLOB 1". Note that at address 30, the hash for the 713 signature is specified as SHA-1. Also note that the sender's 714 certificate is not attached as it is optional in [RFC5652]. 716 0 472: SEQUENCE { 717 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 718 15 457: [0] { 719 19 453: SEQUENCE { 720 23 1: INTEGER 1 721 26 11: SET { 722 28 9: SEQUENCE { 723 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 724 37 0: NULL 725 : } 726 : } 727 39 11: SEQUENCE { 728 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 729 : } 730 52 420: SET { 731 56 416: SEQUENCE { 732 60 1: INTEGER 1 733 63 125: SEQUENCE { 734 65 112: SEQUENCE { 735 67 11: SET { 736 69 9: SEQUENCE { 737 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 738 76 2: PrintableString 'US' 739 : } 740 : } 741 80 19: SET { 742 82 17: SEQUENCE { 743 84 3: OBJECT IDENTIFIER 744 : stateOrProvinceName (2 5 4 8) 745 89 10: UTF8String 'California' 746 : } 747 : } 748 101 17: SET { 749 103 15: SEQUENCE { 750 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 751 110 8: UTF8String 'San Jose' 752 : } 753 : } 754 120 14: SET { 755 122 12: SEQUENCE { 756 124 3: OBJECT IDENTIFIER 757 : organizationName (2 5 4 10) 758 129 5: UTF8String 'sipit' 759 : } 760 : } 761 136 41: SET { 762 138 39: SEQUENCE { 763 140 3: OBJECT IDENTIFIER 764 : organizationalUnitName (2 5 4 11) 765 145 32: UTF8String 'Sipit Test Certificate 766 Authority' 767 : } 768 : } 769 : } 770 179 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D 771 : } 772 190 9: SEQUENCE { 773 192 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 774 199 0: NULL 775 : } 776 201 13: SEQUENCE { 777 203 9: OBJECT IDENTIFIER 778 : rsaEncryption (1 2 840 113549 1 1 1) 779 214 0: NULL 780 : } 781 216 256: OCTET STRING 782 : 74 4D 21 39 D6 E2 E2 2C 30 5A AA BC 4E 60 8D 69 783 : A7 E5 79 50 1A B1 7D 4A D3 C1 03 9F 19 7D A2 76 784 : 97 B3 CE 30 CD 62 4B 96 20 35 DB C1 64 D9 33 92 785 : 96 CD 28 03 98 6E 2C 0C F6 8D 93 40 F2 88 DA 29 786 : AD 0B C2 0E F9 D3 6A 95 2C 79 6E C2 3D 62 E6 54 787 : A9 1B AC 66 DB 16 B7 44 6C 03 1B 71 9C EE C9 EC 788 : 4D 93 B1 CF F5 17 79 C5 C8 BA 2F A7 6C 4B DC CF 789 : 62 A3 F3 1A 1B 24 E4 40 66 3C 4F 87 86 BF 09 6A 790 : 7A 43 60 2B FC D8 3D 2B 57 17 CB 81 03 2A 56 69 791 : 81 82 FA 78 DE D2 3A 2F FA A3 C5 EA 8B E8 0C 36 792 : 1B BC DC FD 1B 8C 2E 0F 01 AF D9 E1 04 0E 4E 50 793 : 94 75 7C BD D9 0B DD AA FA 36 E3 EC E4 A5 35 46 794 : BE A2 97 1D AD BA 44 54 3A ED 94 DA 76 4A 51 BA 795 : A4 7D 7A 62 BF 2A 2F F2 5C 5A FE CA E6 B9 DC 5D 796 : EA 26 F2 35 17 19 20 CE 97 96 4E 72 9C 72 FD 1F 797 : 68 C1 6A 5C 86 42 F2 ED F2 70 65 4C C7 44 C5 7C 798 : } 799 : } 800 : } 801 : } 802 : } 804 SHA-1 parameters may be omitted entirely, instead of being set to 805 NULL, as mentioned in [RFC3370]. The above dump of Blob 1 has SHA-1 806 parameters set to NULL. Below are the same contents signed with the 807 same key, but omitting the NULL according to [RFC3370]. This is the 808 preferred encoding. This is covered in greater detail in Section 5. 810 0 468: SEQUENCE { 811 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 812 15 453: [0] { 813 19 449: SEQUENCE { 814 23 1: INTEGER 1 815 26 9: SET { 816 28 7: SEQUENCE { 817 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 818 : } 819 : } 820 37 11: SEQUENCE { 821 39 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 822 : } 823 50 418: SET { 824 54 414: SEQUENCE { 825 58 1: INTEGER 1 826 61 125: SEQUENCE { 827 63 112: SEQUENCE { 828 65 11: SET { 829 67 9: SEQUENCE { 830 69 3: OBJECT IDENTIFIER countryName (2 5 4 6) 831 74 2: PrintableString 'US' 832 : } 833 : } 834 78 19: SET { 835 80 17: SEQUENCE { 836 82 3: OBJECT IDENTIFIER 837 : stateOrProvinceName (2 5 4 8) 838 87 10: UTF8String 'California' 839 : } 840 : } 842 99 17: SET { 843 101 15: SEQUENCE { 844 103 3: OBJECT IDENTIFIER localityName (2 5 4 7) 845 108 8: UTF8String 'San Jose' 846 : } 847 : } 848 118 14: SET { 849 120 12: SEQUENCE { 850 122 3: OBJECT IDENTIFIER 851 : organizationName (2 5 4 10) 852 127 5: UTF8String 'sipit' 853 : } 854 : } 855 134 41: SET { 856 136 39: SEQUENCE { 857 138 3: OBJECT IDENTIFIER 858 : organizationalUnitName (2 5 4 11) 859 143 32: UTF8String 'Sipit Test Certificate 860 Authority' 861 : } 862 : } 863 : } 864 177 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D 865 : } 866 188 7: SEQUENCE { 867 190 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 868 : } 869 197 13: SEQUENCE { 870 199 9: OBJECT IDENTIFIER 871 : rsaEncryption (1 2 840 113549 1 1 1) 872 210 0: NULL 873 : } 874 212 256: OCTET STRING 875 : 74 4D 21 39 D6 E2 E2 2C 30 5A AA BC 4E 60 8D 69 876 : A7 E5 79 50 1A B1 7D 4A D3 C1 03 9F 19 7D A2 76 877 : 97 B3 CE 30 CD 62 4B 96 20 35 DB C1 64 D9 33 92 878 : 96 CD 28 03 98 6E 2C 0C F6 8D 93 40 F2 88 DA 29 879 : AD 0B C2 0E F9 D3 6A 95 2C 79 6E C2 3D 62 E6 54 880 : A9 1B AC 66 DB 16 B7 44 6C 03 1B 71 9C EE C9 EC 881 : 4D 93 B1 CF F5 17 79 C5 C8 BA 2F A7 6C 4B DC CF 882 : 62 A3 F3 1A 1B 24 E4 40 66 3C 4F 87 86 BF 09 6A 883 : 7A 43 60 2B FC D8 3D 2B 57 17 CB 81 03 2A 56 69 884 : 81 82 FA 78 DE D2 3A 2F FA A3 C5 EA 8B E8 0C 36 885 : 1B BC DC FD 1B 8C 2E 0F 01 AF D9 E1 04 0E 4E 50 886 : 94 75 7C BD D9 0B DD AA FA 36 E3 EC E4 A5 35 46 887 : BE A2 97 1D AD BA 44 54 3A ED 94 DA 76 4A 51 BA 888 : A4 7D 7A 62 BF 2A 2F F2 5C 5A FE CA E6 B9 DC 5D 889 : EA 26 F2 35 17 19 20 CE 97 96 4E 72 9C 72 FD 1F 890 : 68 C1 6A 5C 86 42 F2 ED F2 70 65 4C C7 44 C5 7C 891 : } 892 : } 893 : } 894 : } 895 : } 897 4.2. MESSAGE Request with Encrypted Body 899 Below is an example of an encrypted text/plain message that says 900 "Hello!". The binary encrypted contents have been replaced with the 901 block "BINARY BLOB 2". 903 MESSAGE sip:kumiko@example.net SIP/2.0 904 905 Via: SIP/2.0/TCP 192.0.2.2:15001; 906 branch=z9hG4bK-d8754z-c276232b541dd527-1---d8754z-; 907 rport=50741 908 909 Max-Forwards: 70 910 To: 911 From: ;tag=7a2e3025 912 Call-ID: MDYyMDhhODA3NWE2ZjEyYzAwOTZlMjExNWI2ZWQwZGM. 913 CSeq: 3260 MESSAGE 914 915 Accept: multipart/signed, text/plain, application/pkcs7-mime, 916 application/sdp, multipart/alternative 917 918 919 Content-Disposition: attachment;handling=required; 920 filename=smime.p7 921 922 Content-Transfer-Encoding: binary 923 924 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 925 name=smime.p7m 926 927 Content-Length: 565 929 ***************** 930 * BINARY BLOB 2 * 931 ***************** 933 Following is the ASN.1 parsing of "BINARY BLOB 2". Note that at 934 address 454, the encryption is set to aes128-CBC. 936 0 561: SEQUENCE { 937 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 938 15 546: [0] { 939 19 542: SEQUENCE { 940 23 1: INTEGER 0 941 26 409: SET { 942 30 405: SEQUENCE { 943 34 1: INTEGER 0 944 37 125: SEQUENCE { 945 39 112: SEQUENCE { 946 41 11: SET { 947 43 9: SEQUENCE { 948 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 949 50 2: PrintableString 'US' 950 : } 951 : } 952 54 19: SET { 953 56 17: SEQUENCE { 954 58 3: OBJECT IDENTIFIER 955 : stateOrProvinceName (2 5 4 8) 956 63 10: UTF8String 'California' 957 : } 958 : } 959 75 17: SET { 960 77 15: SEQUENCE { 961 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 962 84 8: UTF8String 'San Jose' 963 : } 964 : } 965 94 14: SET { 966 96 12: SEQUENCE { 967 98 3: OBJECT IDENTIFIER 968 : organizationName (2 5 4 10) 969 103 5: UTF8String 'sipit' 970 : } 971 : } 972 110 41: SET { 973 112 39: SEQUENCE { 974 114 3: OBJECT IDENTIFIER 975 : organizationalUnitName (2 5 4 11) 976 119 32: UTF8String 'Sipit Test Certificate 977 Authority' 978 : } 979 : } 980 : } 981 153 9: INTEGER 00 96 A3 84 17 4E EF 8A 4E 982 : } 983 164 13: SEQUENCE { 984 166 9: OBJECT IDENTIFIER 985 : rsaEncryption (1 2 840 113549 1 1 1) 986 177 0: NULL 987 : } 988 179 256: OCTET STRING 989 : B9 12 8F 32 AB 4A E2 38 C1 E0 53 69 88 D6 25 E7 990 : 40 03 B1 DE 79 21 A3 E8 23 5A 1B CB FB 58 F4 97 991 : 48 A7 C8 F0 3D DF 41 A3 5A 90 32 70 82 FA B0 DE 992 : D8 94 7C 6C 2E 01 FE 33 BD 62 CB 07 4F 58 DE 6F 993 : EA 3F EF B4 FB 46 72 58 9A 88 A0 85 BC 23 D7 C8 994 : 09 0B 90 8D 4A 5F 3F 96 7C AC D4 E2 19 E8 02 B6 995 : 0E F3 0D F2 91 4A 67 A9 EE 51 6A 97 D7 86 6D EC 996 : 78 6E C6 E0 83 7C E1 00 1F 5A 40 59 60 0C D7 EB 997 : A3 FB 04 B3 C9 A5 EB 79 ED B3 56 F8 F6 51 B2 5E 998 : 58 E2 D8 17 28 33 A6 B8 35 8C 0E 14 7F 90 D0 7B 999 : 03 00 6C 3D 81 29 F5 D7 E5 AC 75 5E E0 F0 DD E3 1000 : 3E B2 06 97 D6 49 A9 CB 38 08 F1 84 05 F5 C0 BC 1001 : 55 A6 D4 C9 D8 FD A4 AC 40 9F 9D 51 5B F7 3A C3 1002 : C3 CD 3A E7 6D 21 05 D0 50 75 4F 14 D8 77 76 C6 1003 : 13 A6 48 12 7B 25 CC 22 5D 73 BD 40 E4 15 02 A2 1004 : 39 4A CB D9 55 08 A4 EE 4E 8A 5E BA C4 4A 46 9C 1005 : } 1006 : } 1007 439 124: SEQUENCE { 1008 441 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 1009 452 29: SEQUENCE { 1010 454 9: OBJECT IDENTIFIER 1011 : aes128-CBC (2 16 840 1 101 3 4 1 2) 1012 465 16: OCTET STRING 1013 : CA 35 CA BD 1E 78 83 D9 20 6C 47 B9 9F DC 91 88 1014 : } 1015 483 80: [0] 1016 : 1B AE 12 C4 0E 55 96 AB 99 CC 1C 7F B5 98 A4 BF 1017 : D2 D8 7F 94 BB B5 38 05 59 F2 38 A1 CD 29 75 17 1018 : 1D 63 1B 0B B0 2D 88 06 7F 78 80 F3 5A 3E DC 35 1019 : BF 22 1E 03 32 59 98 DA FD 81 5F D9 41 63 3A 18 1020 : FD B5 84 14 01 46 0B 40 EB 56 29 86 47 8B D1 EE 1021 : } 1022 : } 1023 : } 1024 : } 1026 4.3. MESSAGE Request with Encrypted and Signed Body 1028 In the example below, some of the header values have been split 1029 across multiple lines. Where the lines have been broken, the 1030 convention has been used. This was only done to make it 1031 fit in the RFC format. Specifically, the application/pkcs7-mime 1032 Content-Type line is one line with no whitespace between the "mime;" 1033 and the "smime-type". The values are split across lines for 1034 formatting, but are not split in the real message. The binary 1035 encrypted content has been replaced with "BINARY BLOB 3", and the 1036 binary signed content has been replaced with "BINARY BLOB 4". 1038 MESSAGE sip:kumiko@example.net SIP/2.0 1039 1040 Via: SIP/2.0/TCP 192.0.2.2:15001; 1041 branch=z9hG4bK-d8754z-97a26e59b7262b34-1---d8754z-; 1042 rport=50742 1043 1044 Max-Forwards: 70 1045 To: 1046 From: ;tag=379f5b27 1047 Call-ID: MjYwMzdjYTY3YWRkYzgzMjU0MGI4Mzc2Njk1YzJlNzE. 1048 CSeq: 5449 MESSAGE 1049 1050 Accept: multipart/signed, text/plain, application/pkcs7-mime, 1051 application/sdp, multipart/alternative 1052 1053 1054 Content-Type: multipart/signed;boundary=e8df6e1ce5d1e864; 1055 micalg=sha1;protocol="application/pkcs7-signature" 1056 1057 Content-Length: 1455 1059 --e8df6e1ce5d1e864 1060 1061 Content-Type: application/pkcs7-mime;smime-type=enveloped-data; 1062 name=smime.p7m 1063 1064 1065 Content-Disposition: attachment;handling=required; 1066 filename=smime.p7 1067 1068 Content-Transfer-Encoding: binary 1070 ***************** 1071 * BINARY BLOB 3 * 1072 ***************** 1073 --e8df6e1ce5d1e864 1074 Content-Type: application/pkcs7-signature;name=smime.p7s 1075 1076 Content-Disposition: attachment;handling=required; 1077 filename=smime.p7s 1078 1079 Content-Transfer-Encoding: binary 1081 ***************** 1082 * BINARY BLOB 4 * 1083 ***************** 1084 --e8df6e1ce5d1e864-- 1085 Below is the ASN.1 parsing of "BINARY BLOB 3". 1087 0 561: SEQUENCE { 1088 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 1089 15 546: [0] { 1090 19 542: SEQUENCE { 1091 23 1: INTEGER 0 1092 26 409: SET { 1093 30 405: SEQUENCE { 1094 34 1: INTEGER 0 1095 37 125: SEQUENCE { 1096 39 112: SEQUENCE { 1097 41 11: SET { 1098 43 9: SEQUENCE { 1099 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1100 50 2: PrintableString 'US' 1101 : } 1102 : } 1103 54 19: SET { 1104 56 17: SEQUENCE { 1105 58 3: OBJECT IDENTIFIER 1106 : stateOrProvinceName (2 5 4 8) 1107 63 10: UTF8String 'California' 1108 : } 1109 : } 1110 75 17: SET { 1111 77 15: SEQUENCE { 1112 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 1113 84 8: UTF8String 'San Jose' 1114 : } 1115 : } 1116 94 14: SET { 1117 96 12: SEQUENCE { 1118 98 3: OBJECT IDENTIFIER 1119 : organizationName (2 5 4 10) 1120 103 5: UTF8String 'sipit' 1121 : } 1122 : } 1123 110 41: SET { 1124 112 39: SEQUENCE { 1125 114 3: OBJECT IDENTIFIER 1126 : organizationalUnitName (2 5 4 11) 1127 119 32: UTF8String 'Sipit Test Certificate 1128 Authority' 1129 : } 1130 : } 1131 : } 1132 153 9: INTEGER 00 96 A3 84 17 4E EF 8A 4E 1133 : } 1134 164 13: SEQUENCE { 1135 166 9: OBJECT IDENTIFIER 1136 : rsaEncryption (1 2 840 113549 1 1 1) 1137 177 0: NULL 1138 : } 1139 179 256: OCTET STRING 1140 : 49 11 0B 11 52 A9 9D E3 AA FB 86 CB EB 12 CC 8E 1141 : 96 9D 85 3E 80 D2 7C C4 9B B7 81 4B B5 FA 13 80 1142 : 6A 6A B2 34 72 D8 C0 82 60 DA B3 43 F8 51 8C 32 1143 : 8B DD D0 76 6D 9C 46 73 C1 44 A0 10 FF 16 A4 83 1144 : 74 85 21 74 7D E0 FD 42 C0 97 00 82 A2 80 81 22 1145 : 9C A2 82 0A 85 F0 68 EF 9A D7 6D 1D 24 2B A9 5E 1146 : B3 9A A0 3E A7 D9 1D 1C D7 42 CB 6F A5 81 66 23 1147 : 28 00 7C 99 6A B6 03 3F 7E F6 48 EA 91 49 35 F1 1148 : FD 40 54 5D AC F7 84 EA 3F 27 43 FD DE E2 10 DD 1149 : 63 C4 35 4A 13 63 0B 6D 0D 9A D5 AB 72 39 69 8C 1150 : 65 4C 44 C4 A3 31 60 79 B9 A8 A3 A1 03 FD 41 25 1151 : 12 E5 F3 F8 47 CE 8C 42 D9 26 77 A5 57 AF 1A 95 1152 : BF 05 A5 E9 47 F2 D1 AE DC 13 7E 1B 83 5C 8C C4 1153 : 1F 31 BC 59 E6 FD 6E 9A B0 91 EC 71 A6 7F 28 3E 1154 : 23 1B 40 E2 C0 60 CF 5E 5B 86 08 06 82 B4 B7 DB 1155 : 00 DD AC 3A 39 27 E2 7C 96 AD 8A E9 C3 B8 06 5E 1156 : } 1157 : } 1158 439 124: SEQUENCE { 1159 441 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 1160 452 29: SEQUENCE { 1161 454 9: OBJECT IDENTIFIER 1162 : aes128-CBC (2 16 840 1 101 3 4 1 2) 1163 465 16: OCTET STRING 1164 : 88 9B 13 75 A7 66 14 C3 CF CD C6 FF D2 91 5D A0 1165 : } 1166 483 80: [0] 1167 : 80 0B A3 B7 57 89 B4 F4 70 AE 1D 14 A9 35 DD F9 1168 : 1D 66 29 46 52 40 13 E1 3B 4A 23 E5 EC AB F9 35 1169 : A6 B6 A4 BE C0 02 31 06 19 C4 39 22 7D 10 4C 0D 1170 : F4 96 04 78 11 85 4E 7E E3 C3 BC B2 DF 55 17 79 1171 : 5F F2 4E E5 25 42 37 45 39 5D F6 DA 57 9A 4E 0B 1172 : } 1173 : } 1174 : } 1175 : } 1177 Below is the ASN.1 parsing of "BINARY BLOB 4". 1179 0 472: SEQUENCE { 1180 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 1181 15 457: [0] { 1182 19 453: SEQUENCE { 1183 23 1: INTEGER 1 1184 26 11: SET { 1185 28 9: SEQUENCE { 1186 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 1187 37 0: NULL 1188 : } 1189 : } 1190 39 11: SEQUENCE { 1191 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 1192 : } 1193 52 420: SET { 1194 56 416: SEQUENCE { 1195 60 1: INTEGER 1 1196 63 125: SEQUENCE { 1197 65 112: SEQUENCE { 1198 67 11: SET { 1199 69 9: SEQUENCE { 1200 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 1201 76 2: PrintableString 'US' 1202 : } 1203 : } 1204 80 19: SET { 1205 82 17: SEQUENCE { 1206 84 3: OBJECT IDENTIFIER 1207 : stateOrProvinceName (2 5 4 8) 1208 89 10: UTF8String 'California' 1209 : } 1210 : } 1211 101 17: SET { 1212 103 15: SEQUENCE { 1213 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 1214 110 8: UTF8String 'San Jose' 1215 : } 1216 : } 1217 120 14: SET { 1218 122 12: SEQUENCE { 1219 124 3: OBJECT IDENTIFIER 1220 : organizationName (2 5 4 10) 1221 129 5: UTF8String 'sipit' 1222 : } 1223 : } 1224 136 41: SET { 1225 138 39: SEQUENCE { 1226 140 3: OBJECT IDENTIFIER 1227 : organizationalUnitName (2 5 4 11) 1229 145 32: UTF8String 'Sipit Test Certificate 1230 Authority' 1231 : } 1232 : } 1233 : } 1234 179 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D 1235 : } 1236 190 9: SEQUENCE { 1237 192 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 1238 199 0: NULL 1239 : } 1240 201 13: SEQUENCE { 1241 203 9: OBJECT IDENTIFIER 1242 : rsaEncryption (1 2 840 113549 1 1 1) 1243 214 0: NULL 1244 : } 1245 216 256: OCTET STRING 1246 : 6E 51 AC 24 2E BA 7C A1 EE 80 A8 55 BC D4 64 5D 1247 : E5 29 09 5F B2 AF AA 6F 91 D2 97 79 32 5B AF CA 1248 : FE A1 73 FC E5 57 4E C6 3B 67 35 AA E4 78 1E 59 1249 : 93 EE 67 63 77 1E 7A 82 BC 1E 26 0F 39 75 0C A6 1250 : 26 92 01 6A B7 5D F0 C0 2C 51 46 FB A7 36 44 E3 1251 : 64 C6 11 CB 0B 6B FD F3 6D 7C FD 3E AE 2E 91 BB 1252 : 78 9E F4 1B A1 20 68 B9 DE D3 E3 0C FC F7 14 9A 1253 : 2C 64 AB 27 52 BD 52 EC 27 88 14 BD DB C3 54 C7 1254 : EA 48 DB 07 E9 9B 2E C8 BE 62 A2 76 83 53 37 E8 1255 : 02 4B D1 86 E9 DF 2E BD 93 39 EC 2F 01 53 A0 7F 1256 : 1A B9 A6 31 FC E7 91 1C DB 22 4A 67 83 94 B2 4E 1257 : 28 A9 CD DE 4A 04 6A E0 86 90 7B 58 5F DB 7A 96 1258 : 96 A0 25 61 C2 58 A2 28 E5 B3 B2 F1 6D 51 06 9C 1259 : 78 61 0D D8 3A A7 9F A3 B5 87 0B 80 11 C2 A9 1A 1260 : E5 17 1C EB 82 55 AB CD 04 E7 D9 5B 11 E8 B7 47 1261 : FE FD CC B7 DB 47 6F 77 85 9E 24 D8 11 E1 E4 7D 1262 : } 1263 : } 1264 : } 1265 : } 1266 : } 1268 5. Observed Interoperability Issues 1270 This section describes some common interoperability problems. These 1271 were observed by the authors at SIPit interoperability events. 1272 Implementers should be careful to verify that their systems do not 1273 introduce these common problems, and, when possible, make their 1274 clients forgiving in what they receive. Implementations should take 1275 extra care to produce reasonable error messages when interacting with 1276 software that has these problems. 1278 Some SIP clients incorrectly only do SSLv3 and do not support TLS. 1279 See Section 26.2.1 of [RFC3261]. 1281 Many SIP clients were found to accept expired certificates with no 1282 warning or error. See Section 4.1.2.5 of [RFC5280]. 1284 When used with SIP, TLS and S/MIME provide the identity of the peer 1285 that a client is communicating with in the Subject Alternative Name 1286 in the certificate. The software checks that this name corresponds 1287 to the identity the server is trying to contact. Normative text 1288 describing path validation can be found in Section 7 of [RFC5922] and 1289 Section 6 of [RFC5280]. If a client is trying to set up a TLS 1290 connection to good.example.com and it gets a TLS connection set up 1291 with a server that presents a valid certificate but with the name 1292 evil.example.com, it will typically generate an error or warning of 1293 some type. Similarly with S/MIME, if a user is trying to communicate 1294 with sip:fluffy@example.com, one of the items in the Subject 1295 Alternate Name set in the certificate will need to match according to 1296 the certificate validation rules in Section 23 of [RFC3261] and 1297 Section 6 of [RFC5280]. 1299 Some implementations used binary MIME encodings while others used 1300 base64. It is advisable that implementations send only binary and 1301 are prepared to receive either. See Section 3.2 of [RFC5621]. 1303 In several places in this document, the messages contain the encoding 1304 for the SHA-1 digest algorithm identifier. The preferred form for 1305 encoding as set out in Section 2 of [RFC3370] is the form in which 1306 the optional AlgorithmIdentifier parameter field is omitted. 1307 However, [RFC3370] also says the recipients need to be able to 1308 receive the form in which the AlgorithmIdentifier parameter field is 1309 present and set to NULL. Examples of the form using NULL can be 1310 found in Section 4.2 of [RFC4134]. Receivers really do need to be 1311 able to receive the form that includes the NULL because the NULL 1312 form, while not preferred, is what was observed as being generated by 1313 most implementations. Implementers should also note that if the 1314 algorithm is MD5 instead of SHA-1, then the form that omits the 1315 AlgorithmIdentifier parameters field is not allowed and the sender 1316 has to use the form where the NULL is included. 1318 The preferred encryption algorithm for S/MIME in SIP is AES as 1319 defined in [RFC3853]. 1321 Observed S/MIME interoperability has been better when UAs did not 1322 attach the senders' certificates. Attaching the certificates 1323 significantly increases the size of the messages, which should be 1324 considered when sending over UDP. Furthermore, the receiver cannot 1325 rely on the sender to always send the certificate, so it does not 1326 turn out to be useful in most situations. 1328 Please note that the certificate path validation algorithm described 1329 in Section 6 of [RFC5280] is a complex algorithm for which all of the 1330 details matter. There are numerous ways in which failing to 1331 precisely implement the algorithm as specified in Section 6 of 1332 [RFC5280] can create a security flaw, a simple example of which is 1333 the failure to check the expiration date that is already mentioned 1334 above. It is important for developers to ensure that this validation 1335 is performed and that the results are verified by their applications 1336 or any libraries that they use. 1338 6. Additional Test Scenarios 1340 This section provides a non-exhaustive list of tests that 1341 implementations should perform while developing systems that use 1342 S/MIME and TLS for SIP. 1344 Much of the required behavior for inspecting certificates when using 1345 S/MIME and TLS with SIP is currently underspecified. The non- 1346 normative recommendations in this document capture the current 1347 folklore around that required behavior, guided by both related 1348 normative works such as [RFC4474] (particularly, Section 13.4 Domain 1349 Names and Subordination) and informative works such as [RFC2818] 1350 Section 3.1. To summarize, test plans should: 1352 o For S/MIME secured bodies, assure that the peer's URI (address-of- 1353 record, as per [RFC3261] Section 23.3) appears in the 1354 subjectAltName of the peer's certificate as a 1355 uniformResourceIdentifier field. 1357 o For TLS, assure that the peer's hostname appears as described in 1358 [RFC5922]. Also: 1360 * assure an exact match in a dNSName entry in the subjectAltName 1361 if there are any dNSNames in the subjectAltName. Wildcard 1362 matching is not allowed against these dNSName entries. See 1363 Section 7.1 of [RFC5922]. 1365 * assure that the most specific CommonName in the Subject field 1366 matches if there are no dNSName entries in the subjectAltName 1367 at all (which is not the same as there being no matching 1368 dNSName entries). This match can be either exact, or against 1369 an entry that uses the wildcard matching character '*' 1371 The peer's hostname is discovered from the initial DNS query in 1372 the server location process [RFC3263]. 1374 o IP addresses can appear in subjectAltName ([RFC5280]) of the 1375 peer's certificate, e.g. "IP:192.168.0.1". Note that if IP 1376 addresses are used in subjectAltName, there are important 1377 ramifications regarding the use of Record-Route headers that also 1378 need to be considered. See Section 7.5 of [RFC5922]. Use of IP 1379 addresses instead of domain names is inadvisable. 1381 For each of these tests, an implementation will proceed past the 1382 verification point only if the certificate is "good". S/MIME 1383 protected requests presenting bad certificate data will be rejected. 1384 S/MIME protected responses presenting bad certificate information 1385 will be ignored. TLS connections involving bad certificate data will 1386 not be completed. 1388 1. S/MIME : Good peer certificate 1390 2. S/MIME : Bad peer certificate (peer URI does not appear in 1391 subjectAltName) 1393 3. S/MIME : Bad peer certificate (valid authority chain does not 1394 end at a trusted CA) 1396 4. S/MIME : Bad peer certificate (incomplete authority chain) 1398 5. S/MIME : Bad peer certificate (the current time does not fall 1399 within the period of validity) 1401 6. S/MIME : Bad peer certificate (certificate, or certificate in 1402 authority chain, has been revoked) 1404 7. S/MIME : Bad peer certificate ("Digital Signature" is not 1405 specified as an X509v3 Key Usage) 1407 8. TLS : Good peer certificate (hostname appears in dNSName in 1408 subjectAltName) 1410 9. TLS : Good peer certificate (no dNSNames in subjectAltName, 1411 hostname appears in CN of Subject) 1413 10. TLS : Good peer certificate (CN of Subject empty, and 1414 subjectAltName extension contains an iPAddress stored in the 1415 octet string in network byte order form as specified in RFC 791 1416 [RFC0791]) 1418 11. TLS : Bad peer certificate (no match in dNSNames or in the 1419 Subject CN) 1421 12. TLS : Bad peer certificate (valid authority chain does not end 1422 at a trusted CA) 1424 13. TLS : Bad peer certificate (incomplete authority chain) 1426 14. TLS : Bad peer certificate (the current time does not fall 1427 within the period of validity) 1429 15. TLS : Bad peer certificate (certificate, or certificate in 1430 authority chain, has been revoked) 1432 16. TLS : Bad peer certificate ("TLS Web Server Authentication" is 1433 not specified as an X509v3 Key Usage) 1435 17. TLS : Bad peer certificate (Neither "SIP Domain" nor "Any 1436 Extended Key Usage" specified as an X509v3 Extended Key Usage, 1437 and X509v3 Extended Key Usage is present) 1439 7. IANA Considerations 1441 No IANA actions are required. 1443 8. Acknowledgments 1445 Many thanks to the developers of all the open source software used to 1446 create these call flows. This includes the underlying crypto and TLS 1447 software used from openssl.org, the SIP stack from 1448 www.resiprocate.org, and the SIMPLE IMPP agent from www.sipimp.org. 1449 The TLS flow dumps were done with SSLDump from 1450 http://www.rtfm.com/ssldump. The book "SSL and TLS" [EKR-TLS] was a 1451 huge help in developing the code for these flows. It's sad there is 1452 no second edition. 1454 Thanks to Jim Schaad, Russ Housley, Eric Rescorla, Dan Wing, Tat 1455 Chan, and Lyndsay Campbell who all helped find and correct mistakes 1456 in this document. 1458 Vijay Gurbani and Alan Jeffrey contributed much of the additional 1459 test scenario content. 1461 9. Security Considerations 1463 Implementers must never use any of the certificates provided in this 1464 document in anything but a test environment. Installing the CA root 1465 certificates used in this document as a trusted root in operational 1466 software would completely destroy the security of the system while 1467 giving the user the impression that the system was operating 1468 securely. 1470 This document recommends some things that implementers might test or 1471 verify to improve the security of their implementations. It is 1472 impossible to make a comprehensive list of these, and this document 1473 only suggests some of the most common mistakes that have been seen at 1474 the SIPit interoperability events. Just because an implementation 1475 does everything this document recommends does not make it secure. 1477 This document does not show any messages to check certificate 1478 revocation status (see Sections 3.3 and 6.3 of [RFC5280]) as that is 1479 not part of the SIP call flow. The expectation is that revocation 1480 status is checked regularly to protect against the possibility of 1481 certificate compromise or repudiation. For more information on how 1482 certificate revocation status can be checked, see [RFC2560] (Online 1483 Certificate Status Protocol) and [RFC5055] (Server-Based Certificate 1484 Validation Protocol). 1486 10. Changelog 1488 (RFC Editor: remove this section) 1490 -02 to -03 1492 * Re-worded "should" and "must" so that the document doesn't 1493 sound like it is making normative statements. Actual normative 1494 behavior is referred to in the respective RFCs. 1496 * Section 5: re-worded paragraphs 4 and 5 regarding 1497 subjectAltName, and added references. 1499 * Section 6: added references, clarified use of IP addresses, and 1500 clarified which From/To URI is used for comparison (from 1501 section 23.2). Added an EKU test case. 1503 * Section 9: added text about certificate revocation checking. 1505 * Appendix B.3: new section to present certificate chains longer 1506 than 2 (non-root CA). 1508 * Made examples consistently use convention. 1510 * CSeq looks more random. 1512 * Serial numbers in certificates are non-zero. 1514 * All flows re-generated using new certificates. IP addresses 1515 conform to RFC 5737. 1517 * Updated references. 1519 -01 to -02 1521 * Draft is now informational, not standards track. Normative- 1522 sounding language and references to RFC 2119 removed. 1524 * Add TODO: change "hello" to "Hello!" in example flows for 1525 consistency. 1527 * Add TODO: Fix subjectAltName DNS:com to DNS:example.com and 1528 DNS:net to DNS:example.net. 1530 * Add TODO: use allOneLine convention from RFC4475. 1532 * Section 3: updated open issue regarding contact headers in 1533 MESSAGE. 1535 * Section 3.2: added some text about RFC 3263 and connection 1536 reuse and closed open issue. 1538 * Section 5: clarified text about sender attaching certs, closed 1539 issue. 1541 * Section 5: clarified text about observed problems, closed 1542 issue. 1544 * Section 5: closed issue about clients vs. servers vs. proxies. 1546 * Section 6: updated section text and open issue where IP address 1547 is in subjectAltName. 1549 * Section 6: added normative references and closed "folklore" 1550 issue. 1552 * Section 6: added cases about cert usage and broken chains, 1553 updated OPEN ISSUE: we need a SIP EKU example. 1555 * References: updated references to drafts and re-categorized 1556 informative vs. normative. 1558 * Section 9: added some text about revocation status and closed 1559 issue. 1561 * Appendix B: open issue: do we need non-root-CA certs and host 1562 certs signed by them for help in testing cases in Section 6? 1564 * Miscellaneous minor editorial changes. 1566 -00 to -01 1568 * Addition of OPEN ISSUES. 1570 * Numerous minor edits from mailing list feedback. 1572 to -00 1574 * Changed RFC 3369 references to RFC 3852. 1576 * Changed draft-ietf-sip-identity references to RFC 4474. 1578 * Added an ASN.1 dump of CMS signed content where SHA-1 1579 parameters are omitted instead of being set to ASN.1 NULL. 1581 * Accept headers added to messages. 1583 * User and domain certificates are generated with EKU as 1584 specified in Draft SIP EKU. 1586 * Message content that is shown is computed using certificates 1587 generated with EKU. 1589 * Message dump archive returned. 1591 * Message archive contains messages formed with and without EKU 1592 certificates. 1594 prior to -00 1596 * Incorporated the Test cases from Vijay Gurbani's and Alan 1597 Jeffrey's Use of TLS in SIP draft 1599 * Began to capture the folklore around where identities are 1600 carried in certificates for use with SIP 1602 * Removed the message dump archive pending verification (will 1603 return in -02) 1605 11. References 1607 11.1. Normative References 1609 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1610 September 1981. 1612 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1613 Adams, "X.509 Internet Public Key Infrastructure Online 1614 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1616 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1617 A., Peterson, J., Sparks, R., Handley, M., and E. 1618 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1619 June 2002. 1621 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1622 Protocol (SIP): Locating SIP Servers", RFC 3263, 1623 June 2002. 1625 [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) 1626 Algorithms", RFC 3370, August 2002. 1628 [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., 1629 and D. Gurle, "Session Initiation Protocol (SIP) Extension 1630 for Instant Messaging", RFC 3428, December 2002. 1632 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 1633 Requirement for the Session Initiation Protocol (SIP)", 1634 RFC 3853, July 2004. 1636 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1637 Authenticated Identity Management in the Session 1638 Initiation Protocol (SIP)", RFC 4474, August 2006. 1640 [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. 1641 Polk, "Server-Based Certificate Validation Protocol 1642 (SCVP)", RFC 5055, December 2007. 1644 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1645 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1647 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1648 Housley, R., and W. Polk, "Internet X.509 Public Key 1649 Infrastructure Certificate and Certificate Revocation List 1650 (CRL) Profile", RFC 5280, May 2008. 1652 [RFC5621] Camarillo, G., "Message Body Handling in the Session 1653 Initiation Protocol (SIP)", RFC 5621, September 2009. 1655 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 1656 RFC 5652, September 2009. 1658 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 1659 Mail Extensions (S/MIME) Version 3.2 Message 1660 Specification", RFC 5751, January 2010. 1662 [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain 1663 Certificates in the Session Initiation Protocol (SIP)", 1664 RFC 5922, June 2010. 1666 [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in 1667 the Session Initiation Protocol (SIP)", RFC 5923, 1668 June 2010. 1670 [RFC5924] Lawrence, S. and V. Gurbani, "Extended Key Usage (EKU) for 1671 Session Initiation Protocol (SIP) X.509 Certificates", 1672 RFC 5924, June 2010. 1674 [X.509] International Telecommunications Union, "Information 1675 technology - Open Systems Interconnection - The Directory: 1676 Public-key and attribute certificate frameworks", ITU- 1677 T Recommendation X.509 (2005), ISO/IEC 9594-8:2005. 1679 [X.683] International Telecommunications Union, "Information 1680 technology - Abstract Syntax Notation One (ASN.1): 1681 Parameterization of ASN.1 specifications", ITU- 1682 T Recommendation X.683 (2002), ISO/IEC 8824-4:2002, 2002. 1684 11.2. Informative References 1686 [EKR-TLS] Rescorla, E., "SSL and TLS - Designing and Building Secure 1687 Systems", 2001. 1689 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 1691 [RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, 1692 July 2005. 1694 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 1695 and H. Schulzrinne, "Session Initiation Protocol (SIP) 1696 Torture Test Messages", RFC 4475, May 2006. 1698 [RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol 1699 (LDAP): String Representation of Distinguished Names", 1700 RFC 4514, June 2006. 1702 [ssldump-manpage] 1703 Rescorla, E., "SSLDump manpage". 1705 Appendix A. Making Test Certificates 1707 These scripts allow you to make certificates for test purposes. The 1708 certificates will all share a common CA root so that everyone running 1709 these scripts can have interoperable certificates. WARNING - these 1710 certificates are totally insecure and are for test purposes only. 1711 All the CA created by this script share the same private key to 1712 facilitate interoperability testing, but this totally breaks the 1713 security since the private key of the CA is well known. 1715 The instructions assume a Unix-like environment with openssl 1716 installed, but openssl does work in Windows too. OpenSSL version 1717 0.9.8j was used to generate the certificates used in this document. 1718 Make sure you have openssl installed by trying to run "openssl". Run 1719 the makeCA script found in Appendix A.1; this creates a subdirectory 1720 called demoCA. If the makeCA script cannot find where your openssl 1721 is installed you will have to set an environment variable called 1722 OPENSSLDIR to whatever directory contains the file openssl.cnf. You 1723 can find this with a "locate openssl.cnf". You are now ready to make 1724 certificates. 1726 To create certificates for use with TLS, run the makeCert script 1727 found in Appendix A.2 with the fully qualified domain name of the 1728 proxy you are making the certificate for. For example, "makeCert 1729 host.example.net domain eku". This will generate a private key and a 1730 certificate. The private key will be left in a file named 1731 domain_key_example.net.pem in Privacy Enhanced Mail (PEM) format. 1732 The certificate will be in domain_cert_example.net.pem. Some 1733 programs expect both the certificate and private key combined 1734 together in a Public-key Cryptography Standards (PKCS) #12 format 1735 file. This is created by the script and left in a file named 1736 example.net.p12. Some programs expect this file to have a .pfx 1737 extension instead of .p12 - just rename the file if needed. A file 1738 with a certificate signing request, called example.net.csr, is also 1739 created and can be used to get the certificate signed by another CA. 1741 A second argument indicating the number of days for which the 1742 certificate should be valid can be passed to the makeCert script. It 1743 is possible to make an expired certificate using the command 1744 "makeCert host.example.net 0". 1746 Anywhere that a password is used to protect a certificate, the 1747 password is set to the string "password". 1749 The root certificate for the CA is in the file 1750 root_cert_fluffyCA.pem. 1752 For things that need DER format certificates, a certificate can be 1753 converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM 1754 -out cert.der -outform DER". 1756 Some programs expect certificates in PKCS #7 format (with a file 1757 extension of .p7c). You can convert these from PEM format to PKCS #7 1758 with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/ 1759 cacert.pem -outform DER -out cert.p7c" 1761 IE (version 8), Outlook Express (version 6), and Firefox (version 1762 3.5) can import and export .p12 files and .p7c files. You can 1763 convert a PKCS #7 certificate to PEM format with "openssl pkcs7 -in 1764 cert.p7c -inform DER -outform PEM -out cert.pem". 1766 The private key can be converted to PKCS #8 format with "openssl 1767 pkcs8 -in a_key.pem -topk8 -outform DER -out a_key.p8c" 1769 In general, a TLS client will just need the root certificate of the 1770 CA. A TLS server will need its private key and its certificate. 1771 These could be in two PEM files, a single file with both certificate 1772 and private key PEM sections, or a single .p12 file. An S/MIME 1773 program will need its private key and certificate, the root 1774 certificate of the CA, and the certificate for every other user it 1775 communicates with. 1777 A.1. makeCA script 1779 #!/bin/sh 1780 set -x 1782 rm -rf demoCA 1784 mkdir demoCA 1785 mkdir demoCA/certs 1786 mkdir demoCA/crl 1787 mkdir demoCA/newcerts 1788 mkdir demoCA/private 1789 # This is done to generate the exact serial number used for the RFC 1790 echo "4902110184015C" > demoCA/serial 1791 touch demoCA/index.txt 1793 # You may need to modify this for where your default file is 1794 # you can find where yours in by typing "openssl ca" 1795 for D in /etc/ssl /usr/local/ssl /sw/etc/ssl /sw/share/ssl; do 1796 CONF=${OPENSSLDIR:=$D}/openssl.cnf 1797 [ -f ${CONF} ] && break 1798 done 1800 CONF=${OPENSSLDIR}/openssl.cnf 1801 if [ ! -f $CONF ]; then 1802 echo "Can not find file $CONF - set your OPENSSLDIR variable" 1803 exit 1804 fi 1806 cp $CONF openssl.cnf 1808 cat >> openssl.cnf < demoCA/private/cakey.pem < demoCA/cacert.pem < demoCA/serial 1937 echo 96a384174eef8a4d > demoCA/serial 1939 openssl crl2pkcs7 -nocrl -certfile demoCA/cacert.pem \ 1940 -outform DER -out demoCA/cacert.p7c 1942 cp demoCA/cacert.pem root_cert_fluffyCA.pem 1944 A.2. makeCert script 1946 #!/bin/sh 1947 set -x 1949 # Make a symbolic link to this file called "makeUserCert" 1950 # if you wish to use it to make certs for users. 1952 # ExecName=$(basename $0) 1953 # 1954 # if [ ${ExecName} == "makeUserCert" ]; then 1955 # ExtPrefix="sipuser" 1956 # elif [ ${ExecName} == "makeEkuUserCert" ]; then 1957 # ExtPrefix="sipuser_eku" 1958 # elif [ ${ExecName} == "makeEkuCert" ]; then 1959 # ExtPrefix="sipdomain_eku" 1960 # else 1961 # ExtPrefix="sipdomain" 1962 # fi 1964 if [ $# == 3 ]; then 1965 DAYS=36500 1966 elif [ $# == 4 ]; then 1967 DAYS=$4 1968 else 1969 echo "Usage: makeCert test.example.org user|domain eku|noeku [days]" 1970 echo " makeCert alice@example.org [days]" 1971 echo "days is how long the certificate is valid" 1972 echo "days set to 0 generates an invalid certificate" 1973 exit 0 1974 fi 1976 ExtPrefix="sip"${2} 1978 if [ $3 == "noeku" ]; then 1979 ExtPrefix=${ExtPrefix}"_noeku" 1980 fi 1982 DOMAIN=`echo $1 | perl -ne '{print "$1\n" if (/(\w+\..*)$/)}' ` 1983 USER=`echo $1 | perl -ne '{print "$1\n" if (/(\w+)\@(\w+\..*)$/)}' ` 1984 ADDR=$1 1985 echo "making cert for $DOMAIN ${ADDR}" 1987 if [ $2 == "user" ]; then 1988 CNVALUE=$USER 1989 else 1990 CNVALUE=$DOMAIN 1991 fi 1993 rm -f ${ADDR}_*.pem 1994 rm -f ${ADDR}.p12 1996 case ${ADDR} in 1997 *:*) ALTNAME="URI:${ADDR}" ;; 1998 *@*) ALTNAME="URI:sip:${ADDR},URI:im:${ADDR},URI:pres:${ADDR}" ;; 1999 *) ALTNAME="DNS:${DOMAIN},URI:sip:${ADDR}" ;; 2000 esac 2002 rm -f demoCA/index.txt 2003 touch demoCA/index.txt 2004 rm -f demoCA/newcerts/* 2006 export ALTNAME 2008 openssl genrsa -out ${ADDR}_key.pem 2048 2009 openssl req -new -config openssl.cnf -reqexts ${ExtPrefix}_req \ 2010 -sha1 -key ${ADDR}_key.pem \ 2011 -out ${ADDR}.csr -days ${DAYS} <