draft-ietf-sipcore-sec-flows-01.txt   draft-ietf-sipcore-sec-flows-02.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: Informational K. Ono
Expires: May 27, 2010 Columbia University Expires: July 26, 2010 Columbia University
R. Sparks R. Sparks
B. Hibbard, Ed. B. Hibbard, Ed.
Tekelec Tekelec
November 23, 2009 January 22, 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-01 draft-ietf-sipcore-sec-flows-02
Abstract
This document shows example call flows demonstrating the use of
Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail
Extensions (S/MIME) in Session Initiation Protocol (SIP). It also
provides information that helps implementers build interoperable SIP
software. To help facilitate interoperability testing, it includes
certificates used in the example call flows and processes to create
certificates for testing.
Status of this Memo 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.
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
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 May 27, 2010. This Internet-Draft will expire on July 26, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document shows example call flows demonstrating the use of This document may contain material from IETF Documents or IETF
Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Contributions published or made publicly available before November
Extensions (S/MIME) in Session Initiation Protocol (SIP). It also 10, 2008. The person(s) controlling the copyright in some of this
provides information that helps implementers build interoperable SIP material may not have granted the IETF Trust the right to allow
software. To help facilitate interoperability testing, it includes modifications of such material outside the IETF Standards Process.
certificates used in the example call flows and processes to create Without obtaining an adequate license from the person(s) controlling
certificates for testing. the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Certificates . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 5
3.1. CA Certificates . . . . . . . . . . . . . . . . . . . . . 5 2.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 9
3.2. Host Certificates . . . . . . . . . . . . . . . . . . . . 9 2.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10
3.3. User Certificates . . . . . . . . . . . . . . . . . . . . 10 3. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12
4. Callflow with Message Over TLS . . . . . . . . . . . . . . . . 12 3.1. TLS with Server Authentication . . . . . . . . . . . . . . 12
4.1. TLS with Server Authentication . . . . . . . . . . . . . . 12 3.2. MESSAGE Message Over TLS . . . . . . . . . . . . . . . . . 14
4.2. MESSAGE Message Over TLS . . . . . . . . . . . . . . . . . 14 4. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 15
5. Callflow with S/MIME-secured Message . . . . . . . . . . . . . 15 4.1. MESSAGE Message with Signed Body . . . . . . . . . . . . . 15
5.1. MESSAGE Message with Signed Body . . . . . . . . . . . . . 15 4.2. MESSAGE Message with Encrypted Body . . . . . . . . . . . 21
5.2. MESSAGE Message with Encrypted Body . . . . . . . . . . . 20 4.3. MESSAGE Message with Encrypted and Signed Body . . . . . . 23
5.3. MESSAGE Message with Encrypted and Signed Body . . . . . . 23 5. Observed Interoperability Issues . . . . . . . . . . . . . . . 28
6. Observed Interoperability Issues . . . . . . . . . . . . . . . 28 6. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 29
7. Additional Test Scenarios . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 9. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32 10. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 32
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34
12.1. Normative References . . . . . . . . . . . . . . . . . . . 33 11.2. Informative References . . . . . . . . . . . . . . . . . . 35
12.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35 Appendix A. Making Test Certificates . . . . . . . . . . . . . . 35
A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 36 A.1. makeCA script . . . . . . . . . . . . . . . . . . . . . . 37
A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 39 A.2. makeCert script . . . . . . . . . . . . . . . . . . . . . 40
Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42 Appendix B. Certificates for Testing . . . . . . . . . . . . . . 42
B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42 B.1. Certificates Using EKU . . . . . . . . . . . . . . . . . . 42
B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 49 B.2. Certificates NOT Using EKU . . . . . . . . . . . . . . . . 50
Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 58 Appendix C. Message Dumps . . . . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
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 [5]) implementations are becoming very common. SIP with TLS (RFC 5246 [12]) implementations are becoming very
Several implementations of the S/MIME (RFC 3851 [8]) portion of SIP common. Several implementations of the S/MIME (RFC 3851 [8]) portion
(RFC 3261 [2]) are also becoming available. After several of SIP (RFC 3261 [2]) 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 hampered by trying to get certificates signed by some common often hindered due to the lack of a commonly trusted certificate
test root into the appropriate format for various clients. This authority to sign the certificates used in the events. This document
document addresses both of these issues by providing messages that addresses both of these issues by providing messages that give
give detailed examples that implementers can use for comparison and detailed examples that implementers can use for comparison and that
that can also be used for testing. In addition, this document can also be used for testing. In addition, this document provides a
provides a common certificate and private key that can be used for a common certificate and private key that can be used to set up a mock
Certificate Authority (CA) to reduce the time it takes to set up a Certificate Authority (CA) that can be used during the SIP
test at an interoperability event. The document also provides some interoperability events. Certificate requests from the users will be
hints and clarifications for implementers. signed by the private key of the mock CA. The document also provides
some hints and clarifications for implementers.
A simple SIP call flow using SIPS URIs and TLS is shown in Section 4. A simple SIP call flow using SIPS URIs and TLS is shown in Section 3.
The certificates for the hosts used are shown in Section 3.2, and the The certificates for the hosts used are shown in Section 2.2, and the
CA certificates used to sign these are shown in Section 3.1. CA certificates used to sign these are shown in Section 2.1.
The text from Section 5.1 through Section 5.3 shows some simple SIP The text from Section 4.1 through Section 4.3 shows some simple SIP
call flows using S/MIME to sign and encrypt the body of the message. 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 3.3. These host certificates are signed with the same CA Section 2.3. These host certificates are signed with the same mock
certificate. CA private key.
Section 6 presents a partial list of things implementers should Section 5 presents a partial list of items that 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 Scripts and instructions to make certificates that can be used for
testing is presented in Appendix A, along with methods for converting interoperability testing are presented in Appendix A, along with
these to various formats. The certificates used while creating the methods for converting these to various formats. The certificates
examples and test messages in this document are made available in used while creating the examples and test messages in this document
Appendix B. are made available in 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. Certificates
2.1. CA Certificates
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
OPEN ISSUE: If there's no intent to have normative language, this
section and reference to RFC 2119 should be removed.
3. Certificates
3.1. CA Certificates
The certificate used by the CA to sign the other certificates is The certificate used by the CA to sign the other certificates is
shown below. This is a X509v3 certificate. Note that the X.509v3 shown below. This is a X509v3 certificate. Note that the X.509v3
Basic Constraints in the certificate allows it to be used as a CA, Basic Constraints in the certificate allows it to be used as a CA,
certificate authority. This certificate is not used directly in the certificate authority. This certificate is not used directly in the
TLS call flow; it is used only to verify user and host certificates. 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
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
3.2. Host Certificates 2.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 41 skipping to change at page 10, line 41
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
The example host certificate above, as well as all the others The example host certificate above, as well as all the others
presented in this document, are signed directly by a root CA. These presented in this document, are signed directly by a root CA. These
certificate chains have a length equal to two: the root CA and the certificate chains have a length equal to two: the root CA and the
host certificate. Non-root CAs exist and may also sign certificates. host certificate. Non-root CAs exist and may also sign certificates.
The certificate chains presented by hosts with certificates signed by The certificate chains presented by hosts with certificates signed by
non-root CAs will have a length greater than two. For more details non-root CAs will have a length greater than two. For more details
on how certificate chains are validated, see section 6.1.4 of RFC on how certificate chains are validated, see section 6.1.4 of RFC
5280 [4]. 5280 [13].
3.3. User Certificates TODO: Fix subjectAltName DNS:com to DNS:example.com and DNS:net to
DNS:example.net.
2.3. User Certificates
User certificates are used by many applications to establish user User certificates are used by many applications to establish user
identity. The user certificate for fluffy@example.com is shown identity. The user certificate for fluffy@example.com is shown
below. Note that the Subject Alternative Name has a list of names below. Note that the Subject Alternative Name has a list of names
with different URL types such as a sip, im, or pres URL. This is with different URL types such as a sip, im, or pres URL. This is
necessary for interoperating with a CPIM gateway. In this example, necessary for interoperating with a CPIM gateway. In this example,
example.com is the domain for fluffy. The message could be coming example.com is the domain for fluffy. The message could be coming
from a host called atlanta.example.com, and the AOR in the user from any host in *.example.com, and the AOR in the user certificate
certificate would still be the same. The others are shown in would still be the same. The others are shown in Appendix B.1.
Appendix B.1. These certificates make use of the EKU extension These certificates make use of the EKU extension discussed in Draft
discussed in Draft SIP EKU [13]. Note that the X509v3 Extended Key SIP EKU [14]. Note that the X509v3 Extended Key Usage attribute
Usage attribute refers to the SIP OID introduced in Draft SIP EKU refers to the SIP OID introduced in Draft SIP EKU [14], which is
[13] 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:
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
skipping to change at page 12, line 28 skipping to change at page 12, line 31
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
4. Callflow with Message Over TLS 3. Callflow with Message Over TLS
4.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 TLSRFC 5246 [5] connection to example.net. In example.com forming a TLS RFC 5246 [12] connection to example.net.
this example mutual authentication is not used. Note that the client In this example mutual authentication is not used. Note that the
proposed three protocol suites including TLS_RSA_WITH_AES_128_CBC_SHA client proposed three protocol suites including
defined in RFC 3268 [7]. The certificate returned by the server TLS_RSA_WITH_AES_128_CBC_SHA defined in RFC 3268 [4]. The
contains a Subject Alternative Name that is set to example.net. A certificate returned by the server contains a Subject Alternative
detailed discussion of TLS can be found in SSL and TLS [18]. For Name that is set to example.net. A detailed discussion of TLS can be
more details on the SSLDump tool, see the SSLDump Manual [19]. found in SSL and TLS [20]. For more details on the SSLDump tool, see
the SSLDump Manual [21].
This example does not use the Server Extended Hello (see RFC 3546 This example does not use the Server Extended Hello (see RFC 3546
[6]). [7]).
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 20 skipping to change at page 14, line 24
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
4.2. MESSAGE Message Over TLS 3.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 RFC 3428 [15] is sent from fluffy@example.com to defined in RFC 3428 [6] is sent from fluffy@example.com to
kumiko@example.net. Note that the URI has a SIPS URL and that the kumiko@example.net. Note that the URI has a SIPS URL and that the
VIA indicates that TLS was used. In order to format this document, VIA indicates that TLS was used. In order to format this document,
the <allOneLine> convention from RFC 4475 [12] is used to break long the <allOneLine> convention from RFC 4475 [19] 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
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.
CSeq: 1 MESSAGE CSeq: 1 MESSAGE
Accept: multipart/signed, text/plain, application/pkcs7-mime,\ Accept: multipart/signed, text/plain, application/pkcs7-mime,\
application/sdp, multipart/alternative application/sdp, multipart/alternative
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
already has a TLS connection to example.com and if it does, it may
send the message over this connection. A UA should have some scheme
for reusing connections as opening a new TLS connection for every
message results in awful performance. Implementers are encouraged to
read Draft Connection Reuse in SIP [16] and RFC 3263 [3].
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
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
OPEN ISSUE: Ben Campbell pointed out: Contact: "RFC3428 forbids TODO: Actually use the allOneLine convention. This will be fixed in
Contact header fields in MESSAGE requests or 2XX responses to a change to binary-generated content.
MESSAGE. This brings up the question as to whether MESSAGE is a good
example, as you may wish to illustrate SIPS rules concerning Contact.
(This reoccurs in all MESSAGE and 200 OK examples)." We need
consensus on this.
OPEN ISSUE: There should be some more information about how this TODO: Remove the Contact headers.
MESSAGE is associated with the handshake example. The dump in 5.1 is
slightly confusing in that example.com and example.net both resolved
to the same address, so reverse lookup shows both domains as
example.com.
OPEN ISSUE: Add a few lines about RFC 3263. Add a few lines about OPEN ISSUE: There should be some more information about how this
how the UA decides to create a new TLS session or use an existing one MESSAGE is associated with the handshake example. The dump in
(but not "connection-reuse" draft level of reuse complexity). Any Section 3.1 is slightly confusing in that example.com and example.net
volunteers? both resolved to the same address, so reverse lookup shows both
domains as example.com.
5. Callflow with S/MIME-secured Message 4. Callflow with S/MIME-secured Message
5.1. MESSAGE Message with Signed Body 4.1. MESSAGE Message with Signed Body
Below is an example of a signed message. The values on the Content- Below is an example of a signed message. The values on the Content-
Type line (multipart/signed) and on the Content-Disposition line have Type line (multipart/signed) and on the Content-Disposition line have
been broken across lines to fit on the page, but they should not be been broken across lines to fit on the page, but they should not be
broken across lines in actual implementations. 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
skipping to change at page 18, line 47 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 RFC 3370 [11]. The above dump of Blob 1 has NULL, as mentioned in RFC 3370 [5]. The above dump of Blob 1 has
SHA-1 parameters set to NULL. Below are the same contents signed SHA-1 parameters set to NULL. Below are the same contents signed
with the same key, but omitting the NULL according to RFC 3370 [11]. with the same key, but omitting the NULL according to RFC 3370 [5].
This is the preferred encoding. This is covered in greater detail in This is the preferred encoding. This is covered in greater detail in
Section 6. Section 5.
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 44 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
: } : }
: } : }
: } : }
: } : }
: } : }
5.2. MESSAGE Message with Encrypted Body TODO: For generated-content, change "hello" to "Hello!" to be
consistent.
TODO: Actually use the allOneLine convention. This will be fixed in
a change to binary-generated content.
4.2. MESSAGE Message with Encrypted Body
Below is an example of an encrypted text/plain message that says Below is an example of an encrypted text/plain message that says
"hello". The binary encrypted contents have been replaced with the "hello". The binary encrypted contents have been replaced with the
block "BINARY BLOB 2". block "BINARY BLOB 2".
MESSAGE sip:kumiko@example.net SIP/2.0 MESSAGE sip:kumiko@example.net SIP/2.0
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
skipping to change at page 23, line 24 skipping to change at page 23, line 30
: 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
: } : }
: } : }
: } : }
: } : }
5.3. MESSAGE Message with Encrypted and Signed Body TODO: For generated-content, change "hello" to "Hello!" to be
consistent.
TODO: Actually use the allOneLine convention. This will be fixed in
a change to binary-generated content.
4.3. MESSAGE Message with Encrypted and Signed Body
In the example below, some of the header values have been split In the example below, some of the header values have been split
across mutliple lines. Where the lines have been broken, a "\" has across mutliple lines. Where the lines have been broken, a "\" has
been inserted. This was only done to make it fit in the RFC format. been inserted. This was only done to make it fit in the RFC format.
Specifically, the application/pkcs7-mime Content-Type line should be Specifically, the application/pkcs7-mime Content-Type line should be
one line with no whitespace between the "mime;" and the "smime-type". one line with no whitespace between the "mime;" and the "smime-type".
The values are split across lines for formatting, but are not split The values are split across lines for formatting, but are not split
in the real message. The binary encrypted content has been replaced 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 3", and the binary signed content has been replaced
with "BINARY BLOB 4". with "BINARY BLOB 4".
skipping to change at page 28, 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
: } : }
: } : }
: } : }
: } : }
: } : }
6. Observed Interoperability Issues TODO: Actually use the allOneLine convention. This will be fixed in
a change to binary-generated content.
OPEN ISSUE: Who observed them? Is this experience from SIPits, etc? 5. Observed Interoperability Issues
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. These
Implementers should verify that their clients do the correct things were observed by the authors at SIPit interoperability events.
and when possible make their clients forgiving in what they receive. Implementers should be careful to verify that their systems do not
Implementations should take extra care to produce reasonable error introduce these common problems, and, when possible, make their
messages when interacting with software that has these problems. clients forgiving in what they receive. Implementations should take
extra care to produce reasonable error messages when interacting with
software that has these problems.
Some SIP clients incorrectly only do SSLv3 and do not support TLS. 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 [11] is the form in encoding as set out in Section 2 of RFC 3370 [5] is the form in which
which the optional AlgorithmIdentifier parameter field is omitted. the optional AlgorithmIdentifier parameter field is omitted.
However, RFC 3370 also says the recipients need to be able to receive However, RFC 3370 also says the recipients need to be able to receive
the form in which the AlgorithmIdentifier parameter field is present the form in which the AlgorithmIdentifier parameter field is present
and set to NULL. Examples of the form using NULL can be found in and set to NULL. Examples of the form using NULL can be found in
Section 4.2 of RFC 4134 [14]. Receivers really do need to be able to Section 4.2 of RFC 4134 [18]. 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 [10]. defined in RFC 3853 [10].
Observed S/MIME interoperability has been better when UAs did not Observed S/MIME interoperability has been better when UAs did not
attach the senders' certificates. Attaching the certificates attach the senders' certificates. Attaching the certificates
significantly increases the size of the messages, and since it can significantly increases the size of the messages, which should be
not be relied on, it does not turn out to be useful in most considered when sending over UDP. Furthermore, the receiver cannot
situations. rely on the sender to always send the certificate, so it does not
turn out to be useful in most situations.
OPEN ISSUE: There's some implicit stuff here that should be explicit.
Do you mean to recommend never attaching certs? It's probably worth
mentioning the message size limit issue. What do we mean by "it
cannot be relied upon"--that we can't rely on the peer sending it, or
it is unreliable when the peer does send it?
7. Additional Test Scenarios 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 [16] (particulary, section 13.4 normative works such as RFC 4474 [11] (particulary, section 13.4
Domain Names and Subordination) and informative works such as RFC Domain Names and Subordination) and informative works such as RFC
2818 [17] section 3.1. To summarize that non-normative lore: 2818 [17] section 3.1. To summarize:
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
peer's certifcate as a uniformResourceIdentifier field. the peer's certifcate as a uniformResourceIdentifier field.
o For TLS the peer's hostname (from the initial DNS query in the o For TLS, the peer's hostname must appear as described in Draft SIP
server location process RFC 3263 [3]) must appear as Domain Certs [15]:
* 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 '*'
The peer's hostname is discovered from the initial DNS query in
OPEN ISSUE: Are we sure all of this is truly folklore and none of it the server location process RFC 3263 [3].
is from bona fide normative language somewhere? The true folklore o An IP Address can appear in subjectAltName (RFC 5280 [13]) of the
portions may indicate future normative work we need to do. peer's certificate, e.g. "DNS:192.168.0.1".
OPEN ISSUE: From first bullet, "peer's URI"...What URI? An AoR for OPEN ISSUE: From first bullet, "peer's URI"...What URI? An AoR for
the user? From or To values? Contacts? Request-URIs? For request the user? From or To values? Contacts? Request-URIs? For request
URIs, do we need to discuss the effects of retargeting? Do we need URIs, do we need to discuss the effects of retargeting? Do we need
to consider some of the current History-Info discussions? to consider some of the current History-Info discussions?
OPEN ISSUE: From second bullet: What if all you've got is an IP OPEN ISSUE: From second bullet: What if all you've got is an IP
address? Do we disallow IPAddress entries in SubjectAltName? address? Do we disallow IPAddress entries in subjectAltName? IP
addresses can appear in the subjectAltName (rfc5280 says so.) Their
handling is specified in domain-certs (I believe they will appear as
"DNS:192.168.0.1"; we need to have someone -- from pkix? -- ascertain
this. If this is the case, then their handling is specified in S7.1
of domain-certs.
OPEN ISSUE: First sub-bullet (Wildcard matching is not allowed OPEN ISSUE: First sub-bullet (Wildcard matching is not allowed
against these dNSName entries): Is there something that can be against these dNSName entries): Is there something that can be
referenced here? In particular, RFC2818 explicitly allows wildcards referenced here? In particular, RFC2818 explicitly allows wildcards
in dNSName entries. It is not obvious to me whether the proscription in dNSName entries. It is not obvious to me whether the proscription
against wildcards in RFC4474 should apply to general use of TLS, or against wildcards in RFC4474 should apply to general use of TLS, or
just to identity. 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)
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 (the current time does not fall 4. S/MIME : Bad peer certificate (incomplete authority chain)
5. S/MIME : Bad peer certificate (the current time does not fall
within the period of validity) within the period of validity)
5. 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)
6. TLS : Good peer certificate (hostname appears in dNSName in 7. S/MIME : Bad peer certificate ("Digital Signature" is not
specified as an X509v3 Key Usage)
8. TLS : Good peer certificate (hostname appears in dNSName in
subjAltName) subjAltName)
7. 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)
8. TLS : Bad peer certificate (no match in dNSNames or in the 10. TLS : Good peer certificate (CN of Subject empty, and
subjectAltName extension contains an iPAddress stored in the
octet string in network byte order form as specified in RFC 791
[1])
11. 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 12. 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 13. TLS : Bad peer certificate (incomplete authority chain)
14. 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 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
not specified as an X509v3 Key Usage)
OPEN ISSUE: What about cases where the basic constraints or allowed OPEN ISSUE: Should we have at least one case for SIP EKU?
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 7. IANA Considerations
No IANA actions are required. No IANA actions are required.
9. 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" [18] was a huge http://www.rtfm.com/ssldump. The book "SSL and TLS" [20] 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 9. Security Considerations
Implementers must never use any of the certificates provided in this Implementers must never use any of the certificates provided in this
document in anything but a test environment. Installing the CA root document in anything but a test environment. Installing the CA root
certificates used in this document as a trusted root in operational certificates used in this document as a trusted root in operational
software would completely destroy the security of the system while software would completely destroy the security of the system while
giving the user the impression that the system was operating giving the user the impression that the system was operating
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 the messages needed to check Certificate 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 revocation status (see RFC 5280 [13]) as that is not part of the SIP
call flow. call flow. The expectation is that revocation status is checked
periodically and regularly to protect against the possibility of
OPEN ISSUE: We should probably say something about CRLs. We need to certificate compromise or repudiation.
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 10. Changelog
(RFC Editor: remove this section) (RFC Editor: remove this section)
-01 to -02
* Draft is now informational, not standards track. Normative-
sounding language and references to RFC 2119 removed.
* Add TODO: change "hello" to "Hello!" in example flows for
consistency.
* Add TODO: Fix subjectAltName DNS:com to DNS:example.com and
DNS:net to DNS:example.net.
* Add TODO: use allOneLine convention from RFC4475.
* Section 3: updated open issue regarding contact headers in
MESSAGE.
* Section 3.2: added some text about RFC 3263 and connection
reuse and closed open issue.
* Section 5: clarified text about sender attaching certs, closed
issue.
* Section 5: clarified text about observed problems, closed
issue.
* Section 5: closed issue about clients vs. servers vs. proxies.
* Section 6: updatee section text and open issue where IP address
is in subjectAltName.
* Section 6: added normative references and closed "folklore"
issue.
* Section 6: added cases about cert usage and broken chains,
updated OPEN ISSUE: we need a SIP EKU example.
* References: updated references to drafts and re-categorized
informative vs. normative.
* Section 9: added some text about revocation status and closed
issue.
* 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?
* 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 [13]. specified in Draft SIP EKU [14].
* 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)
12. References 11. References
12.1. Normative References 11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Postel, J., "Internet Protocol", STD 5, RFC 791,
Levels", BCP 14, RFC 2119, March 1997. September 1981.
[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] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [3] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002. (SIP): Locating SIP Servers", RFC 3263, June 2002.
[4] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, [4] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
R., and W. Polk, "Internet X.509 Public Key Infrastructure Transport Layer Security (TLS)", RFC 3268, June 2002.
Certificate and Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008.
[5] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) [5] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms",
Protocol Version 1.2", RFC 5246, August 2008. RFC 3370, August 2002.
[6] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and [6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", T. Wright, "Transport Layer Security (TLS) Extensions",
RFC 3546, June 2003. RFC 3546, June 2003.
[7] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002.
[8] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions [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.
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, [9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004. July 2004.
[10] 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.
[11] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", [11] Peterson, J. and C. Jennings, "Enhancements for Authenticated
RFC 3370, August 2002. Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[12] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and [12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test Protocol Version 1.2", RFC 5246, August 2008.
Messages", RFC 4475, May 2006.
[13] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU) [13] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley,
for Session Initiation Protocol (SIP) X.509 Certificates", R., and W. Polk, "Internet X.509 Public Key Infrastructure
draft-ietf-sip-eku-04 (work in progress), April 2009. Certificate and Certificate Revocation List (CRL) Profile",
RFC 5280, May 2008.
12.2. Informative References [14] Lawrence, S. and V. Gurbani, "Using Extended Key Usage (EKU)
for Session Initiation Protocol (SIP) X.509 Certificates",
draft-ietf-sip-eku-08 (work in progress), October 2009.
[14] Hoffman, P., "Examples of S/MIME Messages", RFC 4134, [15] Gurbani, V., Lawrence, S., and B. Laboratories, "Domain
July 2005. Certificates in the Session Initiation Protocol (SIP)",
draft-ietf-sip-domain-certs-04 (work in progress), May 2009.
[15] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and [16] Gurbani, V., Mahy, R., and B. Tate, "Connection Reuse in the
D. Gurle, "Session Initiation Protocol (SIP) Extension for Session Initiation Protocol (SIP)",
Instant Messaging", RFC 3428, December 2002. draft-ietf-sip-connect-reuse-14 (work in progress),
August 2009.
[16] Peterson, J. and C. Jennings, "Enhancements for Authenticated 11.2. Informative References
Identity Management in the Session Initiation Protocol (SIP)",
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] Hoffman, P., "Examples of S/MIME Messages", RFC 4134,
July 2005.
[19] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., and
H. Schulzrinne, "Session Initiation Protocol (SIP) Torture Test
Messages", RFC 4475, May 2006.
[20] Rescorla, E., "SSL and TLS - Designing and Building Secure
Systems", 2001. Systems", 2001.
[19] Rescorla, E., "SSLDump manpage". [21] 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 36, line 24 skipping to change at page 37, line 4
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 (version 8), Outlook Express (version 6), and Firefox (version IE (version 8), Outlook Express (version 6), and Firefox (version
3.5) can import and export .p12 files and .p7c files. You can 3.5) can import and export .p12 files and .p7c files. You can
convert a pkcs7 certificate to PEM format with "openssl pkcs7 -in convert a pkcs7 certificate to PEM format with "openssl pkcs7 -in
cert.p7c -inform DER -outform PEM -out cert.pem". 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 OPEN ISSUE: The information in this section needs to be verified with
the latest software versions. How to do conversions between the latest software versions. How to do conversions between
supported types needs to be updated accordingly. supported types needs to be updated accordingly. Any Windows users
out there want to volunteer for verify the Windows side of these?
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, a single file with both certificate These could be in two PEM files, a single file with both certificate
and private key PEM sections, or a single .p12 file. An S/MIME and private key PEM sections, or a single .p12 file. An S/MIME
program will need its private key and certificate, the root program will need its private key and certificate, the root
certificate of the CA, and the certificate for every other user it certificate of the CA, and the certificate for every other user it
communicates with. communicates with.
A.1. makeCA script A.1. makeCA script
skipping to change at page 42, line 10 skipping to change at page 42, line 37
mv ${ADDR}_cert.pem user_cert_${ADDR}.pem ;; mv ${ADDR}_cert.pem user_cert_${ADDR}.pem ;;
*) mv ${ADDR}_key.pem domain_key_${ADDR}.pem; \ *) mv ${ADDR}_key.pem domain_key_${ADDR}.pem; \
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.
OPEN ISSUE: Should we discuss certificate chains? We aren't really
trying to be a tutorial. Would it be helpful to add a non-root CA
and hosts signed by that non-root CA to help with testing events? We
do imply non-root CAs in Section 6.
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
Draft SIP EKU [13]. Draft SIP EKU [14].
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 49, line 35 skipping to change at page 50, 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 Draft SIP EKU [13]. Most existing certificates fall in this in Draft SIP EKU [14]. Most existing certificates fall in this
category. 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
skipping to change at page 58, line 34 skipping to change at page 59, line 34
4IvWRPUvwc+QQ6srxDwgTOECgYBK0i9og1uzn4WVO5IOeT/RUd/uvprN5eA2HTTa 4IvWRPUvwc+QQ6srxDwgTOECgYBK0i9og1uzn4WVO5IOeT/RUd/uvprN5eA2HTTa
Hl0wgSpM6si8g3f49bssnwZdiy5Ei3M/jL9T24DK5b3EGcXg1BNGd0So7FuD23XN Hl0wgSpM6si8g3f49bssnwZdiy5Ei3M/jL9T24DK5b3EGcXg1BNGd0So7FuD23XN
UQJ7w658hXtpXFQo0hI5bEz6YvIDmd9UYlkZpZjjDyJsNJVyiLHAxVGq8OmbWF6B UQJ7w658hXtpXFQo0hI5bEz6YvIDmd9UYlkZpZjjDyJsNJVyiLHAxVGq8OmbWF6B
Qbnh+QKBgQCF4xV6Ha7dSRZoU6iPYp2t6y4JRCXf9H1kIJVrFzPv0sfysdwflbJS Qbnh+QKBgQCF4xV6Ha7dSRZoU6iPYp2t6y4JRCXf9H1kIJVrFzPv0sfysdwflbJS
XAn+206ShYN6OBPt6f9As6oggw+xzKiiAxHdlhsipuUlQRIUGMIxJ1DQcXtsLp7L XAn+206ShYN6OBPt6f9As6oggw+xzKiiAxHdlhsipuUlQRIUGMIxJ1DQcXtsLp7L
8YeoLWCvYknXw/k5TT3uzrZ6I5GsqzNSzh0jsay91zp/4qrdcnr7fg== 8YeoLWCvYknXw/k5TT3uzrZ6I5GsqzNSzh0jsay91zp/4qrdcnr7fg==
-----END RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
Appendix C. Message Dumps Appendix C. Message Dumps
OPEN ISSUE: All of this binary bit-exact stuff needs to be verified
by other than myself. I'm looking into ways to make this easier for
someone else to review and verify. Any code I make available will be
OpenSSL-centric. -BCH
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 --
H4sIANiq/UoCA+xcaUATV9cmYV/CIoriGilisQRmJjNJAEHBhEVJEAjQpFqZ H4sIAOoQWksCA+xcaUATV9cmYV/CIoriGilisQRmJjNJAEHBhEVJEAjQpFqZ
JBMSyGYSBIOoRaUW14ILWkVcEVRk0brgjhuyVdzB7QUtiFvFutRafYdqK0UU JBMSyGYSBIOoRaUW14ILWkVcEVRk0brgjhuyVdzB7QUtiFvFutRafYdqK0UU
v764ftw/Se7MPXMyuec8z33OnQjlGopGLpVjFLkm2lWEavU6vwF4o8Hwn690 v764ftw/Se7MPXMyuec8z33OnQjlGopGLpVjFLkm2lWEavU6vwF4o8Hwn690
GvKPV7xBCEDTA0GITqdCCJUK6AEgFQJpemRA7x20OI0WVZPJegK1FFW85ryO GvKPV7xBCEDTA0GITqdCCJUK6AEgFQJpemRA7x20OI0WVZPJegK1FFW85ryO
jn+kjc0KC/PxZ5E1UpVHbJxcGqscjiWgcpUMc1VgWnJY4Gg3yBUgmUVIUY+/ jn+kjc0KC/PxZ5E1UpVHbJxcGqscjiWgcpUMc1VgWnJY4Gg3yBUgmUVIUY+/
PrlxR4wmQwDDlU53BRkMV5BG8wARAAA9BWpUIZR46dwl/rBgFEXEoCOwjgKL PrlxR4wmQwDDlU53BRkMV5BG8wARAAA9BWpUIZR46dwl/rBgFEXEoCOwjgKL
3SEUpjEAOgohGABQQArlr2OeapVSrfVCYAQASWZsNIHip1THo2qRxoNMx687 3SEUpjEAOgohGABQQArlr2OeapVSrfVCYAQASWZsNIHip1THo2qRxoNMx687
QqnQokKtB3loi4diWZxYPPFvD4VKuTfJjKt8fvRl//Gjfmql/NWjPbVotJcA QqnQokKtB3loi4diWZxYPPFvD4VKuTfJjKt8fvRl//Gjfmql/NWjPbVotJcA
hejuEIDgV0NlMkog04PMhvxkHGiklC3nxPJj+HKOPBxmR4YAnEiejiMPBIO5 hejuEIDgV0NlMkog04PMhvxkHGiklC3nxPJj+HKOPBxmR4YAnEiejiMPBIO5
khgeVxbDjwx3xYeFYeM9yCD5+c0kmfkIhZgKd1oeJ9NKVaha66aRRiswkQtZ khgeVxbDjwx3xYeFYeM9yCD5+c0kmfkIhZgKd1oeJ9NKVaha66aRRiswkQtZ
iyVo3VQyVKpwIaMqlUwqRLVSpcJNFSvU0CktgfjPfo1I5dLKDCrTYmoFfmgC iyVo3VQyVKpwIaMqlUwqRLVSpcJNFSvU0CktgfjPfo1I5dLKDCrTYmoFfmgC
 End of changes. 97 change blocks. 
247 lines changed or deleted 301 lines changed or added

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