Network Working Group C. Jennings Internet-Draft Cisco Systems Intended status: Standards Track K. Ono Expires: May 27, 2010 Columbia University R. Sparks B. Hibbard, Ed. Tekelec November 23, 2009 Example call flows using Session Initiation Protocol (SIP) security mechanisms draft-ietf-sipcore-sec-flows-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 27, 2010. Copyright Notice Jennings, et al. Expires May 27, 2010 [Page 1] Internet-Draft SIP Secure Call Flows November 2009 Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. Jennings, et al. Expires May 27, 2010 [Page 2] Internet-Draft SIP Secure Call Flows November 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 5 3.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 9 3.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10 4. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12 4.1. TLS with Server Authentication . . . . . . . . . . . . . . 12 4.2. MESSAGE Message Over TLS . . . . . . . . . . . . . . . . . 14 5. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 15 5.1. MESSAGE Message with Signed Body . . . . . . . . . . . . . 15 5.2. MESSAGE Message with Encrypted Body . . . . . . . . . . . 20 5.3. MESSAGE Message with Encrypted and Signed Body . . . . . . 23 6. Observed Interoperability Issues . . . . . . . . . . . . . . . 28 7. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 12.2. Informative References . . . . . . . . . . . . . . . . . . 34 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 36 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 39 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42 B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42 B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 49 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 Jennings, et al. Expires May 27, 2010 [Page 3] Internet-Draft SIP Secure Call Flows November 2009 1. Introduction This document is informational and is not normative on any aspect of SIP. SIP with TLS (RFC 5246 [5]) implementations are becoming very common. Several implementations of the S/MIME (RFC 3851 [8]) portion of SIP (RFC 3261 [2]) are also becoming available. After several interoperability events, it is clear that it is difficult to write these systems without any test vectors or examples of "known good" messages to test against. Furthermore, testing at the events is often hampered by trying to get certificates signed by some common test root into the appropriate format for various clients. This document addresses both of these issues by providing messages that give detailed examples that implementers can use for comparison and that can also be used for testing. In addition, this document provides a common certificate and private key that can be used for a Certificate Authority (CA) to reduce the time it takes to set up a test at an interoperability event. The document also provides some hints and clarifications for implementers. A simple SIP call flow using SIPS URIs and TLS is shown in Section 4. The certificates for the hosts used are shown in Section 3.2, and the CA certificates used to sign these are shown in Section 3.1. The text from Section 5.1 through Section 5.3 shows some simple SIP call flows using S/MIME to sign and encrypt the body of the message. The user certificates used in these examples are shown in Section 3.3. These host certificates are signed with the same CA certificate. Section 6 presents a partial list of things implementers should consider in order to implement systems that will interoperate. A way to make certificates that can be used for interoperability testing is presented in Appendix A, along with methods for converting these to various formats. The certificates used while creating the examples and test messages in this document are made available in Appendix B. Binary copies of various messages in this draft that can be used for testing appear in Appendix C. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Jennings, et al. Expires May 27, 2010 [Page 4] Internet-Draft SIP Secure Call Flows November 2009 document are to be interpreted as described in RFC 2119 [1]. OPEN ISSUE: If there's no intent to have normative language, this section and reference to RFC 2119 should be removed. 3. Certificates 3.1. CA Certificates The certificate used by the CA to sign the other certificates is shown below. This is a X509v3 certificate. Note that the X.509v3 Basic Constraints in the certificate allows it to be used as a CA, certificate authority. This certificate is not used directly in the TLS call flow; it is used only to verify user and host certificates. Jennings, et al. Expires May 27, 2010 [Page 5] Internet-Draft SIP Secure Call Flows November 2009 Version: 3 (0x2) Serial Number: 0 (0x0) Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=California, L=San Jose, O=sipit, OU=Sipit Test Certificate Authority Validity Not Before: Jul 18 12:21:52 2003 GMT Not After : Jul 15 12:21:52 2013 GMT Subject: C=US, ST=California, L=San Jose, O=sipit, OU=Sipit Test Certificate Authority Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): 00:c3:22:1e:83:91:c5:03:2c:3c:8a:f4:11:14:c6: 4b:9d:fa:72:78:c6:b0:95:18:a7:e0:8c:79:ba:5d: a4:ae:1e:21:2d:9d:f1:0b:1c:cf:bd:5b:29:b3:90: 13:73:66:92:6e:df:4c:b3:b3:1c:1f:2a:82:0a:ba: 07:4d:52:b0:f8:37:7b:e2:0a:27:30:70:dd:f9:2e: 03:ff:2a:76:cd:df:87:1a:bd:71:eb:e1:99:6a:c4: 7f:8e:74:a0:77:85:04:e9:41:ad:fc:03:b6:17:75: aa:33:ea:0a:16:d9:fb:79:32:2e:f8:cf:4d:c6:34: a3:ff:1b:d0:68:28:e1:9d:e5 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6 X509v3 Authority Key Identifier: 6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6 DirName:/C=US/ST=California/L=San Jose/O=sipit/ OU=Sipit Test Certificate Authority serial:00 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha1WithRSAEncryption 96:6d:1b:ef:d5:91:93:45:7c:5b:1f:cf:c4:aa:47:52:0b:34: a8:50:fa:ec:fa:b4:2a:47:4c:5d:41:a7:3d:c0:d6:3f:9e:56: 5b:91:1d:ce:a8:07:b3:1b:a4:9f:9a:49:6f:7f:e0:ce:83:94: 71:42:af:fe:63:a2:34:dc:b4:5e:a5:ce:ca:79:50:e9:6a:99: 4c:14:69:e9:7c:ab:22:6c:44:cc:8a:9c:33:6b:23:50:42:05: 1f:e1:c2:81:88:5f:ba:e5:47:bb:85:9b:83:25:ad:84:32:ff: 2a:5b:8b:70:12:11:83:61:c9:69:15:4f:58:a3:3c:92:d4:e8: 6f:52 The ASN.1 parse of the CA certificate is shown below. Jennings, et al. Expires May 27, 2010 [Page 6] Internet-Draft SIP Secure Call Flows November 2009 0:l= 804 cons: SEQUENCE 4:l= 653 cons: SEQUENCE 8:l= 3 cons: cont [ 0 ] 10:l= 1 prim: INTEGER :02 13:l= 1 prim: INTEGER :00 16:l= 13 cons: SEQUENCE 18:l= 9 prim: OBJECT :sha1WithRSAEncryption 29:l= 0 prim: NULL 31:l= 112 cons: SEQUENCE 33:l= 11 cons: SET 35:l= 9 cons: SEQUENCE 37:l= 3 prim: OBJECT :countryName 42:l= 2 prim: PRINTABLESTRING :US 46:l= 19 cons: SET 48:l= 17 cons: SEQUENCE 50:l= 3 prim: OBJECT :stateOrProvinceName 55:l= 10 prim: PRINTABLESTRING :California 67:l= 17 cons: SET 69:l= 15 cons: SEQUENCE 71:l= 3 prim: OBJECT :localityName 76:l= 8 prim: PRINTABLESTRING :San Jose 86:l= 14 cons: SET 88:l= 12 cons: SEQUENCE 90:l= 3 prim: OBJECT :organizationName 95:l= 5 prim: PRINTABLESTRING :sipit 102:l= 41 cons: SET 104:l= 39 cons: SEQUENCE 106:l= 3 prim: OBJECT :organizationalUnitName 111:l= 32 prim: PRINTABLESTRING :Sipit Test Certificate Authority 145:l= 30 cons: SEQUENCE 147:l= 13 prim: UTCTIME :030718122152Z 162:l= 13 prim: UTCTIME :130715122152Z 177:l= 112 cons: SEQUENCE 179:l= 11 cons: SET 181:l= 9 cons: SEQUENCE 183:l= 3 prim: OBJECT :countryName 188:l= 2 prim: PRINTABLESTRING :US 192:l= 19 cons: SET 194:l= 17 cons: SEQUENCE 196:l= 3 prim: OBJECT :stateOrProvinceName 201:l= 10 prim: PRINTABLESTRING :California 213:l= 17 cons: SET 215:l= 15 cons: SEQUENCE 217:l= 3 prim: OBJECT :localityName 222:l= 8 prim: PRINTABLESTRING :San Jose 232:l= 14 cons: SET 234:l= 12 cons: SEQUENCE 236:l= 3 prim: OBJECT :organizationName Jennings, et al. Expires May 27, 2010 [Page 7] Internet-Draft SIP Secure Call Flows November 2009 241:l= 5 prim: PRINTABLESTRING :sipit 248:l= 41 cons: SET 250:l= 39 cons: SEQUENCE 252:l= 3 prim: OBJECT :organizationalUnitName 257:l= 32 prim: PRINTABLESTRING :Sipit Test Certificate Authority 291:l= 159 cons: SEQUENCE 294:l= 13 cons: SEQUENCE 296:l= 9 prim: OBJECT :rsaEncryption 307:l= 0 prim: NULL 309:l= 141 prim: BIT STRING 00 30 81 89 02 81 81 00-c3 22 1e 83 91 c5 03 2c .0......."....., 3c 8a f4 11 14 c6 4b 9d-fa 72 78 c6 b0 95 18 a7 <.....K..rx..... e0 8c 79 ba 5d a4 ae 1e-21 2d 9d f1 0b 1c cf bd ..y.]...!-...... 5b 29 b3 90 13 73 66 92-6e df 4c b3 b3 1c 1f 2a [)...sf.n.L....* 82 0a ba 07 4d 52 b0 f8-37 7b e2 0a 27 30 70 dd ....MR..7{..'0p. f9 2e 03 ff 2a 76 cd df-87 1a bd 71 eb e1 99 6a ....*v.....q...j c4 7f 8e 74 a0 77 85 04-e9 41 ad fc 03 b6 17 75 ...t.w...A.....u aa 33 ea 0a 16 d9 fb 79-32 2e f8 cf 4d c6 34 a3 .3.....y2...M.4. ff 1b d0 68 28 e1 9d e5-02 03 01 00 01 ...h(........ 453:l= 205 cons: cont [ 3 ] 456:l= 202 cons: SEQUENCE 459:l= 29 cons: SEQUENCE 461:l= 3 prim: OBJECT :X509v3 Subject Key Identifier 466:l= 22 prim: OCTET STRING 04 14 6b 46 17 14 ea 94-76 25 80 54 6e 13 54 da ..kF....v%.Tn.T. a1 e3 54 14 a1 b6 ..T... 490:l= 154 cons: SEQUENCE 493:l= 3 prim: OBJECT :X509v3 Authority Key Identifier 498:l= 146 prim: OCTET STRING 30 81 8f 80 14 6b 46 17-14 ea 94 76 25 80 54 6e 0....kF....v%.Tn 13 54 da a1 e3 54 14 a1-b6 a1 74 a4 72 30 70 31 .T...T....t.r0p1 0b 30 09 06 03 55 04 06-13 02 55 53 31 13 30 11 .0...U....US1.0. 06 03 55 04 08 13 0a 43-61 6c 69 66 6f 72 6e 69 ..U....Californi 61 31 11 30 0f 06 03 55-04 07 13 08 53 61 6e 20 a1.0...U....San 4a 6f 73 65 31 0e 30 0c-06 03 55 04 0a 13 05 73 Jose1.0...U....s 69 70 69 74 31 29 30 27-06 03 55 04 0b 13 20 53 ipit1)0'..U... S 69 70 69 74 20 54 65 73-74 20 43 65 72 74 69 66 ipit Test Certif 69 63 61 74 65 20 41 75-74 68 6f 72 69 74 79 82 icate Authority. 01 . 0092 - 647:l= 12 cons: SEQUENCE 649:l= 3 prim: OBJECT :X509v3 Basic Constraints 654:l= 5 prim: OCTET STRING 30 03 01 01 ff 0.... 661:l= 13 cons: SEQUENCE 663:l= 9 prim: OBJECT :sha1WithRSAEncryption 674:l= 0 prim: NULL 676:l= 129 prim: BIT STRING Jennings, et al. Expires May 27, 2010 [Page 8] Internet-Draft SIP Secure Call Flows November 2009 00 96 6d 1b ef d5 91 93-45 7c 5b 1f cf c4 aa 47 ..m.....E|[....G 52 0b 34 a8 50 fa ec fa-b4 2a 47 4c 5d 41 a7 3d R.4.P....*GL]A.= c0 d6 3f 9e 56 5b 91 1d-ce a8 07 b3 1b a4 9f 9a ..?.V[.......... 49 6f 7f e0 ce 83 94 71-42 af fe 63 a2 34 dc b4 Io.....qB..c.4.. 5e a5 ce ca 79 50 e9 6a-99 4c 14 69 e9 7c ab 22 ^...yP.j.L.i.|." 6c 44 cc 8a 9c 33 6b 23-50 42 05 1f e1 c2 81 88 lD...3k#PB...... 5f ba e5 47 bb 85 9b 83-25 ad 84 32 ff 2a 5b 8b _..G....%..2.*[. 70 12 11 83 61 c9 69 15-4f 58 a3 3c 92 d4 e8 6f p...a.i.OX.<...o 52 R 3.2. Host Certificates The certificate for the host example.com is shown below. Note that the Subject Alternative Name is set to example.com and is a DNS type. The certificates for the other hosts are shown in Appendix B. Version: 3 (0x2) Serial Number: 01:52:01:54:01:90:00:43 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=California, L=San Jose, O=sipit, OU=Sipit Test Certificate Authority Validity Not Before: Apr 28 22:12:00 2009 GMT Not After : Apr 27 22:12:00 2012 GMT Subject: C=US, ST=California, L=San Jose, O=sipit, CN=example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:c7:60:09:2c:e2:0b:a6:8d:2c:8f:86:eb:47:72: 4d:dc:20:a5:48:69:9c:c6:79:73:3a:65:e4:74:b6: 80:99:4f:6e:a4:1b:1b:6f:5c:91:29:7c:11:a1:bd: ad:25:c6:42:a3:96:bb:d8:c8:11:d8:2a:bc:39:5f: e3:5f:9a:54:f5:0c:77:44:c6:f0:ee:a7:73:85:d0: d1:d7:34:96:d8:24:83:fe:1d:a7:5e:94:6a:a6:79: e6:8b:d6:96:06:31:8d:da:4d:f1:72:c0:a2:9c:48: c9:d2:1f:80:27:60:52:b8:12:cc:43:7c:e7:66:ac: b7:6e:07:bc:e7:d5:0f:fa:41:b3:37:4f:16:33:71: fc:6d:73:17:b5:65:8b:65:03:34:83:8e:98:7d:8b: a3:36:f1:a7:37:94:65:af:dd:13:29:f8:1b:c2:8b: fa:05:03:6b:4b:26:ae:a9:93:ab:5d:0c:f3:08:84: 9e:16:c0:13:fa:da:8f:1c:b6:69:95:04:6d:c8:cf: c0:12:8f:fd:27:2a:cb:16:16:fd:c2:fa:94:fe:e8: 78:40:e4:5a:ac:a7:ef:d7:17:7d:e8:f8:86:8c:16: 35:ff:3e:32:fd:43:1c:c1:20:08:2c:aa:56:a6:17: 4f:bc:74:b0:5d:57:ba:a5:19:b4:20:46:dd:36:3d: Jennings, et al. Expires May 27, 2010 [Page 9] Internet-Draft SIP Secure Call Flows November 2009 15:b3 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: DNS:com, URI:sip:example.com X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: 28:CC:9B:2B:4F:7C:43:5C:9D:AD:96:8B:73:A2:4F:58:5D:30:D4:04 X509v3 Authority Key Identifier: 6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6 DirName:/C=US/ST=California/L=San Jose/O=sipit/ OU=Sipit Test Certificate Authority serial:00 X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, 1.3.6.1.5.5.7.3.20 Signature Algorithm: sha1WithRSAEncryption 1f:b7:c2:84:43:90:d2:06:81:47:48:e7:14:39:5a:ad:a0:53: 36:fb:6f:d7:e1:bf:b1:65:98:fd:a6:c5:e0:5a:b7:5f:90:08: ab:d4:85:2a:d1:57:f2:0e:c1:26:43:de:e1:26:1e:ef:90:95: 94:6e:74:45:36:01:41:ce:43:c2:91:54:dd:35:a8:6e:57:3b: b2:34:71:aa:d4:ea:34:aa:8c:8e:dd:e1:a4:2c:05:45:fb:b8: 38:0c:7b:1f:4f:d7:3c:d7:68:7c:57:57:6d:13:c6:3f:44:dd: fd:6b:fb:65:96:9b:87:92:95:10:af:e7:47:cd:72:6c:6e:d7: 60:f5 The example host certificate above, as well as all the others presented in this document, are signed directly by a root CA. These certificate chains have a length equal to two: the root CA and the host certificate. Non-root CAs exist and may also sign certificates. The certificate chains presented by hosts with certificates signed by non-root CAs will have a length greater than two. For more details on how certificate chains are validated, see section 6.1.4 of RFC 5280 [4]. 3.3. User Certificates User certificates are used by many applications to establish user identity. The user certificate for fluffy@example.com is shown below. Note that the Subject Alternative Name has a list of names with different URL types such as a sip, im, or pres URL. This is necessary for interoperating with a CPIM gateway. In this example, example.com is the domain for fluffy. The message could be coming from a host called atlanta.example.com, and the AOR in the user Jennings, et al. Expires May 27, 2010 [Page 10] Internet-Draft SIP Secure Call Flows November 2009 certificate would still be the same. The others are shown in Appendix B.1. These certificates make use of the EKU extension discussed in Draft SIP EKU [13]. Note that the X509v3 Extended Key Usage attribute refers to the SIP OID introduced in Draft SIP EKU [13] is 1.3.6.1.5.5.7.3.20 Version: 3 (0x2) Serial Number: 01:52:01:54:01:90:00:47 Signature Algorithm: sha1WithRSAEncryption Issuer: C=US, ST=California, L=San Jose, O=sipit, OU=Sipit Test Certificate Authority Validity Not Before: Apr 29 17:10:46 2009 GMT Not After : Apr 28 17:10:46 2012 GMT Subject: C=US, ST=California, L=San Jose, O=sipit, CN=fluffy@example.com Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): 00:f4:0f:e8:18:2d:b1:9b:93:ef:64:6b:19:d7:83: ac:f7:af:12:37:30:48:df:6e:55:0a:ce:f7:2a:19: 17:66:bc:42:af:7a:af:78:6c:96:c6:c1:de:5e:38: 67:93:8d:f2:40:13:b5:6f:07:79:de:32:2c:23:e7: ba:e4:a8:36:32:83:8a:75:79:86:85:a2:50:d1:bb: b5:81:36:7e:6b:f2:64:9b:b6:54:d3:8b:c4:4d:4d: 26:94:ae:7c:50:e4:b2:e6:5f:ac:34:e0:97:51:cd: ff:66:b9:92:98:c5:cc:22:e7:0c:30:a4:4c:a6:37: ba:21:31:b2:81:93:0d:24:ee:a7:27:c9:b3:ec:46: e3:f9:7a:d2:42:0a:59:ab:e7:a3:8b:30:66:3d:31: 88:6f:ee:c4:8d:24:ca:99:f1:c8:4c:50:0d:4b:6b: 73:80:ac:74:6f:45:b1:29:29:a1:89:40:94:02:57: 23:8b:6d:60:5c:38:d3:1f:c3:bb:74:3d:15:87:af: 2d:29:16:6c:30:01:4e:e3:39:13:17:6b:ea:58:97: 75:9f:60:38:84:2c:31:95:6e:d8:6d:69:81:bb:2e: fa:59:a2:fb:08:53:59:df:1e:94:17:e5:10:f8:72: 5a:fb:4e:4f:2f:cd:3b:3d:30:c5:b6:c8:3b:e0:e7: 32:ed Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Alternative Name: URI:sip:fluffy@example.com, URI:im:fluffy@example.com, URI:pres:fluffy@example.com X509v3 Basic Constraints: CA:FALSE X509v3 Subject Key Identifier: D2:A2:22:FB:4D:A1:37:B9:15:0B:1E:FC:27:BC:FA:00:A7:1C:F2:29 Jennings, et al. Expires May 27, 2010 [Page 11] Internet-Draft SIP Secure Call Flows November 2009 X509v3 Authority Key Identifier: 6B:46:17:14:EA:94:76:25:80:54:6E:13:54:DA:A1:E3:54:14:A1:B6 DirName:/C=US/ST=California/L=San Jose/O=sipit/ OU=Sipit Test Certificate Authority serial:00 X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: E-mail Protection, 1.3.6.1.5.5.7.3.20 Signature Algorithm: sha1WithRSAEncryption 80:a0:db:45:dd:7d:b6:50:b6:93:27:36:cd:cd:28:3c:39:23: aa:e4:6e:9c:f7:d9:8c:96:4d:b7:36:f6:ac:c1:8f:86:d8:6a: 91:3a:4f:5a:68:32:37:df:0f:dd:40:b7:34:68:91:ce:0f:f0: 16:02:ee:be:b6:1d:e1:92:87:c9:5e:a9:42:78:26:45:bb:17: 08:ee:83:ea:e9:d8:30:84:66:90:69:b8:78:ff:c4:09:5c:ea: e2:8a:10:e6:f9:64:eb:db:47:0e:10:29:4d:0e:bb:53:65:70: e1:71:82:c8:d0:14:f4:24:30:49:a6:fc:80:a8:b1:84:bc:e9: 73:75 Versions of these certificates that do not make use of EKU are also included in Appendix B.2 4. Callflow with Message Over TLS 4.1. TLS with Server Authentication The flow below shows the edited SSLDump output of the host example.com forming a TLSRFC 5246 [5] connection to example.net. In this example mutual authentication is not used. Note that the client proposed three protocol suites including TLS_RSA_WITH_AES_128_CBC_SHA defined in RFC 3268 [7]. The certificate returned by the server contains a Subject Alternative Name that is set to example.net. A detailed discussion of TLS can be found in SSL and TLS [18]. For more details on the SSLDump tool, see the SSLDump Manual [19]. This example does not use the Server Extended Hello (see RFC 3546 [6]). New TCP connection #1: www.example.com(57592) <-> www.example.com(5061) 1 1 0.0015 (0.0015) C>SV3.1(101) Handshake ClientHello Version 3.1 random[32]= 49 f7 83 8d 1f 21 c7 73 0c 9f 61 ab 13 2d 6b 26 1e 79 0c 68 b3 b6 f8 24 54 6b 41 0d 9b 3a 03 31 Jennings, et al. Expires May 27, 2010 [Page 12] Internet-Draft SIP Secure Call Flows November 2009 cipher suites TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_DSS_RSA_WITH_AES_256_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_DES_192_CBC3_SHA TLS_ECDH_RSA_WITH_DES_192_CBC3_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 compression methods NULL 1 2 0.0040 (0.0024) S>CV3.1(48) Handshake ServerHello Version 3.1 random[32]= 49 f7 83 8d a0 f8 f0 3f ff 2d d4 13 9c 29 2b 2b fc 1c 92 b9 a8 2a d2 10 0c 54 8e fd af d6 42 22 session_id[0]= cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA compressionMethod NULL 1 3 0.0040 (0.0000) S>CV3.1(1823) Handshake Certificate 1 4 0.0040 (0.0000) S>CV3.1(14) Handshake CertificateRequest certificate_types rsa_sign certificate_types dss_sign certificate_types unknown value ServerHelloDone 1 5 0.0360 (0.0320) C>SV3.1(7) Handshake Jennings, et al. Expires May 27, 2010 [Page 13] Internet-Draft SIP Secure Call Flows November 2009 Certificate 1 6 0.0360 (0.0000) C>SV3.1(262) Handshake ClientKeyExchange 1 7 0.0360 (0.0000) C>SV3.1(1) ChangeCipherSpec 1 8 0.0360 (0.0000) C>SV3.1(48) Handshake 1 9 0.0770 (0.0410) S>CV3.1(170) Handshake 1 10 0.0770 (0.0000) S>CV3.1(1) ChangeCipherSpec 1 11 0.0770 (0.0000) S>CV3.1(48) Handshake 1 12 0.0780 (0.0010) C>SV3.1(32) application_data 1 13 0.0780 (0.0000) C>SV3.1(448) application_data 1 14 0.2804 (0.2023) S>CV3.1(32) application_data 1 15 0.2804 (0.0000) S>CV3.1(416) application_data 1 16 12.3288 (12.0483) S>CV3.1(32) Alert 1 12.3293 (0.0004) S>C TCP FIN 1 17 12.3310 (0.0017) C>SV3.1(32) Alert 4.2. MESSAGE Message Over TLS Once the TLS session is set up, the following MESSAGE message (as defined in RFC 3428 [15] is sent from fluffy@example.com to kumiko@example.net. Note that the URI has a SIPS URL and that the VIA indicates that TLS was used. In order to format this document, the convention from RFC 4475 [12] is used to break long lines. The actual message does not contain the linebreaks contained within those tags. MESSAGE sips:kumiko@example.net:5061 SIP/2.0 Via: SIP/2.0/TLS 208.77.188.166:15001;\ branch=z9hG4bK-d8754z-3be7667f18d2f53c-1---d8754z-;\ rport=54499 Max-Forwards: 70 Contact: To: From: ;tag=2eff6a6f Call-ID: NmE1NDk1YzFmYmMzMDVjOTEwMzVlZjNkMTBjZGZlMzY. CSeq: 1 MESSAGE Accept: multipart/signed, text/plain, application/pkcs7-mime,\ application/sdp, multipart/alternative Content-Type: text/plain Content-Length: 6 Hello! The response is sent from example.net to example.com over the same TLS connection. It is shown below. Jennings, et al. Expires May 27, 2010 [Page 14] Internet-Draft SIP Secure Call Flows November 2009 SIP/2.0 200 OK Via: SIP/2.0/TLS 208.77.188.166:15001;\ branch=z9hG4bK-d8754z-3be7667f18d2f53c-1---d8754z-;\ rport=54499 Contact: To: ;tag=00e62966 From: ;tag=2eff6a6f Call-ID: NmE1NDk1YzFmYmMzMDVjOTEwMzVlZjNkMTBjZGZlMzY. CSeq: 1 MESSAGE Content-Length: 0 OPEN ISSUE: Ben Campbell pointed out: Contact: "RFC3428 forbids Contact header fields in MESSAGE requests or 2XX responses to MESSAGE. This brings up the question as to whether MESSAGE is a good example, as you may wish to illustrate SIPS rules concerning Contact. (This reoccurs in all MESSAGE and 200 OK examples)." We need consensus on this. OPEN ISSUE: There should be some more information about how this MESSAGE is associated with the handshake example. The dump in 5.1 is slightly confusing in that example.com and example.net both resolved to the same address, so reverse lookup shows both domains as example.com. OPEN ISSUE: Add a few lines about RFC 3263. Add a few lines about how the UA decides to create a new TLS session or use an existing one (but not "connection-reuse" draft level of reuse complexity). Any volunteers? 5. Callflow with S/MIME-secured Message 5.1. MESSAGE Message with Signed Body Below is an example of a signed message. The values on the Content- Type line (multipart/signed) and on the Content-Disposition line have been broken across lines to fit on the page, but they should not be broken across lines in actual implementations. Jennings, et al. Expires May 27, 2010 [Page 15] Internet-Draft SIP Secure Call Flows November 2009 MESSAGE sip:kumiko@example.net SIP/2.0 Via: SIP/2.0/TCP 208.77.188.166:15001;\ branch=z9hG4bK-d8754z-36f515466f3a7f5c-1---d8754z-;\ rport=54500 Max-Forwards: 70 Contact: To: From: ;tag=e8cc1b5c Call-ID: NjVjYjNjNzQzNTZlYzdjMWUwM2VjYjcwOTVjM2RkZDM. CSeq: 1 MESSAGE Accept: multipart/signed, text/plain, application/pkcs7-mime,\ application/sdp, multipart/alternative Content-Type: multipart/signed;boundary=ac31fa52a112030f;\ micalg=sha1;protocol="application/pkcs7-signature" Content-Length: 772 --ac31fa52a112030f Content-Type: text/plain Content-Transfer-Encoding: binary hello --ac31fa52a112030f Content-Type: application/pkcs7-signature;name=smime.p7s Content-Disposition: attachment;handling=required;\ filename=smime.p7s Content-Transfer-Encoding: binary ***************** * BINARY BLOB 1 * ***************** --ac31fa52a112030f-- It is important to note that the signature ("BINARY BLOB 1") is computed over the MIME headers and body, but excludes the multipart boundary lines. The value on the Message-body line ends with CRLF. The CRLF is included in the boundary and should not be part of the signature computation. To be clear, the signature is computed over data starting with the C in the Content-Type and ending with the o in the hello. Content-Type: text/plain Content-Transfer-Encoding: binary hello Following is the ASN.1 parsing of encrypted contents referred to above as "BINARY BLOB 1". Note that at address 30, the hash for the signature is specified as SHA-1. Also note that the sender's Jennings, et al. Expires May 27, 2010 [Page 16] Internet-Draft SIP Secure Call Flows November 2009 certificate is not attached as it is optional in RFC 3852 [9]. 0 471: SEQUENCE { 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 15 456: [0] { 19 452: SEQUENCE { 23 1: INTEGER 1 26 11: SET { 28 9: SEQUENCE { 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 37 0: NULL : } : } 39 11: SEQUENCE { 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) : } 52 419: SET { 56 415: SEQUENCE { 60 1: INTEGER 1 63 124: SEQUENCE { 65 112: SEQUENCE { 67 11: SET { 69 9: SEQUENCE { 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 76 2: PrintableString 'US' : } : } 80 19: SET { 82 17: SEQUENCE { 84 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 89 10: PrintableString 'California' : } : } 101 17: SET { 103 15: SEQUENCE { 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 110 8: PrintableString 'San Jose' : } : } 120 14: SET { 122 12: SEQUENCE { 124 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 129 5: PrintableString 'sipit' : } : } 136 41: SET { Jennings, et al. Expires May 27, 2010 [Page 17] Internet-Draft SIP Secure Call Flows November 2009 138 39: SEQUENCE { 140 3: OBJECT IDENTIFIER : organizationalUnitName (2 5 4 11) 145 32: PrintableString 'Sipit Test Certificate Aut hority' : } : } : } 179 8: INTEGER 01 52 01 54 01 90 00 47 : } 189 9: SEQUENCE { 191 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 198 0: NULL : } 200 13: SEQUENCE { 202 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) 213 0: NULL : } 215 256: OCTET STRING : B1 08 00 AA 15 AC 59 6D 1A 66 66 61 40 A7 BB B1 : D6 7C 32 D8 CE 59 98 E3 8F 69 94 09 A5 F2 C4 34 : 6F 49 4D 56 64 FE EB A9 EA 71 5D 44 B4 0C 77 C1 : 0E BF FD 42 17 E3 84 A2 7E 5E 13 6C A6 F8 2B A9 : 24 3F BE AE 14 51 0E 0D 3E 9A 93 9A 16 52 25 AB : 28 AA C5 8D 15 EB 96 29 C0 9B D9 52 3E 38 D8 07 : 86 2D 22 28 9F 66 0F 74 DF B1 63 0B 26 0D 51 11 : EF AD 54 01 6D A4 C9 65 C6 3E 78 E3 CE 1C 78 5A : 41 85 B5 20 22 9F 0B 70 5A 0B 62 1F EF 92 56 75 : 22 25 41 90 2B F5 12 08 60 07 09 F7 73 5A 89 B9 : 0D F1 48 54 FF 1C FA C3 A8 10 58 6D 58 98 18 A5 : 0B B3 24 24 D5 CE DB 33 FC 31 75 E9 AC 15 1F 02 : F2 A8 E0 3A 3F 1E D2 22 B8 4D EA 11 0A 08 76 A7 : 14 1B 55 8F E7 E7 1C E0 16 E7 1B 62 D4 D4 F2 0A : 7C AB B0 2C 46 02 08 B7 CA 2A 1E 08 CB 4D 1C AA : 09 34 AA 53 5F 59 95 3D C7 87 DD 17 8D 78 04 01 : } : } : } : } : } SHA-1 parameters may be omitted entirely, instead of being set to NULL, as mentioned in RFC 3370 [11]. The above dump of Blob 1 has SHA-1 parameters set to NULL. Below are the same contents signed with the same key, but omitting the NULL according to RFC 3370 [11]. This is the preferred encoding. This is covered in greater detail in Jennings, et al. Expires May 27, 2010 [Page 18] Internet-Draft SIP Secure Call Flows November 2009 Section 6. 0 467: SEQUENCE { 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 15 452: [0] { 19 448: SEQUENCE { 23 1: INTEGER 1 26 9: SET { 28 7: SEQUENCE { 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) : } : } 37 11: SEQUENCE { 39 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) : } 50 417: SET { 54 413: SEQUENCE { 58 1: INTEGER 1 61 124: SEQUENCE { 63 112: SEQUENCE { 65 11: SET { 67 9: SEQUENCE { 69 3: OBJECT IDENTIFIER countryName (2 5 4 6) 74 2: PrintableString 'US' : } : } 78 19: SET { 80 17: SEQUENCE { 82 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 87 10: PrintableString 'California' : } : } 99 17: SET { 101 15: SEQUENCE { 103 3: OBJECT IDENTIFIER localityName (2 5 4 7) 108 8: PrintableString 'San Jose' : } : } 118 14: SET { 120 12: SEQUENCE { 122 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 127 5: PrintableString 'sipit' : } : } 134 41: SET { 136 39: SEQUENCE { Jennings, et al. Expires May 27, 2010 [Page 19] Internet-Draft SIP Secure Call Flows November 2009 138 3: OBJECT IDENTIFIER : organizationalUnitName (2 5 4 11) 143 32: PrintableString 'Sipit Test Certificate Aut hority' : } : } : } 177 8: INTEGER 01 52 01 54 01 90 00 47 : } 187 7: SEQUENCE { 189 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) : } 196 13: SEQUENCE { 198 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) 209 0: NULL : } 211 256: OCTET STRING : B1 08 00 AA 15 AC 59 6D 1A 66 66 61 40 A7 BB B1 : D6 7C 32 D8 CE 59 98 E3 8F 69 94 09 A5 F2 C4 34 : 6F 49 4D 56 64 FE EB A9 EA 71 5D 44 B4 0C 77 C1 : 0E BF FD 42 17 E3 84 A2 7E 5E 13 6C A6 F8 2B A9 : 24 3F BE AE 14 51 0E 0D 3E 9A 93 9A 16 52 25 AB : 28 AA C5 8D 15 EB 96 29 C0 9B D9 52 3E 38 D8 07 : 86 2D 22 28 9F 66 0F 74 DF B1 63 0B 26 0D 51 11 : EF AD 54 01 6D A4 C9 65 C6 3E 78 E3 CE 1C 78 5A : 41 85 B5 20 22 9F 0B 70 5A 0B 62 1F EF 92 56 75 : 22 25 41 90 2B F5 12 08 60 07 09 F7 73 5A 89 B9 : 0D F1 48 54 FF 1C FA C3 A8 10 58 6D 58 98 18 A5 : 0B B3 24 24 D5 CE DB 33 FC 31 75 E9 AC 15 1F 02 : F2 A8 E0 3A 3F 1E D2 22 B8 4D EA 11 0A 08 76 A7 : 14 1B 55 8F E7 E7 1C E0 16 E7 1B 62 D4 D4 F2 0A : 7C AB B0 2C 46 02 08 B7 CA 2A 1E 08 CB 4D 1C AA : 09 34 AA 53 5F 59 95 3D C7 87 DD 17 8D 78 04 01 : } : } : } : } : } 5.2. MESSAGE Message with Encrypted Body Below is an example of an encrypted text/plain message that says "hello". The binary encrypted contents have been replaced with the block "BINARY BLOB 2". Jennings, et al. Expires May 27, 2010 [Page 20] Internet-Draft SIP Secure Call Flows November 2009 MESSAGE sip:kumiko@example.net SIP/2.0 Via: SIP/2.0/TCP 208.77.188.166:15001;\ branch=z9hG4bK-d8754z-1c7dd40a5fff4463-1---d8754z-;\ rport=54502 Max-Forwards: 70 Contact: To: From: ;tag=5a10502e Call-ID: YTk3ODIwN2FiYTUwMGZmYTM1MDJiMzY2ODcyYzE4MGM. CSeq: 1 MESSAGE Accept: multipart/signed, text/plain, application/pkcs7-mime,\ application/sdp, multipart/alternative Content-Disposition: attachment;handling=required;\ filename=smime.p7 Content-Transfer-Encoding: binary Content-Type: application/pkcs7-mime;smime-type=enveloped-data;\ name=smime.p7m Content-Length: 564 ***************** * BINARY BLOB 2 * ***************** Following is the ASN.1 parsing of "BINARY BLOB 2". Note that at address 453, the encryption is set to aes128-CBC. 0 560: SEQUENCE { 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 15 545: [0] { 19 541: SEQUENCE { 23 1: INTEGER 0 26 408: SET { 30 404: SEQUENCE { 34 1: INTEGER 0 37 124: SEQUENCE { 39 112: SEQUENCE { 41 11: SET { 43 9: SEQUENCE { 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 50 2: PrintableString 'US' : } : } 54 19: SET { 56 17: SEQUENCE { 58 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 63 10: PrintableString 'California' : } Jennings, et al. Expires May 27, 2010 [Page 21] Internet-Draft SIP Secure Call Flows November 2009 : } 75 17: SET { 77 15: SEQUENCE { 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 84 8: PrintableString 'San Jose' : } : } 94 14: SET { 96 12: SEQUENCE { 98 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 103 5: PrintableString 'sipit' : } : } 110 41: SET { 112 39: SEQUENCE { 114 3: OBJECT IDENTIFIER : organizationalUnitName (2 5 4 11) 119 32: PrintableString 'Sipit Test Certificate Aut hority' : } : } : } 153 8: INTEGER 01 52 01 54 01 90 00 48 : } 163 13: SEQUENCE { 165 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) 176 0: NULL : } 178 256: OCTET STRING : 6E 48 A2 78 07 3A 47 09 C0 57 6F CB 01 AA 0E E7 : 3E 2C 1B 78 8F 6B 0B C2 D4 F2 BD 41 8E 3E CB 95 : CD 35 9C 2E 59 8B E8 E5 35 59 6F 0E FC 3B BB A4 : 2E 66 0D 68 6E 45 04 CA 4B E5 29 BE 65 F1 51 A1 : E3 40 83 95 7C 8F B0 A9 56 CF 34 D4 DE C4 63 BE : 26 55 1D 57 51 E2 86 8C 2A 7D B1 37 13 B5 F8 8D : B8 3C F1 84 31 0C 57 B2 24 E3 D2 F6 94 5D A2 80 : 2E 45 B7 36 96 6C EF A3 90 23 8E 9D B3 50 0A 6F : DB E7 47 54 EA 2D 5E 38 75 77 CB 05 EE 45 71 B6 : BB 95 93 AF 59 31 BC B3 10 F7 FE 72 B9 85 22 51 : 80 A6 7E F6 E5 9E 46 32 2C 8A BB ED 60 C8 F6 7B : 2D 9E CF 5F 9E D9 21 68 08 BE 00 51 27 A7 1B 54 : 53 CF 45 2A 58 61 63 3C 19 75 86 67 04 C3 05 77 : 6D 77 19 3B A4 16 32 38 1C 79 05 7B 71 11 7B 56 : 24 75 24 6B F7 75 D1 8A DA AE B8 3A 86 4D 31 0A : 1B D2 80 88 64 52 13 DA FE 93 DD AA C9 E0 D2 CB : } Jennings, et al. Expires May 27, 2010 [Page 22] Internet-Draft SIP Secure Call Flows November 2009 : } 438 124: SEQUENCE { 440 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 451 29: SEQUENCE { 453 9: OBJECT IDENTIFIER : aes128-CBC (2 16 840 1 101 3 4 1 2) 464 16: OCTET STRING : E8 E4 34 63 AE 68 F7 C1 62 C5 9E 7B 6F 25 22 AF : } 482 80: [0] : 41 4C FE FA A4 B4 70 1A 62 86 BC C1 DE 90 94 69 : 7D 0A D2 0F F3 4E 7D 6F 72 2F 7A A7 4B B4 4A 59 : C9 C0 CB F3 AD 92 D6 31 66 94 0E B3 49 01 63 D5 : BA 5A AE 29 ED C9 8A 87 EA 00 FC 4B 97 62 54 56 : 91 DB 78 50 B6 AD B7 B8 5D F6 11 41 3C C0 20 DD : } : } : } : } 5.3. MESSAGE Message with Encrypted and Signed Body In the example below, some of the header values have been split across mutliple lines. Where the lines have been broken, a "\" has been inserted. This was only done to make it fit in the RFC format. Specifically, the application/pkcs7-mime Content-Type line should be one line with no whitespace between the "mime;" and the "smime-type". The values are split across lines for formatting, but are not split in the real message. The binary encrypted content has been replaced with "BINARY BLOB 3", and the binary signed content has been replaced with "BINARY BLOB 4". Jennings, et al. Expires May 27, 2010 [Page 23] Internet-Draft SIP Secure Call Flows November 2009 MESSAGE sip:kumiko@example.net SIP/2.0 Via: SIP/2.0/TCP 208.77.188.166:15001;\ branch=z9hG4bK-d8754z-c2d73f665e157842-1---d8754z-;\ rport=54503 Max-Forwards: 70 Contact: To: From: ;tag=5e4dd355 Call-ID: MDQ2ZGVkZWQ4YzJhZTZhZDRjNzE0MDJkNzk1NGIxNTQ. CSeq: 1 MESSAGE Accept: multipart/signed, text/plain, application/pkcs7-mime,\ application/sdp, multipart/alternative Content-Type: multipart/signed;boundary=e0c6b73cedc44967;\ micalg=sha1;protocol="application/pkcs7-signature" Content-Length: 1453 --e0c6b73cedc44967 Content-Type: application/pkcs7-mime;smime-type=enveloped-data;\ name=smime.p7m Content-Disposition: attachment;handling=required;\ filename=smime.p7 Content-Transfer-Encoding: binary ***************** * BINARY BLOB 3 * ***************** --e0c6b73cedc44967 Content-Type: application/pkcs7-signature;name=smime.p7s Content-Disposition: attachment;handling=required;\ filename=smime.p7s Content-Transfer-Encoding: binary ***************** * BINARY BLOB 4 * ***************** --e0c6b73cedc44967-- Below is the ASN.1 parsing of "BINARY BLOB 3". 0 560: SEQUENCE { 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 15 545: [0] { 19 541: SEQUENCE { 23 1: INTEGER 0 26 408: SET { 30 404: SEQUENCE { 34 1: INTEGER 0 37 124: SEQUENCE { Jennings, et al. Expires May 27, 2010 [Page 24] Internet-Draft SIP Secure Call Flows November 2009 39 112: SEQUENCE { 41 11: SET { 43 9: SEQUENCE { 45 3: OBJECT IDENTIFIER countryName (2 5 4 6) 50 2: PrintableString 'US' : } : } 54 19: SET { 56 17: SEQUENCE { 58 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 63 10: PrintableString 'California' : } : } 75 17: SET { 77 15: SEQUENCE { 79 3: OBJECT IDENTIFIER localityName (2 5 4 7) 84 8: PrintableString 'San Jose' : } : } 94 14: SET { 96 12: SEQUENCE { 98 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 103 5: PrintableString 'sipit' : } : } 110 41: SET { 112 39: SEQUENCE { 114 3: OBJECT IDENTIFIER : organizationalUnitName (2 5 4 11) 119 32: PrintableString 'Sipit Test Certificate Aut hority' : } : } : } 153 8: INTEGER 01 52 01 54 01 90 00 48 : } 163 13: SEQUENCE { 165 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) 176 0: NULL : } 178 256: OCTET STRING : 8A C2 F2 23 B0 D4 11 0E EB 38 60 3A 47 99 14 33 : 78 01 1A F9 12 9E 97 93 D5 68 B2 B8 4E CF 76 15 : EF CD 36 0E A5 B8 36 5F E1 05 78 45 F7 05 12 6D : 55 0A A1 50 4C A9 F7 E3 B1 69 65 F8 38 A8 F7 2F Jennings, et al. Expires May 27, 2010 [Page 25] Internet-Draft SIP Secure Call Flows November 2009 : A1 74 0F 15 6F 29 B6 5C 74 21 49 21 77 07 E4 0A : 4D A9 02 30 15 45 2F 8F AE 08 2E 49 D9 B2 77 73 : E8 41 08 4E 2D B0 B0 EE 2F 49 B7 75 D7 70 E0 60 : FC A3 C9 49 38 C8 B3 79 71 46 98 C3 17 20 A9 13 : E7 EE E3 99 AA E2 1F C3 C3 7A B3 70 40 DA F3 40 : 0B 69 99 DC EB 5C 10 A9 FF A8 66 D1 56 BB B9 B9 : 84 CB 6D 03 3F 96 CC 6D 5A 92 8B 00 23 CB 8B FE : FB BF 19 26 7F C9 69 CC 93 98 5A E4 DE D3 B0 DE : 6E 0E 29 9C E8 05 D7 4F 3D A0 F7 C2 B2 8E 0E FF : 06 DA 46 0B ED 3B 84 BF 88 17 9C 40 DA 52 65 62 : A9 BB F5 7A E7 D1 78 69 9D 61 D5 48 53 56 0A BB : DD F3 35 C3 04 0D C0 BD 26 41 C1 E4 9E 19 A2 4B : } : } 438 124: SEQUENCE { 440 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) 451 29: SEQUENCE { 453 9: OBJECT IDENTIFIER : aes128-CBC (2 16 840 1 101 3 4 1 2) 464 16: OCTET STRING : 9E C3 11 33 C1 F5 42 09 C8 8B D2 C9 54 32 78 46 : } 482 80: [0] : 89 5B E2 84 60 E5 45 2B 74 CC 61 4F A2 E4 03 37 : D3 C6 83 52 A3 CF C9 E8 C7 8D AF F3 36 39 56 BF : 8F 7D E3 F8 65 43 6E 61 65 85 5B 62 AC BF 3A DD : 99 C7 8B B7 BA A7 3F 97 61 3C B1 E2 E0 45 BC 17 : 43 51 03 F4 41 8C 55 E7 02 5F CC AE F5 02 6B D8 : } : } : } : } Below is the ASN.1 parsing of "BINARY BLOB 4". 0 471: SEQUENCE { 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 15 456: [0] { 19 452: SEQUENCE { 23 1: INTEGER 1 26 11: SET { 28 9: SEQUENCE { 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 37 0: NULL : } : } 39 11: SEQUENCE { Jennings, et al. Expires May 27, 2010 [Page 26] Internet-Draft SIP Secure Call Flows November 2009 41 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1) : } 52 419: SET { 56 415: SEQUENCE { 60 1: INTEGER 1 63 124: SEQUENCE { 65 112: SEQUENCE { 67 11: SET { 69 9: SEQUENCE { 71 3: OBJECT IDENTIFIER countryName (2 5 4 6) 76 2: PrintableString 'US' : } : } 80 19: SET { 82 17: SEQUENCE { 84 3: OBJECT IDENTIFIER : stateOrProvinceName (2 5 4 8) 89 10: PrintableString 'California' : } : } 101 17: SET { 103 15: SEQUENCE { 105 3: OBJECT IDENTIFIER localityName (2 5 4 7) 110 8: PrintableString 'San Jose' : } : } 120 14: SET { 122 12: SEQUENCE { 124 3: OBJECT IDENTIFIER : organizationName (2 5 4 10) 129 5: PrintableString 'sipit' : } : } 136 41: SET { 138 39: SEQUENCE { 140 3: OBJECT IDENTIFIER : organizationalUnitName (2 5 4 11) 145 32: PrintableString 'Sipit Test Certificate Aut hority' : } : } : } 179 8: INTEGER 01 52 01 54 01 90 00 47 : } 189 9: SEQUENCE { 191 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 198 0: NULL : } Jennings, et al. Expires May 27, 2010 [Page 27] Internet-Draft SIP Secure Call Flows November 2009 200 13: SEQUENCE { 202 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) 213 0: NULL : } 215 256: OCTET STRING : 29 C3 93 9D 71 C5 93 52 80 4B 0F C5 66 C7 CD 18 : 2F 4D A0 07 E1 29 CE F9 2E CE 92 16 CD 7D B1 45 : 5A 6D C2 5A 90 51 C3 20 66 FC 76 F0 DF D3 AE C5 : CE 4D DF C8 0D D7 87 B3 69 ED 81 BA 71 EA B4 C0 : E3 F5 A3 A4 CA 2E 36 A3 29 37 86 37 C3 B6 90 A7 : EA 6A 27 52 C6 9C AB B1 2C 7B 60 10 26 E9 33 43 : 83 BA 06 B0 68 05 26 88 A2 68 1A 4E E5 82 16 5B : E4 00 7D 18 09 4A 13 09 2D B5 F1 A6 C0 39 60 29 : 02 32 24 29 D6 37 55 4C 42 DA 7D E9 98 F8 C6 FE : E8 01 1C 56 8B AD DB D2 B2 C4 20 A0 CC 92 BD 9B : 9F 0E C9 9E 5C BF 4E DA 1D D9 E4 02 DC DA 57 A6 : 59 EC 89 CD AD 66 D3 A3 7A 88 F9 A2 DA D5 9E FB : 4F AD 7D D9 69 68 35 B1 98 10 64 42 1D 3D 24 57 : C5 BF 48 C3 B0 E6 3C 91 3C 27 52 28 D2 BE 2C AC : 79 79 32 2E C4 9D 7C 8A 73 73 68 EC 60 E0 22 0D : 50 7F 72 33 96 89 F8 9F 7B ED D1 4A 75 7B D5 14 : } : } : } : } : } 6. Observed Interoperability Issues OPEN ISSUE: Who observed them? Is this experience from SIPits, etc? I think it would strengthen the idea that these are real-world, observed-in-the-wild issues to give sources. This section describes some common interoperability problems. Implementers should verify that their clients do the correct things and when possible make their clients forgiving in what they receive. Implementations should take extra care to produce reasonable error messages when interacting with software that has these problems. Some SIP clients incorrectly only do SSLv3 and do not support TLS. OPEN ISSUE: Do mean client class devices, or user agents in general? Does this exclude proxies? (same question throughout section.) Many SIP clients were found to accept expired certificates with no Jennings, et al. Expires May 27, 2010 [Page 28] Internet-Draft SIP Secure Call Flows November 2009 warning or error. When used with SIP, TLS and S/MIME provide the identity of the peer that a client is communicating with in the Subject Alternative Name in the certificate. The software must check that this name corresponds to the identity the server is trying to contact. If a client is trying to set up a TLS connection to good.example.com and it gets a TLS connection set up with a server that presents a valid certificate but with the name evil.example.com, it must generate an error or warning of some type. Similarly with S/MIME, if a user is trying to communicate with sip:fluffy@example.com, one of the items in the Subject Alternate Name set in the certificate must match. Some implementations used binary MIME encodings while others used base64. Implementations should send only binary but must be prepared to receive either. OPEN ISSUE: Is "...should send...must be prepared..." intended to be a normative statement? There is a larger issue as to whether this document is intended to be normative or informative. Should it be standards track? In several places in this draft, the messages contain the encoding for the SHA-1 digest algorithm identifier. The preferred form for encoding as set out in Section 2 of RFC 3370 [11] is the form in which the optional AlgorithmIdentifier parameter field is omitted. However, RFC 3370 also says the recipients need to be able to receive the form in which the AlgorithmIdentifier parameter field is present and set to NULL. Examples of the form using NULL can be found in Section 4.2 of RFC 4134 [14]. Receivers really do need to be able to receive the form that includes the NULL because the NULL form, while not preferred, is what was observed as being generated by most implementations. Implementers should also note that if the algorithm is MD5 instead of SHA-1, then the form that omits the AlgorithmIdentifier parameters field is not allowed and the sender has to use the form where the NULL is included. The preferred encryption algorithm for S/MIME in SIP is AES as defined in RFC 3853 [10]. Observed S/MIME interoperability has been better when UAs did not attach the senders' certificates. Attaching the certificates significantly increases the size of the messages, and since it can not be relied on, it does not turn out to be useful in most situations. OPEN ISSUE: There's some implicit stuff here that should be explicit. Do you mean to recommend never attaching certs? It's probably worth Jennings, et al. Expires May 27, 2010 [Page 29] Internet-Draft SIP Secure Call Flows November 2009 mentioning the message size limit issue. What do we mean by "it cannot be relied upon"--that we can't rely on the peer sending it, or it is unreliable when the peer does send it? 7. Additional Test Scenarios This section provides a non-exhaustive list of tests that implementations should perform while developing systems that use S/MIME and TLS for SIP. Much of the required behavior for inspecting certificates when using S/MIME and TLS with SIP is currently underspecified. The non- normative recommendations in this document capture the current folklore around that required behavior, guided by both related normative works such as RFC 4474 [16] (particulary, section 13.4 Domain Names and Subordination) and informative works such as RFC 2818 [17] section 3.1. To summarize that non-normative lore: o For S/MIME the peer's URI must appear in the subjectAltName of the peer's certifcate as a uniformResourceIdentifier field. o For TLS the peer's hostname (from the initial DNS query in the server location process RFC 3263 [3]) must appear as * an exact match in a dNSName entry in the subjectAltName if there are any dNSNames in the subjectAltName. (Wildcard matching is not allowed against these dNSName entries) * the most specific CommonName in the Subject field if there are no dNSName entries in the subjectAltName at all (which is not the same as there being no matching dNSName entries). This match can be either exact, or against an entry that uses the wildcard matching character '*' OPEN ISSUE: Are we sure all of this is truly folklore and none of it is from bona fide normative language somewhere? The true folklore portions may indicate future normative work we need to do. OPEN ISSUE: From first bullet, "peer's URI"...What URI? An AoR for the user? From or To values? Contacts? Request-URIs? For request URIs, do we need to discuss the effects of retargeting? Do we need to consider some of the current History-Info discussions? OPEN ISSUE: From second bullet: What if all you've got is an IP address? Do we disallow IPAddress entries in SubjectAltName? OPEN ISSUE: First sub-bullet (Wildcard matching is not allowed against these dNSName entries): Is there something that can be referenced here? In particular, RFC2818 explicitly allows wildcards in dNSName entries. It is not obvious to me whether the proscription against wildcards in RFC4474 should apply to general use of TLS, or Jennings, et al. Expires May 27, 2010 [Page 30] Internet-Draft SIP Secure Call Flows November 2009 just to identity. For each of these tests, an implementation will proceed past the verification point only if the certificate is "good". S/MIME protected requests presenting bad certificate data will be rejected. S/MIME protected responses presenting bad certificate information will be ignored. TLS connections involving bad certificate data will not be completed. 1. S/MIME : Good peer certificate 2. S/MIME : Bad peer certificate (peer URI does not appear in subjAltName) 3. S/MIME : Bad peer certificate (valid authority chain does not end at a trusted CA) 4. S/MIME : Bad peer certificate (the current time does not fall within the period of validity) 5. S/MIME : Bad peer certificate (certificate or cert in authority chain has been revoked) 6. TLS : Good peer certificate (hostname appears in dNSName in subjAltName) 7. TLS : Good peer certificate (no dNSNames in subjAltName, hostname appears in CN of Subject) 8. TLS : Bad peer certificate (no match in dNSNames or in the Subject CN) 9. TLS : Bad peer certificate (valid authority chain does not end at a trusted CA) 10. TLS : Bad peer certificate (the current time does not fall within the period of validity) 11. TLS : Bad peer certificate (certificate or cert in authority chain has been revoked) OPEN ISSUE: What about cases where the basic constraints or allowed uses are not appropriate? Is it worth putting in cases around self- signed certs? (i.e. self-signed cert, explicitly trusted, not trusted, etc.) How about cases where one or more certs in the chain to the root were not provided and not available through other means? Those seem like sensible cases to either include or explain why they aren't included. The self-signed cert is definitely a popular case among developers. 8. IANA Considerations No IANA actions are required. Jennings, et al. Expires May 27, 2010 [Page 31] Internet-Draft SIP Secure Call Flows November 2009 9. Acknowledgments Many thanks to the developers of all the open source software used to create these call flows. This includes the underlying crypto and TLS software used from openssl.org, the SIP stack from www.resiprocate.org, and the SIMPLE IMPP agent from www.sipimp.org. The TLS flow dumps were done with SSLDump from http://www.rtfm.com/ssldump. The book "SSL and TLS" [18] was a huge help in developing the code for these flows. It's sad there is no second edition. Thanks to Jim Schaad, Russ Housley, Eric Rescorla, Dan Wing, Tat Chan, and Lyndsay Campbell who all helped find and correct mistakes in this document. Vijay Gurbani and Alan Jeffrey contributed much of the additional test scenario content. 10. Security Considerations Implementers must never use any of the certificates provided in this document in anything but a test environment. Installing the CA root certificates used in this document as a trusted root in operational software would completely destroy the security of the system while giving the user the impression that the system was operating securely. This document recommends some things that implementers might test or verify to improve the security of their implementations. It is impossible to make a comprehensive list of these, and this document only suggests some of the most common mistakes that have been seen at the SIPit interoperability events. Just because an implementation does everything this document recommends does not make it secure. This document does not show the messages needed to check Certificate Revocation Lists (see RFC 5280 [4]) as that is not part of the SIP call flow. OPEN ISSUE: We should probably say something about CRLs. We need to get consensus on whether we want to recommend a method for retrieving CRLs. We could explicitly state that these are assumed to be retrieved out-of-band. Should they be retrieved by HTTP by some maintenance procedure? Via OCSP? Jennings, et al. Expires May 27, 2010 [Page 32] Internet-Draft SIP Secure Call Flows November 2009 11. Changelog (RFC Editor: remove this section) -00 to -01 * Addition of OPEN ISSUES. * Numerous minor edits from mailing list feedback. to -00 * Changed RFC 3369 references to RFC 3852. * Changed draft-ietf-sip-identity references to RFC 4474. * Added an ASN.1 dump of CMS signed content where SHA-1 parameters are omitted instead of being set to ASN.1 NULL. * Accept headers added to messages. * User and domain certificates are generated with EKU as specified in Draft SIP EKU [13]. * Message content that is shown is computed using certificates generated with EKU. * Message dump archive returned. * Message archive contains messages formed with and without EKU certificates. prior to -00 * Incorporated the Test cases from Vijay Gurbani's and Alan Jeffrey's Use of TLS in SIP draft * Began to capture the folklore around where identities are carried in certificates for use with SIP * Removed the message dump archive pending verification (will return in -02) 12. References 12.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [4] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. Jennings, et al. Expires May 27, 2010 [Page 33] Internet-Draft SIP Secure Call Flows November 2009 [5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [6] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [7] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [10] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004. [11] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. [12] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Messages", RFC 4475, May 2006. [13] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) for Session Initiation Protocol (SIP) X.509 Certificates", draft-ietf-sip-eku-04 (work in progress), April 2009. 12.2. Informative References [14] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, July 2005. [15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [16] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [17] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [18] Rescorla, E., "SSL and TLS - Designing and Building Secure Jennings, et al. Expires May 27, 2010 [Page 34] Internet-Draft SIP Secure Call Flows November 2009 Systems", 2001. [19] Rescorla, E., "SSLDump manpage". Appendix A. Making Test Certificates These scripts allow you to make certificates for test purposes. The certificates will all share a common CA root so that everyone running these scripts can have interoperable certificates. WARNING - these certificates are totally insecure and are for test purposes only. All the CA created by this script share the same private key to facilitate interoperability testing, but this totally breaks the security since the private key of the CA is well known. The instructions assume a Unix-like environment with openssl installed, but openssl does work in Windows too. OpenSSL version 0.9.8j was used to generate the certificates used in this document. Make sure you have openssl installed by trying to run "openssl". Run the makeCA script found in Appendix A.1; this creates a subdirectory called demoCA. If the makeCA script cannot find where your openssl is installed you will have to set an environment variable called OPENSSLDIR to whatever directory contains the file openssl.cnf. You can find this with a "locate openssl.cnf". You are now ready to make certificates. To create certs for use with TLS, run the makeCert script found in Appendix A.2 with the fully qualified domain name of the proxy you are making the certificate for. For example, "makeCert host.example.net". This will generate a private key and a certificate. The private key will be left in a file named domain_key_example.net.pem in pem format. The certificate will be in domain_cert_example.net.pem. Some programs expect both the certificate and private key combined together in a PKCS12 format file. This is created by the script and left in a file named example.net.p12. Some programs expect this file to have a .pfx extension instead of .p12 - just rename the file if needed. A file with a certificate signing request, called example.net.csr, is also created and can be used to get the certificate signed by another CA. A second argument indicating the number of days for which the certificate should be valid can be passed to the makeCert script. It is possible to make an expired certificate using the command "makeCert host.example.net 0". Anywhere that a password is used to protect a certificate, the password is set to the string "password". Jennings, et al. Expires May 27, 2010 [Page 35] Internet-Draft SIP Secure Call Flows November 2009 The root certificate for the CA is in the file root_cert_fluffyCA.pem. For things that need DER format certificates, a certificate can be converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM -out cert.der -outform DER". Some programs expect certificates in PKCS#7 format (with a file extension of .p7c). You can convert these from PEM format to PKCS#7 with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/ cacert.pem -outform DER -out cert.p7c" IE (version 8), Outlook Express (version 6), and Firefox (version 3.5) can import and export .p12 files and .p7c files. You can convert a pkcs7 certificate to PEM format with "openssl pkcs7 -in cert.p7c -inform DER -outform PEM -out cert.pem". The private key can be converted to pkcs8 format with "openssl pkcs8 -in a_key.pem -topk8 -outform DER -out a_key.p8c" OPEN ISSUE: The information in this section needs to be verified with the latest software versions. How to do conversions between supported types needs to be updated accordingly. In general, a TLS client will just need the root certificate of the CA. A TLS server will need its private key and its certificate. These could be in two PEM files, a single file with both certificate and private key PEM sections, or a single .p12 file. An S/MIME program will need its private key and certificate, the root certificate of the CA, and the certificate for every other user it communicates with. A.1. makeCA script #!/bin/sh set -x rm -rf demoCA mkdir demoCA mkdir demoCA/certs mkdir demoCA/crl mkdir demoCA/newcerts mkdir demoCA/private echo "01" > demoCA/serial hexdump -n 4 -e '4/1 "%04u"' /dev/random > demoCA/serial touch demoCA/index.txt Jennings, et al. Expires May 27, 2010 [Page 36] Internet-Draft SIP Secure Call Flows November 2009 # You may need to modify this for where your default file is # you can find where yours in by typing "openssl ca" for D in /etc/ssl /usr/local/ssl /sw/etc/ssl /sw/share/ssl; do CONF=${OPENSSLDIR:=$D}/openssl.cnf [ -f ${CONF} ] && break done CONF=${OPENSSLDIR}/openssl.cnf if [ ! -f $CONF ]; then echo "Can not find file $CONF - set your OPENSSLDIR variable" exit fi cp $CONF openssl.cnf cat >> openssl.cnf < demoCA/private/cakey.pem < demoCA/cacert.pem <