draft-ietf-sipcore-sec-flows-03.txt   draft-ietf-sipcore-sec-flows-04.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Informational K. Ono Intended status: Informational K. Ono
Expires: December 16, 2010 Columbia University Expires: May 12, 2011 Columbia University
R. Sparks R. Sparks
B. Hibbard, Ed. B. Hibbard, Ed.
Tekelec Tekelec
June 14, 2010 November 8, 2010
Example call flows using Session Initiation Protocol (SIP) security Example call flows using Session Initiation Protocol (SIP) security
mechanisms mechanisms
draft-ietf-sipcore-sec-flows-03 draft-ietf-sipcore-sec-flows-04
Abstract Abstract
This document shows example call flows demonstrating the use of This document shows example call flows demonstrating the use of
Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail
Extensions (S/MIME) in Session Initiation Protocol (SIP). It also Extensions (S/MIME) in Session Initiation Protocol (SIP). It also
provides information that helps implementers build interoperable SIP provides information that helps implementers build interoperable SIP
software. To help facilitate interoperability testing, it includes software. To help facilitate interoperability testing, it includes
certificates used in the example call flows and processes to create certificates used in the example call flows and processes to create
certificates for testing. certificates for testing.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 16, 2010. This Internet-Draft will expire on May 12, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the BSD License.
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 5 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4
2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 9 2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8
2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10 2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 9
3. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12 3. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 11
3.1. TLS with Server Authentication . . . . . . . . . . . . . . 12 3.1. TLS with Server Authentication . . . . . . . . . . . . . . 11
3.2. MESSAGE Message Over TLS . . . . . . . . . . . . . . . . . 14 3.2. MESSAGE Transaction Over TLS . . . . . . . . . . . . . . . 13
4. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 15 4. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 14
4.1. MESSAGE Message with Signed Body . . . . . . . . . . . . . 15 4.1. MESSAGE Request with Signed Body . . . . . . . . . . . . . 14
4.2. MESSAGE Message with Encrypted Body . . . . . . . . . . . 21 4.2. MESSAGE Request with Encrypted Body . . . . . . . . . . . 20
4.3. MESSAGE Message with Encrypted and Signed Body . . . . . . 23 4.3. MESSAGE Request with Encrypted and Signed Body . . . . . . 22
5. Observed Interoperability Issues . . . . . . . . . . . . . . . 28 5. Observed Interoperability Issues . . . . . . . . . . . . . . . 27
6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 30 6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 32 9. Security Considerations . . . . . . . . . . . . . . . . . . . 31
10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33
11.2. Informative References . . . . . . . . . . . . . . . . . . 36 11.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Making Test Certificates . . . . . . . . . . . . . . 36 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35
A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 37 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 36
A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 41 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 39
Appendix B. Certificates for Testing . . . . . . . . . . . . . . 43 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42
B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 43 B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42
B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 50 B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 49
B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 58 B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 57
Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 64 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
This document is informational and is not normative on any aspect of This document is informational and is not normative on any aspect of
SIP. SIP.
SIP with TLS (RFC 5246 [14]) implementations are becoming very SIP with TLS (RFC 5246 [13]) implementations are becoming very
common. Several implementations of the S/MIME (RFC 3851 [9]) portion common. Several implementations of the S/MIME (RFC 5751 [8]) portion
of SIP (RFC 3261 [3]) are also becoming available. After several of SIP (RFC 3261 [3]) are also becoming available. After several
interoperability events, it is clear that it is difficult to write interoperability events, it is clear that it is difficult to write
these systems without any test vectors or examples of "known good" these systems without any test vectors or examples of "known good"
messages to test against. Furthermore, testing at the events is messages to test against. Furthermore, testing at the events is
often hindered due to the lack of a commonly trusted certificate often hindered due to the lack of a commonly trusted certificate
authority to sign the certificates used in the events. This document authority to sign the certificates used in the events. This document
addresses both of these issues by providing messages that give addresses both of these issues by providing messages that give
detailed examples that implementers can use for comparison and that detailed examples that implementers can use for comparison and that
can also be used for testing. In addition, this document provides a 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 common certificate and private key that can be used to set up a mock
skipping to change at page 10, line 40 skipping to change at page 9, line 40
b5:48:dc:68:bc:e5:5c:5c:dd:43:34:af:14:3a:85:60:a3:46: b5:48:dc:68:bc:e5:5c:5c:dd:43:34:af:14:3a:85:60:a3:46:
17:69 17:69
The example host certificate above, as well as all the others The example host certificate above, as well as all the others
presented in this document, are signed directly by a root CA. These 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 certificate chains have a length equal to two: the root CA and the
host certificate. Non-root CAs exist and may also sign certificates. host certificate. Non-root CAs exist and may also sign certificates.
The certificate chains presented by hosts with certificates signed by The certificate chains presented by hosts with certificates signed by
non-root CAs will have a length greater than two. For more details 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 on how certificate chains are validated, see section 6.1.4 of RFC
5280 [15]. 5280 [14].
2.3. User Certificates 2.3. User Certificates
User certificates are used by many applications to establish user User certificates are used by many applications to establish user
identity. The user certificate for fluffy@example.com is shown identity. The user certificate for fluffy@example.com is shown
below. Note that the Subject Alternative Name has a list of names 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 with different URL types such as a sip, im, or pres URL. This is
necessary for interoperating with a CPIM gateway. In this example, necessary for interoperating with a CPIM gateway. In this example,
example.com is the domain for fluffy. The message could be coming example.com is the domain for fluffy. The message could be coming
from any host in *.example.com, and the AOR in the user certificate from any host in *.example.com, and the AOR in the user certificate
would still be the same. The others are shown in Appendix B.1. would still be the same. The others are shown in Appendix B.1.
These certificates make use of the EKU extension discussed in Draft These certificates make use of the EKU extension discussed in RFC
SIP EKU [16]. Note that the X509v3 Extended Key Usage attribute 5924 [15]. Note that the X509v3 Extended Key Usage attribute refers
refers to the SIP OID introduced in Draft SIP EKU [16], which is to the SIP OID introduced in RFC 5924 [15], which is
1.3.6.1.5.5.7.3.20 1.3.6.1.5.5.7.3.20
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number:
49:02:11:01:84:01:5c 49:02:11:01:84:01:5c
Signature Algorithm: sha1WithRSAEncryption Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=sipit, Issuer: C=US, ST=California, L=San Jose, O=sipit,
OU=Sipit Test Certificate Authority OU=Sipit Test Certificate Authority
Validity Validity
Not Before: May 11 20:22:55 2010 GMT Not Before: May 11 20:22:55 2010 GMT
skipping to change at page 12, line 32 skipping to change at page 11, line 32
1e:a1 1e:a1
Versions of these certificates that do not make use of EKU are also Versions of these certificates that do not make use of EKU are also
included in Appendix B.2 included in Appendix B.2
3. Callflow with Message Over TLS 3. Callflow with Message Over TLS
3.1. TLS with Server Authentication 3.1. TLS with Server Authentication
The flow below shows the edited SSLDump output of the host The flow below shows the edited SSLDump output of the host
example.com forming a TLS RFC 5246 [14] connection to example.net. example.com forming a TLS RFC 5246 [13] connection to example.net.
In this example mutual authentication is not used. Note that the In this example mutual authentication is not used. Note that the
client proposed three protocol suites including client proposed three protocol suites including
TLS_RSA_WITH_AES_128_CBC_SHA defined in RFC 3268 [5]. The TLS_RSA_WITH_AES_128_CBC_SHA defined in RFC 5246 [13]. The
certificate returned by the server contains a Subject Alternative certificate returned by the server contains a Subject Alternative
Name that is set to example.net. A detailed discussion of TLS can be Name that is set to example.net. A detailed discussion of TLS can be
found in SSL and TLS [22]. For more details on the SSLDump tool, see found in SSL and TLS [21]. For more details on the SSLDump tool, see
the SSLDump Manual [23]. the SSLDump Manual [22].
This example does not use the Server Extended Hello (see RFC 3546 This example does not use the Server Extended Hello (see RFC 4366
[8]). [7]).
New TCP connection #1: example.com(50713) <-> example.net(5061) New TCP connection #1: example.com(50713) <-> example.net(5061)
1 1 0.0004 (0.0004) C>SV3.1(101) Handshake 1 1 0.0004 (0.0004) C>SV3.1(101) Handshake
ClientHello ClientHello
Version 3.1 Version 3.1
random[32]= random[32]=
4c 09 5b a7 66 77 eb 43 52 30 dd 98 4d 09 23 d3 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 ff 81 74 ab 04 69 bb 79 8c dc 59 cd c2 1f b7 ec
cipher suites cipher suites
skipping to change at page 14, line 20 skipping to change at page 13, line 20
1 10 0.0129 (0.0000) S>CV3.1(1) ChangeCipherSpec 1 10 0.0129 (0.0000) S>CV3.1(1) ChangeCipherSpec
1 11 0.0129 (0.0000) S>CV3.1(48) Handshake 1 11 0.0129 (0.0000) S>CV3.1(48) Handshake
1 12 0.0134 (0.0005) C>SV3.1(32) application_data 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 13 0.0134 (0.0000) C>SV3.1(496) application_data
1 14 0.2150 (0.2016) S>CV3.1(32) 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 15 0.2150 (0.0000) S>CV3.1(336) application_data
1 16 12.2304 (12.0154) S>CV3.1(32) Alert 1 16 12.2304 (12.0154) S>CV3.1(32) Alert
1 12.2310 (0.0005) S>C TCP FIN 1 12.2310 (0.0005) S>C TCP FIN
1 17 12.2321 (0.0011) C>SV3.1(32) Alert 1 17 12.2321 (0.0011) C>SV3.1(32) Alert
3.2. MESSAGE Message Over TLS 3.2. MESSAGE Transaction Over TLS
Once the TLS session is set up, the following MESSAGE message (as Once the TLS session is set up, the following MESSAGE request (as
defined in RFC 3428 [7] is sent from fluffy@example.com to defined in RFC 3428 [6] is sent from fluffy@example.com to
kumiko@example.net. Note that the URI has a SIPS URL and that the 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, VIA indicates that TLS was used. In order to format this document,
the <allOneLine> convention from RFC 4475 [21] is used to break long the <allOneLine> convention from RFC 4475 [20] is used to break long
lines. The actual message does not contain the linebreaks contained lines. The actual message does not contain the linebreaks contained
within those tags. within those tags.
MESSAGE sips:kumiko@example.net:5061 SIP/2.0 MESSAGE sips:kumiko@example.net:5061 SIP/2.0
<allOneLine> <allOneLine>
Via: SIP/2.0/TLS 192.0.2.2:15001; Via: SIP/2.0/TLS 192.0.2.2:15001;
branch=z9hG4bK-d8754z-33d8961795354459-1---d8754z-; branch=z9hG4bK-d8754z-33d8961795354459-1---d8754z-;
rport=50713 rport=50713
</allOneLine> </allOneLine>
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 15, line 7 skipping to change at page 14, line 7
Content-Type: text/plain Content-Type: text/plain
Content-Length: 6 Content-Length: 6
Hello! Hello!
When a UA goes to send a message to example.com, the UA can see if it When a 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 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 send the message over this connection. A UA should have some scheme
for reusing connections as opening a new TLS connection for every for reusing connections as opening a new TLS connection for every
message results in awful performance. Implementers are encouraged to message results in awful performance. Implementers are encouraged to
read Draft Connection Reuse in SIP [18] and RFC 3263 [4]. read RFC 5923 [17] and RFC 3263 [4].
The response is sent from example.net to example.com over the same The response is sent from example.net to example.com over the same
TLS connection. It is shown below. TLS connection. It is shown below.
SIP/2.0 200 OK SIP/2.0 200 OK
<allOneLine> <allOneLine>
Via: SIP/2.0/TLS 192.0.2.2:15001; Via: SIP/2.0/TLS 192.0.2.2:15001;
branch=z9hG4bK-d8754z-33d8961795354459-1---d8754z-; branch=z9hG4bK-d8754z-33d8961795354459-1---d8754z-;
rport=50713 rport=50713
</allOneLine> </allOneLine>
To: <sips:kumiko@example.net:5061>;tag=a0d41548 To: <sips:kumiko@example.net:5061>;tag=a0d41548
From: <sips:fluffy@example.com:15001>;tag=10f47d62 From: <sips:fluffy@example.com:15001>;tag=10f47d62
Call-ID: ODU5YTQzYTMyYjNkZDAyODcyOGJiMWNmOWZmZmY2MGU. Call-ID: ODU5YTQzYTMyYjNkZDAyODcyOGJiMWNmOWZmZmY2MGU.
CSeq: 4308 MESSAGE CSeq: 4308 MESSAGE
Content-Length: 0 Content-Length: 0
4. Callflow with S/MIME-secured Message 4. Callflow with S/MIME-secured Message
4.1. MESSAGE Message with Signed Body 4.1. MESSAGE Request with Signed Body
Below is an example of a signed message. The values on the Content- Below is an example of a signed message. The values on the Content-
Type line (multipart/signed) and on the Content-Disposition line have 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 been broken across lines to fit on the page, but they are not broken
across lines in actual implementations. across lines in actual implementations.
MESSAGE sip:kumiko@example.net SIP/2.0 MESSAGE sip:kumiko@example.net SIP/2.0
<allOneLine> <allOneLine>
Via: SIP/2.0/TCP 192.0.2.2:15001; Via: SIP/2.0/TCP 192.0.2.2:15001;
branch=z9hG4bK-d8754z-c947ab3f4ea84000-1---d8754z-; branch=z9hG4bK-d8754z-c947ab3f4ea84000-1---d8754z-;
skipping to change at page 16, line 49 skipping to change at page 15, line 49
***************** *****************
* BINARY BLOB 1 * * BINARY BLOB 1 *
***************** *****************
--d0c5ff1dcdc8f431-- --d0c5ff1dcdc8f431--
It is important to note that the signature ("BINARY BLOB 1") is It is important to note that the signature ("BINARY BLOB 1") is
computed over the MIME headers and body, but excludes the multipart computed over the MIME headers and body, but excludes the multipart
boundary lines. The value on the Message-body line ends with CRLF. 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 The CRLF is included in the boundary and is not part of the signature
computation. To be clear, the signature is computed over data 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 starting with the "C" in the "Content-Type" and ending with the "!"
hello. in the "Hello!".
Content-Type: text/plain Content-Type: text/plain
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Hello! Hello!
Following is the ASN.1 parsing of encrypted contents referred to 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 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 signature is specified as SHA-1. Also note that the sender's
certificate is not attached as it is optional in RFC 3852 [10]. certificate is not attached as it is optional in RFC 5652 [9].
0 470: SEQUENCE { 0 470: SEQUENCE {
4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
15 455: [0] { 15 455: [0] {
19 451: SEQUENCE { 19 451: SEQUENCE {
23 1: INTEGER 1 23 1: INTEGER 1
26 11: SET { 26 11: SET {
28 9: SEQUENCE { 28 9: SEQUENCE {
30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
37 0: NULL 37 0: NULL
skipping to change at page 19, line 7 skipping to change at page 18, line 7
: 6C 20 E9 0C BE BA 4E 9D 2F 31 3E BA A4 6F EC CA : 6C 20 E9 0C BE BA 4E 9D 2F 31 3E BA A4 6F EC CA
: E4 02 1F 2E AD 88 2F 94 F3 C3 5D 3F BF DF 0A 41 : E4 02 1F 2E AD 88 2F 94 F3 C3 5D 3F BF DF 0A 41
: 30 17 1A 9F 1D F6 EB B3 7A 0B E1 42 DF 36 45 BB : 30 17 1A 9F 1D F6 EB B3 7A 0B E1 42 DF 36 45 BB
: } : }
: } : }
: } : }
: } : }
: } : }
SHA-1 parameters may be omitted entirely, instead of being set to SHA-1 parameters may be omitted entirely, instead of being set to
NULL, as mentioned in RFC 3370 [6]. The above dump of Blob 1 has NULL, as mentioned in RFC 3370 [5]. The above dump of Blob 1 has
SHA-1 parameters set to NULL. Below are the same contents signed SHA-1 parameters set to NULL. Below are the same contents signed
with the same key, but omitting the NULL according to RFC 3370 [6]. with the same key, but omitting the NULL according to RFC 3370 [5].
This is the preferred encoding. This is covered in greater detail in This is the preferred encoding. This is covered in greater detail in
Section 5. Section 5.
0 466: SEQUENCE { 0 466: SEQUENCE {
4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2) 4 9: OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
15 451: [0] { 15 451: [0] {
19 447: SEQUENCE { 19 447: SEQUENCE {
23 1: INTEGER 1 23 1: INTEGER 1
26 9: SET { 26 9: SET {
28 7: SEQUENCE { 28 7: SEQUENCE {
skipping to change at page 21, line 5 skipping to change at page 20, line 5
: C5 A7 1B 76 13 97 6A 13 BD 17 37 1D BC 2B 9A 48 : C5 A7 1B 76 13 97 6A 13 BD 17 37 1D BC 2B 9A 48
: 6C 20 E9 0C BE BA 4E 9D 2F 31 3E BA A4 6F EC CA : 6C 20 E9 0C BE BA 4E 9D 2F 31 3E BA A4 6F EC CA
: E4 02 1F 2E AD 88 2F 94 F3 C3 5D 3F BF DF 0A 41 : E4 02 1F 2E AD 88 2F 94 F3 C3 5D 3F BF DF 0A 41
: 30 17 1A 9F 1D F6 EB B3 7A 0B E1 42 DF 36 45 BB : 30 17 1A 9F 1D F6 EB B3 7A 0B E1 42 DF 36 45 BB
: } : }
: } : }
: } : }
: } : }
: } : }
4.2. MESSAGE Message with Encrypted Body 4.2. MESSAGE Request with Encrypted Body
Below is an example of an encrypted text/plain message that says Below is an example of an encrypted text/plain message that says
"hello". The binary encrypted contents have been replaced with the "Hello!". The binary encrypted contents have been replaced with the
block "BINARY BLOB 2". block "BINARY BLOB 2".
MESSAGE sip:kumiko@example.net SIP/2.0 MESSAGE sip:kumiko@example.net SIP/2.0
<allOneLine> <allOneLine>
Via: SIP/2.0/TCP 192.0.2.2:15001; Via: SIP/2.0/TCP 192.0.2.2:15001;
branch=z9hG4bK-d8754z-19883b67d813801b-1---d8754z-; branch=z9hG4bK-d8754z-19883b67d813801b-1---d8754z-;
rport=50716 rport=50716
</allOneLine> </allOneLine>
Max-Forwards: 70 Max-Forwards: 70
To: <sip:kumiko@example.net> To: <sip:kumiko@example.net>
skipping to change at page 23, line 37 skipping to change at page 22, line 37
: CB F2 22 1B C0 F8 ED 86 6A CB 65 8C 08 7C BE 21 : CB F2 22 1B C0 F8 ED 86 6A CB 65 8C 08 7C BE 21
: 8A 53 3D C5 92 EE 23 E3 8A EA D6 DF B3 22 3A 00 : 8A 53 3D C5 92 EE 23 E3 8A EA D6 DF B3 22 3A 00
: F9 96 4C 5F 8B 75 4F 7E 22 F7 D6 8A D3 13 56 EE : F9 96 4C 5F 8B 75 4F 7E 22 F7 D6 8A D3 13 56 EE
: BF B7 D9 24 32 6D F1 0B E8 CF 7C FC 14 90 BE DA : BF B7 D9 24 32 6D F1 0B E8 CF 7C FC 14 90 BE DA
: F3 5E 04 38 CC D6 E5 9D 6F AF 44 BF A0 0A 3A 5C : F3 5E 04 38 CC D6 E5 9D 6F AF 44 BF A0 0A 3A 5C
: } : }
: } : }
: } : }
: } : }
4.3. MESSAGE Message with Encrypted and Signed Body 4.3. MESSAGE Request with Encrypted and Signed Body
In the example below, some of the header values have been split In the example below, some of the header values have been split
across mutliple lines. Where the lines have been broken, the across mutliple lines. Where the lines have been broken, the
<allOneLine> convention has been used. This was only done to make it <allOneLine> convention has been used. This was only done to make it
fit in the RFC format. Specifically, the application/pkcs7-mime fit in the RFC format. Specifically, the application/pkcs7-mime
Content-Type line is one line with no whitespace between the "mime;" Content-Type line is one line with no whitespace between the "mime;"
and the "smime-type". The values are split across lines for and the "smime-type". The values are split across lines for
formatting, but are not split in the real message. The binary formatting, but are not split in the real message. The binary
encrypted content has been replaced with "BINARY BLOB 3", and the encrypted content has been replaced with "BINARY BLOB 3", and the
binary signed content has been replaced with "BINARY BLOB 4". binary signed content has been replaced with "BINARY BLOB 4".
skipping to change at page 29, line 16 skipping to change at page 28, line 16
Some SIP clients incorrectly only do SSLv3 and do not support TLS. Some SIP clients incorrectly only do SSLv3 and do not support TLS.
Many SIP clients were found to accept expired certificates with no Many SIP clients were found to accept expired certificates with no
warning or error. warning or error.
When used with SIP, TLS and S/MIME provide the identity of the peer 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 that a client is communicating with in the Subject Alternative Name
in the certificate. The software checks that this name corresponds in the certificate. The software checks that this name corresponds
to the identity the server is trying to contact. Normative text to the identity the server is trying to contact. Normative text
describing path validation can be found in section 7 of Draft SIP describing path validation can be found in section 7 of RFC 5922 [16]
Domain Certs [17] and section 6 of RFC 5280 [15]. If a client is and section 6 of RFC 5280 [14]. If a client is trying to set up a
trying to set up a TLS connection to good.example.com and it gets a TLS connection to good.example.com and it gets a TLS connection set
TLS connection set up with a server that presents a valid certificate up with a server that presents a valid certificate but with the name
but with the name evil.example.com, it will typically generate an evil.example.com, it will typically generate an error or warning of
error or warning of some type. Similarly with S/MIME, if a user is some type. Similarly with S/MIME, if a user is trying to communicate
trying to communicate with sip:fluffy@example.com, one of the items with sip:fluffy@example.com, one of the items in the Subject
in the Subject Alternate Name set in the certificate will need to Alternate Name set in the certificate will need to match according to
match according to the certificate validation rules in section 23 of the certificate validation rules in section 23 of RFC 3261 [3] and
RFC 3261 [3] and section 6 of RFC 5280 [15]. section 6 of RFC 5280 [14].
Some implementations used binary MIME encodings while others used Some implementations used binary MIME encodings while others used
base64. It is advisable that implementations send only binary and base64. It is advisable that implementations send only binary and
are prepared to receive either. are prepared to receive either.
In several places in this document, the messages contain the encoding In several places in this document, the messages contain the encoding
for the SHA-1 digest algorithm identifier. The preferred form for for the SHA-1 digest algorithm identifier. The preferred form for
encoding as set out in Section 2 of RFC 3370 [6] is the form in which encoding as set out in Section 2 of RFC 3370 [5] is the form in which
the optional AlgorithmIdentifier parameter field is omitted. the optional AlgorithmIdentifier parameter field is omitted.
However, RFC 3370 also says the recipients need to be able to receive However, RFC 3370 also says the recipients need to be able to receive
the form in which the AlgorithmIdentifier parameter field is present the form in which the AlgorithmIdentifier parameter field is present
and set to NULL. Examples of the form using NULL can be found in and set to NULL. Examples of the form using NULL can be found in
Section 4.2 of RFC 4134 [20]. Receivers really do need to be able to Section 4.2 of RFC 4134 [19]. Receivers really do need to be able to
receive the form that includes the NULL because the NULL form, while receive the form that includes the NULL because the NULL form, while
not preferred, is what was observed as being generated by most not preferred, is what was observed as being generated by most
implementations. Implementers should also note that if the algorithm implementations. Implementers should also note that if the algorithm
is MD5 instead of SHA-1, then the form that omits the is MD5 instead of SHA-1, then the form that omits the
AlgorithmIdentifier parameters field is not allowed and the sender AlgorithmIdentifier parameters field is not allowed and the sender
has to use the form where the NULL is included. has to use the form where the NULL is included.
The preferred encryption algorithm for S/MIME in SIP is AES as The preferred encryption algorithm for S/MIME in SIP is AES as
defined in RFC 3853 [11]. defined in RFC 3853 [10].
Observed S/MIME interoperability has been better when UAs did not Observed S/MIME interoperability has been better when UAs did not
attach the senders' certificates. Attaching the certificates attach the senders' certificates. Attaching the certificates
significantly increases the size of the messages, which should be significantly increases the size of the messages, which should be
considered when sending over UDP. Furthermore, the receiver cannot considered when sending over UDP. Furthermore, the receiver cannot
rely on the sender to always send the certificate, so it does not rely on the sender to always send the certificate, so it does not
turn out to be useful in most situations. turn out to be useful in most situations.
6. Additional Test Scenarios 6. Additional Test Scenarios
This section provides a non-exhaustive list of tests that This section provides a non-exhaustive list of tests that
implementations should perform while developing systems that use implementations should perform while developing systems that use
S/MIME and TLS for SIP. S/MIME and TLS for SIP.
Much of the required behavior for inspecting certificates when using Much of the required behavior for inspecting certificates when using
S/MIME and TLS with SIP is currently underspecified. The non- S/MIME and TLS with SIP is currently underspecified. The non-
normative recommendations in this document capture the current normative recommendations in this document capture the current
folklore around that required behavior, guided by both related folklore around that required behavior, guided by both related
normative works such as RFC 4474 [12] (particulary, section 13.4 normative works such as RFC 4474 [11] (particulary, section 13.4
Domain Names and Subordination) and informative works such as RFC Domain Names and Subordination) and informative works such as RFC
2818 [19] section 3.1. To summarize, test plans should: 2818 [18] section 3.1. To summarize, test plans should:
o For S/MIME secured bodies, assure that the peer's URI (address-of- o For S/MIME secured bodies, assure that the peer's URI (address-of-
record, as per RFC 3261 [3] section 23.3) appears in the record, as per RFC 3261 [3] section 23.3) appears in the
subjectAltName of the peer's certifcate as a subjectAltName of the peer's certifcate as a
uniformResourceIdentifier field. uniformResourceIdentifier field.
o For TLS, assure that the peer's hostname appears as described in o For TLS, assure that the peer's hostname appears as described in
Draft SIP Domain Certs [17]. Also: RFC 5922 [16]. Also:
* assure an exact match in a dNSName entry in the subjectAltName * assure an exact match in a dNSName entry in the subjectAltName
if there are any dNSNames in the subjectAltName. Wildcard if there are any dNSNames in the subjectAltName. Wildcard
matching is not allowed against these dNSName entries. See matching is not allowed against these dNSName entries. See
section 7.1 of Draft SIP Domain Certs [17]. section 7.1 of RFC 5922 [16].
* assure that the most specific CommonName in the Subject field * assure that the most specific CommonName in the Subject field
matches if there are no dNSName entries in the subjectAltName matches if there are no dNSName entries in the subjectAltName
at all (which is not the same as there being no matching at all (which is not the same as there being no matching
dNSName entries). This match can be either exact, or against dNSName entries). This match can be either exact, or against
an entry that uses the wildcard matching character '*' an entry that uses the wildcard matching character '*'
The peer's hostname is discovered from the initial DNS query in The peer's hostname is discovered from the initial DNS query in
the server location process RFC 3263 [4]. the server location process RFC 3263 [4].
o IP addresses can appear in subjectAltName (RFC 5280 [15]) of the o IP addresses can appear in subjectAltName (RFC 5280 [14]) of the
peer's certificate, e.g. "IP:192.168.0.1". Note that if IP peer's certificate, e.g. "IP:192.168.0.1". Note that if IP
addresses are used in subjectAltName, there are important addresses are used in subjectAltName, there are important
ramifications regarding the use of Record-Route headers that also ramifications regarding the use of Record-Route headers that also
need to be considered. See section 7.5 of Draft SIP Domain Certs need to be considered. See section 7.5 of RFC 5922 [16]. Use of
[17]. Use of IP addresses instead of domain names is inadvisable. IP addresses instead of domain names is inadvisable.
For each of these tests, an implementation will proceed past the For each of these tests, an implementation will proceed past the
verification point only if the certificate is "good". S/MIME verification point only if the certificate is "good". S/MIME
protected requests presenting bad certificate data will be rejected. protected requests presenting bad certificate data will be rejected.
S/MIME protected responses presenting bad certificate information S/MIME protected responses presenting bad certificate information
will be ignored. TLS connections involving bad certificate data will will be ignored. TLS connections involving bad certificate data will
not be completed. not be completed.
1. S/MIME : Good peer certificate 1. S/MIME : Good peer certificate
2. S/MIME : Bad peer certificate (peer URI does not appear in 2. S/MIME : Bad peer certificate (peer URI does not appear in
skipping to change at page 32, line 4 skipping to change at page 31, line 4
No IANA actions are required. No IANA actions are required.
8. Acknowledgments 8. Acknowledgments
Many thanks to the developers of all the open source software used to Many thanks to the developers of all the open source software used to
create these call flows. This includes the underlying crypto and TLS create these call flows. This includes the underlying crypto and TLS
software used from openssl.org, the SIP stack from software used from openssl.org, the SIP stack from
www.resiprocate.org, and the SIMPLE IMPP agent from www.sipimp.org. www.resiprocate.org, and the SIMPLE IMPP agent from www.sipimp.org.
The TLS flow dumps were done with SSLDump from The TLS flow dumps were done with SSLDump from
http://www.rtfm.com/ssldump. The book "SSL and TLS" [22] was a huge http://www.rtfm.com/ssldump. The book "SSL and TLS" [21] was a huge
help in developing the code for these flows. It's sad there is no help in developing the code for these flows. It's sad there is no
second edition. second edition.
Thanks to Jim Schaad, Russ Housley, Eric Rescorla, Dan Wing, Tat Thanks to Jim Schaad, Russ Housley, Eric Rescorla, Dan Wing, Tat
Chan, and Lyndsay Campbell who all helped find and correct mistakes Chan, and Lyndsay Campbell who all helped find and correct mistakes
in this document. in this document.
Vijay Gurbani and Alan Jeffrey contributed much of the additional Vijay Gurbani and Alan Jeffrey contributed much of the additional
test scenario content. test scenario content.
skipping to change at page 32, line 32 skipping to change at page 31, line 32
securely. securely.
This document recommends some things that implementers might test or This document recommends some things that implementers might test or
verify to improve the security of their implementations. It is verify to improve the security of their implementations. It is
impossible to make a comprehensive list of these, and this document impossible to make a comprehensive list of these, and this document
only suggests some of the most common mistakes that have been seen at only suggests some of the most common mistakes that have been seen at
the SIPit interoperability events. Just because an implementation the SIPit interoperability events. Just because an implementation
does everything this document recommends does not make it secure. does everything this document recommends does not make it secure.
This document does not show any messages to check certificate This document does not show any messages to check certificate
revocation status (see section 3.3 of RFC 5280 [15]) as that is not revocation status (see section 3.3 of RFC 5280 [14]) as that is not
part of the SIP call flow. The expectation is that revocation status part of the SIP call flow. The expectation is that revocation status
is checked regularly to protect against the possibility of is checked regularly to protect against the possibility of
certificate compromise or repudiation. For more information on how certificate compromise or repudiation. For more information on how
certificate revocation status can be checked, see RFC 2560 [2] certificate revocation status can be checked, see RFC 2560 [2]
(Online Certificate Status Protocol) and RFC 5055 [13] (Server-Based (Online Certificate Status Protocol) and RFC 5055 [12] (Server-Based
Certificate Validation Protocol). Certificate Validation Protocol).
10. Changelog 10. Changelog
(RFC Editor: remove this section) (RFC Editor: remove this section)
-02 to -03 -02 to -03
* Re-worded "should" and "must" so that the document doesn't * Re-worded "should" and "must" so that the document doesn't
sound like it is making normative statements. Actual normative sound like it is making normative statements. Actual normative
behavior is referred to in the respective RFCs. behavior is referred to in the respective RFCs.
skipping to change at page 34, line 15 skipping to change at page 33, line 15
-00 to -01 -00 to -01
* Addition of OPEN ISSUES. * Addition of OPEN ISSUES.
* Numerous minor edits from mailing list feedback. * Numerous minor edits from mailing list feedback.
to -00 to -00
* Changed RFC 3369 references to RFC 3852. * Changed RFC 3369 references to RFC 3852.
* Changed draft-ietf-sip-identity references to RFC 4474. * Changed draft-ietf-sip-identity references to RFC 4474.
* Added an ASN.1 dump of CMS signed content where SHA-1 * Added an ASN.1 dump of CMS signed content where SHA-1
parameters are omitted instead of being set to ASN.1 NULL. parameters are omitted instead of being set to ASN.1 NULL.
* Accept headers added to messages. * Accept headers added to messages.
* User and domain certificates are generated with EKU as * User and domain certificates are generated with EKU as
specified in Draft SIP EKU [16]. specified in Draft SIP EKU.
* Message content that is shown is computed using certificates * Message content that is shown is computed using certificates
generated with EKU. generated with EKU.
* Message dump archive returned. * Message dump archive returned.
* Message archive contains messages formed with and without EKU * Message archive contains messages formed with and without EKU
certificates. certificates.
prior to -00 prior to -00
* Incorporated the Test cases from Vijay Gurbani's and Alan * Incorporated the Test cases from Vijay Gurbani's and Alan
Jeffrey's Use of TLS in SIP draft Jeffrey's Use of TLS in SIP draft
* Began to capture the folklore around where identities are * Began to capture the folklore around where identities are
carried in certificates for use with SIP carried in certificates for use with SIP
skipping to change at page 34, line 47 skipping to change at page 33, line 47
"X.509 Internet Public Key Infrastructure Online Certificate "X.509 Internet Public Key Infrastructure Online Certificate
Status Protocol - OCSP", RFC 2560, June 1999. Status Protocol - OCSP", RFC 2560, June 1999.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002. (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [5] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
Transport Layer Security (TLS)", RFC 3268, June 2002.
[6] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
RFC 3370, August 2002. RFC 3370, August 2002.
[7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002. Instant Messaging", RFC 3428, December 2002.
[8] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and [7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 3546, June 2003. RFC 4366, April 2006.
[9] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [8] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail
(S/MIME) Version 3.1 Message Specification", RFC 3851, Extensions (S/MIME) Version 3.2 Message Specification",
July 2004. RFC 5751, January 2010.
[10] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, [9] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
July 2004. RFC 5652, September 2009.
[11] Peterson, J., "S/MIME Advanced Encryption Standard (AES) [10] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)", Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004. RFC 3853, July 2004.
[12] Peterson, J. and C. Jennings, "Enhancements for Authenticated [11] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)", Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006. RFC 4474, August 2006.
[13] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, [12] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk,
"Server-Based Certificate Validation Protocol (SCVP)", "Server-Based Certificate Validation Protocol (SCVP)",
RFC 5055, December 2007. RFC 5055, December 2007.
[14] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [13] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008. Protocol Version 1.2", RFC 5246, August 2008.
[15] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, [14] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,
R., and W. Polk, "Internet X.509 Public Key Infrastructure R., and W. Polk, "Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", Certificate and Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008. RFC 5280, May 2008.
[16] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) [15] Lawrence, S. and V. Gurbani, "Extended Key Usage (EKU) for
for Session Initiation Protocol (SIP) X.509 Certificates", Session Initiation Protocol (SIP) X.509 Certificates",
draft-ietf-sip-eku-08 (work in progress), October 2009. RFC 5924, June 2010.
[17] Gurbani, V., Lawrence, S., and B. Laboratories, "Domain [16] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates
Certificates in the Session Initiation Protocol (SIP)", in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
draft-ietf-sip-domain-certs-07 (work in progress), May 2010.
[18] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the [17] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the
Session Initiation Protocol (SIP)", Session Initiation Protocol (SIP)", RFC 5923, June 2010.
draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009.
11.2. Informative References 11.2. Informative References
[19] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [18] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[20] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, [19] Hoffman, P., "Examples of S/MIME Messages", RFC 4134,
July 2005. July 2005.
[21] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and [20] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and
H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test
Messages", RFC 4475, May 2006. Messages", RFC 4475, May 2006.
[22] Rescorla, E., "SSL and TLS - Designing and Building Secure [21] Rescorla, E., "SSL and TLS - Designing and Building Secure
Systems", 2001. Systems", 2001.
[23] Rescorla, E., "SSLDump manpage". [22] Rescorla, E., "SSLDump manpage".
Appendix A. Making Test Certificates Appendix A. Making Test Certificates
These scripts allow you to make certificates for test purposes. The These scripts allow you to make certificates for test purposes. The
certificates will all share a common CA root so that everyone running certificates will all share a common CA root so that everyone running
these scripts can have interoperable certificates. WARNING - these these scripts can have interoperable certificates. WARNING - these
certificates are totally insecure and are for test purposes only. certificates are totally insecure and are for test purposes only.
All the CA created by this script share the same private key to All the CA created by this script share the same private key to
facilitate interoperability testing, but this totally breaks the facilitate interoperability testing, but this totally breaks the
security since the private key of the CA is well known. security since the private key of the CA is well known.
skipping to change at page 43, line 18 skipping to change at page 42, line 16
mv ${ADDR}_cert.pem domain_cert_${ADDR}.pem ;; mv ${ADDR}_cert.pem domain_cert_${ADDR}.pem ;;
esac esac
Appendix B. Certificates for Testing Appendix B. Certificates for Testing
This section contains various certificates used for testing in PEM This section contains various certificates used for testing in PEM
format. format.
B.1. Certificates Using EKU B.1. Certificates Using EKU
These certificates make use of the EKU specification described in These certificates make use of the EKU specification described in RFC
Draft SIP EKU [16]. 5924 [15].
Fluffy's user certificate for example.com: Fluffy's user certificate for example.com:
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIEKDCCA5GgAwIBAgIHSQIRAYQBXDANBgkqhkiG9w0BAQUFADBwMQswCQYDVQQG MIIEKDCCA5GgAwIBAgIHSQIRAYQBXDANBgkqhkiG9w0BAQUFADBwMQswCQYDVQQG
EwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxDjAM EwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxDjAM
BgNVBAoTBXNpcGl0MSkwJwYDVQQLEyBTaXBpdCBUZXN0IENlcnRpZmljYXRlIEF1 BgNVBAoTBXNpcGl0MSkwJwYDVQQLEyBTaXBpdCBUZXN0IENlcnRpZmljYXRlIEF1
dGhvcml0eTAgFw0xMDA1MTEyMDIyNTVaGA8yMTEwMDQxNzIwMjI1NVowYjELMAkG dGhvcml0eTAgFw0xMDA1MTEyMDIyNTVaGA8yMTEwMDQxNzIwMjI1NVowYjELMAkG
A1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3Nl A1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3Nl
MQ4wDAYDVQQKEwVzaXBpdDEbMBkGA1UEAxQSZmx1ZmZ5QGV4YW1wbGUuY29tMIIB MQ4wDAYDVQQKEwVzaXBpdDEbMBkGA1UEAxQSZmx1ZmZ5QGV4YW1wbGUuY29tMIIB
skipping to change at page 50, line 36 skipping to change at page 49, line 36
Fb7jqHV9TRDPkHS9EPHxQdyHjUAeKDeke6tsP1I+I+MWM/Do2ZOaN3/ayYLcrIUE Fb7jqHV9TRDPkHS9EPHxQdyHjUAeKDeke6tsP1I+I+MWM/Do2ZOaN3/ayYLcrIUE
SYl5AYiq/Xzjau9bcsWf3n3ca0dGqUn85kPi9l0H6OvqlY/H6lb3kM+V/wBe34vv SYl5AYiq/Xzjau9bcsWf3n3ca0dGqUn85kPi9l0H6OvqlY/H6lb3kM+V/wBe34vv
7AlGP0ECgYBefLxSwdv+abhBraz60jNpnMoKkowTJ3qxzzLVB7yx/a0e0Sb83Hi2 7AlGP0ECgYBefLxSwdv+abhBraz60jNpnMoKkowTJ3qxzzLVB7yx/a0e0Sb83Hi2
I/EMeSUotZcwVNsqgEZSxRqrQbryDsOIkCckzmOgAk8F5vgDXSmZfqPDhFufF1kg I/EMeSUotZcwVNsqgEZSxRqrQbryDsOIkCckzmOgAk8F5vgDXSmZfqPDhFufF1kg
lMvhtbGLv0wC+ODzIj9VY5PVhYsYSMfVOneGzllkOb4ika9Ms/BSVg== lMvhtbGLv0wC+ODzIj9VY5PVhYsYSMfVOneGzllkOb4ika9Ms/BSVg==
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
B.2. Certificates NOT Using EKU B.2. Certificates NOT Using EKU
These certificates do not make use of the EKU specification described These certificates do not make use of the EKU specification described
in Draft SIP EKU [16]. Most existing certificates fall in this in RFC 5924 [15]. Most existing certificates fall in this category.
category.
Fluffy's user certificate for example.com: Fluffy's user certificate for example.com:
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIECTCCA3KgAwIBAgIHSQIRAYQBYDANBgkqhkiG9w0BAQUFADBwMQswCQYDVQQG MIIECTCCA3KgAwIBAgIHSQIRAYQBYDANBgkqhkiG9w0BAQUFADBwMQswCQYDVQQG
EwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxDjAM EwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2UxDjAM
BgNVBAoTBXNpcGl0MSkwJwYDVQQLEyBTaXBpdCBUZXN0IENlcnRpZmljYXRlIEF1 BgNVBAoTBXNpcGl0MSkwJwYDVQQLEyBTaXBpdCBUZXN0IENlcnRpZmljYXRlIEF1
dGhvcml0eTAgFw0xMDA1MTEyMDIyNTdaGA8yMTEwMDQxNzIwMjI1N1owYjELMAkG dGhvcml0eTAgFw0xMDA1MTEyMDIyNTdaGA8yMTEwMDQxNzIwMjI1N1owYjELMAkG
A1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3Nl A1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3Nl
MQ4wDAYDVQQKEwVzaXBpdDEbMBkGA1UEAxQSZmx1ZmZ5QGV4YW1wbGUuY29tMIIB MQ4wDAYDVQQKEwVzaXBpdDEbMBkGA1UEAxQSZmx1ZmZ5QGV4YW1wbGUuY29tMIIB
skipping to change at page 58, line 37 skipping to change at page 57, line 37
yp+SxVFwY5yy9MgfcHEOEt+1vUrJOH8T5ucE9CO0NI4NCG4xljaM0cWl54UEV3NJ yp+SxVFwY5yy9MgfcHEOEt+1vUrJOH8T5ucE9CO0NI4NCG4xljaM0cWl54UEV3NJ
aQJUqQKBgQCf+dCVtWEEPtFtrron48Gw1j41d3prOHEgPaSjfDK5jyxOplvre9ta aQJUqQKBgQCf+dCVtWEEPtFtrron48Gw1j41d3prOHEgPaSjfDK5jyxOplvre9ta
1htMIgENsXeiCvsobmI6LQ1dcdP3B+PCDmGtnPfEQZ7u9tQpThC+dw/dYl0VrmCm 1htMIgENsXeiCvsobmI6LQ1dcdP3B+PCDmGtnPfEQZ7u9tQpThC+dw/dYl0VrmCm
mIEIx6i15btHhdckAL+2nXt2dZ4wfW56Rgptl3m+MI1HCLLhlMN9PA== mIEIx6i15btHhdckAL+2nXt2dZ4wfW56Rgptl3m+MI1HCLLhlMN9PA==
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
B.3. Certificate Chaining with a Non-Root CA B.3. Certificate Chaining with a Non-Root CA
Following is a certificate for a non-root CA in example.net. The Following is a certificate for a non-root CA in example.net. The
certificate was signed by the root CA shown in Section 2.1. As certificate was signed by the root CA shown in Section 2.1. As
indicated in sections 4.2.1.9 and 4.2.1.3 RFC 5280 [15], "cA" is set indicated in sections 4.2.1.9 and 4.2.1.3 RFC 5280 [14], "cA" is set
in Basic Constraints, and "keyCertSign" is set in Key Usage. This in Basic Constraints, and "keyCertSign" is set in Key Usage. This
identifies the certificate holder as a signing authority. identifies the certificate holder as a signing authority.
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number:
49:02:11:01:84:01:60 49:02:11:01:84:01:60
Signature Algorithm: sha1WithRSAEncryption Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=San Jose, O=sipit, Issuer: C=US, ST=California, L=San Jose, O=sipit,
OU=Sipit Test Certificate Authority OU=Sipit Test Certificate Authority
Validity Validity
 End of changes. 61 change blocks. 
133 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/