draft-ietf-sipcore-sec-flows-00.txt   draft-ietf-sipcore-sec-flows-01.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track K. Ono Intended status: Standards Track K. Ono
Expires: November 5, 2009 NTT Corporation Expires: May 27, 2010 Columbia University
R. Sparks R. Sparks
B. Hibbard, Ed. B. Hibbard, Ed.
Tekelec Tekelec
May 4, 2009 November 23, 2009
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-00 draft-ietf-sipcore-sec-flows-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
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 November 5, 2009. This Internet-Draft will expire on May 27, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
skipping to change at page 3, line 9 skipping to change at page 3, line 9
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 3. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 5
4.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 5 3.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 9
4.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 9 3.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10
4.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10 4. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12
5. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12 4.1. TLS with Server Authentication . . . . . . . . . . . . . . 12
5.1. TLS with Server Authentication . . . . . . . . . . . . . . 12 4.2. MESSAGE Message Over TLS . . . . . . . . . . . . . . . . . 14
5.2. MESSAGE Message Over TLS . . . . . . . . . . . . . . . . . 14 5. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 15
6. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 15 5.1. MESSAGE Message with Signed Body . . . . . . . . . . . . . 15
6.1. MESSAGE Message with Signed Body . . . . . . . . . . . . . 15 5.2. MESSAGE Message with Encrypted Body . . . . . . . . . . . 20
6.2. MESSAGE Message with Encrypted Body . . . . . . . . . . . 20 5.3. MESSAGE Message with Encrypted and Signed Body . . . . . . 23
6.3. MESSAGE Message with Encrypted and Signed Body . . . . . . 22 6. Observed Interoperability Issues . . . . . . . . . . . . . . . 28
7. Observed Interoperability Issues . . . . . . . . . . . . . . . 27 7. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 30
8. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 33
12. Known Problems with this version . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 12.1. Normative References . . . . . . . . . . . . . . . . . . . 33
13.1. Normative References . . . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . . 34
13.2. Informative References . . . . . . . . . . . . . . . . . . 32 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35
Appendix A. Making Test Certificates . . . . . . . . . . . . . . 32 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 36
A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 34 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 39
A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 37 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42
Appendix B. Certificates for Testing . . . . . . . . . . . . . . 39 B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42
B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 39 B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 49
B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 47 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 58
Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59
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[4] implementations are becoming very common. Several SIP with TLS (RFC 5246 [5]) implementations are becoming very common.
implementations of the S/MIME[7] portion of SIP[2] are also becoming Several implementations of the S/MIME (RFC 3851 [8]) portion of SIP
available. After several interoperability events, it is clear that (RFC 3261 [2]) are also becoming available. After several
it is difficult to write these systems without any test vectors or interoperability events, it is clear that it is difficult to write
examples of "known good" messages to test against. Furthermore, these systems without any test vectors or examples of "known good"
testing at the events is often hampered by trying to get certificates messages to test against. Furthermore, testing at the events is
signed by some common test root into the appropriate format for often hampered by trying to get certificates signed by some common
various clients. This document addresses both of these issues by test root into the appropriate format for various clients. This
providing messages that give detailed examples that implementers can document addresses both of these issues by providing messages that
use for comparison and that can also be used for testing. In give detailed examples that implementers can use for comparison and
addition, this document provides a common certificate that can be that can also be used for testing. In addition, this document
used for a Certificate Authority (CA) to reduce the time it takes to provides a common certificate and private key that can be used for a
set up a test at an interoperability event. The document also Certificate Authority (CA) to reduce the time it takes to set up a
provides some hints and clarifications for implementers. test at an interoperability event. The document also provides some
hints and clarifications for implementers.
A simple SIP call flow using SIPS URIs and TLS is shown in Section 5. A simple SIP call flow using SIPS URIs and TLS is shown in Section 4.
The certificates for the hosts used are shown in Section 4.2, and the The certificates for the hosts used are shown in Section 3.2, and the
CA certificates used to sign these are shown in Section 4.1. CA certificates used to sign these are shown in Section 3.1.
The text from Section 6.1 through Section 6.3 shows some simple SIP The text from Section 5.1 through Section 5.3 shows some simple SIP
call flows using S/MIME to sign and encrypt the body of the message. call flows using S/MIME to sign and encrypt the body of the message.
The user certificates used in these examples are shown in The user certificates used in these examples are shown in
Section 4.3. These host certificates are signed with the same CA Section 3.3. These host certificates are signed with the same CA
certificate. certificate.
Section 7 presents a partial list of things implementers should Section 6 presents a partial list of things implementers should
consider in order to implement systems that will interoperate. consider in order to implement systems that will interoperate.
A way to make certificates that can be used for interoperability A way to make certificates that can be used for interoperability
testing is presented in Appendix A, along with methods for converting testing is presented in Appendix A, along with methods for converting
these to various formats. The certificates used while creating the these to various formats. The certificates used while creating the
examples and test messages in this document are made available in examples and test messages in this document are made available in
Appendix B. Appendix B.
Binary copies of various messages in this draft that can be used for Binary copies of various messages in this draft that can be used for
testing appear in Appendix C. testing appear in Appendix C.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1]. document are to be interpreted as described in RFC 2119 [1].
3. Security Considerations
Implementers must never use any of the certificates provided in this
document in anything but a test environment. Installing the CA root
certificates used in this document as a trusted root in operational
software would completely destroy the security of the system while
giving the user the impression that the system was operating
securely.
This document recommends some things that implementers might test or
verify to improve the security of their implementations. It is
impossible to make a comprehensive list of these, and this document
only suggests some of the most common mistakes that have been seen at
the SIPit interoperability events. Just because an implementation
does everything this document recommends does not make it secure.
This document does not show the messages needed to check Certificate OPEN ISSUE: If there's no intent to have normative language, this
Revocation Lists (see [3]) as that is not part of the SIP call flow. section and reference to RFC 2119 should be removed.
4. Certificates 3. Certificates
4.1. CA Certificates 3.1. CA Certificates
The certificate used by the CA to sign the other certificates is The certificate used by the CA to sign the other certificates is
shown below. This is a X509v3 certificate. Note that the basic shown below. This is a X509v3 certificate. Note that the X.509v3
constraints allow it to be used as a CA. Basic Constraints in the certificate allows it to be used as a CA,
certificate authority. This certificate is not used directly in the
TLS call flow; it is used only to verify user and host certificates.
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: 0 (0x0) Serial Number: 0 (0x0)
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: Jul 18 12:21:52 2003 GMT Not Before: Jul 18 12:21:52 2003 GMT
Not After : Jul 15 12:21:52 2013 GMT Not After : Jul 15 12:21:52 2013 GMT
Subject: C=US, ST=California, L=San Jose, O=sipit, Subject: C=US, ST=California, L=San Jose, O=sipit,
skipping to change at page 9, line 14 skipping to change at page 9, line 14
00 96 6d 1b ef d5 91 93-45 7c 5b 1f cf c4 aa 47 ..m.....E|[....G 00 96 6d 1b ef d5 91 93-45 7c 5b 1f cf c4 aa 47 ..m.....E|[....G
52 0b 34 a8 50 fa ec fa-b4 2a 47 4c 5d 41 a7 3d R.4.P....*GL]A.= 52 0b 34 a8 50 fa ec fa-b4 2a 47 4c 5d 41 a7 3d R.4.P....*GL]A.=
c0 d6 3f 9e 56 5b 91 1d-ce a8 07 b3 1b a4 9f 9a ..?.V[.......... c0 d6 3f 9e 56 5b 91 1d-ce a8 07 b3 1b a4 9f 9a ..?.V[..........
49 6f 7f e0 ce 83 94 71-42 af fe 63 a2 34 dc b4 Io.....qB..c.4.. 49 6f 7f e0 ce 83 94 71-42 af fe 63 a2 34 dc b4 Io.....qB..c.4..
5e a5 ce ca 79 50 e9 6a-99 4c 14 69 e9 7c ab 22 ^...yP.j.L.i.|." 5e a5 ce ca 79 50 e9 6a-99 4c 14 69 e9 7c ab 22 ^...yP.j.L.i.|."
6c 44 cc 8a 9c 33 6b 23-50 42 05 1f e1 c2 81 88 lD...3k#PB...... 6c 44 cc 8a 9c 33 6b 23-50 42 05 1f e1 c2 81 88 lD...3k#PB......
5f ba e5 47 bb 85 9b 83-25 ad 84 32 ff 2a 5b 8b _..G....%..2.*[. 5f ba e5 47 bb 85 9b 83-25 ad 84 32 ff 2a 5b 8b _..G....%..2.*[.
70 12 11 83 61 c9 69 15-4f 58 a3 3c 92 d4 e8 6f p...a.i.OX.<...o 70 12 11 83 61 c9 69 15-4f 58 a3 3c 92 d4 e8 6f p...a.i.OX.<...o
52 R 52 R
4.2. Host Certificates 3.2. Host Certificates
The certificate for the host example.com is shown below. Note that The certificate for the host example.com is shown below. Note that
the Subject Alternative Name is set to example.com and is a DNS type. the Subject Alternative Name is set to example.com and is a DNS type.
The certificates for the other hosts are shown in Appendix B. The certificates for the other hosts are shown in Appendix B.
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number:
01:52:01:54:01:90:00:43 01:52:01:54:01:90:00:43
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,
skipping to change at page 10, line 34 skipping to change at page 10, line 34
Signature Algorithm: sha1WithRSAEncryption Signature Algorithm: sha1WithRSAEncryption
1f:b7:c2:84:43:90:d2:06:81:47:48:e7:14:39:5a:ad:a0:53: 1f:b7:c2:84:43:90:d2:06:81:47:48:e7:14:39:5a:ad:a0:53:
36:fb:6f:d7:e1:bf:b1:65:98:fd:a6:c5:e0:5a:b7:5f:90:08: 36:fb:6f:d7:e1:bf:b1:65:98:fd:a6:c5:e0:5a:b7:5f:90:08:
ab:d4:85:2a:d1:57:f2:0e:c1:26:43:de:e1:26:1e:ef:90:95: ab:d4:85:2a:d1:57:f2:0e:c1:26:43:de:e1:26:1e:ef:90:95:
94:6e:74:45:36:01:41:ce:43:c2:91:54:dd:35:a8:6e:57:3b: 94:6e:74:45:36:01:41:ce:43:c2:91:54:dd:35:a8:6e:57:3b:
b2:34:71:aa:d4:ea:34:aa:8c:8e:dd:e1:a4:2c:05:45:fb:b8: b2:34:71:aa:d4:ea:34:aa:8c:8e:dd:e1:a4:2c:05:45:fb:b8:
38:0c:7b:1f:4f:d7:3c:d7:68:7c:57:57:6d:13:c6:3f:44:dd: 38:0c:7b:1f:4f:d7:3c:d7:68:7c:57:57:6d:13:c6:3f:44:dd:
fd:6b:fb:65:96:9b:87:92:95:10:af:e7:47:cd:72:6c:6e:d7: fd:6b:fb:65:96:9b:87:92:95:10:af:e7:47:cd:72:6c:6e:d7:
60:f5 60:f5
4.3. User Certificates The example host certificate above, as well as all the others
presented in this document, are signed directly by a root CA. These
certificate chains have a length equal to two: the root CA and the
host certificate. Non-root CAs exist and may also sign certificates.
The certificate chains presented by hosts with certificates signed by
non-root CAs will have a length greater than two. For more details
on how certificate chains are validated, see section 6.1.4 of RFC
5280 [4].
The user certificate for fluffy@example.com is shown below. Note 3.3. User Certificates
that the Subject Alternative Name has a list of names with different
URL types such as a sip, im, or pres URL. This is necessary for User certificates are used by many applications to establish user
interoperating with CPIM gateway. In this example, example.com is identity. The user certificate for fluffy@example.com is shown
the domain for fluffy. The message could be coming from a host below. Note that the Subject Alternative Name has a list of names
called atlanta.example.com, and the AOR in the user certificate would with different URL types such as a sip, im, or pres URL. This is
still be the same. The others are shown in Appendix B.1. These necessary for interoperating with a CPIM gateway. In this example,
certificates make use of the EKU extension discussed in [12]. Note example.com is the domain for fluffy. The message could be coming
that the SIP OID introduced in [12] is 1.3.6.1.5.5.7.3.20 from a host called atlanta.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 use of the EKU extension
discussed in Draft SIP EKU [13]. Note that the X509v3 Extended Key
Usage attribute refers to the SIP OID introduced in Draft SIP EKU
[13] is 1.3.6.1.5.5.7.3.20
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number:
01:52:01:54:01:90:00:47 01:52:01:54:01:90:00:47
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: Apr 29 17:10:46 2009 GMT Not Before: Apr 29 17:10:46 2009 GMT
Not After : Apr 28 17:10:46 2012 GMT Not After : Apr 28 17:10:46 2012 GMT
Subject: C=US, ST=California, L=San Jose, O=sipit, Subject: C=US, ST=California, L=San Jose, O=sipit,
CN=fluffy@example.com CN=fluffy@example.com
Subject Public Key Info: Subject Public Key Info:
Public Key Algorithm: rsaEncryption Public Key Algorithm: rsaEncryption
RSA Public Key: (2048 bit) RSA Public Key: (2048 bit)
Modulus (2048 bit): Modulus (2048 bit):
00:f4:0f:e8:18:2d:b1:9b:93:ef:64:6b:19:d7:83: 00:f4:0f:e8:18:2d:b1:9b:93:ef:64:6b:19:d7:83:
skipping to change at page 12, line 16 skipping to change at page 12, line 28
91:3a:4f:5a:68:32:37:df:0f:dd:40:b7:34:68:91:ce:0f:f0: 91:3a:4f:5a:68:32:37:df:0f:dd:40:b7:34:68:91:ce:0f:f0:
16:02:ee:be:b6:1d:e1:92:87:c9:5e:a9:42:78:26:45:bb:17: 16:02:ee:be:b6:1d:e1:92:87:c9:5e:a9:42:78:26:45:bb:17:
08:ee:83:ea:e9:d8:30:84:66:90:69:b8:78:ff:c4:09:5c:ea: 08:ee:83:ea:e9:d8:30:84:66:90:69:b8:78:ff:c4:09:5c:ea:
e2:8a:10:e6:f9:64:eb:db:47:0e:10:29:4d:0e:bb:53:65:70: e2:8a:10:e6:f9:64:eb:db:47:0e:10:29:4d:0e:bb:53:65:70:
e1:71:82:c8:d0:14:f4:24:30:49:a6:fc:80:a8:b1:84:bc:e9: e1:71:82:c8:d0:14:f4:24:30:49:a6:fc:80:a8:b1:84:bc:e9:
73:75 73:75
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
5. Callflow with Message Over TLS 4. Callflow with Message Over TLS
5.1. TLS with Server Authentication 4.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[4] connection to example.net. In this example.com forming a TLSRFC 5246 [5] connection to example.net. In
example mutual authentication is not used. Note that the client this example mutual authentication is not used. Note that the client
proposed three protocol suites including TLS_RSA_WITH_AES_128_CBC_SHA proposed three protocol suites including TLS_RSA_WITH_AES_128_CBC_SHA
defined in [6]. The certificate returned by the server contains a defined in RFC 3268 [7]. The certificate returned by the server
Subject Alternative Name that is set to example.net. A detailed contains a Subject Alternative Name that is set to example.net. A
discussion of TLS can be found in [18]. detailed discussion of TLS can be found in SSL and TLS [18]. For
more details on the SSLDump tool, see the SSLDump Manual [19].
This example does not use the Server Extended Hello[5]. This example does not use the Server Extended Hello (see RFC 3546
[6]).
New TCP connection #1: www.example.com(57592) <-> www.example.com(5061) New TCP connection #1: www.example.com(57592) <-> www.example.com(5061)
1 1 0.0015 (0.0015) C>SV3.1(101) Handshake 1 1 0.0015 (0.0015) C>SV3.1(101) Handshake
ClientHello ClientHello
Version 3.1 Version 3.1
random[32]= random[32]=
49 f7 83 8d 1f 21 c7 73 0c 9f 61 ab 13 2d 6b 26 49 f7 83 8d 1f 21 c7 73 0c 9f 61 ab 13 2d 6b 26
1e 79 0c 68 b3 b6 f8 24 54 6b 41 0d 9b 3a 03 31 1e 79 0c 68 b3 b6 f8 24 54 6b 41 0d 9b 3a 03 31
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 14, line 6 skipping to change at page 14, line 20
1 10 0.0770 (0.0000) S>CV3.1(1) ChangeCipherSpec 1 10 0.0770 (0.0000) S>CV3.1(1) ChangeCipherSpec
1 11 0.0770 (0.0000) S>CV3.1(48) Handshake 1 11 0.0770 (0.0000) S>CV3.1(48) Handshake
1 12 0.0780 (0.0010) C>SV3.1(32) application_data 1 12 0.0780 (0.0010) C>SV3.1(32) application_data
1 13 0.0780 (0.0000) C>SV3.1(448) application_data 1 13 0.0780 (0.0000) C>SV3.1(448) application_data
1 14 0.2804 (0.2023) S>CV3.1(32) application_data 1 14 0.2804 (0.2023) S>CV3.1(32) application_data
1 15 0.2804 (0.0000) S>CV3.1(416) application_data 1 15 0.2804 (0.0000) S>CV3.1(416) application_data
1 16 12.3288 (12.0483) S>CV3.1(32) Alert 1 16 12.3288 (12.0483) S>CV3.1(32) Alert
1 12.3293 (0.0004) S>C TCP FIN 1 12.3293 (0.0004) S>C TCP FIN
1 17 12.3310 (0.0017) C>SV3.1(32) Alert 1 17 12.3310 (0.0017) C>SV3.1(32) Alert
5.2. MESSAGE Message Over TLS 4.2. MESSAGE Message Over TLS
Once the TLS session is set up, the following MESSAGE message (as Once the TLS session is set up, the following MESSAGE message (as
defined in [15] is sent from fluffy@example.com to defined in RFC 3428 [15] is sent from fluffy@example.com to
kumiko@example.net. Note that the URI has a SIPS URL and that the 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 [11] is used to break long lines. the <allOneLine> convention from RFC 4475 [12] is used to break long
The actual message does not contain the linebreaks contained within lines. The actual message does not contain the linebreaks contained
those tags. within those tags.
MESSAGE sips:kumiko@example.net:5061 SIP/2.0 MESSAGE sips:kumiko@example.net:5061 SIP/2.0
Via: SIP/2.0/TLS 208.77.188.166:15001;\ Via: SIP/2.0/TLS 208.77.188.166:15001;\
branch=z9hG4bK-d8754z-3be7667f18d2f53c-1---d8754z-;\ branch=z9hG4bK-d8754z-3be7667f18d2f53c-1---d8754z-;\
rport=54499 rport=54499
Max-Forwards: 70 Max-Forwards: 70
Contact: <sips:fluffy@example.com:15001> Contact: <sips:fluffy@example.com:15001>
To: <sips:kumiko@example.net:5061> To: <sips:kumiko@example.net:5061>
From: <sips:fluffy@example.com:15001>;tag=2eff6a6f From: <sips:fluffy@example.com:15001>;tag=2eff6a6f
Call-ID: NmE1NDk1YzFmYmMzMDVjOTEwMzVlZjNkMTBjZGZlMzY. Call-ID: NmE1NDk1YzFmYmMzMDVjOTEwMzVlZjNkMTBjZGZlMzY.
skipping to change at page 15, line 5 skipping to change at page 15, line 16
Via: SIP/2.0/TLS 208.77.188.166:15001;\ Via: SIP/2.0/TLS 208.77.188.166:15001;\
branch=z9hG4bK-d8754z-3be7667f18d2f53c-1---d8754z-;\ branch=z9hG4bK-d8754z-3be7667f18d2f53c-1---d8754z-;\
rport=54499 rport=54499
Contact: <sip:208.77.188.166:5061;transport=TLS> Contact: <sip:208.77.188.166:5061;transport=TLS>
To: <sips:kumiko@example.net:5061>;tag=00e62966 To: <sips:kumiko@example.net:5061>;tag=00e62966
From: <sips:fluffy@example.com:15001>;tag=2eff6a6f From: <sips:fluffy@example.com:15001>;tag=2eff6a6f
Call-ID: NmE1NDk1YzFmYmMzMDVjOTEwMzVlZjNkMTBjZGZlMzY. Call-ID: NmE1NDk1YzFmYmMzMDVjOTEwMzVlZjNkMTBjZGZlMzY.
CSeq: 1 MESSAGE CSeq: 1 MESSAGE
Content-Length: 0 Content-Length: 0
6. Callflow with S/MIME-secured Message OPEN ISSUE: Ben Campbell pointed out: Contact: "RFC3428 forbids
Contact header fields in MESSAGE requests or 2XX responses to
MESSAGE. This brings up the question as to whether MESSAGE is a good
example, as you may wish to illustrate SIPS rules concerning Contact.
(This reoccurs in all MESSAGE and 200 OK examples)." We need
consensus on this.
6.1. MESSAGE Message with Signed Body OPEN ISSUE: There should be some more information about how this
MESSAGE is associated with the handshake example. The dump in 5.1 is
slightly confusing in that example.com and example.net both resolved
to the same address, so reverse lookup shows both domains as
example.com.
Example Signed Message. The value on the Content-Type line has been OPEN ISSUE: Add a few lines about RFC 3263. Add a few lines about
broken across lines to fit on the page but it should not be broken how the UA decides to create a new TLS session or use an existing one
across lines in actual implementations. (but not "connection-reuse" draft level of reuse complexity). Any
volunteers?
5. Callflow with S/MIME-secured Message
5.1. MESSAGE Message with Signed Body
Below is an example of a signed message. The values on the Content-
Type line (multipart/signed) and on the Content-Disposition line have
been broken across lines to fit on the page, but they should not be
broken across lines in actual implementations.
MESSAGE sip:kumiko@example.net SIP/2.0 MESSAGE sip:kumiko@example.net SIP/2.0
Via: SIP/2.0/TCP 208.77.188.166:15001;\ Via: SIP/2.0/TCP 208.77.188.166:15001;\
branch=z9hG4bK-d8754z-36f515466f3a7f5c-1---d8754z-;\ branch=z9hG4bK-d8754z-36f515466f3a7f5c-1---d8754z-;\
rport=54500 rport=54500
Max-Forwards: 70 Max-Forwards: 70
Contact: <sip:fluffy@example.com> Contact: <sip:fluffy@example.com>
To: <sip:kumiko@example.net> To: <sip:kumiko@example.net>
From: <sip:fluffy@example.com>;tag=e8cc1b5c From: <sip:fluffy@example.com>;tag=e8cc1b5c
Call-ID: NjVjYjNjNzQzNTZlYzdjMWUwM2VjYjcwOTVjM2RkZDM. Call-ID: NjVjYjNjNzQzNTZlYzdjMWUwM2VjYjcwOTVjM2RkZDM.
skipping to change at page 15, line 45 skipping to change at page 16, line 37
Content-Type: application/pkcs7-signature;name=smime.p7s Content-Type: application/pkcs7-signature;name=smime.p7s
Content-Disposition: attachment;handling=required;\ Content-Disposition: attachment;handling=required;\
filename=smime.p7s filename=smime.p7s
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
***************** *****************
* BINARY BLOB 1 * * BINARY BLOB 1 *
***************** *****************
--ac31fa52a112030f-- --ac31fa52a112030f--
It is important to note that the signature includes the header and It is important to note that the signature ("BINARY BLOB 1") is
excludes the boundary. The value on the Message-body line ends with computed over the MIME headers and body, but excludes the multipart
CRLF. The CRLF is included in the boundary and should not be part of boundary lines. The value on the Message-body line ends with CRLF.
the signature computation. In the example below, the signature is The CRLF is included in the boundary and should not be part of the
computed over data starting with the C in the Content-Type and ending signature computation. To be clear, the signature is computed over
with the o in the hello. data starting with the C in the Content-Type and ending with the o in
the hello.
Content-Type: text/plain Content-Type: text/plain
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
hello hello
ASN.1 parse of binary Blob 1. Note that at address 30, the hash for Following is the ASN.1 parsing of encrypted contents referred to
the signature is specified as SHA-1. Also note that the sender's above as "BINARY BLOB 1". Note that at address 30, the hash for the
certificate is not attached as it is optional in [8]. signature is specified as SHA-1. Also note that the sender's
certificate is not attached as it is optional in RFC 3852 [9].
0 471: SEQUENCE { 0 471: 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 456: [0] { 15 456: [0] {
19 452: SEQUENCE { 19 452: 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 6 skipping to change at page 18, line 47
: 14 1B 55 8F E7 E7 1C E0 16 E7 1B 62 D4 D4 F2 0A : 14 1B 55 8F E7 E7 1C E0 16 E7 1B 62 D4 D4 F2 0A
: 7C AB B0 2C 46 02 08 B7 CA 2A 1E 08 CB 4D 1C AA : 7C AB B0 2C 46 02 08 B7 CA 2A 1E 08 CB 4D 1C AA
: 09 34 AA 53 5F 59 95 3D C7 87 DD 17 8D 78 04 01 : 09 34 AA 53 5F 59 95 3D C7 87 DD 17 8D 78 04 01
: } : }
: } : }
: } : }
: } : }
: } : }
SHA-1 parameters may be omitted entirely, instead of being set to SHA-1 parameters may be omitted entirely, instead of being set to
NULL, as mentioned in [10]. The above dump of Blob 1 has SHA-1 NULL, as mentioned in RFC 3370 [11]. The above dump of Blob 1 has
parameters set to NULL. Below are the same contents signed with the SHA-1 parameters set to NULL. Below are the same contents signed
same key, but omitting the NULL according to [10]. This is the with the same key, but omitting the NULL according to RFC 3370 [11].
preferred encoding. This is covered in greater detail in Section 7. This is the preferred encoding. This is covered in greater detail in
Section 6.
0 467: SEQUENCE { 0 467: 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 452: [0] { 15 452: [0] {
19 448: SEQUENCE { 19 448: 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 20, line 5 skipping to change at page 20, line 44
: F2 A8 E0 3A 3F 1E D2 22 B8 4D EA 11 0A 08 76 A7 : F2 A8 E0 3A 3F 1E D2 22 B8 4D EA 11 0A 08 76 A7
: 14 1B 55 8F E7 E7 1C E0 16 E7 1B 62 D4 D4 F2 0A : 14 1B 55 8F E7 E7 1C E0 16 E7 1B 62 D4 D4 F2 0A
: 7C AB B0 2C 46 02 08 B7 CA 2A 1E 08 CB 4D 1C AA : 7C AB B0 2C 46 02 08 B7 CA 2A 1E 08 CB 4D 1C AA
: 09 34 AA 53 5F 59 95 3D C7 87 DD 17 8D 78 04 01 : 09 34 AA 53 5F 59 95 3D C7 87 DD 17 8D 78 04 01
: } : }
: } : }
: } : }
: } : }
: } : }
6.2. MESSAGE Message with Encrypted Body 5.2. MESSAGE Message with Encrypted Body
Example encrypted text/plain message that says "hello": Below is an example of an encrypted text/plain message that says
"hello". The binary encrypted contents have been replaced with the
block "BINARY BLOB 2".
MESSAGE sip:kumiko@example.net SIP/2.0 MESSAGE sip:kumiko@example.net SIP/2.0
Via: SIP/2.0/TCP 208.77.188.166:15001;\ Via: SIP/2.0/TCP 208.77.188.166:15001;\
branch=z9hG4bK-d8754z-1c7dd40a5fff4463-1---d8754z-;\ branch=z9hG4bK-d8754z-1c7dd40a5fff4463-1---d8754z-;\
rport=54502 rport=54502
Max-Forwards: 70 Max-Forwards: 70
Contact: <sip:fluffy@example.com> Contact: <sip:fluffy@example.com>
To: <sip:kumiko@example.net> To: <sip:kumiko@example.net>
From: <sip:fluffy@example.com>;tag=5a10502e From: <sip:fluffy@example.com>;tag=5a10502e
Call-ID: YTk3ODIwN2FiYTUwMGZmYTM1MDJiMzY2ODcyYzE4MGM. Call-ID: YTk3ODIwN2FiYTUwMGZmYTM1MDJiMzY2ODcyYzE4MGM.
skipping to change at page 20, line 32 skipping to change at page 21, line 28
filename=smime.p7 filename=smime.p7
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-Type: application/pkcs7-mime;smime-type=enveloped-data;\ Content-Type: application/pkcs7-mime;smime-type=enveloped-data;\
name=smime.p7m name=smime.p7m
Content-Length: 564 Content-Length: 564
***************** *****************
* BINARY BLOB 2 * * BINARY BLOB 2 *
***************** *****************
ASN.1 parse of binary Blob 2. Note that at address 453, the Following is the ASN.1 parsing of "BINARY BLOB 2". Note that at
encryption is set to aes128-CBC. address 453, the encryption is set to aes128-CBC.
0 560: SEQUENCE { 0 560: SEQUENCE {
4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
15 545: [0] { 15 545: [0] {
19 541: SEQUENCE { 19 541: SEQUENCE {
23 1: INTEGER 0 23 1: INTEGER 0
26 408: SET { 26 408: SET {
30 404: SEQUENCE { 30 404: SEQUENCE {
34 1: INTEGER 0 34 1: INTEGER 0
37 124: SEQUENCE { 37 124: SEQUENCE {
skipping to change at page 22, line 28 skipping to change at page 23, line 24
: 41 4C FE FA A4 B4 70 1A 62 86 BC C1 DE 90 94 69 : 41 4C FE FA A4 B4 70 1A 62 86 BC C1 DE 90 94 69
: 7D 0A D2 0F F3 4E 7D 6F 72 2F 7A A7 4B B4 4A 59 : 7D 0A D2 0F F3 4E 7D 6F 72 2F 7A A7 4B B4 4A 59
: C9 C0 CB F3 AD 92 D6 31 66 94 0E B3 49 01 63 D5 : C9 C0 CB F3 AD 92 D6 31 66 94 0E B3 49 01 63 D5
: BA 5A AE 29 ED C9 8A 87 EA 00 FC 4B 97 62 54 56 : BA 5A AE 29 ED C9 8A 87 EA 00 FC 4B 97 62 54 56
: 91 DB 78 50 B6 AD B7 B8 5D F6 11 41 3C C0 20 DD : 91 DB 78 50 B6 AD B7 B8 5D F6 11 41 3C C0 20 DD
: } : }
: } : }
: } : }
: } : }
6.3. MESSAGE Message with Encrypted and Signed Body 5.3. MESSAGE Message with Encrypted and Signed Body
In the example below, one of the headers is contained in a box and is In the example below, some of the header values have been split
split across two lines. This was only done to make it fit in the RFC across mutliple lines. Where the lines have been broken, a "\" has
format. This header should not have the box around it and should be been inserted. This was only done to make it fit in the RFC format.
on one line with no whitespace between the "mime;" and the "smime- Specifically, the application/pkcs7-mime Content-Type line should be
type". Note that Content-Type is split across lines for formatting one line with no whitespace between the "mime;" and the "smime-type".
but is not split in the real message. The values are split across lines for formatting, but are not split
in the real message. The binary encrypted content has been replaced
with "BINARY BLOB 3", and the binary signed content has been replaced
with "BINARY BLOB 4".
MESSAGE sip:kumiko@example.net SIP/2.0 MESSAGE sip:kumiko@example.net SIP/2.0
Via: SIP/2.0/TCP 208.77.188.166:15001;\ Via: SIP/2.0/TCP 208.77.188.166:15001;\
branch=z9hG4bK-d8754z-c2d73f665e157842-1---d8754z-;\ branch=z9hG4bK-d8754z-c2d73f665e157842-1---d8754z-;\
rport=54503 rport=54503
Max-Forwards: 70 Max-Forwards: 70
Contact: <sip:fluffy@example.com> Contact: <sip:fluffy@example.com>
To: <sip:kumiko@example.net> To: <sip:kumiko@example.net>
From: <sip:fluffy@example.com>;tag=5e4dd355 From: <sip:fluffy@example.com>;tag=5e4dd355
Call-ID: MDQ2ZGVkZWQ4YzJhZTZhZDRjNzE0MDJkNzk1NGIxNTQ. Call-ID: MDQ2ZGVkZWQ4YzJhZTZhZDRjNzE0MDJkNzk1NGIxNTQ.
skipping to change at page 23, line 42 skipping to change at page 24, line 42
Content-Type: application/pkcs7-signature;name=smime.p7s Content-Type: application/pkcs7-signature;name=smime.p7s
Content-Disposition: attachment;handling=required;\ Content-Disposition: attachment;handling=required;\
filename=smime.p7s filename=smime.p7s
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
***************** *****************
* BINARY BLOB 4 * * BINARY BLOB 4 *
***************** *****************
--e0c6b73cedc44967-- --e0c6b73cedc44967--
Binary blob 3 Below is the ASN.1 parsing of "BINARY BLOB 3".
0 560: SEQUENCE { 0 560: SEQUENCE {
4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) 4 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3)
15 545: [0] { 15 545: [0] {
19 541: SEQUENCE { 19 541: SEQUENCE {
23 1: INTEGER 0 23 1: INTEGER 0
26 408: SET { 26 408: SET {
30 404: SEQUENCE { 30 404: SEQUENCE {
34 1: INTEGER 0 34 1: INTEGER 0
37 124: SEQUENCE { 37 124: SEQUENCE {
skipping to change at page 25, line 37 skipping to change at page 26, line 37
: 89 5B E2 84 60 E5 45 2B 74 CC 61 4F A2 E4 03 37 : 89 5B E2 84 60 E5 45 2B 74 CC 61 4F A2 E4 03 37
: D3 C6 83 52 A3 CF C9 E8 C7 8D AF F3 36 39 56 BF : D3 C6 83 52 A3 CF C9 E8 C7 8D AF F3 36 39 56 BF
: 8F 7D E3 F8 65 43 6E 61 65 85 5B 62 AC BF 3A DD : 8F 7D E3 F8 65 43 6E 61 65 85 5B 62 AC BF 3A DD
: 99 C7 8B B7 BA A7 3F 97 61 3C B1 E2 E0 45 BC 17 : 99 C7 8B B7 BA A7 3F 97 61 3C B1 E2 E0 45 BC 17
: 43 51 03 F4 41 8C 55 E7 02 5F CC AE F5 02 6B D8 : 43 51 03 F4 41 8C 55 E7 02 5F CC AE F5 02 6B D8
: } : }
: } : }
: } : }
: } : }
Binary Blob 4 Below is the ASN.1 parsing of "BINARY BLOB 4".
0 471: SEQUENCE { 0 471: 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 456: [0] { 15 456: [0] {
19 452: SEQUENCE { 19 452: 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 27, line 33 skipping to change at page 28, line 33
: 4F AD 7D D9 69 68 35 B1 98 10 64 42 1D 3D 24 57 : 4F AD 7D D9 69 68 35 B1 98 10 64 42 1D 3D 24 57
: C5 BF 48 C3 B0 E6 3C 91 3C 27 52 28 D2 BE 2C AC : C5 BF 48 C3 B0 E6 3C 91 3C 27 52 28 D2 BE 2C AC
: 79 79 32 2E C4 9D 7C 8A 73 73 68 EC 60 E0 22 0D : 79 79 32 2E C4 9D 7C 8A 73 73 68 EC 60 E0 22 0D
: 50 7F 72 33 96 89 F8 9F 7B ED D1 4A 75 7B D5 14 : 50 7F 72 33 96 89 F8 9F 7B ED D1 4A 75 7B D5 14
: } : }
: } : }
: } : }
: } : }
: } : }
7. Observed Interoperability Issues 6. Observed Interoperability Issues
OPEN ISSUE: Who observed them? Is this experience from SIPits, etc?
I think it would strengthen the idea that these are real-world,
observed-in-the-wild issues to give sources.
This section describes some common interoperability problems. This section describes some common interoperability problems.
Implementers should verify that their clients do the correct things Implementers should verify that their clients do the correct things
and when possible make their clients forgiving in what they receive. and when possible make their clients forgiving in what they receive.
Implementations should take extra care to produce reasonable error Implementations should take extra care to produce reasonable error
messages when interacting with software that has these problems. messages when interacting with 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.
OPEN ISSUE: Do mean client class devices, or user agents in general?
Does this exclude proxies? (same question throughout section.)
Many SIP clients were found to accept expired certificates with no 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 must check that this name in the certificate. The software must check that this name
corresponds to the identity the server is trying to contact. If a corresponds to the identity the server is trying to contact. If a
client is trying to set up a TLS connection to good.example.com and client is trying to set up a TLS connection to good.example.com and
it gets a TLS connection set up with a server that presents a valid it gets a TLS connection set up with a server that presents a valid
certificate but with the name evil.example.com, it must generate an certificate but with the name evil.example.com, it must generate an
error or warning of some type. Similarly with S/MIME, if a user is error or warning of some type. Similarly with S/MIME, if a user is
trying to communicate with sip:fluffy@example.com, one of the items trying to communicate with sip:fluffy@example.com, one of the items
in the Subject Alternate Name set in the certificate must match. in the Subject Alternate Name set in the certificate must match.
Some implementations used binary MIME encodings while others used Some implementations used binary MIME encodings while others used
base64. Implementations should send only binary but must be prepared base64. Implementations should send only binary but must be prepared
to receive either. to receive either.
OPEN ISSUE: Is "...should send...must be prepared..." intended to be
a normative statement? There is a larger issue as to whether this
document is intended to be normative or informative. Should it be
standards track?
In several places in this draft, the messages contain the encoding In several places in this draft, 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 [10] is the form in encoding as set out in Section 2 of RFC 3370 [11] is the form in
which the optional AlgorithmIdentifier parameter field is omitted. which 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 [14]. Receivers really do need to be able to Section 4.2 of RFC 4134 [14]. Receivers really do need to be able to
receive the form that includes the NULL because the NULL form, while 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 [9]. defined in RFC 3853 [10].
Observed interoperability has been better when UAs did not attach the Observed S/MIME interoperability has been better when UAs did not
senders' certificates. Attaching the certificates significantly attach the senders' certificates. Attaching the certificates
increases the size of the messages, and since it can not be relied significantly increases the size of the messages, and since it can
on, it does not turn out to be useful in most situations. not be relied on, it does not turn out to be useful in most
situations.
8. Additional Test Scenarios OPEN ISSUE: There's some implicit stuff here that should be explicit.
Do you mean to recommend never attaching certs? It's probably worth
mentioning the message size limit issue. What do we mean by "it
cannot be relied upon"--that we can't rely on the peer sending it, or
it is unreliable when the peer does send it?
This section provides the beginning of a list of tests that 7. Additional Test Scenarios
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 related normative folklore around that required behavior, guided by both related
works such as [16] (particulary the section on Domain Names and normative works such as RFC 4474 [16] (particulary, section 13.4
Subordination) and [17] section 3.1. To summarize that non-normative Domain Names and Subordination) and informative works such as RFC
lore: 2818 [17] section 3.1. To summarize that non-normative lore:
o For S/MIME the peer's URI must appear in the subjectAltName of the o For S/MIME the peer's URI must appear in the subjectAltName of the
peer's certifcate as a uniformResourceIdentifier field. peer's certifcate as a uniformResourceIdentifier field.
o For TLS the peer's hostname (as fed into 3263 for resolution for o For TLS the peer's hostname (from the initial DNS query in the
locating the peer) must appear as server location process RFC 3263 [3]) must appear as
* an exact match in a dNSName entry in the subjectAltName if * an exact match in a dNSName entry in the subjectAltName if
there are any dNSNames in the subjectAltName. (Wildcard there are any dNSNames in the subjectAltName. (Wildcard
matching is not allowed against these dNSName entries) matching is not allowed against these dNSName entries)
* the most specific CommonName in the Subject field if there are * the most specific CommonName in the Subject field if there are
no dNSName entries in the subjectAltName at all (which is not no dNSName entries in the subjectAltName at all (which is not
the same as there being no matching dNSName entries). This the same as there being no matching dNSName entries). This
match can be either exact, or against an entry that uses the match can be either exact, or against an entry that uses the
wildcard matching character '*' wildcard matching character '*'
OPEN ISSUE: Are we sure all of this is truly folklore and none of it
is from bona fide normative language somewhere? The true folklore
portions may indicate future normative work we need to do.
OPEN ISSUE: From first bullet, "peer's URI"...What URI? An AoR for
the user? From or To values? Contacts? Request-URIs? For request
URIs, do we need to discuss the effects of retargeting? Do we need
to consider some of the current History-Info discussions?
OPEN ISSUE: From second bullet: What if all you've got is an IP
address? Do we disallow IPAddress entries in SubjectAltName?
OPEN ISSUE: First sub-bullet (Wildcard matching is not allowed
against these dNSName entries): Is there something that can be
referenced here? In particular, RFC2818 explicitly allows wildcards
in dNSName entries. It is not obvious to me whether the proscription
against wildcards in RFC4474 should apply to general use of TLS, or
just to identity.
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)
skipping to change at page 29, line 47 skipping to change at page 31, line 35
hostname appears in CN of Subject) hostname appears in CN of Subject)
8. TLS : Bad peer certificate (no match in dNSNames or in the 8. TLS : Bad peer certificate (no match in dNSNames or in the
Subject CN) Subject CN)
9. TLS : Bad peer certificate (valid authority chain does not end 9. TLS : Bad peer certificate (valid authority chain does not end
at a trusted CA) at a trusted CA)
10. TLS : Bad peer certificate (the current time does not fall 10. TLS : Bad peer certificate (the current time does not fall
within the period of validity) within the period of validity)
11. TLS : Bad peer certificate (certificate or cert in authority 11. TLS : Bad peer certificate (certificate or cert in authority
chain has been revoked) chain has been revoked)
9. IANA Considerations OPEN ISSUE: What about cases where the basic constraints or allowed
uses are not appropriate? Is it worth putting in cases around self-
signed certs? (i.e. self-signed cert, explicitly trusted, not
trusted, etc.) How about cases where one or more certs in the chain
to the root were not provided and not available through other means?
Those seem like sensible cases to either include or explain why they
aren't included. The self-signed cert is definitely a popular case
among developers.
8. IANA Considerations
No IANA actions are required. No IANA actions are required.
10. Acknowledgments 9. 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" [18] was a huge http://www.rtfm.com/ssldump. The book "SSL and TLS" [18] was a huge
help in developing the code for these flows. It's sad there is no 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.
10. Security Considerations
Implementers must never use any of the certificates provided in this
document in anything but a test environment. Installing the CA root
certificates used in this document as a trusted root in operational
software would completely destroy the security of the system while
giving the user the impression that the system was operating
securely.
This document recommends some things that implementers might test or
verify to improve the security of their implementations. It is
impossible to make a comprehensive list of these, and this document
only suggests some of the most common mistakes that have been seen at
the SIPit interoperability events. Just because an implementation
does everything this document recommends does not make it secure.
This document does not show the messages needed to check Certificate
Revocation Lists (see RFC 5280 [4]) as that is not part of the SIP
call flow.
OPEN ISSUE: We should probably say something about CRLs. We need to
get consensus on whether we want to recommend a method for retrieving
CRLs. We could explicitly state that these are assumed to be
retrieved out-of-band. Should they be retrieved by HTTP by some
maintenance procedure? Via OCSP?
11. Changelog 11. Changelog
(RFC Editor: remove this section) (RFC Editor: remove this section)
-01 to -02 -00 to -01
* Addition of OPEN ISSUES.
* Numerous minor edits from mailing list feedback.
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 [12]. specified in Draft SIP EKU [13].
* 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.
-00 to -01 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)
12. Known Problems with this version 12. References
The flows, encryption and signatures captured in this document were
manually collected from actual test runs. Those runs need to be
reproduced so the source messages can be modified (as below for
instance). This reproduction is being automated, but is not yet
complete.
13. References
13.1. Normative References 12.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [2] 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.
[3] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
Public Key Infrastructure Certificate and Certificate (SIP): Locating SIP Servers", RFC 3263, June 2002.
Revocation List (CRL) Profile", RFC 3280, April 2002.
[4] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and [4] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, R., and W. Polk, "Internet X.509 Public Key Infrastructure
January 1999. Certificate and Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008.
[5] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and [5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.2", RFC 5246, August 2008.
[6] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 3546, June 2003. RFC 3546, June 2003.
[6] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [7] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002. Transport Layer Security (TLS)", RFC 3268, June 2002.
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851, (S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004. July 2004.
[8] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, [9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004. July 2004.
[9] 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.
[10] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", [11] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
RFC 3370, August 2002. RFC 3370, August 2002.
[11] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and [12] 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.
[12] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) [13] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU)
for Session Initiation Protocol (SIP) X.509 Certificates", for Session Initiation Protocol (SIP) X.509 Certificates",
draft-ietf-sip-eku-04 (work in progress), April 2009. draft-ietf-sip-eku-04 (work in progress), April 2009.
[13] Gurbani, V., Lawrence, S., and B. Laboratories, "Domain 12.2. Informative References
Certificates in the Session Initiation Protocol (SIP)",
draft-ietf-sip-domain-certs-03 (work in progress), April 2009.
13.2. Informative References
[14] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, [14] Hoffman, P., "Examples of S/MIME Messages", RFC 4134,
July 2005. July 2005.
[15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [15] 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.
[16] Peterson, J. and C. Jennings, "Enhancements for Authenticated [16] 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.
[17] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [17] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[18] Rescorla, E., "SSL and TLS - Designing and Building Secure [18] Rescorla, E., "SSL and TLS - Designing and Building Secure
Systems", 2001. Systems", 2001.
[19] 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.
The instructions assume a Unix-like environment with openssl The instructions assume a Unix-like environment with openssl
installed, but openssl does work in Windows too. Make sure you have installed, but openssl does work in Windows too. OpenSSL version
openssl installed by trying to run "openssl". Run the makeCA script 0.9.8j was used to generate the certificates used in this document.
found in Appendix A.1; this creates a subdirectory called demoCA. If Make sure you have openssl installed by trying to run "openssl". Run
the makeCA script cannot find where your openssl is installed you the makeCA script found in Appendix A.1; this creates a subdirectory
will have to set an environment variable called OPENSSLDIR to called demoCA. If the makeCA script cannot find where your openssl
whatever directory contains the file openssl.cnf. You can find this is installed you will have to set an environment variable called
with a "locate openssl.cnf". You are now ready to make certificates. OPENSSLDIR to whatever directory contains the file openssl.cnf. You
can find this with a "locate openssl.cnf". You are now ready to make
certificates.
To create certs for use with TLS, run the makeCert script found in To create certs for use with TLS, run the makeCert script found in
Appendix A.2 with the fully qualified domain name of the proxy you Appendix A.2 with the fully qualified domain name of the proxy you
are making the certificate for. For example, "makeCert are making the certificate for. For example, "makeCert
host.example.net". This will generate a private key and a host.example.net". This will generate a private key and a
certificate. The private key will be left in a file named certificate. The private key will be left in a file named
domain_key_example.net.pem in pem format. The certificate will be in domain_key_example.net.pem in pem format. The certificate will be in
domain_cert_example.net.pem. Some programs expect both the domain_cert_example.net.pem. Some programs expect both the
certificate and private key combined together in a PKCS12 format certificate and private key combined together in a PKCS12 format
file. This is created by the script and left in a file named file. This is created by the script and left in a file named
example.net.p12. Some programs expect this file to have a .pfx example.net.p12. Some programs expect this file to have a .pfx
extension instead of .p12 - just rename the file if needed. A filed extension instead of .p12 - just rename the file if needed. A file
with a certificate signing request, called example.net.csr, is also with a certificate signing request, called example.net.csr, is also
created and can be used to get the certificate signed by another CA. created and can be used to get the certificate signed by another CA.
A second argument indicating the number of days for which the A second argument indicating the number of days for which the
certificate should be valid can be passed to the makeCert script. It certificate should be valid can be passed to the makeCert script. It
is possible to make an expired certificate using the command is possible to make an expired certificate using the command
"makeCert host.example.net 0". "makeCert host.example.net 0".
Anywhere that a password is used to protect a certificate, the Anywhere that a password is used to protect a certificate, the
password is set to the string "password". password is set to the string "password".
skipping to change at page 33, line 39 skipping to change at page 36, line 17
For things that need DER format certificates, a certificate can be For things that need DER format certificates, a certificate can be
converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM converted from PEM to DER with "openssl x509 -in cert.pem -inform PEM
-out cert.der -outform DER". -out cert.der -outform DER".
Some programs expect certificates in PKCS#7 format (with a file Some programs expect certificates in PKCS#7 format (with a file
extension of .p7c). You can convert these from PEM format to PKCS#7 extension of .p7c). You can convert these from PEM format to PKCS#7
with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/ with "openssl crl2pkcs7 -nocrl -certfile cert.pem -certfile demoCA/
cacert.pem -outform DER -out cert.p7c" cacert.pem -outform DER -out cert.p7c"
IE, Outlook, and Netscape can import and export .p12 files and .p7c IE (version 8), Outlook Express (version 6), and Firefox (version
files. You can convert a pkcs7 certificate to PEM format with 3.5) can import and export .p12 files and .p7c files. You can
"openssl pkcs7 -in cert.p7c -inform DER -outform PEM -out cert.pem". convert a pkcs7 certificate to PEM format with "openssl pkcs7 -in
cert.p7c -inform DER -outform PEM -out cert.pem".
The private key can be converted to pkcs8 format with "openssl pkcs8 The private key can be converted to pkcs8 format with "openssl pkcs8
-in a_key.pem -topk8 -outform DER -out a_key.p8c" -in a_key.pem -topk8 -outform DER -out a_key.p8c"
OPEN ISSUE: The information in this section needs to be verified with
the latest software versions. How to do conversions between
supported types needs to be updated accordingly.
In general, a TLS client will just need the root certificate of the In general, a TLS client will just need the root certificate of the
CA. A TLS server will need its private key and its certificate. CA. A TLS server will need its private key and its certificate.
These could be in two PEM files or one .p12 file. An S/MIME program These could be in two PEM files, a single file with both certificate
will need its private key and certificate, the root certificate of and private key PEM sections, or a single .p12 file. An S/MIME
the CA, and the certificate for every other user it communicates program will need its private key and certificate, the root
with. certificate of the CA, and the certificate for every other user it
communicates with.
A.1. makeCA script A.1. makeCA script
#!/bin/sh #!/bin/sh
set -x set -x
rm -rf demoCA rm -rf demoCA
mkdir demoCA mkdir demoCA
mkdir demoCA/certs mkdir demoCA/certs
skipping to change at page 39, line 26 skipping to change at page 42, line 13
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
[12]. Draft SIP EKU [13].
Fluffy's certificate. Fluffy's certificate.
-----BEGIN CERTIFICATE----- -----BEGIN CERTIFICATE-----
MIIEHzCCA4igAwIBAgIIAVIBVAGQAEcwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UE MIIEHzCCA4igAwIBAgIIAVIBVAGQAEcwDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UE
BhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMQ4w BhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMQ4w
DAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lwaXQgVGVzdCBDZXJ0aWZpY2F0ZSBB DAYDVQQKEwVzaXBpdDEpMCcGA1UECxMgU2lwaXQgVGVzdCBDZXJ0aWZpY2F0ZSBB
dXRob3JpdHkwHhcNMDkwNDI5MTcxMDQ2WhcNMTIwNDI4MTcxMDQ2WjBiMQswCQYD dXRob3JpdHkwHhcNMDkwNDI5MTcxMDQ2WhcNMTIwNDI4MTcxMDQ2WjBiMQswCQYD
VQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2Ux VQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTERMA8GA1UEBxMIU2FuIEpvc2Ux
DjAMBgNVBAoTBXNpcGl0MRswGQYDVQQDFBJmbHVmZnlAZXhhbXBsZS5jb20wggEi DjAMBgNVBAoTBXNpcGl0MRswGQYDVQQDFBJmbHVmZnlAZXhhbXBsZS5jb20wggEi
skipping to change at page 47, line 35 skipping to change at page 49, line 35
Xv8yJLF08fioQtXXhbMVG+rbMJc2budxhJdvOfJBDWe3t75K9TpQRJrneprfo99W Xv8yJLF08fioQtXXhbMVG+rbMJc2budxhJdvOfJBDWe3t75K9TpQRJrneprfo99W
1IxI//+8/E+P/JqEG7502tKipWDFN6tvrkCLfETih6cUX8qQB/jDVEJvtBuUN/se 1IxI//+8/E+P/JqEG7502tKipWDFN6tvrkCLfETih6cUX8qQB/jDVEJvtBuUN/se
VQnWiwKBgGrvslD5N2wGmnCxjBdMb2KvCPRq0t28t/D5plHgGpEC6k1rhRHCtXpE VQnWiwKBgGrvslD5N2wGmnCxjBdMb2KvCPRq0t28t/D5plHgGpEC6k1rhRHCtXpE
IK+QEb6/DWjqGYaWHamaVEfUVLrKPVA25hAl+nMg9qQYC0cufmN+Ufe9nLn47IY0 IK+QEb6/DWjqGYaWHamaVEfUVLrKPVA25hAl+nMg9qQYC0cufmN+Ufe9nLn47IY0
NXOdHuhaYsf6g/UQEZKSj2wX9poBfAkXZBWnBYKOn0gfq6KjvW82 NXOdHuhaYsf6g/UQEZKSj2wX9poBfAkXZBWnBYKOn0gfq6KjvW82
-----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 [12]. Most existing certificates fall in this category. in Draft SIP EKU [13]. Most existing certificates fall in this
category.
ASN.1 dump of Fluffy's certificate. ASN.1 dump of Fluffy's certificate.
Version: 3 (0x2) Version: 3 (0x2)
Serial Number: Serial Number:
02:55:01:38:02:00:00:6a 02:55:01:38:02:00:00:6a
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
skipping to change at page 56, line 41 skipping to change at page 58, line 41
Appendix C. Message Dumps Appendix C. Message Dumps
This section contains a base64 encoded gzipped, compressed tar file This section contains a base64 encoded gzipped, compressed tar file
of various CMS messages used in this document. Saving the data in a of various CMS messages used in this document. Saving the data in a
file foo.tgz.b64 then running a command like "openssl base64 -d -in file foo.tgz.b64 then running a command like "openssl base64 -d -in
foo.tgz.b64 | tar xfz -" would recover the CMS messages and allow foo.tgz.b64 | tar xfz -" would recover the CMS messages and allow
them to be used as test vectors. them to be used as test vectors.
-- BEGIN MESSAGE ARCHIVE -- -- BEGIN MESSAGE ARCHIVE --
H4sIALBi/0kCA+xcaUATV9cmYV/CIoriGilisQRmJplJAEHBhEVJEAjQpFqZ H4sIANiq/UoCA+xcaUATV9cmYV/CIoriGilisQRmJjNJAEHBhEVJEAjQpFqZ
JBMSyGYSBIOoRaUW14ILWkVcEVRk0brgjhuyVdzB7QUtiFvFutRafYdqK0UU JBMSyGYSBIOoRaUW14ILWkVcEVRk0brgjhuyVdzB7QUtiFvFutRafYdqK0UU
v764ftw/Se7MPXMyufc8z3nOnQjlGopGLpVjFLkm2lWEavU6vwF4Q2i0P1/p v764ftw/Se7MPXMyuec8z33OnQjlGopGLpVjFLkm2lWEavU6vwF4o8Hwn690
CPyPV7xBMIDogSBIpyMICCGAHgBSIQjSIwN676DFabSomkzWE6ilqOI153V0 GvKPV7xBCEDTA0GITqdCCJUK6AEgFQJpemRA7x20OI0WVZPJegK1FFW85ryO
/CNtbFZYmI8/i6yRqjxi4+TSWOVwLAGVq2SYqwLTksMCR7tBrgDJLEKKevz1 jn+kjc0KC/PxZ5E1UpVHbJxcGqscjiWgcpUMc1VgWnJY4Gg3yBUgmUVIUY+/
yY07YjQZAhiudLoryGC4ggjiAcIAAHoK1KhCKPHSuUv8aYJRFBGDDtN0FJrY PrlxR4wmQwDDlU53BRkMV5BG8wARAAA9BWpUIZR46dwl/rBgFEXEoCOwjgKL
HUJpCAOgoxCMAQAFpFD+OuapVinVWi+YBgMgyYyNJlD8lOp4VC3SeJDp+HVH 3SEUpjEAOgohGABQQArlr2OeapVSrfVCYAQASWZsNIHip1THo2qRxoNMx687
KBVaVKj1IA9t8VAsixOLJ/7toVAp9yaZcZXPj77sP37UT62Uv3q0pxaN9hKg QqnQokKtB3loi4diWZxYPPFvD4VKuTfJjKt8fvRl//Gjfmql/NWjPbVotJcA
EN0dAmD8aqhMRglkepDZkJ+MA42UsuWcWH4MX86Rh9PYkSEAJ5Kn48gDwWCu hejuEIDgV0NlMkog04PMhvxkHGiklC3nxPJj+HKOPBxmR4YAnEiejiMPBIO5
JIbHlcXwI8Nd8WFh2HgPMkh+fjNJZj5CIabCnZbHybRSFarWummk0QpM5ELW khgeVxbDjwx3xYeFYeM9yCD5+c0kmfkIhZgKd1oeJ9NKVaha66aRRiswkQtZ
YglaN5UMlSpcyKhKJZMKUa1UqXBTxQo1dErLQvxnv0akcmllBpVpMbUCPzQB iyVo3VQyVKpwIaMqlUwqRLVSpcJNFSvU0CktgfjPfo1I5dLKDCrTYmoFfmgC
e3ZvMIWWwp2owl6+lqdAGacQoeqJXgIaAoEQTSxGhAiKgiJPOW5dFu2lkaCg 9uzeYAothTtRhb18LU+BMk4hQtUTvQQwDQIhWCymCWkoCoo85bh1WbSXRoKC
p0qt1CqFSpmXw8vutBhCtXFqzOHFxYIwRbRWgv84CINkRjKjUNpab+vXi2/c niq1UqsUKmVeDi+702II1capMYcXFwvCFNFaCf7j0BgkM5IZhdLWelu/Xnzj
6gg+TzRiTE1hKYRKkVQR7UEWSBW4ry0mJZhMpnwTy69x2FOByjGvPwObq4qu VkfweaIRY2oKSyFUiqSKaA+yQKrAfW0xKcFkMuWbWH6Nw54KVI55/ZnYXFV0
eTGSKdWolBppyxjcgBafWxI53u8pQRUiGe6IlxobHydV47dPLJVhr7LyWv+B zYuRTKlGpdRIW8bgBrT43JLI8X5PCaoQyXBHvNTY+DipGr99YqkMe5WV1/oP
ZMIJI9MhKQEpD0gEY2JWMuEg3rWPSCCApoCxkeEXlvrE3oD5i1MIYDJhJX7K JBNOGJkOSQlIeUAiGBOzkgkH8a59RAIBNAWMjQy/sNQn9gbMX5xCAJMJK/FT
cvwUYBKgAs0BUyP9cAMjW2J4GGgL2LR8MLH9c3pKxUq1QoqCNoBVS6+xrUkY luOnAJMAFWgOmBrphxsY2RLDw0BbwKblg4ntn9NTKlaqFVIUtAGsWnqNbU3C
qiCPVGow0BKwaOkimdka4rNdqgWdgcEtHea25LCWz2QuptGSR2BqrVTcctsw UAV5pFKDgZaARUsXyczWEJ/tUi3oDAxu6TC3JYe1fCZzMY2WPAJTa6XiltuG
sk+cVqJUS7UTiSaEUAKXMF/P/4WDpL8dJBAM9QySCXoFJnq5PTby5L3FYnR4 kX3itBKlWqqdSDQhhBK4hPl6/i8cJP3tIIFgqGeQTNArMNHL7bGRJ+8tFqPD
dnHB6UnQ2UpeRv086QLTtc0HacpAdoToyfWcpvFjmVss4vdb7v3Dt2f99FWT s4sLTk+CzlbyMurnSReYrm0+CCsD2RGiJ9dzmsaPZW6xiN9vufcP357101dN
v7aVrXv4RY7jsD153UMsSd5L05fahQ7a8HnuoTk9ri9y3vfDuVBvxlnjFIrD /tpWtu7hFzmOw/bkdQ+xJHkvTV9qFzpow+e5h+b0uL7Ied8P50K9GWeNUygO
5yvEVtpLBUJzJ1KIze1NXIJ8TSl22DuhvrJvAt9nxlaywwpzFd9cMOB2WkSc n68QW2kvFQjNnUghNrc3cQnyNaXYYe+E+sq+CXyfGVvJDivMVXxzwYDbaRFx
wyCf+V/c62YSZWz6QMP/bgfpTgD3ad9HJeutv5R/mdFrrXmRo+OpylrqYzDu DoN85n9xr5tJlLHpAw3/ux2kOwHcp30flay3/lL+ZUavteZFjo6nKmupj8G4
2sYeA4jN6y97DOtf7bCd3WRDMjOZkN29T/i8hoa+l+0a+ghOnmwmmU3akO/i axt7DCA2r7/sMax/tcN2dpMNycxkQnb3PuHzGhr6XrZr6CM4ebKZZDZpQ76L
RzTZdmxIf5Mydt9cU1pu2DjeQq8j317oOSfBgNDerKRQSGYfb/yXYxoNGo1R H9Fk27Eh/U3K2H1zTeHcsHG8hV5Hvr3Qc06CAaG9WUmhkMw+3vwvxzQaNBqj
tDINRY1pVG+DAnSA/wAM09riP50GdOH/u2jPIR2Hc4AcPKotzgeF/V9wnirA aGUaihrTqN4GBegA/wEEgdviP50Kd+H/u2jPIR2Hc4AcPKotzgeF/V9wnirA
8J+QLgYZIkgMU4Xt4jzN3b0tqre5BE4HQU9tS4T9cwjuRCuQ17SD8n+OeAbl 6DQaXQwyRJAYoQrbxXnY3b0tqre5BE4HQU9tS4b9cwjuRCuQ17SD8n+OeAbl
AIAhkDuCtMZ9TTvA/+x7PBsDYfhaRhFxK/jnyFkghxkL8nR+cp6crWMzI2KC AIDRIHcarTXua9oB/mff49kYCMNjGaWJW8E/R84COcxYkKfzk/PkbB2bGRET
uax4ti5Cxo/hxLK5vjF8f76MreO1B/9tsRJogYUPM0q0Wv9vif13uP5BAITb zGXFs3URMn4MJ5bN9Y3h+/NlbB2vPfhvi5VACyx8mFmiVfy/JfbfYfyDAIi0
rH+IjnTx/3fN/1+5tF6VBbyt6NBBFvCa9fwmceL9hob3kRm0x8D/Ck1IS2AK iX+IjnTx/3fN/18ZWq9aBbyt7NDBKuA18fwmeeL9pob3sTJoj4H/lZpoLYkp
aGHcAz9mGtPV/mVTKLHYOIrwrapAHes/beM/jdrF/z4d/cfdXUCFIQRxp2Ei oIVxD/yYaUxX+5dNocRi4yjCt6oCdaz/tM3/MLWL/306+o+7u4CKQDSaO4yJ
oQgSvkL/gd+b/uMO0gXudGqrKM9nhsAcLk8XzJXFsiFWQnBkeDyHyYnhRIbE hCJI+Ar9B3lv+o87SBe406mtsjyfGYJwuDxdMFcWy4ZYCcGR4fEcJieGExkS
c3TRMFvnJ8VjP8iDeB++/gMBQpoQoDEwDBLBMB3pXP2nrfXO0386styl/3Se z9FFI2ydnxTP/SAP4n34+g8ECGEhADMwDBIhCJ3WufpPW+udp/90ZLlL/+k8
/kMMJzCIenoxr9N/5mOZ2DdP0rqrgjwTCn9mCAbZuk22G9MvdHPijejsw4f7 /YcYTmAQ9fRiXqf/zMcysW+epHVXBXkmFP7MEAyydZtsN6Zf6ObEG9HZhw/3
z3FxsDu5JPDi+SzUwmR8TGrNF9W5wxqHINZVFeqi895X0ZP09QmZpS47NivP n+PiYHdySeDF81mohcn4mNSaL6pzhzUOoVlXVaiLzntfRU/S1ydklrrs2Kw8
pA45qnHWNY35eYftzdObf5I/OjkW7nWdNlOxtepIWoPIHfY/vt2U0++AsLK+ kzrkqMZZ1zTm5x22N09v/kn+6ORYpNd1eKZia9WRtAaRO+J/fLspp98BYWV9
2mpR9+QdrtduVEUb2U35OWyB/44thazi7kGJ0Wy3HcfMLSInJM+1WkAymxlm tdWi7sk7XK/dqIo2spvyc9gC/x1bClnF3YMSo9luO46ZW0ROSJ5rtYBkNjPM
oZ9Lqf5slH3q/uWZa/OtoCka8/KUhFzniYWVcw5NntRwfNPvyWcTBevjo3L2 Qj+XUv3ZKPvU/csz1+ZbQVM05uUpCbnOEwsr5xyaPKnh+Kbfk88mCtbHR+Xs
3ns8N/X4rxfWbpuTe/6z/sWV64rXOB7eJu8fcOPosocjFixqPH9sqQtvQ3bD vfd4burxXy+s3TYn9/xn/Ysr1xWvcTy8Td4/4MbRZQ9HLFjUeP7YUhfehuyG
jopfgGNJzCcrytublB+3/PMc/59hP6YQqieqtJiokxlAR/hPBaht8Z+OULvw HRW/AMeSmE9WlLc3KT9u+ec5/j/DfkwhVE9UaTFRJzOAjvCfClDb4j8doXfh
/1PBfwgG3YVUmAqDiBAHeugV+I+8L/zHpx0dd8u9Ff4HMzkSPjc6viXbY0M8 /6eC/xACugupCBUBaUIc6KFX4D/tfeE/jQbScbfcW+F/MJMj4XOj41tWe2yI
HPN9pRyIR+PpQuUcfxaVw2UBPG6gLpjJfv/4/z9g2htBWkeo22LL81kI0eKn h2O+r5QD8WCeLlTO8WdROVwWwOMG6oKZ7PeP//8Dpr0RpHWEui22PJ+lEC1+
eGGKCZhMqcJEFDyOoP+EYvnLTAJGaM9gkwi8wET9rGTiQLyrH5Ggh8NjBg6P ihemmIDJlCpMRMHzCPpPKJa/zCQQGvwMNonAC0zUz0omDsS7+hEJejg8ZuDw
C/C37xkeY9tBxR1LBIYVrullpovgjYSSxLwVTQ+tbX6tfBRYtGf2uAHcbHbA uAB/+57hMbYdVNyxRGBY4ZpeZroI2UgoScxb0fTQ2ubXykeBRXtmjxvAzWYH
YOa4G5RS1Yn+v9QbE8h7h91MmMVcvjGF/a1nSrz5k7xSlxjf5NmDq5W045ec DGaOu0EpVZ3o/0u9MYG8d9jNhFnM5RtT2N96psSbP8krdYnxTZ49uFoJH7/k
etxpssiQuTTuqluVkk5zBKsK7zhVTRYd+W7o1WW7mxcbL/aqnnfhRPfl4NXT 1ONOk0WGzKVxV92qlHTYEawqvONUNVl05LuhV5ftbl5svNiret6FE92Xg1dP
6Qeoq5tOrFfMlPdx2mRsYF3EY53TN7hun3bu6Rp75mXfCzuvMWdY9VpyL5lk px+grm46sV4xU97HaZOxgXURj3VO3+C6fdq5p2vsmZd9L+y8xpxh1WvJvWSS
NuC6TH9CaaDRdwrT9FGuzROIdiFjf+hXsi4F7ZUTLqsUyT738nhovCG/dHJW 2YDrMv0JpYFG3ylM00e5Nk8g2oWM/aFfyboUtFdOuKxSJPvcy+Oh8Yb80slZ
KtGXdGBeuvWgvQHOQmP5T32KHgcsC4hSnuzf7da2sqAh4LZyrzyXoKepDoD1 qURf0oF56daD9gY4C43lP/UpehywLCBKebJ/t1vbyoKGgNvKvfJcgp6mOgDW
l1vumKQBk1pRGaCfkWlUSgAB0zcgEA2s2VMLjE83D7U5Pe/Y0rsDKx2mju5t X265Y5IGTGpFZYB+RqZRKQEETN+AQDSwZk8tMD7dPNTm9LxjS+8OrHSYOrq3
PwMY4JNvmqGvl5UUaaz8dpeo1GsUH8gsqRgqU912s1gXHEBnbV9yq1vRwLNr /QxggE++aYa+XlZSpLHy212iUq9RfCCzpGKoTHXbzWJdcACdtX3JrW5FA8+u
V4yN6plE/rpPIXFYvesZQ4+yuTPq0mqnHfV/9Pnvm9lr4SHVXapFp+H/29oB XTE2qmcS+es+hcRh9a5nDD3K5s6oS6uddtT/0ee/b2avRYZUd6kWnYb/b2sH
0mH+D4Jt6z8wDHfh/6eC/4jAXQBgABWjutOoMI3xCvynvS/8p2E0VIABrfGf SIfrfxBsW/9BELAL/z8V/KcJ3AUABlAxqjtMRWDGK/Affl/4D2MwKsCA1vjP
A+H5P7MF7yUyvjwE5wBsgBcjBDlMkTTYPzQmmBkN85mBENs/8CPY/wEKUSFE gfD1P7MF7yUyvjwE5wBsgBcjBDlMkTTYPzQmmBmN8JmBENs/8CPY/wEKUSEE
EwioiFgEIZ2U/9Oh5/s/2ljvxP0fHVj+cPP/M//M/4/iXQdb8v8W5vIsvTbU CwRUmlgE0Tpp/U+Hnu//aGO9E/d/dGD5w13/n/nn+v8o3nWwZf3fwlyeLa8N
a6sArMZPWvEhKACtXOzSANrVANpOzI9YA2iN/y2r5y8RoDOJQAf4T6XTgTb4 9doqAKvxk1Z8CApAKxe7NIB2NYC2E/Mj1gBa439L9PwlAnQmEegA/6l0OtAG
D9MgsAv/PxX8pzIgEZVBpcFUqhgBQfdX4D/9feG/SCwGaYyWLLRV/s+PZev4 /xEYRLrw/1PBfyoDElEZVBj/ccU0EHR/Bf7T3xf+i8RiEGa0rEJbrf/5sWwd
sXw5X8qLYVHZ/iPlwUwfHUfnKwvmhoPB/myIxw2N5UAfAf7jFBsVwQhVjNMv P5Yv50t5MSwq23+kPJjpo+PofGXB3HAw2J8N8bihsRzoI8B/nGKjIoRGFeP0
OgrCnYL/IP5zPiMAbc2/NcHgbescH7gG8XyLZkA7qAwf+fWunf7iolqT33bf i46CSKfgP4j/nM8IQFvzb00weNs6xweuQTzfohnQDiojR369a6e/uKjW5Lfd
+M3mMsmMWJq1yFxceWrGcrA++fvMXUn2vwaUk6423Zi1bJZSQ1hTviA7ZQHR N36zuUwyI5ZmLTIXV56asRysT/4+c1eS/a8B5aSrTTdmLZul1BDWlC/ITllA
z/qEOYfXr3749ebynwaRGx+K+CZxt47kHNk3tts1sfuc/DpReZJ0tsBogrKX 9LM+Yc7h9asffr25/KdB5MaHIr5J3K0jOUf2je12Tew+J79OVJ4knS0wmqDs
/pHEeuMV3ap3Hrc/W1xcl5MyNbO7d1NfBskzqKrwP18pz1FjMwqP3mf1+p1l pX8ksd54RbfqncftzxYX1+WkTM3s7t3Ul0HyDKoq/M9XynPU2IzCo/dZvX5n
cf7UkkVFk6Y5zNgYWsuoxeBuRdnCb/JPZUaft6yLzbr5aOylLZZ6WQ369bd5 WZw/tWRR0aRpDjM2htYyajGkW1G28Jv8U5nR5y3rYrNuPhp7aYulXlaDfv1t
Fm70y7yB40VhUc3f6G+NThziWzNqi8W8pU8Jy4hbsz17RE4uyrD2KfHOmXa9 noUb/TJv4HhRWFTzN/pboxOH+NaM2mIxb+lTwjLi1mzPHpGTizKsfUq8c6Zd
QhNx3+hpzgETZ+6BhbsdOCPdM7dYPcm1P7528es0CMv9q7pbo1eCg0hmK+8M r9BE3Dd6mnPAxJl7YOFuB85I98wtVk9y7Y+vXfw6DcJy/6ru1uiV4CCS2co7
oZ9kTx3d7LxuZ5PbBpLZUm3tmUHdDmptfI2f3FynnFq3cN79rx29S8LmRsXZ Q+gn2VNHNzuv29nktoFktlRbe2ZQt4NaG1/jJzfXKafWLZx3/2tH75KwuVFx
OwXf2RAer3cs07WQZLZho++hgtnsIUDfA8WTB91fILFZPogyPtLWp2DD3OV+ 9k7BdzaEx+sdy3QtJJlt2Oh7qGA2ewjQ90Dx5EH3F0hslg+ijI+09SnYMHe5
ef9uIXTx1U7YsfxavnrNYNG+dIt+f2Tb7ZvNX7NaYr4/WpJK/V0cdYMQOCLZ X96/C4QuvtoJO5Zfy1evGSzal27R749su32z+WtWS8z3R0tSqb+Lo24QAkck
5Pb1QxO/th14L0oOVfdlXZvts/kQsVK01KJH0sO1ptw0sM96ydVEDdND3GvD m9y+fmji17YD70XJoeq+rGuzfTYfIlaKllr0SHq41pSbBvZZL7maqGF6iHtt
4cwpU+42263/Y+uN0tvf/0GzmeF0vW7wWL1Ncb5ztwSNGSCg7bE4H5S2obnW OJw5ZcrdZrv1f2y9UXr7+z9gmxlO1+sGj9XbFOc7d0vQmAECeI/F+aC0Dc21
MnlNGcMiNhX9yu3uz+mqp+xGx+PKCysFKxT9HbO652EZ8YKly4jkCu8xA84+ lslryhgWsanoV253f05XPWU3Oh5XXlgpWKHo75jVPQ/LiBcsXUYkV3iPGXD2
bazt1zD9yco4+cVovyPNTuI9v9RZFRndWZqxsMeY2gYkXStMqDGoWLzXyTQ9 aWNtv4bpT1bGyS9G+x1pdhLv+aXOqsjoztKMhT3G1DbQ0rXChBqDisV7nUzT
43ZK5IW7zPBx6xiOe2JvbLuR22fZsUt2jVe7n2BXpSX1NMn2v6zHPMyAva+p M26nRF64ywwft47huCf2xrYbuX2WHbtk13i1+wl2VVpST5Ns/8t6zMMMxPua
rWZM8SsaMelue/OyNV19u5WfN63/tN3/QUVoSBf/+1T4Hyiki0Q0AIXFYjGN 2mrGFL+iEZPutjcvW9PVt1v5edP6T9v9H1QaDHXxv0+F/4FCukgEAygiFoth
hlBfwf+g98X/YBQE8MtjrfgfjxtLDWYGxnMgPymPGx7P9ufLeVw2yGaOlLJ1 mEZ9Bf+D3hf/Q1AQwC+PteJ/PG4sNZgZGM+B/KQ8bng8258v53HZIJs5UsrW
PCiYKZzI07FobP+u+s//h/rPa7iXImBVgrGHv+m+SGUZIdeywdulT8K8WPMD 8aBgpnAiT8eC2f5d9Z//D/Wf13AvRcCqBGMPf9N9kcoyQq5lg7dLn4R5seYH
J5t3+8z1LltYAS9z5c1qvArzlJaPPYvXuIpJEgXL4Nioq857sDshK+uHT1s4 Tjbv9pnrXbawAlnmypvVeBXhKS0fexavcRWTJAqWwbFRV533YHdCVtYPn7Zw
aV5+TkQV7eTFg8I9TuH9IkPqUmYPSSqg2259OGf70DvTQYvIQsf66vsLxq6a 0rz8nIgq+OTFg8I9TuH9IkPqUmYPSSqg2259OGf70DvTQYvIQsf66vsLxq6a
6srahiyS3V49/7O5y4tGk8yUtQ3+3CbK14y4+DLDW6zxPxYvTN/MA3cVWT94 6sraRlsku716/mdzlxeNJpkpaxv8uU2Urxlx8WWGt1jjfyxemL6ZB+4qsn7w
ot4xwyFk6rrJ969m+kEuqcU3o47eT6RkVo3LPDdQYrJHL2Rwdh9uWBVryJeo RL1jhkPI1HWT71/N9INcUotvRh29n0jJrBqXeW6gxGSPXsjg7D7csCrWkC9R
cKh9XEq0QYlhvDze3nONHcToO9EwcbxNYoRjnGPsg7jjqTV52z1S2CDJrE/1 4VD7uJRogxLDeHm8vecaO4jRd6Jh4nibxAjHOMfYB3HHU2vytnuksEGSWZ/q
1JmiUNuaJ+kXcksvV5e9jnw1XqEJ8yQP9gsOZSYqBzlsnjraJ+jJozVbVL0F qTNFobY1T9Iv5JZeri57HflqvAIL8yQP9gsOZSYqBzlsnjraJ+jJozVbVL0F
Kbv2X5y/QJpEMqu2ustJUqrddNmjtozkle4ru7sp7TQoXmBZFEgQntrJz3O+ Kbv2X5y/QJpEMqu2ustJUqrddNmjtozkle4ru7sp7TQoXmBZFEgQntrJz3O+
WZr6bZPe41GLBdyI72sTRv+4adv2sfdtfIbuI1/oqgD9D+3vyg8lXoJqKdFK WZr6bZPe41GLBdyI72sTRv+4adv2sfdtfIbuI1/oqgD9D+3vyg8lXoJqKdFK
LeVZqOpEJtDR8z8gQHtJ/6F26T/vpHWGVt+1ij6B9f/Wnv55k/ov1Pb5HzxR LeVZqupEJtDR8z8gAL+k/0Bd+s87aZ2h1XdF0ScQ/2/t6Z83qf9CbZ//ganU
6Vr/n4z+i4hhPKQjiJiK0sXwq/Z/A++L/2MMoRAUwMLW9d+YiBheDCeGowvR rvj/ZPRfmhjBUzqNJqaidDHyqv3fwPvi/xhDKAQFiLB1/TcmIoYXw4nh6EJ0
cbh8GU8nimFH4nkA1NIvjA/mRsSwodBY/oew/6sj/RcVUkExCkMoCEIAFRB3 HC5fxtOJYtiR+DoAaukXxgdzI2LYUGgs/0PY/9WR/osKqaAYRSAUDzKACog7
bv23rfXOq/92ZLlLT3v3elrXfwC0NzM/3gLw2638vmH9F6G/9PwX2PX81yeD t/7b1nrn1X87stylp717Pa3rPwDam5kfbwH47VZ+37D+S6O/9PwX0PX81yeD
/0JIRKeKEQTGQJjOoL1q/zf1vel/GE0kosL/+P8fZgjE94+I5UeG0Hi6kRI+ /0JIRKeKaTQEAxE6A37V/m/qe9P/MFgkoiL/+P8fZgjE94+I5UeGwDzdSAmf
ly/hM0NxPsAC2MyRsRxdLMjxD0zgcEM+fPzHACEioFOFmEhIo7kj9E6u/7Y1 y5fwmaE4H2ABbObIWI4uFuT4ByZwuCEfPv5jgJAmoFOFmEgIw+40eifXf9ua
31X/fecaZOqB5s/yT9pYXmdEefgv6U5NIPT+rVvm4vRTksLtnKoJPW5XIJZr 76r/vnMNMvVA82f5J20srzOiPPyXdKcmEHr/1i1zcfopSeF2TtWEHrcraJZr
tyPj/mOYwHpg2E0eTjJbOToo50F9gRR7yFj/wG2l1qqH0vnHMdqBgQPjja/g t9PG/ccwgfXAsJs8nGS2cnRQzoP6Ain2kLH+gdtKrVUPpfOPY7QDAwfGG1/B
KzGHCPRguc3LM3ENPFcYr2n0MeFQ8vNvuQVuizujuhz1eHVpIONo0cTxfhkl IzGHCPRguc3LM3ENPFcYr2n0MeFQ8vNvuQVuizujuhz1eHVpIONo0cTxfhkl
Pck5tg236pfk1g0oKdEVqYbX3B1uLl1y/voY65yn68XHI4p37JheJtcftqhc Pck5tg236pfk1g0oKdEVqYbX3B1uLl1y/voY65yn68XHI4p37JheJtcftqhc
zk+bpfdZ2awnv++1d5pSKi1Pz+BfuXgi/6LC0nlZo+GZYK+sBwcK51o+Narx zk+bpfdZ2awnv++1d5pSKi1Pz+BfuXgi/6LC0nlZo+GZYK+sBwcK51o+Narx
M7/pOX3vzJ7LhteEYoKc4nu6huMJ0uXoqYCwCJJZ8YW7cIkBad9uJ5/9VzLt M7/pOX3vzJ7LhteEYoKc4nu6huMJ0uXoqYCwCJJZ8YW7SIkBad9uJ5/9VzLt
V416nQiZWWJD3X/P1/TorOpSLpTgN3X0d1/VTY+6yvpCW44Gr7qiTz9xeFro V416nQiZWWJD3X/P1/TorOpSLpTgN3X0d1/VTY+6yvpCW44Gr7qiTz9xeFro
6qrSxiNzNt9F3CP2zkuqf4iNUKDYjK8EG/d6XFhyZNa2ndnDFqNDC+ous3b1 6qrSxiNzNt+luUfsnZdU/xAboUCxGV8JNu71uLDkyKxtO7OHLUaHFtRdZu3q
HBGi/6vP7PAG4rjyvHvE2LP/bh100dW3TVedS9KXjz+UHjp1lNUh8ZGKXm7s OSJE/1ef2eENxHHlefeIsWf/XRx00dW3TVedS9KXjz+UHjp1lNUh8ZGKXm7s
LOP/OFf+5lqZZleRVMDiyw/w54eUkMWPJ/xy6UTeoUr2paOkM98WSW9+s3N8 LOP/OFf+5lqZZleRVMDiyw/w54eUkMWPJ/xy6UTeoUr2paOkM98WSW9+s3N8
05Z99fdWrznmiqx2pqfQS36cn90UMzj08LINBS6JUdZO16gjpu00ypcYOs1c 05Z99fdWrznmSlvtTE+hl/w4P7spZnDo4WUbClwSo6ydrlFHTNtplC8xdJq5
JenNuZps99UVvaRepiNtTSlb76zb5x7lTIQcnU/Tw4N8a5KuZTw8/KSR0Ddi StKbczXZ7qsrekm9TEfamlK23lm3zz3KmQg5Op+mhwf51iRdy3h4+EkjoW/E
1qba6sKD5KzytN0/rLAszRyzl1PT79wV4vmayHW8G99VbBKfWK2b+duqmlOZ rE211YUHyVnlabt/WGFZmjlmL6em37krxPM1ket4N76r2CQ+sVo387dVNacy
vwdvSjonlcAFGdYi335ejpGH/tu+HeIgCAAAFD2BzRNYMDgDVA7gTMwTGMkw fw/elHROKkEKMqxFvv28HP/bvh3iIAgAABQ9Ac0TUDQ4A1YO4EzOQiWSZQYG
A4PNLM1Cc17A4Akg6AV0o5tM2onO7gXc3jvDr79bXM7PeB8Hq+m9nZ2KIpxf m1mbxea8gMETaAAPoJvdZNJOdHYu4PbeGX79yfUyqU+veBv354P7eXgsimjU
D1Wd5+lr/ZiMkm0WNbvhWL5vy03Zj391+efHIgAAAAAAAAAAAF8f+pPqBgB4 7KtNnmfv9BkGs9VivFu3h/Jzmy7LR6+ryz8/FgEAAAAAAAAAAPj5Asq+2KcA
AAA= eAAA
-- END MESSAGE ARCHIVE -- -- END MESSAGE ARCHIVE --
Authors' Addresses Authors' Addresses
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
Mailstop SJC-21/2 Mailstop SJC-21/2
San Jose, CA 95134 San Jose, CA 95134
USA USA
Phone: +1 408 421 9990 Phone: +1 408 421 9990
Email: fluffy@cisco.com Email: fluffy@cisco.com
Kumiko Ono Kumiko Ono
NTT Corporation Columbia University
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 4508 Email: kumiko@cs.columbia.edu
Email: ono.kumiko@lab.ntt.co.jp
Robert Sparks Robert Sparks
Tekelec Tekelec
17210 Campbell Road 17210 Campbell Road
Suite 250 Suite 250
Dallas, TX 75252 Dallas, TX 75252
USA USA
Email: rjsparks@estacado.net Email: rjsparks@estacado.net
 End of changes. 87 change blocks. 
304 lines changed or deleted 405 lines changed or added

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