draft-ietf-sip-sec-agree-02.txt   draft-ietf-sip-sec-agree-03.txt 
SIP Working Group Jari Arkko SIP Working Group Jari Arkko
INTERNET-DRAFT Vesa Torvinen INTERNET-DRAFT Vesa Torvinen
<draft-ietf-sip-sec-agree-02.txt> Gonzalo Camarillo <draft-ietf-sip-sec-agree-03.txt> Gonzalo Camarillo
May 2002 Ericsson June 2002 Ericsson
Expires: December 2002 Tao Haukka Expires: December 2002 Tao Haukka
Nokia Nokia
Sanjoy Sen Sanjoy Sen
Nortel Networks Nortel Networks
Security Mechanism Agreement for SIP Sessions Security Mechanism Agreement for SIP Sessions
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
skipping to change at page 1, line 51 skipping to change at page 1, line 51
attachments. These mechanisms have even alternative algorithms and attachments. These mechanisms have even alternative algorithms and
parameters. SIP does not currently provide any mechanism for parameters. SIP does not currently provide any mechanism for
selecting which security mechanisms to use between two entities. In selecting which security mechanisms to use between two entities. In
particular, even if some mechanisms such as OPTIONS were used to make particular, even if some mechanisms such as OPTIONS were used to make
this selection, the selection would be vulnerable against the this selection, the selection would be vulnerable against the
Bidding-Down attack. This document defines three header fields for Bidding-Down attack. This document defines three header fields for
negotiating the security mechanisms within SIP between a SIP entity negotiating the security mechanisms within SIP between a SIP entity
and its next SIP hop. A SIP entity applying this mechanism must and its next SIP hop. A SIP entity applying this mechanism must
always require some minimum security (i.e. integrity protection) from always require some minimum security (i.e. integrity protection) from
all communicating parties in order to secure the negotiation, but the all communicating parties in order to secure the negotiation, but the
negotiation can agree on which specific minimum security is used. negotiation can agree on which specific security is used.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction....................................................2 1. Introduction....................................................2
2. The Problem.....................................................3 2. The Problem.....................................................3
3. Solution........................................................4 3. Solution........................................................4
3.1. Requirements...............................................4 3.1. Requirements...............................................4
3.2. Overview of Operations.....................................5 3.2. Overview of Operations.....................................5
3.3. Syntax.....................................................6 3.3. Syntax.....................................................6
3.4. Protocol Operation.........................................7 3.4. Protocol Operation.........................................7
skipping to change at page 2, line 29 skipping to change at page 2, line 29
4. Backwards Compatibility........................................11 4. Backwards Compatibility........................................11
5. Examples.......................................................11 5. Examples.......................................................11
5.1. Client Initiated..........................................10 5.1. Client Initiated..........................................10
5.2. Server Initiated..........................................12 5.2. Server Initiated..........................................12
5.3. Security Negotiation between Proxies......................13 5.3. Security Negotiation between Proxies......................13
6. Security Considerations........................................13 6. Security Considerations........................................13
7. IANA Considerations............................................15 7. IANA Considerations............................................15
8. Acknowledgments................................................15 8. Acknowledgments................................................15
9. Normative References...........................................15 9. Normative References...........................................15
10. Non-Normative References.......................................16 10. Non-Normative References.......................................16
11. AuthorsĘs Addresses............................................16 11. Authors's Addresses............................................16
1. Introduction 1. Introduction
Traditionally, security protocols have included facilities to agree Traditionally, security protocols have included facilities to agree
on the used mechanisms, algorithms, and other security parameters. on the used mechanisms, algorithms, and other security parameters.
The reason for this is that experience has shown that algorithm The reason for this is that algorithm development typically uncovers
development uncovers problems in old algorithms and produces new problems in old algorithms and sometimes even produces new problems.
ones. Furthermore, different mechanisms and algorithms are suitable Furthermore, different mechanisms and algorithms are suitable for
for different situations. Typically, protocols also select other different situations. Typically, protocols also select other
parameters beyond algorithms at the same time. parameters beyond algorithms at the same time.
The purpose of this specification is to define a similar negotiation The purpose of this specification is to define a similar negotiation
functionality in SIP [1]. SIP has some security functionality built- functionality in SIP [1]. SIP has some security functionality built-
in such as HTTP Digest authentication [4], secure attachments such as in (e.g. HTTP Digest authentication [4]), it can utilize secure
S/MIME [5], and can also use underlying security protocols such as attachments (e.g. S/MIME [5]), and it can also use underlying
IPsec/IKE [2] or TLS [3]. Some of the built-in security functionality security protocols (e.g. IPsec/IKE [2] or TLS [3]). Some of the
allows also alternative algorithms and other parameters. While some built-in security functionality allows also alternative algorithms
work within the SIP Working Group has been looking towards reducing and other parameters. While some work within the SIP Working Group
the number of recommended security solutions (i.e., recommend just has been looking towards reducing the number of recommended security
one lower layer security protocol), we can not expect to cut down the solutions (i.e., recommend just one lower layer security protocol),
number of items in the whole list to one. There will still be we can not expect to cut down the number of items in the whole list
multiple security solutions utilized by SIP. Furthermore, it is to one. There will still be multiple security solutions utilized by
likely that new methods will appear in the future, to complement the SIP. Furthermore, it is likely that new methods will appear in the
methods that exist today. future, to complement the methods that exist today.
Chapter 2 shows that without a secured method to choose between Chapter 2 shows that without a secured method to choose between
security mechanisms and/or their parameters, SIP is vulnerable to security mechanisms and/or their parameters, SIP is vulnerable to
certain attacks. As the HTTP authentication RFC [4] points out, certain attacks. As the HTTP authentication RFC [4] points out,
authentication and integrity protection using multiple alternative authentication and integrity protection using multiple alternative
methods and algorithms is vulnerable to Man-in-the-Middle (MitM) methods and algorithms is vulnerable to Man-in-the-Middle (MitM)
attacks. More seriously, it is hard or sometimes even impossible to attacks. More seriously, it is hard or sometimes even impossible to
know whether a SIP peer entity is truly unable to perform (e.g., know whether a SIP peer entity is truly unable to perform (e.g.,
Digest, TLS, or S/MIME) or if a MitM attack is in action. In small Digest, TLS, or S/MIME) or if a MitM attack is in action. In small
networks consisting of workstations and servers these issues are not networks consisting of workstations and servers these issues are not
skipping to change at page 5, line 34 skipping to change at page 5, line 34
Furthermore, peers have to set up IPsec Security Associations before Furthermore, peers have to set up IPsec Security Associations before
they can be used to receive traffic. In contrast S/MIME can be they can be used to receive traffic. In contrast S/MIME can be
received even if no Security Association was in place, because the received even if no Security Association was in place, because the
application can search for a Security Association (or create a new application can search for a Security Association (or create a new
one) after having received a message that contains S/MIME. one) after having received a message that contains S/MIME.
In order to make it possible to negotiate both self-describing and In order to make it possible to negotiate both self-describing and
non-self-describing security mechanisms, we need another requirement non-self-describing security mechanisms, we need another requirement
on the security agreement scheme: on the security agreement scheme:
(f) the security agreement scheme must allow both sides to decide on (f) The security agreement scheme must allow both sides to decide on
the desired security mechanism before it is actually used. the desired security mechanism before it is actually used.
This decision can, and must, take place on both sides before we can This decision can, and must, take place on both sides before we can
be sure that the negotiation has not been tampered by a man-in-the- be sure that the negotiation has not been tampered by a man-in-the-
middle. This tampering will be detected later. middle. This tampering will be detected later.
3.2. Overview of Operations 3.2. Overview of Operations
The message flow below illustrates how the mechanism defined in this The message flow below illustrates how the mechanism defined in this
document works: document works:
skipping to change at page 7, line 8 skipping to change at page 7, line 8
Note that qvalue is already defined in the SIP BNF [1]. We have Note that qvalue is already defined in the SIP BNF [1]. We have
copied its definitions here for completeness. copied its definitions here for completeness.
The parameters described by the BNF above have the following The parameters described by the BNF above have the following
semantics: semantics:
Mechanism-name: It identifies the security mechanism supported by Mechanism-name: It identifies the security mechanism supported by
the client, when it appears in a Security-Client header fields, or the client, when it appears in a Security-Client header fields, or
by the server, when it appears in a Security-Server or in a by the server, when it appears in a Security-Server or in a
Security-Verify header field. This specification defines six Security-Verify header field. This specification defines five
values: values:
- "tls" for TLS [3]. - "tls" for TLS [3].
- "digest-integrity" for HTTP Digest [4] using additional - "digest-integrity" for HTTP Digest [4] using additional
integrity protection for the Security-Verify header field. The integrity protection for the Security-Verify header field. The
additional integrity protection consists of using the qop additional integrity protection consists of using the qop
parameter to protect a sipfrag body part [6] that contains the parameter to protect a sipfrag body part [6] that contains the
Security-Verify header field. Security-Verify header field.
- "ipsec-ike" for IPsec with IKE [2]. - "ipsec-ike" for IPsec with IKE [2].
- "ipsec-man" for manually keyed IPsec without IKE. - "ipsec-man" for manually keyed IPsec without IKE.
skipping to change at page 7, line 44 skipping to change at page 7, line 44
negotiation between a SIP entity and its next-hop SIP entity. negotiation between a SIP entity and its next-hop SIP entity.
Throughout the text the next-hop SIP entity is referred to as the Throughout the text the next-hop SIP entity is referred to as the
first-hop proxy or outbound proxy. However, the reader should bear in first-hop proxy or outbound proxy. However, the reader should bear in
mind that a user agent server can also be the next-hop for a proxy mind that a user agent server can also be the next-hop for a proxy
or, in absence of proxies, for a user agent client. Note as well that or, in absence of proxies, for a user agent client. Note as well that
a proxy can also have an outbound proxy. a proxy can also have an outbound proxy.
3.4.1 Client Initiated 3.4.1 Client Initiated
A client wishing to establish some type of security with its first- A client wishing to establish some type of security with its first-
hop proxy SHOULD add a Security-Client header field to a request hop proxy MUST add a Security-Client header field to a request
addressed to this proxy (i.e., the destination of the request is the addressed to this proxy (i.e., the destination of the request is the
first-hop proxy). This header field contains a list of all the first-hop proxy). This header field contains a list of all the
security mechanisms that the client supports. The client SHOULD NOT security mechanisms that the client supports. The client SHOULD NOT
add preference parameters to this list. The client MUST also add a add preference parameters to this list. The client MUST add both a
Require header field with the value "sec-agree" to its request. Require and Proxy-Require header field with the value "sec-agree" to
its request.
The Security-Client header field is used by the server to include any The Security-Client header field is used by the server to include any
necessary information in its response. For example, if digest- necessary information in its response. For example, if digest-
integrity is the chosen mechanism, the server includes a WWW- integrity is the chosen mechanism, the server includes an HTTP
Authenticate header in the response. If S/MIME is chosen, the authentication challenge in the response. If S/MIME is chosen, the
appropriate certificate is included. If the security mechanisms appropriate certificate is included. If the security mechanisms
supported by the client do not need any further information to be supported by the client do not need any further information to be
established (e.g., TLS) the client MAY choose not to include the established (e.g., TLS) the client MAY choose not to include the
Security-Client header field in its request. Security-Client header field in its request.
A server receiving a request that contains a Require header field A server receiving an unprotected request that contains a Require or
with the value "sec-agree" MUST challenge the client with a 494 Proxy-Require header field with the value "sec-agree" MUST challenge
(Security Agreement Required) response. The server MUST add a the client with a 494 (Security Agreement Required) response. The
Security-Server header field to this response listing the security server MUST add a Security-Server header field to this response
mechanisms that the server supports. The server MUST add its list to listing the security mechanisms that the server supports. The server
the response even if there are no common security mechanisms in the MUST add its list to the response even if there are no common
client's and server's lists. The serverĘs list MUST NOT depend on the security mechanisms in the client's and server's lists. The servers
contents of the client's list. list MUST NOT depend on the contents of the client's list.
The server MUST compare the list received in the Security-Client The server MUST compare the list received in the Security-Client
header field with the list to be sent in the Security-Server header header field with the list to be sent in the Security-Server header
field. When the client receives this response, it will choose the field. When the client receives this response, it will choose the
common security mechanism with the higher preference value. common security mechanism with the highest "q" value. Therefore, the
Therefore, the server MUST add the necessary information so that the server MUST add the necessary information so that the client can
client can initiate that mechanism (e.g., a WWW-Authenticate header initiate that mechanism (e.g., a WWW-Authenticate header field for
field for digest-integrity). digest-integrity).
When the client receives a response with a Security-Server header When the client receives a response with a Security-Server header
field, it SHOULD choose the security mechanism in the serverĘs list field, it SHOULD choose the security mechanism in the servers list
with the highest "q" value among all the mechanisms that are known to with the highest "q" value among all the mechanisms that are known to
the client. Then, it MUST initiate that particular security mechanism the client. Then, it MUST initiate that particular security mechanism
as described in Section 3.5. This initiation may be carried out as described in Section 3.5. This initiation may be carried out
without involving any SIP message exchange (e.g., establishing a TLS without involving any SIP message exchange (e.g., establishing a TLS
connection). connection).
If an attacker modified the Security-Client header field in the If an attacker modified the Security-Client header field in the
request, the server may not include in its response the information request, the server may not include in its response the information
needed to establish the common security mechanism with the highest needed to establish the common security mechanism with the highest
preference value (e.g., the WWW-authenticate header field is preference value (e.g., the WWW-authenticate header field is
missing). A client detecting such a lack of information in the missing). A client detecting such a lack of information in the
response MUST consider the current security negotiation process response MUST consider the current security negotiation process
aborted, and MAY try to start it again by sending a new request with aborted, and MAY try to start it again by sending a new request with
a Security-Client header field as described above. a Security-Client header field as described above.
All the subsequent SIP requests sent by the client SHOULD make use of All the subsequent SIP requests sent by the client to that server
the security mechanism initiated in the previous step. These requests SHOULD make use of the security mechanism initiated in the previous
MUST contain a Security-Verify header field that mirrors the serverĘs step. These requests MUST contain a Security-Verify header field
list received previously in the Security-Server header field. This that mirrors the servers list received previously in the Security-
request MAY use SIP loose routing mechanism (i.e., Route header Server header field. These requests MUST also have both a Require
fields) to traverse the proxy, but its final destination may be and Proxy-Require header fields with the value "sec-agree".
different than the proxy. In this case, the request SHOULD NOT
include a Require header field with the value "sec-agree".
For example, the first request was an OPTIONS request directly
addressed to the proxy and the second request is an INVITE that
will traverse the proxy but that is addressed to a real user (see
example in section 4.1).
The server MUST check that the security mechanisms listed in the The server MUST check that the security mechanisms listed in the
Security-Verify header field of incoming requests correspond to its Security-Verify header field of incoming requests correspond to its
static list of supported security mechanisms. The server can proceed static list of supported security mechanisms. The server can proceed
processing a particular request if, and only if, the list was not processing a particular request if, and only if, the list was not
modified. If modification of the list is detected, the server MUST modified. If modification of the list is detected, the server MUST
challenge the client with a 494 (Security Agreement Required). This challenge the client with a 494 (Security Agreement Required). This
response MUST include a challenge with server's unmodified list of response MUST include a challenge with server's unmodified list of
supported security mechanisms. supported security mechanisms. If the list was not modified, and the
server is a proxy, it MUST remove the "sec-agree" value from both the
Require and Proxy-Require header fields, and then remove the header
fields if no values remain.
Once the security has been negotiated between two SIP entities, the Once the security has been negotiated between two SIP entities, the
same SIP entities MAY use the same security when communicating with same SIP entities MAY use the same security when communicating with
each other in different SIP roles. For example, if a UAC and its each other in different SIP roles. For example, if a UAC and its
outbound proxy negotiate some security, they may try to use the same outbound proxy negotiate some security, they may try to use the same
security for incoming requests (i.e., the UA will be acting as a security for incoming requests (i.e., the UA will be acting as a
UAS). UAS).
The user of a UA MAY be informed about the results of the security The user of a UA MAY be informed about the results of the security
mechanism negotiation. The user MAY decline to accept a particular mechanism negotiation. The user MAY decline to accept a particular
security mechanism, and abort further SIP communications with the security mechanism, and abort further SIP communications with the
peer. peer.
3.4.2 Server Initiated 3.4.2 Server Initiated
A server decides to use the security negotiation described in this A server decides to use the security negotiation described in this
document based on local policy. A server that decides to use this document based on local policy. A server that decides to use this
negotiation MUST challenge requests regardless of the presence or the negotiation MUST challenge unprotected requests regardless of the
absence of any Require or Supported header fields in incoming presence or the absence of any Require, Proxy-Require or Supported
requests. header fields in incoming requests.
A server that by policy requires the use of this specification and A server that by policy requires the use of this specification and
receives a request that does not have the sec-agree option tag in a receives a request that does not have the sec-agree option tag in a
Require or Supported header field MUST return a 421 (Extension Require, Proxy-Require or Supported header field MUST return a 421
Required) response. If the request had the sec-agree option tag in a (Extension Required) response. If the request had the sec-agree
Supported header field, it MUST return a 494 (Security Agreement option tag in a Supported header field, it MUST return a 494
Required) response. In both situation the server MUST also include in (Security Agreement Required) response. In both situation the server
the response a Security-Server header field listing its capabilities MUST also include in the response a Security-Server header field
and a Require header field with an option-tag "sec-agree" in it. All listing its capabilities and a Require header field with an option-
the Via header field entries in the response except the topmost value tag "sec-agree" in it. All the Via header field entries in the
MUST be removed. This ensures that the previous hop is the one response except the topmost value MUST be removed. This ensures that
processing the response (see example in Section 5.3). the previous hop is the one processing the response (see example in
Section 5.3).
Clients that support the extension defined in this document MAY add a Clients that support the extension defined in this document MAY add a
Supported header field with a value of "sec-agree". In addition to Supported header field with a value of "sec-agree". In addition to
this, clients SHOULD add a Security-Client header field so that they this, clients SHOULD add a Security-Client header field so that they
can save a round trip in case the server decides to challenge the can save a round trip in case the server decides to challenge the
request. request.
3.5. Security mechanism initiation 3.5. Security mechanism initiation
Once the client chooses a security mechanism from the list received Once the client chooses a security mechanism from the list received
in the Security-Server header field from the server, it initiates in the Security-Server header field from the server, it initiates
that mechanism. Different mechanisms require different initiation that mechanism. Different mechanisms require different initiation
procedures. procedures.
If TLS is chosen, the client MUST contact the server using the host If TLS is chosen, the client uses the procedures of Section 8.1.2 of
part of the topmost Route entry in the first request to the server as [1] to determine the URI to be used as an input to the DNS procedures
the destination of the connection (note that this may involve using of [7]. However, if the URI is a sip URI, it MUST treat the scheme as
standard SIP DNS procedures to locate a server). In the absence of a if it were sips, not sip. If the URI scheme is not sip, the request
Route header field, the host part of the Request-URI is used as the MUST be sent using TLS.
destination of the connection instead. If this connection attempt
fails, the security agreement procedure MUST be considered to have
failed, and MUST be terminated.
If digest-integrity is chosen, the 494 (Security Agreement Required) If digest-integrity is chosen, the 494 (Security Agreement Required)
response will contain an HTTP authentication challenge. The client response will contain an HTTP authentication challenge. The client
MUST use the qop parameter to protect a sipfrag body part [6] that MUST use the qop parameter to protect a sipfrag body part [6] that
contains the Security-Verify header field in the request. Note that contains the Security-Verify header field in the request. Note that
digest alone would not fulfill the minimum security requirements of digest alone would not fulfill the minimum security requirements of
this specification. this specification.
To use "ipsec-ike", the client attempts to establish an IKE To use "ipsec-ike", the client attempts to establish an IKE
connection to the host part of the Request-URI in the first request connection to the host part of the Request-URI in the first request
skipping to change at page 10, line 32 skipping to change at page 10, line 25
In both IPsec-based mechanisms, it is expected that appropriate In both IPsec-based mechanisms, it is expected that appropriate
policy entries for protecting SIP have been configured or will be policy entries for protecting SIP have been configured or will be
created before attempting to use the security agreement procedure, created before attempting to use the security agreement procedure,
and that SIP communications use port numbers and addresses according and that SIP communications use port numbers and addresses according
to these policy entries. It is outside the scope of this to these policy entries. It is outside the scope of this
specification to describe how this information can be made known to specification to describe how this information can be made known to
the peers, but it could be typically configured at the same time as the peers, but it could be typically configured at the same time as
the IKE credentials or manual SAs have been entered. the IKE credentials or manual SAs have been entered.
To use S/MIME, the client MUST construct its request using S/MIME. To use S/MIME, the client MUST construct its request using S/MIME.
The client may have received the serverĘs certificate in an S/MIME The client may have received the servers certificate in an S/MIME
body in the 494 (Security Agreement Required) response. body in the 494 (Security Agreement Required) response. Note that
S/MIME can only be used if the next hop SIP entity is a UA.
3.6. Duration of Security Associations 3.6. Duration of Security Associations
Once a security mechanism has been negotiated, both the server and Once a security mechanism has been negotiated, both the server and
the client need to know until when it can be used. All the mechanisms the client need to know until when it can be used. All the mechanisms
described in this document have a different way to signal the end of described in this document have a different way to signal the end of
a security association. When TLS is used, the termination of the a security association. When TLS is used, the termination of the
connection indicates that a new negotiation is needed. IKE negotiates connection indicates that a new negotiation is needed. IKE negotiates
the duration of a security association. If the credentials provided the duration of a security association. If the credentials provided
by a client using digest-integrity are not longer valid, the server by a client using digest-integrity are not longer valid, the server
skipping to change at page 12, line 32 skipping to change at page 12, line 32
| | | | | |
| | | | | |
| | | | | |
| | | | | |
Figure 2: Negotiation initiated by the client Figure 2: Negotiation initiated by the client
The UAC sends an OPTIONS request to its outbound proxy, indicating The UAC sends an OPTIONS request to its outbound proxy, indicating
that it is able to negotiate security mechanisms and that it supports that it is able to negotiate security mechanisms and that it supports
TLS and digest-integrity (Step 1 of figure 1). The outbound proxy TLS and digest-integrity (Step 1 of figure 1). The outbound proxy
challenges the UAC with its own list of security mechanisms ū IPsec challenges the UAC with its own list of security mechanisms IPsec
and TLS (Step 2 of figure 1). The only common security mechanism is and TLS (Step 2 of figure 1). The only common security mechanism is
TLS, so they establish a TLS connection between them (Step 3 of TLS, so they establish a TLS connection between them (Step 3 of
figure 1). When the connection is successfully established, the UAC figure 1). When the connection is successfully established, the UAC
sends an INVITE over the TLS connection just established (Step 4 of sends an INVITE over the TLS connection just established (Step 4 of
figure 1). This INVITE contains the serverĘs security list. The figure 1). This INVITE contains the servers security list. The
server verifies it, and since it matches its static list, it server verifies it, and since it matches its static list, it
processes the INVITE and forwards it to the next hop. processes the INVITE and forwards it to the next hop.
If this example was run without Security-Server header in Step 2, the If this example was run without Security-Server header in Step 2, the
UAC would not know what kind of security the other one supports, and UAC would not know what kind of security the other one supports, and
would be forced to error-prone trials. would be forced to error-prone trials.
More seriously, if the Security-verify was omitted in Step 4, the More seriously, if the Security-Verify was omitted in Step 4, the
whole process would be prone for MitM attacks. An attacker could whole process would be prone for MitM attacks. An attacker could
spoof "ICMP Port Unreachable" message on the trials, or remove the spoof "ICMP Port Unreachable" message on the trials, or remove the
stronger security option from the header in Step 1, therefore stronger security option from the header in Step 1, therefore
substantially reducing the security. substantially reducing the security.
(1) OPTIONS sip:proxy.example.com SIP/2.0 (1) OPTIONS sip:proxy.example.com SIP/2.0
Security-Client: tls;q=0.1 Security-Client: tls
Security-Client: digest-integrity;q=0.2 Security-Client: digest-integrity
Require: sec-agree Require: sec-agree
Proxy-Require: sec-agree
(2) SIP/2.0 494 Security Agreement Required (2) SIP/2.0 494 Security Agreement Required
Security-Server: ipsec-ike;q=0.1 Security-Server: ipsec-ike;q=0.1
Security-Server: tls;q=0.2 Security-Server: tls;q=0.2
(3) INVITE sip:proxy.example.com SIP/2.0 (3) INVITE sip:proxy.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1 Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2 Security-Verify: tls;q=0.2
Route: sip:callee@domain.com Route: sip:callee@domain.com
Require: sec-agree
Proxy-Require: sec-agree
The 200 OK response for the INVITE and the ACK are also sent over the The 200 OK response for the INVITE and the ACK are also sent over the
TLS connection. The ACK (7) will contain the same Security-Verify TLS connection. The ACK (7) will contain the same Security-Verify
header field as the INVITE (3). header field as the INVITE (3).
5.2. Server Initiated 5.2. Server Initiated
In this example of figure 3 the client sends an INVITE towards the In this example of figure 3 the client sends an INVITE towards the
callee using an outbound proxy. This INVITE does not contain any callee using an outbound proxy. This INVITE does not contain any
Require header field. Require header field.
skipping to change at page 16, line 19 skipping to change at page 16, line 23
IETF January 1999. IETF January 1999.
[4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access [4] Franks, J. et al, "HTTP Authentication: Basic and Digest Access
Authentication", RFC 2617, IETF, June 1999. Authentication", RFC 2617, IETF, June 1999.
[5] B. Ramsdell and Ed, "S/MIME version 3 message specification", RFC [5] B. Ramsdell and Ed, "S/MIME version 3 message specification", RFC
2633, IETF, June 1999. 2633, IETF, June 1999.
[6] R. Sparks, "Internet Media Type message/sipfrag", Work in [6] R. Sparks, "Internet Media Type message/sipfrag", Work in
Progress, draft-sparks-sip-mimetypes-03.txt, IETF, April 2002. Progress, draft-sparks-sip-mimetypes-03.txt, IETF, April 2002.
[7] H. Schulzrinne and J. Rosenberg, "SIP: Locating SIP servers",
Work in Progress, draft-ietf-sip-srv-06.txt, IETF, February 2002.
10. Non-Normative References 10. Non-Normative References
[7] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A. [7] M. Garcia, D. Mills, G. Bajko, G. Mayer, F. Derome, H. Shieh, A.
Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP", Allen, S. Chotai, K. Drage, J. Bharatia, "3GPP requirements on SIP",
draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF, draft-garcia-sipping-3gpp-reqs-00.txt. Work In Progress, IETF,
October 2001. October 2001.
11. Authors's Addresses 11. Authors's Addresses
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/