draft-ietf-sip-sec-agree-03.txt   draft-ietf-sip-sec-agree-04.txt 
SIP Working Group Jari Arkko SIP Working Group Jari Arkko
INTERNET-DRAFT Vesa Torvinen INTERNET-DRAFT Vesa Torvinen
<draft-ietf-sip-sec-agree-03.txt> Gonzalo Camarillo <draft-ietf-sip-sec-agree-04.txt> Gonzalo Camarillo
June 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
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. Authorss 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 algorithm development typically uncovers The reason for this is that algorithm development typically uncovers
problems in old algorithms and sometimes even produces new problems. problems in old algorithms and sometimes even produces new problems.
Furthermore, different mechanisms and algorithms are suitable for Furthermore, different mechanisms and algorithms are suitable 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.
skipping to change at page 4, line 44 skipping to change at page 4, line 44
(a) It allows the selection of security mechanisms, such as lower (a) It allows the selection of security mechanisms, such as lower
layer security protocols or HTTP digest. It also allows the selection layer security protocols or HTTP digest. It also allows the selection
of individual algorithms and parameters when the security functions of individual algorithms and parameters when the security functions
are integrated in SIP (such as in the case of HTTP authentication). are integrated in SIP (such as in the case of HTTP authentication).
(b) It allows next-hop security negotiation. (b) It allows next-hop security negotiation.
(c) It is secure (i.e., prevents the bidding down attack.) (c) It is secure (i.e., prevents the bidding down attack.)
(d) It is capable of running without additional roundtrips. This is (d) It is capable of running without additional roundtrips. This is
important in the cellular environment, where an additional roundtrip important in the cellular environment, where link delays are
could delay the call set up for 1000-1500 ms. relatively high, and an additional roundtrip could delay the call
set up further.
(e) It does not introduce any additional state to servers and (e) It does not introduce any additional state to servers and
proxies. proxies.
Currently, SIP does not have any mechanism which fulfills all the Currently, SIP does not have any mechanism which fulfills all the
requirements above. The basic SIP features such as OPTIONS and requirements above. The basic SIP features such as OPTIONS and
Require, Supported headers are capable of informing peers about Require, Supported headers are capable of informing peers about
various capabilities including security mechanisms. However, the various capabilities including security mechanisms. However, the
straight forward use of these features can not guarantee a secured straight forward use of these features can not guarantee a secured
agreement. HTTP Digest algorithm lists [4] are not secure for picking agreement. HTTP Digest algorithm lists [4] are not secure for picking
skipping to change at page 7, line 15 skipping to change at page 7, line 15
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 five 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 MIME body (e.g., "message/sip") that
Security-Verify header field. contains the 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.
- "smime" for S/MIME [5]. - "smime" for S/MIME [5].
Preference: The "q" value indicates a relative preference for the Preference: The "q" value indicates a relative preference for the
particular mechanism. The higher the value the more preferred the particular mechanism. The higher the value the more preferred the
mechanism is. mechanism is. All the security mechanisms MUST have different "q"
values. It is an error to provide two mechanisms with the same "q"
value.
Algorithm: An optional algorithm field for those security Algorithm: An optional algorithm field for those security
mechanisms which are not self-describing or which are vulnerable mechanisms which are not self-describing or which are vulnerable
for bidding-down attacks (e.g., HTTP Digest). In the case of HTTP for bidding-down attacks (e.g., HTTP Digest). In the case of HTTP
Digest, the same rules apply as defined in RFC 2617 [4] for the Digest, the same rules apply as defined in RFC 2617 [4] for the
"algorithm" field in HTTP Digest. "algorithm" field in HTTP Digest.
3.4. Protocol Operation 3.4. Protocol Operation
This section deals with the protocol details involved in the This section deals with the protocol details involved in the
skipping to change at page 7, line 56 skipping to change at page 7, line 58
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 add both a add preference parameters to this list. The client MUST add both a
Require and Proxy-Require header field with the value "sec-agree" to Require and Proxy-Require header field with the value "sec-agree" to
its request. 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 an HTTP integrity is the chosen mechanism, the server includes an HTTP
authentication challenge 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.
supported by the client do not need any further information to be
established (e.g., TLS) the client MAY choose not to include the
Security-Client header field in its request.
A server receiving an unprotected request that contains a Require or A server receiving an unprotected request that contains a Require or
Proxy-Require header field with the value "sec-agree" MUST challenge Proxy-Require header field with the value "sec-agree" MUST challenge
the client with a 494 (Security Agreement Required) response. The the client with a 494 (Security Agreement Required) response. The
server MUST add a Security-Server header field to this response server MUST add a Security-Server header field to this response
listing the security mechanisms that the server supports. The server listing the security mechanisms that the server supports. The server
MUST add its list to the response even if there are no common MUST add its list to the response even if there are no common
security mechanisms in the client's and server's lists. The servers security mechanisms in the client's and server's lists. The servers
list MUST NOT depend on the 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 highest "q" value. Therefore, the common security mechanism with the highest "q" value. Therefore, the
server MUST add the necessary information so that the client can server MUST add the necessary information so that the client can
initiate that mechanism (e.g., a WWW-Authenticate header field for initiate that mechanism (e.g., a WWW-Authenticate header 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 servers list field, it MUST choose the security mechanism in the server∆s 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 to that server All the subsequent SIP requests sent by the client to that server
SHOULD make use of the security mechanism initiated in the previous SHOULD make use of the security mechanism initiated in the previous
step. These requests MUST contain a Security-Verify header field step. These requests MUST contain a Security-Verify header field that
that mirrors the servers list received previously in the Security- mirrors the server∆s list received previously in the Security-Server
Server header field. These requests MUST also have both a Require header field. These requests MUST also have both a Require and Proxy-
and Proxy-Require header fields with the value "sec-agree". Require header fields with the value "sec-agree".
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.
processing a particular request if, and only if, the list was not
modified. If modification of the list is detected, the server MUST Note that, following the standard SIP header field comparison rules
challenge the client with a 494 (Security Agreement Required). This defined in [1], both lists have to contain the same security
response MUST include a challenge with server's unmodified list of mechanisms in the same order to be considered equivalent. In
supported security mechanisms. If the list was not modified, and the addition, for each particular security mechanism, its parameters in
server is a proxy, it MUST remove the "sec-agree" value from both the both lists need to have the same values.
Require and Proxy-Require header fields, and then remove the header
fields if no values remain. The server can proceed processing a particular request if, and only
if, the list was not modified. If modification of the list is
detected, the server MUST challenge the client with a 494 (Security
Agreement Required). This response MUST include a challenge with
server's unmodified list of 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 SHOULD 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 unprotected requests regardless of the negotiation MUST challenge unprotected requests regardless of the
presence or the absence of any Require, Proxy-Require or Supported presence or the absence of any Require, Proxy-Require or Supported
skipping to change at page 9, line 50 skipping to change at page 9, line 56
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 uses the procedures of Section 8.1.2 of If TLS is chosen, the client uses the procedures of Section 8.1.2 of
[1] to determine the URI to be used as an input to the DNS procedures [1] to determine the URI to be used as an input to the DNS procedures
of [7]. However, if the URI is a sip URI, it MUST treat the scheme as of [6]. However, if the URI is a sip URI, it MUST treat the scheme as
if it were sips, not sip. If the URI scheme is not sip, the request if it were sips, not sip. If the URI scheme is not sip, the request
MUST be sent using TLS. MUST be sent using TLS.
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 Digest authentication challenge. The
MUST use the qop parameter to protect a sipfrag body part [6] that client MUST use the qop parameter to protect a MIME body (e.g.,
contains the Security-Verify header field in the request. Note that "message/sip") that contains the Security-Verify header field in the
digest alone would not fulfill the minimum security requirements of request. Currently, only the qop value ∆auth-int∆ is able to provide
this specification. required protection. Note that digest alone without placing Security-
Verify header in the body would not fulfill the minimum security
requirements of 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
to the server. If the IKE connection attempt fails, the agreement to the server. If the IKE connection attempt fails, the agreement
procedure MUST be considered to have failed, and MUST be terminated. procedure MUST be considered to have failed, and MUST be terminated.
Note that "ipsec-man" will only work if the communicating SIP Note that "ipsec-man" will only work if the communicating SIP
entities know which keys and other parameters to use. It is outside entities know which keys and other parameters to use. It is outside
the scope of this specification to describe how this information can the scope of this specification to describe how this information can
be made known to the peers. be made known to the peers.
skipping to change at page 10, line 25 skipping to change at page 10, line 34
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 servers 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. Note that 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. 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
skipping to change at page 11, line 43 skipping to change at page 11, line 48
method: method:
- o: The header field is optional. - o: The header field is optional.
4. Backwards Compatibility 4. Backwards Compatibility
A server that, by local policy, decides to use the negotiation A server that, by local policy, decides to use the negotiation
mechanism defined in this document, will not accept requests from mechanism defined in this document, will not accept requests from
clients that do not support this extension. This obviously breaks clients that do not support this extension. This obviously breaks
interoperability with every plain SIP client. Therefore, this interoperability with every plain SIP client. Therefore, this
extension should only be used in closed environments where it is extension should be used in environments where it is somehow ensured
ensured somehow that every client implements this extension. that every client implements this extension. This extension may also
be used in environments where insecure communication is not
acceptable if the option of not being able to communicate is also
accepted.
5. Examples 5. Examples
The following examples illustrate the use of the mechanism defined The following examples illustrate the use of the mechanism defined
above. above.
5.1. Client Initiated 5.1. Client Initiated
A UA negotiates the security mechanism to be used with its outbound A UA negotiates the security mechanism to be used with its outbound
proxy without knowing beforehand which mechanisms the proxy supports. proxy without knowing beforehand which mechanisms the proxy supports.
skipping to change at page 12, line 32 skipping to change at page 12, line 42
| | | | | |
| | | | | |
| | | | | |
| | | | | |
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 servers 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
skipping to change at page 15, line 32 skipping to change at page 15, line 42
client would end up choosing different security mechanisms in Step 3 client would end up choosing different security mechanisms in Step 3
or 4 of figure 1. Since they would be unable to communicate to each or 4 of figure 1. Since they would be unable to communicate to each
other, this would be detected as a potential attack. The client would other, this would be detected as a potential attack. The client would
either retry or give up in this situation. either retry or give up in this situation.
- If the modification did not affect the server's choice, there's no - If the modification did not affect the server's choice, there's no
effect. effect.
All clients that implement this specification MUST select HTTP Digest All clients that implement this specification MUST select HTTP Digest
with integrity, TLS, IPsec, or any stronger method for the protection with integrity, TLS, IPsec, or any stronger method for the protection
of the second request. If HTTP Digest is used alone, the security of the second request.
agreement headers MUST be protected. This can be done with HTTP
Digest if combined with MIME/SIP tunneling, for example.
7. IANA Considerations 7. IANA Considerations
This specification defines three new header fields, namely Security- This specification defines three new header fields, namely Security-
Client, Security-Server and Security-Verify that should be included Client, Security-Server and Security-Verify that should be included
in the registry for SIP header fields maintained by IANA. in the registry for SIP header fields maintained by IANA.
This specification defines the 'sec-agree' SIP option tag which This specification defines the 'sec-agree' SIP option tag which
should be registered in IANA. should be registered in IANA.
This specification also defines a new SIP status code, 494 (Security This specification also defines a new SIP status code, 494 (Security
Agreement Failed), which should be registered in IANA. Agreement Failed), which should be registered in IANA.
8. Acknowledgments 8. Acknowledgments
The authors wish to thank Lee Valerius, Allison Mankin, Rolf Blom,
The authors wish to thank Lee Valerius, Rolf Blom, James Undery, James Undery, Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister
Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David Boman, David Castellanos-Zamora, Aki Niemi, Miguel Garcia, Valtteri
Castellanos-Zamora, Aki Niemi, Miguel Garcia, Valtteri Niemi, Martin Niemi, Martin Euchner, Eric Rescorla and members of the 3GPP SA3
Euchner, Eric Rescorla and members of the 3GPP SA3 group for group for interesting discussions in this problem space.
interesting discussions in this problem space.
9. Normative References 9. Normative References
[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation Peterson, R. Sparks, M. Handley, E. Schooler "SIP: Session Initiation
Protocol", Work in Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF, Protocol", Work in Progress, draft-ietf-sip-rfc2543bis-09.txt, IETF,
February 2002. February 2002.
[2] S. Kent, R. Atkinson, "Security Architecture for the Internet [2] S. Kent, R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 2401, IETF, November 1998. Protocol", RFC 2401, IETF, November 1998.
[3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, [3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
IETF January 1999. IETF January 1999.
skipping to change at page 16, line 21 skipping to change at page 16, line 29
[3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, [3] T. Dierks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246,
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] H. Schulzrinne and J. Rosenberg, "SIP: Locating SIP servers",
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. 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/