draft-ietf-sipcore-sec-flows-05.txt   draft-ietf-sipcore-sec-flows-06.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: May 12, 2011 Columbia University Expires: May 22, 2011 Columbia University
R. Sparks R. Sparks
B. Hibbard, Ed. B. Hibbard, Ed.
Tekelec Tekelec
November 8, 2010 November 18, 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-05 draft-ietf-sipcore-sec-flows-06
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 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on May 12, 2011. This Internet-Draft will expire on May 22, 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 Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 4
2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8 2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 8
2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 9 2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 9
3. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 11 3. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12
3.1. TLS with Server Authentication . . . . . . . . . . . . . . 11 3.1. TLS with Server Authentication . . . . . . . . . . . . . . 12
3.2. MESSAGE Transaction Over TLS . . . . . . . . . . . . . . . 13 3.2. MESSAGE Transaction Over TLS . . . . . . . . . . . . . . . 13
4. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 14 4. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 15
4.1. MESSAGE Request with Signed Body . . . . . . . . . . . . . 14 4.1. MESSAGE Request with Signed Body . . . . . . . . . . . . . 15
4.2. MESSAGE Request with Encrypted Body . . . . . . . . . . . 20 4.2. MESSAGE Request with Encrypted Body . . . . . . . . . . . 20
4.3. MESSAGE Request with Encrypted and Signed Body . . . . . . 22 4.3. MESSAGE Request with Encrypted and Signed Body . . . . . . 22
5. Observed Interoperability Issues . . . . . . . . . . . . . . . 27 5. Observed Interoperability Issues . . . . . . . . . . . . . . . 29
6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 29 6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 31
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . . . 31 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 37
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . . 34 11.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 42
A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 36 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 43
A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 39 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 46
Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 49
B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42 B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 49
B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 49 B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 56
B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 57 B.3. Certificate Chaining with a Non-Root CA . . . . . . . . . 64
Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 63 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74
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 [12]) implementations are becoming very SIP with TLS ([RFC5246]) implementations are becoming very common.
common. Several implementations of the S/MIME (RFC 5751 [7]) portion Several implementations of the S/MIME ([RFC5751]) portion of SIP
of SIP (RFC 3261 [3]) are also becoming available. After several ([RFC3261]) 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
Certificate Authority (CA) that can be used during the SIP Certificate Authority (CA) that can be used during the SIP
skipping to change at page 9, line 39 skipping to change at page 9, line 39
02:e8:4c:80:83:e6:0c:aa:e0:d6:b0:5c:75:d2:90:39:52:8b: 02:e8:4c:80:83:e6:0c:aa:e0:d6:b0:5c:75:d2:90:39:52:8b:
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
5280 [13]. [RFC5280].
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 Common Profile for Instant
example.com is the domain for fluffy. The message could be coming Messaging (CPIM) gateway. In this example, example.com is the domain
from any host in *.example.com, and the AOR in the user certificate for fluffy. The message could be coming from any host in
would still be the same. The others are shown in Appendix B.1. *.example.com, and the AOR in the user certificate would still be the
same. The others are shown in Appendix B.1. These certificates make
These certificates make use of the EKU extension discussed in RFC use of the Extended Key Usage (EKU) extension discussed in [RFC5924].
5924 [14]. Note that the X509v3 Extended Key Usage attribute refers Note that the X509v3 Extended Key Usage attribute refers to the SIP
to the SIP OID introduced in RFC 5924 [14], which is OID introduced in [RFC5924], 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
Not After : Apr 17 20:22:55 2110 GMT Not After : Apr 17 20:22:55 2110 GMT
skipping to change at page 11, line 32 skipping to change at page 12, line 10
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 [12] connection to example.net. example.com forming a TLS [RFC5246] connection to example.net. In
In this example mutual authentication is not used. Note that the this example mutual authentication is not used. Note that the client
client proposed three protocol suites including proposed three protocol suites including TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA defined in RFC 5246 [12]. The defined in [RFC5246]. The certificate returned by the server
certificate returned by the server contains a Subject Alternative contains a Subject Alternative Name that is set to example.net. A
Name that is set to example.net. A detailed discussion of TLS can be detailed discussion of TLS can be found in SSL and TLS [EKR-TLS].
found in SSL and TLS [20]. For more details on the SSLDump tool, see For more details on the SSLDump tool, see the SSLDump Manual
the SSLDump Manual [21]. [ssldump-manpage].
This example does not use the Server Extended Hello (see RFC 5246 This example does not use the Server Extended Hello (see [RFC5246]).
[12]).
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
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_SHA TLS_DHE_RSA_WITH_AES_256_SHA
TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DSS_RSA_WITH_AES_256_SHA TLS_DSS_RSA_WITH_AES_256_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA
skipping to change at page 13, line 23 skipping to change at page 13, line 46
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 Transaction Over TLS 3.2. MESSAGE Transaction Over TLS
Once the TLS session is set up, the following MESSAGE request (as Once the TLS session is set up, the following MESSAGE request (as
defined in RFC 3428 [6] is sent from fluffy@example.com to defined in [RFC3428] 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 [19] is used to break long the <allOneLine> convention from [RFC4475] 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 13, line 50 skipping to change at page 14, line 25
CSeq: 4308 MESSAGE CSeq: 4308 MESSAGE
<allOneLine> <allOneLine>
Accept: multipart/signed, text/plain, application/pkcs7-mime, Accept: multipart/signed, text/plain, application/pkcs7-mime,
application/sdp, multipart/alternative application/sdp, multipart/alternative
</allOneLine> </allOneLine>
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 User Agent (UA) goes to send a message to example.com, the UA
already has a TLS connection to example.com and if it does, it may can see if it already has a TLS connection to example.com and if it
send the message over this connection. A UA should have some scheme does, it may send the message over this connection. A UA should have
for reusing connections as opening a new TLS connection for every some scheme for reusing connections as opening a new TLS connection
message results in awful performance. Implementers are encouraged to for every message results in awful performance. Implementers are
read RFC 5923 [16] and RFC 3263 [4]. encouraged to read [RFC5923] and [RFC3263].
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>
skipping to change at page 16, line 13 skipping to change at page 16, line 20
in 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 5652 [8]. certificate is not attached as it is optional in [RFC5652].
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 18, line 7 skipping to change at page 18, line 15
: 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 [5]. The above dump of Blob 1 has NULL, as mentioned in [RFC3370]. The above dump of Blob 1 has SHA-1
SHA-1 parameters set to NULL. Below are the same contents signed parameters set to NULL. Below are the same contents signed with the
with the same key, but omitting the NULL according to RFC 3370 [5]. same key, but omitting the NULL according to [RFC3370]. This is the
This is the preferred encoding. This is covered in greater detail in 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 {
30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 30 5: OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
: } : }
skipping to change at page 28, line 8 skipping to change at page 29, line 16
This section describes some common interoperability problems. These This section describes some common interoperability problems. These
were observed by the authors at SIPit interoperability events. were observed by the authors at SIPit interoperability events.
Implementers should be careful to verify that their systems do not Implementers should be careful to verify that their systems do not
introduce these common problems, and, when possible, make their introduce these common problems, and, when possible, make their
clients forgiving in what they receive. Implementations should take clients forgiving in what they receive. Implementations should take
extra care to produce reasonable error messages when interacting with extra care to produce reasonable error messages when interacting with
software that has these problems. software that has these problems.
Some SIP clients incorrectly only do SSLv3 and do not support TLS. 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 Many SIP clients were found to accept expired certificates with no
warning or error. 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 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 RFC 5922 [15] describing path validation can be found in Section 7 of [RFC5922] and
and section 6 of RFC 5280 [13]. If a client is trying to set up a Section 6 of [RFC5280]. If a client is trying to set up a TLS
TLS connection to good.example.com and it gets a TLS connection set connection to good.example.com and it gets a TLS connection set up
up with a server that presents a valid certificate but with the name with a server that presents a valid certificate but with the name
evil.example.com, it will typically generate an error or warning of 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 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 with sip:fluffy@example.com, one of the items in the Subject
Alternate Name set in the certificate will need to match according to Alternate Name set in the certificate will need to match according to
the certificate validation rules in section 23 of RFC 3261 [3] and the certificate validation rules in Section 23 of [RFC3261] and
section 6 of RFC 5280 [13]. Section 6 of [RFC5280].
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. See Section 3.2 of [RFC5621].
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 [5] is the form in which encoding as set out in Section 2 of [RFC3370] 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, [RFC3370] also says the recipients need to be able to
the form in which the AlgorithmIdentifier parameter field is present receive the form in which the AlgorithmIdentifier parameter field is
and set to NULL. Examples of the form using NULL can be found in present and set to NULL. Examples of the form using NULL can be
Section 4.2 of RFC 4134 [18]. Receivers really do need to be able to found in Section 4.2 of [RFC4134]. Receivers really do need to be
receive the form that includes the NULL because the NULL form, while able to receive the form that includes the NULL because the NULL
not preferred, is what was observed as being generated by most form, while not preferred, is what was observed as being generated by
implementations. Implementers should also note that if the algorithm most implementations. Implementers should also note that if the
is MD5 instead of SHA-1, then the form that omits the algorithm 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 [9]. defined in [RFC3853].
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 [10] (particulary, section 13.4 normative works such as [RFC4474] (particulary, Section 13.4 Domain
Domain Names and Subordination) and informative works such as RFC Names and Subordination) and informative works such as [RFC2818]
2818 [17] section 3.1. To summarize, test plans should: 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 [RFC3261] 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
RFC 5922 [15]. Also: [RFC5922]. 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 RFC 5922 [15]. Section 7.1 of [RFC5922].
* 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 [RFC3263].
o IP addresses can appear in subjectAltName (RFC 5280 [13]) of the
o IP addresses can appear in subjectAltName ([RFC5280]) 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 RFC 5922 [15]. Use of need to be considered. See Section 7.5 of [RFC5922]. Use of IP
IP addresses instead of domain names is inadvisable. 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
subjAltName) subjAltName)
3. S/MIME : Bad peer certificate (valid authority chain does not 3. S/MIME : Bad peer certificate (valid authority chain does not
end at a trusted CA) end at a trusted CA)
4. S/MIME : Bad peer certificate (incomplete authority chain) 4. S/MIME : Bad peer certificate (incomplete authority chain)
5. S/MIME : Bad peer certificate (the current time does not fall 5. S/MIME : Bad peer certificate (the current time does not fall
within the period of validity) within the period of validity)
6. S/MIME : Bad peer certificate (certificate or cert in authority 6. S/MIME : Bad peer certificate (certificate or cert in authority
chain has been revoked) chain has been revoked)
7. S/MIME : Bad peer certificate ("Digital Signature" is not 7. S/MIME : Bad peer certificate ("Digital Signature" is not
specified as an X509v3 Key Usage) specified as an X509v3 Key Usage)
8. TLS : Good peer certificate (hostname appears in dNSName in 8. TLS : Good peer certificate (hostname appears in dNSName in
subjAltName) subjAltName)
9. TLS : Good peer certificate (no dNSNames in subjAltName, 9. TLS : Good peer certificate (no dNSNames in subjAltName,
hostname appears in CN of Subject) hostname appears in CN of Subject)
10. TLS : Good peer certificate (CN of Subject empty, and 10. TLS : Good peer certificate (CN of Subject empty, and
subjectAltName extension contains an iPAddress stored in the subjectAltName extension contains an iPAddress stored in the
octet string in network byte order form as specified in RFC 791 octet string in network byte order form as specified in RFC 791
[1]) [RFC0791])
11. TLS : Bad peer certificate (no match in dNSNames or in the 11. TLS : Bad peer certificate (no match in dNSNames or in the
Subject CN) Subject CN)
12. TLS : Bad peer certificate (valid authority chain does not end 12. TLS : Bad peer certificate (valid authority chain does not end
at a trusted CA) at a trusted CA)
13. TLS : Bad peer certificate (incomplete authority chain) 13. TLS : Bad peer certificate (incomplete authority chain)
14. TLS : Bad peer certificate (the current time does not fall 14. TLS : Bad peer certificate (the current time does not fall
within the period of validity) within the period of validity)
15. TLS : Bad peer certificate (certificate or cert in authority 15. TLS : Bad peer certificate (certificate or cert in authority
chain has been revoked) chain has been revoked)
16. TLS : Bad peer certificate ("TLS Web Server Authentication" is 16. TLS : Bad peer certificate ("TLS Web Server Authentication" is
not specified as an X509v3 Key Usage) not specified as an X509v3 Key Usage)
17. TLS : Bad peer certificate (Neither "SIP Domain" nor "Any 17. TLS : Bad peer certificate (Neither "SIP Domain" nor "Any
Extended Key Usage" specified as an X509v3 Extended Key Usage, Extended Key Usage" specified as an X509v3 Extended Key Usage,
and X509v3 Extended Key Usage is present) and X509v3 Extended Key Usage is present)
7. IANA Considerations 7. IANA Considerations
No IANA actions are required. No IANA actions are required.
8. Acknowledgments 8. Acknowledgments
skipping to change at page 31, line 4 skipping to change at page 35, line 12
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" [20] was a huge http://www.rtfm.com/ssldump. The book "SSL and TLS" [EKR-TLS] was a
help in developing the code for these flows. It's sad there is no huge help in developing the code for these flows. It's sad there is
second edition. no 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.
9. Security Considerations 9. Security Considerations
skipping to change at page 31, line 32 skipping to change at page 36, line 22
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 [13]) as that is not revocation status (see Section 3.3 of [RFC5280]) as that is not part
part of the SIP call flow. The expectation is that revocation status of the SIP call flow. The expectation is that revocation status is
is checked regularly to protect against the possibility of checked regularly to protect against the possibility of certificate
certificate compromise or repudiation. For more information on how compromise or repudiation. For more information on how certificate
certificate revocation status can be checked, see RFC 2560 [2] revocation status can be checked, see [RFC2560] (Online Certificate
(Online Certificate Status Protocol) and RFC 5055 [11] (Server-Based Status Protocol) and [RFC5055] (Server-Based Certificate Validation
Certificate Validation Protocol). 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.
* Section 5: re-worded paragraphs 4 and 5 regarding * Section 5: re-worded paragraphs 4 and 5 regarding
subjectAltName, and added references. subjectAltName, and added references.
* Section 6: added references, clarified use of IP addresses, and * Section 6: added references, clarified use of IP addresses, and
clarified which From/To URI is used for comparison (from RFC clarified which From/To URI is used for comparison (from
3261 section 23.2). Added an EKU test case. section 23.2). Added an EKU test case.
* Section 9: added text about certificate revocation checking. * Section 9: added text about certificate revocation checking.
* Appendix B.3: new section to present certificate chains longer * Appendix B.3: new section to present certificate chains longer
than 2 (non-root CA). than 2 (non-root CA).
* Made examples consistently use <allOneLine> convention. * Made examples consistently use <allOneLine> convention.
* CSeq looks more random. * CSeq looks more random.
* Serial numbers in certs are non-zero. * Serial numbers in certs are non-zero.
* All flows re-generated using new certs. IP addresses conform * All flows re-generated using new certs. IP addresses conform
to RFC 5737. to RFC 5737.
* Updated references. * Updated references.
-01 to -02 -01 to -02
* Draft is now informational, not standards track. Normative- * Draft is now informational, not standards track. Normative-
sounding language and references to RFC 2119 removed. sounding language and references to RFC 2119 removed.
* Add TODO: change "hello" to "Hello!" in example flows for * Add TODO: change "hello" to "Hello!" in example flows for
consistency. consistency.
* Add TODO: Fix subjectAltName DNS:com to DNS:example.com and * Add TODO: Fix subjectAltName DNS:com to DNS:example.com and
DNS:net to DNS:example.net. DNS:net to DNS:example.net.
* Add TODO: use allOneLine convention from RFC4475. * Add TODO: use allOneLine convention from RFC4475.
* Section 3: updated open issue regarding contact headers in * Section 3: updated open issue regarding contact headers in
MESSAGE. MESSAGE.
* Section 3.2: added some text about RFC 3263 and connection * Section 3.2: added some text about RFC 3263 and connection
reuse and closed open issue. reuse and closed open issue.
* Section 5: clarified text about sender attaching certs, closed * Section 5: clarified text about sender attaching certs, closed
issue. issue.
* Section 5: clarified text about observed problems, closed * Section 5: clarified text about observed problems, closed
issue. issue.
* Section 5: closed issue about clients vs. servers vs. proxies. * Section 5: closed issue about clients vs. servers vs. proxies.
* Section 6: updated section text and open issue where IP address * Section 6: updated section text and open issue where IP address
is in subjectAltName. is in subjectAltName.
* Section 6: added normative references and closed "folklore" * Section 6: added normative references and closed "folklore"
issue. issue.
* Section 6: added cases about cert usage and broken chains, * Section 6: added cases about cert usage and broken chains,
updated OPEN ISSUE: we need a SIP EKU example. updated OPEN ISSUE: we need a SIP EKU example.
* References: updated references to drafts and re-categorized * References: updated references to drafts and re-categorized
informative vs. normative. informative vs. normative.
* Section 9: added some text about revocation status and closed * Section 9: added some text about revocation status and closed
issue. issue.
* Appendix B: open issue: do we need non-root-CA certs and host * Appendix B: open issue: do we need non-root-CA certs and host
certs signed by them for help in testing cases in Section 6? certs signed by them for help in testing cases in Section 6?
* Miscellaneous minor editorial changes. * Miscellaneous minor editorial changes.
-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. 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
* Removed the message dump archive pending verification (will * Removed the message dump archive pending verification (will
return in -02) return in -02)
11. References 11. References
11.1. Normative References 11.1. Normative References
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[2] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
"X.509 Internet Public Key Infrastructure Online Certificate Adams, "X.509 Internet Public Key Infrastructure Online
Status Protocol - OCSP", RFC 2560, June 1999. Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: A., Peterson, J., Sparks, R., Handley, M., and E.
Session Initiation Protocol", RFC 3261, June 2002. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
(SIP): Locating SIP Servers", RFC 3263, June 2002. Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[5] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
RFC 3370, August 2002. Algorithms", RFC 3370, August 2002.
[6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
D. Gurle, "Session Initiation Protocol (SIP) Extension for and D. Gurle, "Session Initiation Protocol (SIP) Extension
Instant Messaging", RFC 3428, December 2002. for Instant Messaging", RFC 3428, December 2002.
[7] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Extensions (S/MIME) Version 3.2 Message Specification", Requirement for the Session Initiation Protocol (SIP)",
RFC 5751, January 2010. RFC 3853, July 2004.
[8] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
RFC 5652, September 2009. Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[9] Peterson, J., "S/MIME Advanced Encryption Standard (AES) [RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W.
Requirement for the Session Initiation Protocol (SIP)", Polk, "Server-Based Certificate Validation Protocol
RFC 3853, July 2004. (SCVP)", RFC 5055, December 2007.
[10] Peterson, J. and C. Jennings, "Enhancements for Authenticated [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
Identity Management in the Session Initiation Protocol (SIP)", (TLS) Protocol Version 1.2", RFC 5246, August 2008.
RFC 4474, August 2006.
[11] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W. Polk, [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
"Server-Based Certificate Validation Protocol (SCVP)", Housley, R., and W. Polk, "Internet X.509 Public Key
RFC 5055, December 2007. Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [RFC5621] Camarillo, G., "Message Body Handling in the Session
Protocol Version 1.2", RFC 5246, August 2008. Initiation Protocol (SIP)", RFC 5621, September 2009.
[13] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
R., and W. Polk, "Internet X.509 Public Key Infrastructure RFC 5652, September 2009.
Certificate and Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008.
[14] Lawrence, S. and V. Gurbani, "Extended Key Usage (EKU) for [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Session Initiation Protocol (SIP) X.509 Certificates", Mail Extensions (S/MIME) Version 3.2 Message
RFC 5924, June 2010. Specification", RFC 5751, January 2010.
[15] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
in the Session Initiation Protocol (SIP)", RFC 5922, June 2010. Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, June 2010.
[16] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the [RFC5923] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in
Session Initiation Protocol (SIP)", RFC 5923, June 2010. the Session Initiation Protocol (SIP)", RFC 5923,
June 2010.
[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.
11.2. Informative References 11.2. Informative References
[17] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [EKR-TLS] Rescorla, E., "SSL and TLS - Designing and Building Secure
Systems", 2001.
[18] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
July 2005.
[19] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and [RFC4134] Hoffman, P., "Examples of S/MIME Messages", RFC 4134,
H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test July 2005.
Messages", RFC 4475, May 2006.
[20] Rescorla, E., "SSL and TLS - Designing and Building Secure [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
Systems", 2001. and H. Schulzrinne, "Session Initiation Protocol (SIP)
Torture Test Messages", RFC 4475, May 2006.
[21] Rescorla, E., "SSLDump manpage". [ssldump-manpage]
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 42, line 12 skipping to change at page 49, line 12
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 RFC These certificates make use of the EKU specification described in
5924 [14]. [RFC5924].
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 49, line 36 skipping to change at page 56, 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 RFC 5924 [14]. Most existing certificates fall in this category. in [RFC5924]. Most existing certificates fall in this 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 57, line 37 skipping to change at page 64, 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 [13], "cA" is set indicated in Sections 4.2.1.9 and 4.2.1.3 [RFC5280], "cA" is set in
in Basic Constraints, and "keyCertSign" is set in Key Usage. This 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
Not Before: Jun 7 22:13:09 2010 GMT Not Before: Jun 7 22:13:09 2010 GMT
 End of changes. 118 change blocks. 
163 lines changed or deleted 241 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/