Internet Engineering Task Force (IETF) C. Jennings
Request for Comments: 6216 Cisco Systems
Category: Informational K. Ono
ISSN: 2070-1721 Columbia University
R. Sparks
B. Hibbard, Ed.
Tekelec
April 2011
Example Call Flows Using Session Initiation Protocol (SIP)
Security Mechanisms
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.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6216.
Jennings, et al. Informational [Page 1]
RFC 6216 SIP Secure Call Flows April 2011
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4
2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8
2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10
3. Call Flow with Message Over TLS . . . . . . . . . . . . . . . 12
3.1. TLS with Server Authentication . . . . . . . . . . . . . . 12
3.2. MESSAGE Transaction Over TLS . . . . . . . . . . . . . . . 13
4. Call Flow with S/MIME-Secured Message . . . . . . . . . . . . 15
4.1. MESSAGE Request with Signed Body . . . . . . . . . . . . . 15
4.2. MESSAGE Request with Encrypted Body . . . . . . . . . . . 20
4.3. MESSAGE Request with Encrypted and Signed Body . . . . . . 22
5. Observed Interoperability Issues . . . . . . . . . . . . . . . 27
6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35
A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 36
A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42
B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42
B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 51
B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 58
Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 64
Jennings, et al. Informational [Page 2]
RFC 6216 SIP Secure Call Flows April 2011
1. Introduction
This document is informational and is not normative on any aspect of
SIP.
SIP with TLS ([RFC5246]) implementations are becoming very common.
Several implementations of the S/MIME ([RFC5751]) portion of SIP
([RFC3261]) 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 hindered due to the lack of a commonly trusted certification
authority to sign the certificates used in the events. 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 to set up a mock
Certification Authority (CA) that can be used during the SIP
interoperability events. Certificate requests from the users will be
signed by the private key of the mock CA. The document also provides
some hints and clarifications for implementers.
A simple SIP call flow using SIPS URIs and TLS is shown in Section 3.
The certificates for the hosts used are shown in Section 2.2, and the
CA certificates used to sign these are shown in Section 2.1.
The text from Section 4.1 through Section 4.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 2.3. These host certificates are signed with the same mock
CA private key.
Section 5 presents a partial list of items that implementers should
consider in order to implement systems that will interoperate.
Scripts and instructions to make certificates that can be used for
interoperability testing are 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 document that can be used
for testing appear in Appendix C.
Jennings, et al. Informational [Page 3]
RFC 6216 SIP Secure Call Flows April 2011
2. Certificates
2.1. CA Certificates
The certificate used by the CA to sign the other certificates is
shown below. This is an X.509v3 ([X.509]) certificate. Note that
the X.509v3 Basic Constraints in the certificate allows it to be used
as a CA, certification authority. This certificate is not used
directly in the TLS call flow; it is used only to verify user and
host certificates.
Version: 3 (0x2)
Serial Number:
96:a3:84:17:4e:ef:8a:4c
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=sipit,
OU=Sipit Test Certificate Authority
Validity
Not Before: Jan 27 18:36:05 2011 GMT
Not After : Jan 3 18:36:05 2111 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: (2048 bit)
Modulus (2048 bit):
00:ab:1f:91:61:f1:1c:c5:cd:a6:7b:16:9b:b7:14:
79:e4:30:9e:98:d0:ec:07:b7:bd:77:d7:d1:f5:5b:
2c:e2:ee:e6:b1:b0:f0:85:fa:a5:bc:cb:cc:cf:69:
2c:4f:fc:50:ef:9d:31:2b:c0:59:ea:fb:64:6f:1f:
55:a7:3d:fd:70:d2:56:db:14:99:17:92:70:ac:26:
f8:34:41:70:d9:c0:03:91:6a:ba:d1:11:8f:ac:12:
31:de:b9:19:70:8d:5d:a7:7d:8b:19:cc:40:3f:ae:
ff:de:1f:db:94:b3:46:77:6c:ae:ae:ff:3e:d6:84:
5b:c2:de:0b:26:65:d0:91:c7:70:4b:c7:0a:4a:bf:
c7:97:04:dd:ba:58:47:cb:e0:2b:23:76:87:65:c5:
55:34:10:ab:27:1f:1c:f8:30:3d:b0:9b:ca:a2:81:
72:4c:bd:60:fe:f7:21:fe:0b:db:0b:db:e9:5b:01:
36:d4:28:15:6b:79:eb:d0:91:1b:21:59:b8:0e:aa:
bf:d5:b1:6c:70:37:a3:3f:a5:7d:0e:95:46:f6:f6:
58:67:83:75:42:37:18:0b:a4:41:39:b2:2f:6c:80:
2c:78:ec:a5:0f:be:9c:10:f8:c0:0b:0d:73:99:9e:
0d:d7:97:50:cb:cc:45:34:23:49:41:85:22:24:ad:
29:c3
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27
Jennings, et al. Informational [Page 4]
RFC 6216 SIP Secure Call Flows April 2011
X509v3 Authority Key Identifier:
95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
06:5f:9e:ae:a0:9a:bc:b5:b9:5b:7e:97:33:cc:df:63:98:98:
94:cb:0d:66:a9:83:e8:aa:58:2a:59:a1:9e:47:31:a6:af:5c:
3f:a2:25:86:f8:df:05:92:b7:db:69:a1:69:72:87:66:c5:ab:
35:89:01:37:19:c9:74:eb:09:d1:3f:88:7b:24:13:42:ca:2d:
fb:45:e6:cc:4b:f8:21:78:f3:f5:97:ec:09:92:24:a2:f0:e6:
94:8d:97:4a:00:94:00:bd:25:b8:17:2c:52:53:5d:cc:5c:48:
a4:a1:1d:2d:f6:50:55:13:a4:d3:b2:a2:f4:f1:b9:6d:48:5e:
5c:f3:de:e0:fc:59:09:a1:d9:14:61:65:bf:d8:3f:b9:ba:2e:
7c:ed:5c:24:9b:6b:ca:aa:5f:f1:c1:1e:b0:a8:da:82:0f:fb:
4c:71:3b:4d:7b:38:c8:e3:8a:2a:19:34:44:26:0b:ea:f0:47:
38:46:28:65:04:e2:01:52:dd:ec:3d:e5:f5:53:74:77:74:75:
6d:c6:d9:c2:0a:ac:3b:b8:98:5c:55:53:34:74:52:a8:26:b1:
2f:30:22:d0:8b:b7:f3:a0:dd:68:07:33:d5:ae:b7:81:b2:94:
58:72:4e:7c:c6:72:2f:bd:6c:69:fb:b5:17:a8:2a:8d:d7:2c:
91:06:c8:0c
The certificate content shown above and throughout this document was
rendered by the OpenSSL "x509" tool. These dumps are included only
as informative examples. Output may vary among future revisions of
the tool. At the time of this document's publication, there were
some irregularities in the presentation of Distinguished Names (DNs).
In particular, note that in the "Issuer" and "Subject" fields, it
appears the intent is to present DNs in Lightweight Directory Access
Protocol (LDAP) format. If this was intended, the spaces should have
been omitted after the delimiting commas, and the elements should
have been presented in order of most-specific to least-specific.
Please refer to Appendix A of [RFC4514]. Using the "Issuer" DN from
above as an example and following guidelines in [RFC4514], it should
have instead appeared as:
Issuer: OU=Sipit Test Certificate Authority,O=sipit,L=San Jose,
ST=California,C=US
The ASN.1 ([X.683]) parse of the CA certificate is shown below.
0:l= 949 cons: SEQUENCE
4:l= 669 cons: SEQUENCE
8:l= 3 cons: cont [ 0 ]
10:l= 1 prim: INTEGER :02
13:l= 9 prim: INTEGER :96A384174EEF8A4C
24:l= 13 cons: SEQUENCE
Jennings, et al. Informational [Page 5]
RFC 6216 SIP Secure Call Flows April 2011
26:l= 9 prim: OBJECT :sha1WithRSAEncryption
37:l= 0 prim: NULL
39:l= 112 cons: SEQUENCE
41:l= 11 cons: SET
43:l= 9 cons: SEQUENCE
45:l= 3 prim: OBJECT :countryName
50:l= 2 prim: PRINTABLESTRING :US
54:l= 19 cons: SET
56:l= 17 cons: SEQUENCE
58:l= 3 prim: OBJECT :stateOrProvinceName
63:l= 10 prim: UTF8STRING
43 61 6c 69 66 6f 72 6e-69 61 California
75:l= 17 cons: SET
77:l= 15 cons: SEQUENCE
79:l= 3 prim: OBJECT :localityName
84:l= 8 prim: UTF8STRING
53 61 6e 20 4a 6f 73 65- San Jose
94:l= 14 cons: SET
96:l= 12 cons: SEQUENCE
98:l= 3 prim: OBJECT :organizationName
103:l= 5 prim: UTF8STRING
73 69 70 69 74 sipit
110:l= 41 cons: SET
112:l= 39 cons: SEQUENCE
114:l= 3 prim: OBJECT :organizationalUnitName
119:l= 32 prim: UTF8STRING
53 69 70 69 74 20 54 65-73 74 20 43 65 72 74 69 Sipit Test Certi
66 69 63 61 74 65 20 41-75 74 68 6f 72 69 74 79 ficate Authority
153:l= 32 cons: SEQUENCE
155:l= 13 prim: UTCTIME :110127183605Z
170:l= 15 prim: GENERALIZEDTIME :21110103183605Z
187:l= 112 cons: SEQUENCE
189:l= 11 cons: SET
191:l= 9 cons: SEQUENCE
193:l= 3 prim: OBJECT :countryName
198:l= 2 prim: PRINTABLESTRING :US
202:l= 19 cons: SET
204:l= 17 cons: SEQUENCE
206:l= 3 prim: OBJECT :stateOrProvinceName
211:l= 10 prim: UTF8STRING
43 61 6c 69 66 6f 72 6e-69 61 California
223:l= 17 cons: SET
225:l= 15 cons: SEQUENCE
227:l= 3 prim: OBJECT :localityName
232:l= 8 prim: UTF8STRING
53 61 6e 20 4a 6f 73 65- San Jose
242:l= 14 cons: SET
244:l= 12 cons: SEQUENCE
Jennings, et al. Informational [Page 6]
RFC 6216 SIP Secure Call Flows April 2011
246:l= 3 prim: OBJECT :organizationName
251:l= 5 prim: UTF8STRING
73 69 70 69 74 sipit
258:l= 41 cons: SET
260:l= 39 cons: SEQUENCE
262:l= 3 prim: OBJECT :organizationalUnitName
267:l= 32 prim: UTF8STRING
53 69 70 69 74 20 54 65-73 74 20 43 65 72 74 69 Sipit Test Certi
66 69 63 61 74 65 20 41-75 74 68 6f 72 69 74 79 ficate Authority
301:l= 290 cons: SEQUENCE
305:l= 13 cons: SEQUENCE
307:l= 9 prim: OBJECT :rsaEncryption
318:l= 0 prim: NULL
320:l= 271 prim: BIT STRING
00 30 82 01 0a 02 82 01-01 00 ab 1f 91 61 f1 1c .0...........a..
c5 cd a6 7b 16 9b b7 14-79 e4 30 9e 98 d0 ec 07 ...{....y.0.....
b7 bd 77 d7 d1 f5 5b 2c-e2 ee e6 b1 b0 f0 85 fa ..w...[,........
a5 bc cb cc cf 69 2c 4f-fc 50 ef 9d 31 2b c0 59 .....i,O.P..1+.Y
ea fb 64 6f 1f 55 a7 3d-fd 70 d2 56 db 14 99 17 ..do.U.=.p.V....
92 70 ac 26 f8 34 41 70-d9 c0 03 91 6a ba d1 11 .p.&.4Ap....j...
8f ac 12 31 de b9 19 70-8d 5d a7 7d 8b 19 cc 40 ...1...p.].}...@
3f ae ff de 1f db 94 b3-46 77 6c ae ae ff 3e d6 ?.......Fwl...>.
84 5b c2 de 0b 26 65 d0-91 c7 70 4b c7 0a 4a bf .[...&e...pK..J.
c7 97 04 dd ba 58 47 cb-e0 2b 23 76 87 65 c5 55 .....XG..+#v.e.U
34 10 ab 27 1f 1c f8 30-3d b0 9b ca a2 81 72 4c 4..'...0=.....rL
bd 60 fe f7 21 fe 0b db-0b db e9 5b 01 36 d4 28 .`..!......[.6.(
15 6b 79 eb d0 91 1b 21-59 b8 0e aa bf d5 b1 6c .ky....!Y......l
70 37 a3 3f a5 7d 0e 95-46 f6 f6 58 67 83 75 42 p7.?.}..F..Xg.uB
37 18 0b a4 41 39 b2 2f-6c 80 2c 78 ec a5 0f be 7...A9./l.,x....
9c 10 f8 c0 0b 0d 73 99-9e 0d d7 97 50 cb cc 45 ......s.....P..E
34 23 49 41 85 22 24 ad-29 c3 02 03 01 00 01 4#IA."$.)......
595:l= 80 cons: cont [ 3 ]
597:l= 78 cons: SEQUENCE
599:l= 29 cons: SEQUENCE
601:l= 3 prim: OBJECT :X509v3 Subject Key Identifier
606:l= 22 prim: OCTET STRING
04 14 95 45 7e 5f 2b ea-65 98 12 91 04 f3 63 c7 ...E~_+.e.....c.
68 9a 58 16 77 27 h.X.w'
630:l= 31 cons: SEQUENCE
632:l= 3 prim: OBJECT :X509v3 Authority Key Identifier
637:l= 24 prim: OCTET STRING
30 16 80 14 95 45 7e 5f-2b ea 65 98 12 91 04 f3 0....E~_+.e.....
63 c7 68 9a 58 16 77 27- c.h.X.w'
663:l= 12 cons: SEQUENCE
665:l= 3 prim: OBJECT :X509v3 Basic Constraints
670:l= 5 prim: OCTET STRING
30 03 01 01 ff 0....
677:l= 13 cons: SEQUENCE
Jennings, et al. Informational [Page 7]
RFC 6216 SIP Secure Call Flows April 2011
679:l= 9 prim: OBJECT :sha1WithRSAEncryption
690:l= 0 prim: NULL
692:l= 257 prim: BIT STRING
00 06 5f 9e ae a0 9a bc-b5 b9 5b 7e 97 33 cc df .._.......[~.3..
63 98 98 94 cb 0d 66 a9-83 e8 aa 58 2a 59 a1 9e c.....f....X*Y..
47 31 a6 af 5c 3f a2 25-86 f8 df 05 92 b7 db 69 G1..\?.%.......i
a1 69 72 87 66 c5 ab 35-89 01 37 19 c9 74 eb 09 .ir.f..5..7..t..
d1 3f 88 7b 24 13 42 ca-2d fb 45 e6 cc 4b f8 21 .?.{$.B.-.E..K.!
78 f3 f5 97 ec 09 92 24-a2 f0 e6 94 8d 97 4a 00 x......$......J.
94 00 bd 25 b8 17 2c 52-53 5d cc 5c 48 a4 a1 1d ...%..,RS].\H...
2d f6 50 55 13 a4 d3 b2-a2 f4 f1 b9 6d 48 5e 5c -.PU........mH^\
f3 de e0 fc 59 09 a1 d9-14 61 65 bf d8 3f b9 ba ....Y....ae..?..
2e 7c ed 5c 24 9b 6b ca-aa 5f f1 c1 1e b0 a8 da .|.\$.k.._......
82 0f fb 4c 71 3b 4d 7b-38 c8 e3 8a 2a 19 34 44 ...Lq;M{8...*.4D
26 0b ea f0 47 38 46 28-65 04 e2 01 52 dd ec 3d &...G8F(e...R..=
e5 f5 53 74 77 74 75 6d-c6 d9 c2 0a ac 3b b8 98 ..Stwtum.....;..
5c 55 53 34 74 52 a8 26-b1 2f 30 22 d0 8b b7 f3 \US4tR.&./0"....
a0 dd 68 07 33 d5 ae b7-81 b2 94 58 72 4e 7c c6 ..h.3......XrN|.
72 2f bd 6c 69 fb b5 17-a8 2a 8d d7 2c 91 06 c8 r/.li....*..,...
0c .
2.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:
96:a3:84:17:4e:ef:8a:4f
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=sipit,
OU=Sipit Test Certificate Authority
Validity
Not Before: Feb 7 19:32:17 2011 GMT
Not After : Jan 14 19:32:17 2111 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:dd:74:06:02:10:c2:e7:04:1f:bc:8c:b6:24:e7:
9b:94:a3:48:37:85:9e:6d:83:12:84:50:1a:8e:48:
b1:fa:86:8c:a7:80:b9:be:52:ec:a6:ca:63:47:84:
ad:f6:74:85:82:16:7e:4e:36:40:0a:74:2c:20:a9:
6a:0e:6a:7f:35:cf:70:71:63:7d:e9:43:67:81:4c:
ea:b5:1e:b7:4c:a3:35:08:7b:21:0d:2a:73:07:63:
9d:8d:75:bf:1f:d4:8e:e6:67:60:75:f7:ea:0a:7a:
Jennings, et al. Informational [Page 8]
RFC 6216 SIP Secure Call Flows April 2011
6c:90:af:92:45:e0:62:05:9a:8a:10:98:dc:7c:54:
8b:e4:61:95:3b:04:fc:10:50:ef:80:45:ba:5e:84:
97:76:c1:20:25:c1:92:1d:89:0a:f7:55:62:64:fa:
e8:69:a2:62:4c:67:d3:08:d9:61:b5:3d:16:54:b6:
b7:44:8d:59:2b:90:d4:e9:fb:c7:7d:87:58:c3:12:
ac:33:78:00:50:ba:07:05:b3:b9:01:1a:63:55:6c:
e1:7a:ec:a3:07:ae:3b:02:83:a1:69:e0:c3:dc:2d:
61:e9:b2:e3:b3:71:c8:a6:cf:da:fb:3e:99:c7:e5:
71:b9:c9:17:d4:ed:bc:a0:47:54:09:8c:6e:6d:53:
9a:2c:c9:68:c6:6f:f1:3d:91:1a:24:43:77:7d:91:
69:4b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:example.com, URI:sip:example.com
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
CC:06:59:5B:8B:5E:D6:0D:F2:05:4D:1B:68:54:1E:FC:F9:43:19:17
X509v3 Authority Key Identifier:
95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27
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
6a:9a:d1:db:00:4b:90:86:b0:53:ea:6f:30:31:89:1e:9b:09:
14:bd:6f:b9:02:aa:6f:58:ee:30:03:b8:a1:fd:b3:41:72:ff:
b3:0d:cb:76:a7:17:c6:57:38:06:13:e5:f3:e4:30:17:4d:f7:
97:b5:f3:74:e9:81:f8:f4:55:a3:0d:f5:82:38:c3:98:43:52:
1f:84:cd:1a:b4:a3:45:9f:3d:e2:31:fd:cb:a2:ad:ed:60:7d:
fa:d2:aa:49:2f:41:a9:80:01:bb:ed:b6:75:c9:97:69:7f:0c:
91:60:f1:c4:5a:36:e8:5c:ac:e1:a8:e7:9a:55:e5:e0:cd:01:
f4:de:93:f4:38:6c:c1:71:d2:fd:cd:1b:5d:25:eb:90:7b:31:
41:e7:37:0e:e5:c0:01:48:91:f7:34:dd:c6:1f:74:e6:34:34:
e6:cd:93:0f:3f:ce:94:ad:91:d9:e2:72:b1:9f:1d:d3:a5:7d:
5e:e2:a4:56:c5:b1:71:4d:10:0a:5d:a6:56:e6:57:1f:48:a5:
5c:75:67:ea:ab:35:3e:f6:b6:fa:c1:f3:8a:c1:80:71:32:18:
6c:33:b5:fa:16:5a:16:e1:a1:6c:19:67:f5:45:68:64:6f:b2:
31:dc:e3:5a:1a:b2:d4:87:89:96:fd:87:ba:38:4e:0a:19:07:
03:4b:9b:b1
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
Jennings, et al. Informational [Page 9]
RFC 6216 SIP Secure Call Flows April 2011
non-root CAs will have a length greater than two. For more details
on how certificate chains are validated, see Sections 6.1 and 6.2 of
[RFC5280].
2.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 Common Profile for Instant
Messaging (CPIM) gateway. In this example, example.com is the domain
for fluffy. The message could be coming from any host in
*.example.com, and the address-of-record (AOR) in the user
certificate would still be the same. The others are shown in
Appendix B.1. These certificates make use of the Extended Key Usage
(EKU) extension discussed in [RFC5924]. Note that the X509v3
Extended Key Usage attribute refers to the SIP OID introduced in
[RFC5924], which is 1.3.6.1.5.5.7.3.20.
Version: 3 (0x2)
Serial Number:
96:a3:84:17:4e:ef:8a:4d
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=sipit,
OU=Sipit Test Certificate Authority
Validity
Not Before: Feb 7 19:32:17 2011 GMT
Not After : Jan 14 19:32:17 2111 GMT
Subject: C=US, ST=California, L=San Jose, O=sipit,
CN=fluffy
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit)
Modulus (2048 bit):
00:a3:2c:59:0c:e9:bc:e4:ec:d3:9e:fb:99:02:ec:
b1:36:3a:b7:d3:1d:4d:c3:3a:b6:ae:50:bd:5f:55:
08:77:8c:7e:a4:e9:f0:68:31:28:8f:23:32:56:19:
c3:22:97:a7:6d:fd:a7:22:2a:01:b5:af:61:bd:5f:
7e:c1:14:e5:98:29:b4:34:4e:38:8a:26:ee:0d:da:
db:27:b9:78:d6:ac:ac:04:78:32:98:c2:75:e7:6a:
b7:2d:b3:3c:e3:eb:97:a5:ef:8b:59:42:50:17:7b:
fe:a7:81:af:37:a7:e7:e3:1f:b0:8d:d0:72:2f:6c:
14:42:c6:01:68:e1:8f:fd:56:4d:7d:cf:16:dc:aa:
05:61:0b:0a:ca:ca:ec:51:ec:53:6e:3d:2b:00:80:
fe:35:1b:06:0a:61:13:88:0b:44:f3:cc:fd:2b:0e:
b4:a2:0b:a0:97:84:14:2e:ee:2b:e3:2f:c1:1a:9e:
86:9a:78:6a:a2:4c:57:93:e7:01:26:d3:56:0d:bd:
Jennings, et al. Informational [Page 10]
RFC 6216 SIP Secure Call Flows April 2011
b0:2f:f8:da:c7:3c:01:dc:cb:2d:31:8c:6c:c6:5c:
b4:63:e8:b2:a2:40:11:bf:ad:f8:6d:12:01:97:1d:
47:f8:6a:15:8b:fb:27:96:73:44:46:34:d7:24:1c:
cf:56:8d:d4:be:d6:94:5b:f0:a6:67:e3:dd:cf:b4:
f2:d5
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:
85:97:09:B8:D3:55:37:24:8A:DC:DE:E3:91:72:E4:22:CF:98:87:52
X509v3 Authority Key Identifier:
95:45:7E:5F:2B:EA:65:98:12:91:04:F3:63:C7:68:9A:58:16:77:27
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
a8:a9:8f:d8:8a:0b:88:ed:ff:4f:bf:e5:cd:8f:9e:7b:b8:e6:
f2:2c:aa:e3:23:5b:9a:71:5e:fd:20:a3:dd:d9:d3:c1:f2:e8:
f0:be:77:db:33:cc:8a:7b:4f:91:2b:8d:d6:f7:14:c3:8d:e0:
60:d3:34:50:bc:be:67:22:cd:f5:74:7b:f4:9a:68:a2:52:2b:
81:2f:46:d3:09:9f:25:c3:20:e8:10:d5:ef:38:7b:d1:17:d4:
f1:d7:54:67:56:f1:13:cf:2f:fc:8b:83:fc:14:e7:01:82:59:
83:cc:b1:8d:f0:c7:da:4e:b1:dc:cc:54:cf:6c:3b:47:47:59:
87:d9:16:ec:af:af:e1:12:13:23:1e:0a:db:f5:b5:ff:5d:ab:
15:0e:e3:25:91:00:0e:90:db:d8:07:11:90:81:01:3a:48:a8:
aa:9e:b0:62:d3:36:f0:0c:b7:2f:a7:17:92:52:36:29:14:0a:
d6:65:86:67:73:74:6e:aa:3c:ee:47:38:1e:c8:6e:06:81:85:
1c:2e:f0:b6:04:7d:6c:38:db:81:9c:b8:07:e3:07:be:f5:2f:
09:68:63:04:6b:87:0e:36:b9:a1:a3:fb:c8:30:0c:a0:63:8d:
6d:ab:0a:f8:44:b0:78:19:1a:38:7e:fa:6a:a1:d4:4b:4b:75:
75:bf:6f:09
Versions of these certificates that do not make use of EKU are also
included in Appendix B.2
Jennings, et al. Informational [Page 11]
RFC 6216 SIP Secure Call Flows April 2011
3. Call Flow with Message Over TLS
3.1. TLS with Server Authentication
The flow below shows the edited SSLDump output of the host
example.com forming a TLS [RFC5246] 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 [RFC5246]. 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 [EKR-TLS]. For more details on the SSLDump tool, see the
SSLDump Manual [ssldump-manpage].
This example does not use the Server Extended Hello (see [RFC5246]).
New TCP connection #1: example.com(50738) <-> example.net(5061)
1 1 0.0004 (0.0004) C>SV3.1(101) Handshake
ClientHello
Version 3.1
random[32]=
4c 09 5b a7 66 77 eb 43 52 30 dd 98 4d 09 23 d3
ff 81 74 ab 04 69 bb 79 8c dc 59 cd c2 1f b7 ec
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
Jennings, et al. Informational [Page 12]
RFC 6216 SIP Secure Call Flows April 2011
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
compression methods
NULL
1 2 0.0012 (0.0007) S>CV3.1(48) Handshake
ServerHello
Version 3.1
random[32]=
4c 09 5b a7 30 87 74 c7 16 98 24 d5 af 35 17 a7
ef c3 78 0c 94 d4 94 d2 7b a6 3f 40 04 25 f6 e0
session_id[0]=
cipherSuite TLS_RSA_WITH_AES_256_CBC_SHA
compressionMethod NULL
1 3 0.0012 (0.0000) S>CV3.1(1858) Handshake
Certificate
1 4 0.0012 (0.0000) S>CV3.1(14) Handshake
CertificateRequest
certificate_types rsa_sign
certificate_types dss_sign
certificate_types unknown value
ServerHelloDone
1 5 0.0043 (0.0031) C>SV3.1(7) Handshake
Certificate
1 6 0.0043 (0.0000) C>SV3.1(262) Handshake
ClientKeyExchange
1 7 0.0043 (0.0000) C>SV3.1(1) ChangeCipherSpec
1 8 0.0043 (0.0000) C>SV3.1(48) Handshake
1 9 0.0129 (0.0085) S>CV3.1(170) Handshake
1 10 0.0129 (0.0000) S>CV3.1(1) ChangeCipherSpec
1 11 0.0129 (0.0000) S>CV3.1(48) Handshake
1 12 0.0134 (0.0005) C>SV3.1(32) application_data
1 13 0.0134 (0.0000) C>SV3.1(496) application_data
1 14 0.2150 (0.2016) S>CV3.1(32) application_data
1 15 0.2150 (0.0000) S>CV3.1(336) application_data
1 16 12.2304 (12.0154) S>CV3.1(32) Alert
1 12.2310 (0.0005) S>C TCP FIN
1 17 12.2321 (0.0011) C>SV3.1(32) Alert
3.2. MESSAGE Transaction Over TLS
Once the TLS session is set up, the following MESSAGE request (as
defined in [RFC3428] 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 [RFC4475] is used to break long
lines. The actual message does not contain the line breaks contained
within those tags.
Jennings, et al. Informational [Page 13]
RFC 6216 SIP Secure Call Flows April 2011
MESSAGE sips:kumiko@example.net:5061 SIP/2.0
Via: SIP/2.0/TLS 192.0.2.2:15001;
branch=z9hG4bK-d8754z-c785a077a9a8451b-1---d8754z-;
rport=50738
Max-Forwards: 70
To:
From: ;tag=1a93430b
Call-ID: OTZmMDE2OWNlYTVjNDkzYzBhMWRlMDU4NDExZmU4ZTQ.
CSeq: 4308 MESSAGE
Accept: multipart/signed, text/plain, application/pkcs7-mime,
application/sdp, multipart/alternative
Content-Type: text/plain
Content-Length: 6
Hello!
When a User Agent (UA) goes to send a message to example.com, the UA
can see if it already has a TLS connection to example.com and if it
does, it may send the message over this connection. A UA should have
some scheme for reusing connections as opening a new TLS connection
for every message results in awful performance. Implementers are
encouraged to read [RFC5923] and [RFC3263].
The response is sent from example.net to example.com over the same
TLS connection. It is shown below.
SIP/2.0 200 OK
Via: SIP/2.0/TLS 192.0.2.2:15001;
branch=z9hG4bK-d8754z-c785a077a9a8451b-1---d8754z-;
rport=50738
To: ;tag=0d075510
From: ;tag=1a93430b
Call-ID: OTZmMDE2OWNlYTVjNDkzYzBhMWRlMDU4NDExZmU4ZTQ.
CSeq: 4308 MESSAGE
Content-Length: 0
Jennings, et al. Informational [Page 14]
RFC 6216 SIP Secure Call Flows April 2011
4. Call Flow with S/MIME-Secured Message
4.1. MESSAGE Request 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 are not broken
across lines in actual implementations.
MESSAGE sip:kumiko@example.net SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2:15001;
branch=z9hG4bK-d8754z-3a922b6dc0f0ff37-1---d8754z-;
rport=50739
Max-Forwards: 70
To:
From: ;tag=ef6bad5e
Call-ID: N2NiZjI0NjRjNDQ0MTY1NDRjNWNmMGU1MDA2MDRhYmI.
CSeq: 8473 MESSAGE
Accept: multipart/signed, text/plain, application/pkcs7-mime,
application/sdp, multipart/alternative
Content-Type: multipart/signed;boundary=3b515e121b43a911;
micalg=sha1;protocol="application/pkcs7-signature"
Content-Length: 774
--3b515e121b43a911
Content-Type: text/plain
Content-Transfer-Encoding: binary
Hello!
--3b515e121b43a911
Content-Type: application/pkcs7-signature;name=smime.p7s
Content-Disposition: attachment;handling=required;
filename=smime.p7s
Content-Transfer-Encoding: binary
*****************
* BINARY BLOB 1 *
*****************
--3b515e121b43a911--
Jennings, et al. Informational [Page 15]
RFC 6216 SIP Secure Call Flows April 2011
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 is not 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 "!"
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
certificate is not attached as it is optional in [RFC5652].
0 472: SEQUENCE {
4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
15 457: [0] {
19 453: 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 420: SET {
56 416: SEQUENCE {
60 1: INTEGER 1
63 125: 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: UTF8String 'California'
Jennings, et al. Informational [Page 16]
RFC 6216 SIP Secure Call Flows April 2011
: }
: }
101 17: SET {
103 15: SEQUENCE {
105 3: OBJECT IDENTIFIER localityName (2 5 4 7)
110 8: UTF8String 'San Jose'
: }
: }
120 14: SET {
122 12: SEQUENCE {
124 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
129 5: UTF8String 'sipit'
: }
: }
136 41: SET {
138 39: SEQUENCE {
140 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
145 32: UTF8String 'Sipit Test Certificate
Authority'
: }
: }
: }
179 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D
: }
190 9: SEQUENCE {
192 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
199 0: NULL
: }
201 13: SEQUENCE {
203 9: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
214 0: NULL
: }
216 256: OCTET STRING
: 74 4D 21 39 D6 E2 E2 2C 30 5A AA BC 4E 60 8D 69
: A7 E5 79 50 1A B1 7D 4A D3 C1 03 9F 19 7D A2 76
: 97 B3 CE 30 CD 62 4B 96 20 35 DB C1 64 D9 33 92
: 96 CD 28 03 98 6E 2C 0C F6 8D 93 40 F2 88 DA 29
: AD 0B C2 0E F9 D3 6A 95 2C 79 6E C2 3D 62 E6 54
: A9 1B AC 66 DB 16 B7 44 6C 03 1B 71 9C EE C9 EC
: 4D 93 B1 CF F5 17 79 C5 C8 BA 2F A7 6C 4B DC CF
: 62 A3 F3 1A 1B 24 E4 40 66 3C 4F 87 86 BF 09 6A
: 7A 43 60 2B FC D8 3D 2B 57 17 CB 81 03 2A 56 69
: 81 82 FA 78 DE D2 3A 2F FA A3 C5 EA 8B E8 0C 36
: 1B BC DC FD 1B 8C 2E 0F 01 AF D9 E1 04 0E 4E 50
: 94 75 7C BD D9 0B DD AA FA 36 E3 EC E4 A5 35 46
Jennings, et al. Informational [Page 17]
RFC 6216 SIP Secure Call Flows April 2011
: BE A2 97 1D AD BA 44 54 3A ED 94 DA 76 4A 51 BA
: A4 7D 7A 62 BF 2A 2F F2 5C 5A FE CA E6 B9 DC 5D
: EA 26 F2 35 17 19 20 CE 97 96 4E 72 9C 72 FD 1F
: 68 C1 6A 5C 86 42 F2 ED F2 70 65 4C C7 44 C5 7C
: }
: }
: }
: }
: }
SHA-1 parameters may be omitted entirely, instead of being set to
NULL, as mentioned in [RFC3370]. 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 [RFC3370]. This is the
preferred encoding. This is covered in greater detail in Section 5.
0 468: SEQUENCE {
4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
15 453: [0] {
19 449: 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 418: SET {
54 414: SEQUENCE {
58 1: INTEGER 1
61 125: 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: UTF8String 'California'
: }
: }
99 17: SET {
Jennings, et al. Informational [Page 18]
RFC 6216 SIP Secure Call Flows April 2011
101 15: SEQUENCE {
103 3: OBJECT IDENTIFIER localityName (2 5 4 7)
108 8: UTF8String 'San Jose'
: }
: }
118 14: SET {
120 12: SEQUENCE {
122 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
127 5: UTF8String 'sipit'
: }
: }
134 41: SET {
136 39: SEQUENCE {
138 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
143 32: UTF8String 'Sipit Test Certificate
Authority'
: }
: }
: }
177 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D
: }
188 7: SEQUENCE {
190 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: }
197 13: SEQUENCE {
199 9: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
210 0: NULL
: }
212 256: OCTET STRING
: 74 4D 21 39 D6 E2 E2 2C 30 5A AA BC 4E 60 8D 69
: A7 E5 79 50 1A B1 7D 4A D3 C1 03 9F 19 7D A2 76
: 97 B3 CE 30 CD 62 4B 96 20 35 DB C1 64 D9 33 92
: 96 CD 28 03 98 6E 2C 0C F6 8D 93 40 F2 88 DA 29
: AD 0B C2 0E F9 D3 6A 95 2C 79 6E C2 3D 62 E6 54
: A9 1B AC 66 DB 16 B7 44 6C 03 1B 71 9C EE C9 EC
: 4D 93 B1 CF F5 17 79 C5 C8 BA 2F A7 6C 4B DC CF
: 62 A3 F3 1A 1B 24 E4 40 66 3C 4F 87 86 BF 09 6A
: 7A 43 60 2B FC D8 3D 2B 57 17 CB 81 03 2A 56 69
: 81 82 FA 78 DE D2 3A 2F FA A3 C5 EA 8B E8 0C 36
: 1B BC DC FD 1B 8C 2E 0F 01 AF D9 E1 04 0E 4E 50
: 94 75 7C BD D9 0B DD AA FA 36 E3 EC E4 A5 35 46
: BE A2 97 1D AD BA 44 54 3A ED 94 DA 76 4A 51 BA
: A4 7D 7A 62 BF 2A 2F F2 5C 5A FE CA E6 B9 DC 5D
: EA 26 F2 35 17 19 20 CE 97 96 4E 72 9C 72 FD 1F
: 68 C1 6A 5C 86 42 F2 ED F2 70 65 4C C7 44 C5 7C
Jennings, et al. Informational [Page 19]
RFC 6216 SIP Secure Call Flows April 2011
: }
: }
: }
: }
: }
4.2. MESSAGE Request 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".
MESSAGE sip:kumiko@example.net SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2:15001;
branch=z9hG4bK-d8754z-c276232b541dd527-1---d8754z-;
rport=50741
Max-Forwards: 70
To:
From: ;tag=7a2e3025
Call-ID: MDYyMDhhODA3NWE2ZjEyYzAwOTZlMjExNWI2ZWQwZGM.
CSeq: 3260 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: 565
*****************
* BINARY BLOB 2 *
*****************
Following is the ASN.1 parsing of "BINARY BLOB 2". Note that at
address 454, the encryption is set to aes128-CBC.
0 561: SEQUENCE {
4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
15 546: [0] {
Jennings, et al. Informational [Page 20]
RFC 6216 SIP Secure Call Flows April 2011
19 542: SEQUENCE {
23 1: INTEGER 0
26 409: SET {
30 405: SEQUENCE {
34 1: INTEGER 0
37 125: 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: UTF8String 'California'
: }
: }
75 17: SET {
77 15: SEQUENCE {
79 3: OBJECT IDENTIFIER localityName (2 5 4 7)
84 8: UTF8String 'San Jose'
: }
: }
94 14: SET {
96 12: SEQUENCE {
98 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
103 5: UTF8String 'sipit'
: }
: }
110 41: SET {
112 39: SEQUENCE {
114 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
119 32: UTF8String 'Sipit Test Certificate
Authority'
: }
: }
: }
153 9: INTEGER 00 96 A3 84 17 4E EF 8A 4E
: }
164 13: SEQUENCE {
166 9: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
177 0: NULL
Jennings, et al. Informational [Page 21]
RFC 6216 SIP Secure Call Flows April 2011
: }
179 256: OCTET STRING
: B9 12 8F 32 AB 4A E2 38 C1 E0 53 69 88 D6 25 E7
: 40 03 B1 DE 79 21 A3 E8 23 5A 1B CB FB 58 F4 97
: 48 A7 C8 F0 3D DF 41 A3 5A 90 32 70 82 FA B0 DE
: D8 94 7C 6C 2E 01 FE 33 BD 62 CB 07 4F 58 DE 6F
: EA 3F EF B4 FB 46 72 58 9A 88 A0 85 BC 23 D7 C8
: 09 0B 90 8D 4A 5F 3F 96 7C AC D4 E2 19 E8 02 B6
: 0E F3 0D F2 91 4A 67 A9 EE 51 6A 97 D7 86 6D EC
: 78 6E C6 E0 83 7C E1 00 1F 5A 40 59 60 0C D7 EB
: A3 FB 04 B3 C9 A5 EB 79 ED B3 56 F8 F6 51 B2 5E
: 58 E2 D8 17 28 33 A6 B8 35 8C 0E 14 7F 90 D0 7B
: 03 00 6C 3D 81 29 F5 D7 E5 AC 75 5E E0 F0 DD E3
: 3E B2 06 97 D6 49 A9 CB 38 08 F1 84 05 F5 C0 BC
: 55 A6 D4 C9 D8 FD A4 AC 40 9F 9D 51 5B F7 3A C3
: C3 CD 3A E7 6D 21 05 D0 50 75 4F 14 D8 77 76 C6
: 13 A6 48 12 7B 25 CC 22 5D 73 BD 40 E4 15 02 A2
: 39 4A CB D9 55 08 A4 EE 4E 8A 5E BA C4 4A 46 9C
: }
: }
439 124: SEQUENCE {
441 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
452 29: SEQUENCE {
454 9: OBJECT IDENTIFIER
: aes128-CBC (2 16 840 1 101 3 4 1 2)
465 16: OCTET STRING
: CA 35 CA BD 1E 78 83 D9 20 6C 47 B9 9F DC 91 88
: }
483 80: [0]
: 1B AE 12 C4 0E 55 96 AB 99 CC 1C 7F B5 98 A4 BF
: D2 D8 7F 94 BB B5 38 05 59 F2 38 A1 CD 29 75 17
: 1D 63 1B 0B B0 2D 88 06 7F 78 80 F3 5A 3E DC 35
: BF 22 1E 03 32 59 98 DA FD 81 5F D9 41 63 3A 18
: FD B5 84 14 01 46 0B 40 EB 56 29 86 47 8B D1 EE
: }
: }
: }
: }
4.3. MESSAGE Request with Encrypted and Signed Body
In the example below, some of the header values have been split
across multiple lines. Where the lines have been broken, the
convention has been used. This was only done to make it
fit in the RFC format. Specifically, the application/pkcs7-mime
Content-Type line is 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
Jennings, et al. Informational [Page 22]
RFC 6216 SIP Secure Call Flows April 2011
encrypted content has been replaced with "BINARY BLOB 3", and the
binary signed content has been replaced with "BINARY BLOB 4".
MESSAGE sip:kumiko@example.net SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2:15001;
branch=z9hG4bK-d8754z-97a26e59b7262b34-1---d8754z-;
rport=50742
Max-Forwards: 70
To:
From: ;tag=379f5b27
Call-ID: MjYwMzdjYTY3YWRkYzgzMjU0MGI4Mzc2Njk1YzJlNzE.
CSeq: 5449 MESSAGE
Accept: multipart/signed, text/plain, application/pkcs7-mime,
application/sdp, multipart/alternative
Content-Type: multipart/signed;boundary=e8df6e1ce5d1e864;
micalg=sha1;protocol="application/pkcs7-signature"
Content-Length: 1455
--e8df6e1ce5d1e864
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 *
*****************
--e8df6e1ce5d1e864
Content-Type: application/pkcs7-signature;name=smime.p7s
Content-Disposition: attachment;handling=required;
filename=smime.p7s
Content-Transfer-Encoding: binary
*****************
* BINARY BLOB 4 *
Jennings, et al. Informational [Page 23]
RFC 6216 SIP Secure Call Flows April 2011
*****************
--e8df6e1ce5d1e864--
Below is the ASN.1 parsing of "BINARY BLOB 3".
0 561: SEQUENCE {
4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
15 546: [0] {
19 542: SEQUENCE {
23 1: INTEGER 0
26 409: SET {
30 405: SEQUENCE {
34 1: INTEGER 0
37 125: 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: UTF8String 'California'
: }
: }
75 17: SET {
77 15: SEQUENCE {
79 3: OBJECT IDENTIFIER localityName (2 5 4 7)
84 8: UTF8String 'San Jose'
: }
: }
94 14: SET {
96 12: SEQUENCE {
98 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
103 5: UTF8String 'sipit'
: }
: }
110 41: SET {
112 39: SEQUENCE {
114 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
119 32: UTF8String 'Sipit Test Certificate
Authority'
: }
Jennings, et al. Informational [Page 24]
RFC 6216 SIP Secure Call Flows April 2011
: }
: }
153 9: INTEGER 00 96 A3 84 17 4E EF 8A 4E
: }
164 13: SEQUENCE {
166 9: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
177 0: NULL
: }
179 256: OCTET STRING
: 49 11 0B 11 52 A9 9D E3 AA FB 86 CB EB 12 CC 8E
: 96 9D 85 3E 80 D2 7C C4 9B B7 81 4B B5 FA 13 80
: 6A 6A B2 34 72 D8 C0 82 60 DA B3 43 F8 51 8C 32
: 8B DD D0 76 6D 9C 46 73 C1 44 A0 10 FF 16 A4 83
: 74 85 21 74 7D E0 FD 42 C0 97 00 82 A2 80 81 22
: 9C A2 82 0A 85 F0 68 EF 9A D7 6D 1D 24 2B A9 5E
: B3 9A A0 3E A7 D9 1D 1C D7 42 CB 6F A5 81 66 23
: 28 00 7C 99 6A B6 03 3F 7E F6 48 EA 91 49 35 F1
: FD 40 54 5D AC F7 84 EA 3F 27 43 FD DE E2 10 DD
: 63 C4 35 4A 13 63 0B 6D 0D 9A D5 AB 72 39 69 8C
: 65 4C 44 C4 A3 31 60 79 B9 A8 A3 A1 03 FD 41 25
: 12 E5 F3 F8 47 CE 8C 42 D9 26 77 A5 57 AF 1A 95
: BF 05 A5 E9 47 F2 D1 AE DC 13 7E 1B 83 5C 8C C4
: 1F 31 BC 59 E6 FD 6E 9A B0 91 EC 71 A6 7F 28 3E
: 23 1B 40 E2 C0 60 CF 5E 5B 86 08 06 82 B4 B7 DB
: 00 DD AC 3A 39 27 E2 7C 96 AD 8A E9 C3 B8 06 5E
: }
: }
439 124: SEQUENCE {
441 9: OBJECT IDENTIFIER data (1 2 840 113549 1 7 1)
452 29: SEQUENCE {
454 9: OBJECT IDENTIFIER
: aes128-CBC (2 16 840 1 101 3 4 1 2)
465 16: OCTET STRING
: 88 9B 13 75 A7 66 14 C3 CF CD C6 FF D2 91 5D A0
: }
483 80: [0]
: 80 0B A3 B7 57 89 B4 F4 70 AE 1D 14 A9 35 DD F9
: 1D 66 29 46 52 40 13 E1 3B 4A 23 E5 EC AB F9 35
: A6 B6 A4 BE C0 02 31 06 19 C4 39 22 7D 10 4C 0D
: F4 96 04 78 11 85 4E 7E E3 C3 BC B2 DF 55 17 79
: 5F F2 4E E5 25 42 37 45 39 5D F6 DA 57 9A 4E 0B
: }
: }
: }
: }
Jennings, et al. Informational [Page 25]
RFC 6216 SIP Secure Call Flows April 2011
Below is the ASN.1 parsing of "BINARY BLOB 4".
0 472: SEQUENCE {
4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
15 457: [0] {
19 453: 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 420: SET {
56 416: SEQUENCE {
60 1: INTEGER 1
63 125: 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: UTF8String 'California'
: }
: }
101 17: SET {
103 15: SEQUENCE {
105 3: OBJECT IDENTIFIER localityName (2 5 4 7)
110 8: UTF8String 'San Jose'
: }
: }
120 14: SET {
122 12: SEQUENCE {
124 3: OBJECT IDENTIFIER
: organizationName (2 5 4 10)
129 5: UTF8String 'sipit'
: }
: }
136 41: SET {
Jennings, et al. Informational [Page 26]
RFC 6216 SIP Secure Call Flows April 2011
138 39: SEQUENCE {
140 3: OBJECT IDENTIFIER
: organizationalUnitName (2 5 4 11)
145 32: UTF8String 'Sipit Test Certificate
Authority'
: }
: }
: }
179 9: INTEGER 00 96 A3 84 17 4E EF 8A 4D
: }
190 9: SEQUENCE {
192 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
199 0: NULL
: }
201 13: SEQUENCE {
203 9: OBJECT IDENTIFIER
: rsaEncryption (1 2 840 113549 1 1 1)
214 0: NULL
: }
216 256: OCTET STRING
: 6E 51 AC 24 2E BA 7C A1 EE 80 A8 55 BC D4 64 5D
: E5 29 09 5F B2 AF AA 6F 91 D2 97 79 32 5B AF CA
: FE A1 73 FC E5 57 4E C6 3B 67 35 AA E4 78 1E 59
: 93 EE 67 63 77 1E 7A 82 BC 1E 26 0F 39 75 0C A6
: 26 92 01 6A B7 5D F0 C0 2C 51 46 FB A7 36 44 E3
: 64 C6 11 CB 0B 6B FD F3 6D 7C FD 3E AE 2E 91 BB
: 78 9E F4 1B A1 20 68 B9 DE D3 E3 0C FC F7 14 9A
: 2C 64 AB 27 52 BD 52 EC 27 88 14 BD DB C3 54 C7
: EA 48 DB 07 E9 9B 2E C8 BE 62 A2 76 83 53 37 E8
: 02 4B D1 86 E9 DF 2E BD 93 39 EC 2F 01 53 A0 7F
: 1A B9 A6 31 FC E7 91 1C DB 22 4A 67 83 94 B2 4E
: 28 A9 CD DE 4A 04 6A E0 86 90 7B 58 5F DB 7A 96
: 96 A0 25 61 C2 58 A2 28 E5 B3 B2 F1 6D 51 06 9C
: 78 61 0D D8 3A A7 9F A3 B5 87 0B 80 11 C2 A9 1A
: E5 17 1C EB 82 55 AB CD 04 E7 D9 5B 11 E8 B7 47
: FE FD CC B7 DB 47 6F 77 85 9E 24 D8 11 E1 E4 7D
: }
: }
: }
: }
: }
5. Observed Interoperability Issues
This section describes some common interoperability problems. These
were observed by the authors at SIPit interoperability events.
Implementers should be careful to verify that their systems do not
introduce these common problems, and, when possible, make their
Jennings, et al. Informational [Page 27]
RFC 6216 SIP Secure Call Flows April 2011
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.
See Section 26.2.1 of [RFC3261].
Many SIP clients were found to accept expired certificates with no
warning or error. See Section 4.1.2.5 of [RFC5280].
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 checks that this name corresponds
to the identity the server is trying to contact. Normative text
describing path validation can be found in Section 7 of [RFC5922] and
Section 6 of [RFC5280]. 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 will typically 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 will need to match according to
the certificate validation rules in Section 23 of [RFC3261] and
Section 6 of [RFC5280].
Some implementations used binary MIME encodings while others used
base64. It is advisable that implementations send only binary and
are prepared to receive either. See Section 3.2 of [RFC5621].
In several places in this document, the messages contain the encoding
for the SHA-1 digest algorithm identifier. The preferred form for
encoding as set out in Section 2 of [RFC3370] is the form in which
the optional AlgorithmIdentifier parameter field is omitted.
However, [RFC3370] 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 [RFC4134]. 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 [RFC3853].
Jennings, et al. Informational [Page 28]
RFC 6216 SIP Secure Call Flows April 2011
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, which should be
considered when sending over UDP. Furthermore, the receiver cannot
rely on the sender to always send the certificate, so it does not
turn out to be useful in most situations.
Please note that the certificate path validation algorithm described
in Section 6 of [RFC5280] is a complex algorithm for which all of the
details matter. There are numerous ways in which failing to
precisely implement the algorithm as specified in Section 6 of
[RFC5280] can create a security flaw, a simple example of which is
the failure to check the expiration date that is already mentioned
above. It is important for developers to ensure that this validation
is performed and that the results are verified by their applications
or any libraries that they use.
6. 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 [RFC4474] (particularly, Section 13.4 Domain
Names and Subordination) and informative works such as [RFC2818],
Section 3.1. To summarize, test plans should:
o For S/MIME secured bodies, ensure that the peer's URI (address-of-
record, as per [RFC3261], Section 23.3) appears in the
subjectAltName of the peer's certificate as a
uniformResourceIdentifier field.
o For TLS, ensure that the peer's hostname appears as described in
[RFC5922]. Also:
* ensure 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. See
Section 7.1 of [RFC5922].
* ensure that the most specific CommonName in the Subject field
matches if there are no dNSName entries in the subjectAltName
at all (which is not the same as there being no matching
Jennings, et al. Informational [Page 29]
RFC 6216 SIP Secure Call Flows April 2011
dNSName entries). This match can be either exact, or against
an entry that uses the wildcard matching character '*'.
The peer's hostname is discovered from the initial DNS query in
the server location process [RFC3263].
o IP addresses can appear in subjectAltName ([RFC5280]) of the
peer's certificate, e.g., "IP:192.168.0.1". Note that if IP
addresses are used in subjectAltName, there are important
ramifications regarding the use of Record-Route headers that also
need to be considered. See Section 7.5 of [RFC5922]. Use of IP
addresses instead of domain names is inadvisable.
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
subjectAltName)
3. S/MIME : Bad peer certificate (valid authority chain does not
end at a trusted CA)
4. S/MIME : Bad peer certificate (incomplete authority chain)
5. S/MIME : Bad peer certificate (the current time does not fall
within the period of validity)
6. S/MIME : Bad peer certificate (certificate, or certificate in
authority chain, has been revoked)
7. S/MIME : Bad peer certificate ("Digital Signature" is not
specified as an X509v3 Key Usage)
8. TLS : Good peer certificate (hostname appears in dNSName in
subjectAltName)
9. TLS : Good peer certificate (no dNSNames in subjectAltName,
hostname appears in Common Name (CN) of Subject)
Jennings, et al. Informational [Page 30]
RFC 6216 SIP Secure Call Flows April 2011
10. TLS : Good peer certificate (CN of Subject empty, and
subjectAltName extension contains an iPAddress stored in the
octet string in network byte order form as specified in RFC 791
[RFC0791])
11. TLS : Bad peer certificate (no match in dNSNames or in the
Subject CN)
12. TLS : Bad peer certificate (valid authority chain does not end
at a trusted CA)
13. TLS : Bad peer certificate (incomplete authority chain)
14. TLS : Bad peer certificate (the current time does not fall
within the period of validity)
15. TLS : Bad peer certificate (certificate, or certificate in
authority chain, has been revoked)
16. TLS : Bad peer certificate ("TLS Web Server Authentication" is
not specified as an X509v3 Key Usage)
17. TLS : Bad peer certificate (Neither "SIP Domain" nor "Any
Extended Key Usage" specified as an X509v3 Extended Key Usage,
and X509v3 Extended Key Usage is present)
7. 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 SIP for Instant Messaging and Presence
Leveraging Extensions (SIMPLE) Instant Messaging and Presence
Protocol (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" [EKR-TLS] 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.
Jennings, et al. Informational [Page 31]
RFC 6216 SIP Secure Call Flows April 2011
8. 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 any messages to check certificate
revocation status (see Sections 3.3 and 6.3 of [RFC5280]) as that is
not part of the SIP call flow. The expectation is that revocation
status is checked regularly to protect against the possibility of
certificate compromise or repudiation. For more information on how
certificate revocation status can be checked, see [RFC2560] (Online
Certificate Status Protocol) and [RFC5055] (Server-Based Certificate
Validation Protocol).
9. References
9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S.,
and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol
- OCSP", RFC 2560, June 1999.
[RFC3261] 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.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session
Initiation Protocol (SIP): Locating SIP Servers",
RFC 3263, June 2002.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
Jennings, et al. Informational [Page 32]
RFC 6216 SIP Secure Call Flows April 2011
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H.,
Huitema, C., and D. Gurle, "Session Initiation
Protocol (SIP) Extension for Instant Messaging",
RFC 3428, December 2002.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard
(AES) Requirement for the Session Initiation
Protocol (SIP)", RFC 3853, July 2004.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D.,
and W. Polk, "Server-Based Certificate Validation
Protocol (SCVP)", RFC 5055, December 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.2", RFC 5246,
August 2008.
[RFC5280] 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.
[RFC5621] Camarillo, G., "Message Body Handling in the
Session Initiation Protocol (SIP)", RFC 5621,
September 2009.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
STD 70, RFC 5652, September 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose
Internet Mail Extensions (S/MIME) Version 3.2
Message Specification", RFC 5751, January 2010.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol
(SIP)", RFC 5922, June 2010.
[RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection
Reuse in the Session Initiation Protocol (SIP)",
RFC 5923, June 2010.
Jennings, et al. Informational [Page 33]
RFC 6216 SIP Secure Call Flows April 2011
[RFC5924] Lawrence, S. and V. Gurbani, "Extended Key Usage
(EKU) for Session Initiation Protocol (SIP) X.509
Certificates", RFC 5924, June 2010.
[X.509] International Telecommunications Union,
"Information technology - Open Systems
Interconnection - The Directory: Public-key and
attribute certificate frameworks",
ITU-T Recommendation X.509 (2005), ISO/
IEC 9594-8:2005.
[X.683] International Telecommunications Union,
"Information technology - Abstract Syntax Notation
One (ASN.1): Parameterization of ASN.1
specifications", ITU-T Recommendation X.683
(2002), ISO/IEC 8824-4:2002, 2002.
9.2. Informative References
[EKR-TLS] Rescorla, E., "SSL and TLS - Designing and
Building Secure Systems", Addison-Wesley, ISBN
0-201-61598-3, 2001.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4134] Hoffman, P., "Examples of S/MIME Messages",
RFC 4134, July 2005.
[RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A.,
Rosenberg, J., and H. Schulzrinne, "Session
Initiation Protocol (SIP) Torture Test Messages",
RFC 4475, May 2006.
[RFC4514] Zeilenga, K., "Lightweight Directory Access
Protocol (LDAP): String Representation of
Distinguished Names", RFC 4514, June 2006.
[ssldump-manpage] Rescorla, E., "SSLDump manpage",
.
Jennings, et al. Informational [Page 34]
RFC 6216 SIP Secure Call Flows April 2011
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 CAs 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 certificates 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, e.g., "makeCert
host.example.net domain eku". 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 Privacy Enhanced Mail (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 Public-Key Cryptography Standards (PKCS) #12 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".
The root certificate for the CA is in the file
root_cert_fluffyCA.pem.
Jennings, et al. Informational [Page 35]
RFC 6216 SIP Secure Call Flows April 2011
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 PKCS #7 certificate to PEM format with "openssl pkcs7 -in
cert.p7c -inform DER -outform PEM -out cert.pem".
The private key can be converted to PKCS #8 format with "openssl
pkcs8 -in a_key.pem -topk8 -outform DER -out a_key.p8c".
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
# This is done to generate the exact serial number used for the RFC
echo "4902110184015C" > demoCA/serial
touch demoCA/index.txt
# 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
Jennings, et al. Informational [Page 36]
RFC 6216 SIP Secure Call Flows April 2011
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 < demoCA/serial
echo 96a384174eef8a4d > demoCA/serial
Jennings, et al. Informational [Page 39]
RFC 6216 SIP Secure Call Flows April 2011
openssl crl2pkcs7 -nocrl -certfile demoCA/cacert.pem \
-outform DER -out demoCA/cacert.p7c
cp demoCA/cacert.pem root_cert_fluffyCA.pem
A.2. makeCert script
#!/bin/sh
set -x
# Make a symbolic link to this file called "makeUserCert"
# if you wish to use it to make certs for users.
# ExecName=$(basename $0)
#
# if [ ${ExecName} == "makeUserCert" ]; then
# ExtPrefix="sipuser"
# elif [ ${ExecName} == "makeEkuUserCert" ]; then
# ExtPrefix="sipuser_eku"
# elif [ ${ExecName} == "makeEkuCert" ]; then
# ExtPrefix="sipdomain_eku"
# else
# ExtPrefix="sipdomain"
# fi
if [ $# == 3 ]; then
DAYS=36500
elif [ $# == 4 ]; then
DAYS=$4
else
echo "Usage: makeCert test.example.org user|domain eku|noeku [days]"
echo " makeCert alice@example.org [days]"
echo "days is how long the certificate is valid"
echo "days set to 0 generates an invalid certificate"
exit 0
fi
ExtPrefix="sip"${2}
if [ $3 == "noeku" ]; then
ExtPrefix=${ExtPrefix}"_noeku"
fi
DOMAIN=`echo $1 | perl -ne '{print "$1\n" if (/(\w+\..*)$/)}' `
USER=`echo $1 | perl -ne '{print "$1\n" if (/(\w+)\@(\w+\..*)$/)}' `
ADDR=$1
echo "making cert for $DOMAIN ${ADDR}"
Jennings, et al. Informational [Page 40]
RFC 6216 SIP Secure Call Flows April 2011
if [ $2 == "user" ]; then
CNVALUE=$USER
else
CNVALUE=$DOMAIN
fi
rm -f ${ADDR}_*.pem
rm -f ${ADDR}.p12
case ${ADDR} in
*:*) ALTNAME="URI:${ADDR}" ;;
*@*) ALTNAME="URI:sip:${ADDR},URI:im:${ADDR},URI:pres:${ADDR}" ;;
*) ALTNAME="DNS:${DOMAIN},URI:sip:${ADDR}" ;;
esac
rm -f demoCA/index.txt
touch demoCA/index.txt
rm -f demoCA/newcerts/*
export ALTNAME
openssl genrsa -out ${ADDR}_key.pem 2048
openssl req -new -config openssl.cnf -reqexts ${ExtPrefix}_req \
-sha1 -key ${ADDR}_key.pem \
-out ${ADDR}.csr -days ${DAYS} <
RFC, FYI, BCP