Internet DRAFT - draft-cao-sip-response-auth
draft-cao-sip-response-auth
SIP F. Cao, Ed.
Internet-Draft Cisco Systems
Expires: July 14, 2006 January 10, 2006
Response Authentication in Session Initiation Protocol
draft-cao-sip-response-auth-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This draft describes some extensions for enhancing SIP response
authentication. In the real-world SIP deployment, TLS may be not
available on some hops. Due to the lack of other response
authentication mechanisms in SIP, several kinds of security attacks
could be conducted on those hops through SIP response. This draft
suggests some approaches for complementary enhancement on SIP
response authentication. With the new per-hop response
authentication proposed in this draft, the security gaps on the hops
without TLS can be bridged.
Cao Expires July 14, 2006 [Page 1]
Internet-Draft Response Authentication January 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Per-hop Authentication Enhancement . . . . . . . . . . . . 4
3.2. Complementariness with TLS . . . . . . . . . . . . . . . . 6
4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 7
5. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . . 7
6. Syntax and Examples . . . . . . . . . . . . . . . . . . . . . 9
6.1. Header Syntax . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. Header Field Names . . . . . . . . . . . . . . . . . . . . 11
8.2. 432 'Failed Response Authorization Response Code . . . . . 12
9. Contributors' Address . . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informational References . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Cao Expires July 14, 2006 [Page 2]
Internet-Draft Response Authentication January 2006
1. Introduction
This document provides complementary enhancements for addressing
security concerns on response authentication in Session Initiation
Protocol (SIP [1]). [3] described the current limitations of some
security mechanisms provided in SIP ([1]). One of them is about the
difficulties of deploying TLS over each hop of all SIP dialogs.
Because SIPs is the only mechanism for response authentication, the
lack of TLS on some hops imposes some threats of malicious attacks
through SIP response to disturb the desired service. In particular,
there is no strict per-hop authentication for the received SIP
response when TLS is absent. This may enable the attackers to spoof
SIP response and easily disturb the SIP service.
For example, if a rogue proxy can sniff the SIP requests from Proxy-1
to Proxy-2 without TLS, it can spoof the addresses and URIs of
Proxy-2 and fake the response back to Proxy-1 along with its own
rogue domain authentication service info, right before Proxy-2's
response. Proxy-1 and the initiators of SIP requests will be
deceived by the responses from the rogue proxy. This allows the
rogue proxy to conduct many attacks, such as redirecting the requests
to attack other targets for DoS attacks, redirecting the requests to
rogue users for information disclosure, and terminating the requests
for turning down SIP services.
This draft suggests some approaches for complementary enhancement on
per-hop response authentication inside SIP, which can bridge the gap
when TLS is absent on those hops.
2. Terminology
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 [2].
Domain-based Authentication Service (DAS): Authentication service is
provided for each domain through its certificate and the domain
private key. Proxies may act as the role of authenticate service
with the domain private keys.
Authenticated Identity Body (AIB): some SIP headers are replicated
into a S/MIME body of the same message and are signed with a digital
signature (See [5])
Chain of SIP Response Trust (CSRT): All the hops in the path of SIP
response provides the authentication mechanisms so that the chain of
the trust on the response message can be built from end to end.
Cao Expires July 14, 2006 [Page 3]
Internet-Draft Response Authentication January 2006
Certificate: An X.509v3 [15] style certificate containing a public
key and a list of identities in the SubjectAltName that are bound to
this key. The certificates discussed in this document are generally
self signed and use the mechanisms in the SIP Identity specification
to vouch for their validity.
3. Overview
This section gives an overview of the requirements and the mechanisms
for addressing the security concerns of SIP response. In particular,
some security mechanisms on per-hop authentication are proposed to
enhance the response authentication and prevent the malicious attacks
through SIP response.
The following requirements should be addressed:
o The new response authentication must be complementary with SIPs,
i.e. it should work when TLS is absent.
o Response authentication between neighboring domains or nodes can
be enhanced
o The mechanism should be simple
o CSRT can be built when either this mechanism is applied on all the
hops, or this mechanism is applied on some of the hops and TLS is
used for the rest.
3.1. Per-hop Authentication Enhancement
One simple authentication mechanism is proposed in this document for
satisfying all these requirements. This mechanism is to generate a
digest challenge for the next-hop node (or domain), and the
authorization to this challenge should be delayed, and piggybacked
with the next normal SIP response from the next-hop downstream node
(or domain). After the digest is verified, the trust can be enhanced
for the SIP response from the next-hop node (or domain).
There are several security mechanisms covered in this document to
support this mechanism:
O DAS
O shared secret key with the next-hop downstream node
O public key of the next-hop downstream node
The figure below shows a basic call to illustrate some scenarios.
The call is initiated by alice@atlanta.com to bob@biloxy.com. The
assumption is that Alice and Atlanta have a shared secret, Biloxi has
a public certificate, and Bob and Biloxi have a shared secret.
Cao Expires July 14, 2006 [Page 4]
Internet-Draft Response Authentication January 2006
Alice Atlanta Biloxi Bob
| INV+E(n1) | | |
|--------F1--------->| SUBECRIBE | |
| +------F2----------->| |
| | NOTIFY(cert) | |
| |<-------F3----------+ |
| | | |
| | INV+E(n2) | |
| +-------F4---------->+ INV+E(n3) |
| | +--------F5--------->|
| | | |
| | | 200+hash3(n3, .) |
| | 200+hash2(n2, .) |<-------F6----------+
| 200+hash1(n1, .) |<------F7-----------+ |
|<--------F8---------+ | |
| | | |
| | | BYE+ hash3(n3, .) |
| | BYE+ hash2(n2, .) |<-------F9----------+
| BYE+hash1(n1, .) |<-------F10---------+ |
|<--------F11--------+ | |
In message F1, Alice sends a normal invite but includes an
Authentication header that include the encrypted nonce, n1, that is
encrypted for the next hop which is Atlanta.
In message F4, Atlanta will forward the invite to Bilboxi with a
nonce that is encrypted for Biloxi however, to do the encryption,
Atlanta may have to use the Sub/NOT if message F2 and F3 to fetch
Biloxi's public key so that it can encrypt the nonce. Note F2 and F3
might be done for previous SIP dialogs from Atlanta.com to
Bilboxi.com.
In message F5, biloxi sends the INVITE with a nonce encrypted for bob
using the shared secret between Biloxi and Bob.
In message F6, Bob inserts a header that says the responder in
bob@biloxi.com and computes a hash over key parts of the message
including the responder header field value. The hash includes the
decrypted content of the nonce that Biloxi sent to Bob. When biloxi
receives this message it can verify that it the hash is correct and
that it believes the responder information.
Biloxi computes a new hash over the message using the nonce2 and
sends F7 using this hash.
Later in message F9, F10, and F11, the hash can be computed using the
previous nonces. The proxies do not need to be session state-full as
long as the nonce are constructed in a way such that the proxy can
Cao Expires July 14, 2006 [Page 5]
Internet-Draft Response Authentication January 2006
later check that they are only being used in the dialog for which
they were originally constructed.
If the verification in Biloxy or Atlanta indicates the unmatched SIP
response authorization, the proxy may replace the response code with
432 Failed Response Authorization for announcing the failure of the
next-hop response authentication.
3.2. Complementariness with TLS
This proposed per-hop authentication mechanism is complementary with
TLS in SIP deployment. If TLS is available on some hops, this
mechanism can be applied to the other hops where TLS is absent. The
below example demonstrate how they work together.
Assume that TLS is available between Alice and Atlanta AND between
Biloxi and Bob. The hop between Atlanta and Biloxi doesn't support
TLS.
Alice Atlanta Biloxi Bob
| INV over TLS | | |
|--------F1--------->| SUBECRIBE | |
| +------F2----------->| |
| | NOTIFY(cert) | |
| |<-------F3----------+ |
| | | |
| | INV+E(n) | |
| +-------F4---------->+ INV over TLS |
| | +--------F5--------->|
| | | |
| | | 200 over TLS |
| | 200+hash(n, .) |<-------F6----------+
| 200 over TLS |<------F7-----------+ |
|<--------F8---------+ | |
| | | |
| | | BYE over TLS |
| | BYE+ hash(n, .) |<-------F9----------+
| BYE over TLS |<-------F10---------+ |
|<--------F11--------+ | |
TLS can be applied to create the security tunnels for two hops, i.e.
between Alice and Atlanta AND between Biloxy and Bob. Similar to the
above example, the hop between Atlanta and Biloxy can use the
proposed response authentication mechanism to enhace response
security.
All the hops in this example provide the security mechanisms to check
Cao Expires July 14, 2006 [Page 6]
Internet-Draft Response Authentication January 2006
that
o the received response message from the desired upstream node
o the integrity of this received message can be verified.
Therefore, CSRT can be built by combining this extension and TLS from
end to end. The rogue proxies can be prevented from attacking SIP
services through SIP responses.
4. User Agent Behavior
The extensions in this document require new processing and parsing
for both UAS and UAC. Their behaviors are described in this section.
When UAC sends the SIP request, UAC can generate nonce before
assembling the new authentication header field.
For DAS, UAC must obtain the certificate of DAS for the next-hop
node. The nonce is encrypted and inserted into Response-
Authentication. For the shared key with the next-hop node, the nonce
is encrypted by the shared key to ensure its privacy.
When it receives the SIP response for the corresponding SIP request,
UAC should verify the authorization from the next hop. It generates
its own digest through its saved nonce in decrypted format, plus some
header fields and the message body in response message. This digest
is compared with the one in SIP response message from the next hop.
If there is a mismatch, it should treat it as an error and may
terminate the dialog with the failure reason.
Even if UAC may receive the response code 432 Failed Response
Authorization, UAC should finish the steps for verifying the received
response from the upstream node. If Response-Authorization carries
the correct digest, this response code can be trusted. The proper
follow-up operations should take place, such as terminating the
dialog with the failure reason. If not, the received response may be
suspicious. UAC should analyze the reason before taking any steps
for further operations.
As a recipient of the SIP request with Response-Authentication, UAS
should generate the digest for SIP response with respect to the
specified method. The digest is inserted into UAS's next SIP
response message back to the downstream node.
5. Proxy Server Behavior
The extensions in this document require new processing and parsing
Cao Expires July 14, 2006 [Page 7]
Internet-Draft Response Authentication January 2006
for proxy servers. Their behaviors are described in this section.
After receiving the SIP request with Response-Authentication, the
proxy server must save the nonce received from the upstream node.
When the proxy server relays the SIP request, it is recommended that
the proxy server carry its own Response-Authentication inside the
request. The nonce should be encrypted in the specified methods.
Before relaying the SIP request to the next-hop downstream node, the
proxy server should generate its own nonce, encrypt the nonce in the
specified method, and overwrite Response-Authentication header field
inside the SIP request.
For DAS, the nonce is encrypted by the certificate of the next-hop
domain and inserted into Response-Authentication. For the shared key
with the downstream node, the nonce is encrypted by the shared key to
ensure its privacy.
Note the nonce received from the previous hop should not be forwarded
to the next hop for reducing the risk of disclosure.
If the SIP response is received, the proxy server must finish two
steps. First, it has to verify the authorization from the next-hop
downstream node. It generates its own digest through its saved nonce
in decrypted format, plus some header fields and the message body in
response message. This digest is compared with the one in SIP
response message from the next hop.
Second, it has to generate another digest from the decrypted nonce
received from the upstream node, some header fields, and the message
body for SIP response. This digest is inserted into its relayed SIP
response to the upstream node.
Note that the proxy server has to obtain the certificate, the public
key or the shared key with the downstream node (or domain) before
Response-Authentication is assembled. [4] is recommended to retrieve
the certificate through SUBSCRIBE and NOTIFY in the enhanced
certificate management.
When it receives the SIP response for the corresponding SIP request,
the proxy server should compare the digest inside Response-
Authorization with its generated one. If there is a mismatch, the
proxy server should analyze this suspicious response. The proper
follow-up operations should take place, such as replacing the
response code with 432 Failed Response Authorization. Note that the
saved digest for the corresponding SIP request should be piggybacked
into its response.
Cao Expires July 14, 2006 [Page 8]
Internet-Draft Response Authentication January 2006
Even if it receives the response code 432 Failed Response-
Authorization, the proxy server should finish the steps for verifying
the validness of this received response from the downstream node.
6. Syntax and Examples
6.1. Header Syntax
Two new SIP headers are introduced in this document. Response-
Authorization appear in the response. Response-Authentication is
eligible in the request.
Response-Authentication = "Response-Authentication"
HCOLON resp-authen-param
resp-authen-param = auth-method-param * (SEMI nonce-param)
auth-method-param = "method" EQUAL auth-method-enum
* (SEMI alg-param)
auth-method-eum = "DAS" / "SharedKey" / "PublicKey"
alg-param = "alg" EQUAL token
nonce-param = "nonce" EQUAL "nonce-value"
Response-Authorization = "digest" EQUAL resp-author-digest
Resp-author-digest = LDQUOT 32LHEX RDQUOT
For the digest generated in Response-Authorization, the digest-string
includes
o status code of the response
o addr-spec in To
o addr-spec in From
o addr-spec of claimer field in Responder
o method and nonce in Response-Authentication
o callid from Call-ID
o the digits and the method from CSeq
o Date field
o body content of the message with the bits exactly as they are in
the message (in the ABNF for SIP, the message body).
In summary, digest-string for Identity header in the SIP response is
digest-string = status-code ":"
addr-spec ":" addr-spec ":" addr-spec ":"
auth-method-enum nonce-value ":"
callid ":" 1*DIGIT SP method ":" SIP-Date ":"
message-body
Cao Expires July 14, 2006 [Page 9]
Internet-Draft Response Authentication January 2006
The decrypted nonce plus this digest-string is hashed and signed with
the key based on the specified method. The mandatory procedure is
sha1WithRSAEncryption as described in RFC 3371 with base64 encoding
as described in RFC 3548.
One simple example is given below to show how these new header fields
are used when Alice sends an INVITE to bob.
INVITE sip:bob@biloxi.com SIP/2.0
Max-Forwards: 70
To: Bob <sip:bob@biloxi.com>
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.com>
Response-Authentication: method=DAS; alg=rsa-sha1;
nonce=rqupqurcnvajfaqruiopqurewfval4139814kfaj134
vnnfaq2kqklpijmhyhhbvfdw43ikfr3535wtetwetw
Content-Type: application/sdp
Content-Length: 142
The response from Bob should provide Response-Authorization to answer
the challenge from Alice.
SIP/2.0 200 OK
To: Bob <sip:bob@biloxi.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.com
CSeq: 314159 INVITE
Contact: <sip:bob@192.0.2.4>
Response-Authorization:
digest=lqkduncbhyr467u8932udjbfsgdiwoopxjnxdg
wuhfduiiqriqopqr3990mcnvbgdqewzsjdormgbktgui
Content-Type: application/sdp
Content-Length: 131
7. Security Considerations
This document provides some complementary security enhancements on
SIP response authentication, when TSL is absent on some hops.
For example, if a rogue proxy can sniff the SIP requests from Proxy-1
to Proxy-2 without TLS, it can spoof the addresses and URIs of
Proxy-2 and send the response back to Proxy-1 along with its own
rogue domain authentication service info, before Proxy-2's response.
Cao Expires July 14, 2006 [Page 10]
Internet-Draft Response Authentication January 2006
Without the proposed mechanisms, Proxy-1 and the initiator of SIP
requests will be deceived by the response from the rogue proxy. This
allows the rogue proxy to conduct attacks, such as redirecting the
requests to attack other targets for DoS attacks, redirecting the
requests to rogue users for information disclosure, and terminating
the dialogs for turning down SIP services.
With the mechanisms introduced in the document, Proxy-1 can detect
the faked responses from the rogue proxy, by checking the digest in
Response-Authorization. These faked responses are dropped
immediately by Proxy-1 without any impact on the callers of SIP
requests.
All the hops with security concerns should apply these mechanisms for
enhancing authentication for SIP response, when TLS is absent on
those hops. CSRT should be created by combining TLS and this per-hop
response authentication. If not, man-in-the-middle attacks may be
possible again through SIP response, just as before.
There are some open questions in the future work for enforcing these
mechanisms and creating CSRT per SIP dialog. One is how to indicate
CSRT is required by the originator UAC. Another is how to notify UAC
if CSRT is fully formed or where CRST is missing if applicable.
Another security concern is about nonce used this enhancement. Nonce
should be random enough for a long period of time. Nonce during a
long SIP session should be refreshed periodically to prevent it from
being compromised.
This document is also based on some existing results for domain-based
authentication and certificate management (See [3, 4]). Therefore,
these mechanisms may be affected by the secure concerns for these
functional components.
8. IANA Considerations
This document requests changes to the header and response-code sub-
registries of the SIP parameters IANA registry.
8.1. Header Field Names
This document specifies two new SIP headers: Response-Authentication
and Response-Authorization. Their syntax is given in Section 6.
These headers are defined by the following information, which is to
be added to the header sub-registry under
http://www.iana.org/assignments/sip-parameters.
Cao Expires July 14, 2006 [Page 11]
Internet-Draft Response Authentication January 2006
Header Name: Response-Authentication
Compact Form: (none)
Header Name: Response-Authorization
Compact Form: (none)
8.2. 432 'Failed Response Authorization Response Code
This document registers a new SIP response code which is described in
Section 3.2. It is used when the expected Response-Authorization is
missing or doesn't carry the correct digest. This response code is
defined by the following information, which is to be added to the
method and response-code sub-registry under
http://www.iana.org/assignments/sip-parameters.
Response Code Number: 432
Default Reason Phrase: Bad Identity-Info
9. Contributors' Address
Cullen contributed to the development of this document in every
aspect. He helped to define the scope and the essential goals in the
beginning. He provided substantial input and rewrote some parts of
this documents.
Cullen Jennings
Cisco Systems
170 West Tasman Dr
MS: SJC-21/3
Phone: +1 408 421 9990
EMail: fluffy@cisco.com
10. Acknowledgments
The editor and the contributors would like to acknowledge the
constructive feedback and input provided by John Elwell, Jon
Peterson, Jonathan Rosenberg, Peter Thermos, Dean Willis, and Rohan
Mahy in emails and discussions in IETF meetings.
11. References
Cao Expires July 14, 2006 [Page 12]
Internet-Draft Response Authentication January 2006
11.1. Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-06 (work in progress), October 2005.
[4] Jennings, C. and J. Peterson, "Certificate Management Service
for The Session Initiation Protocol (SIP)",
draft-ietf-sipping-certs-02 (work in progress), July 2005.
[5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated
Identity Body (AIB) Format", RFC 3893, September 2004.
[6] Metz, C., "OTP Extended Responses", RFC 2243, November 1997.
11.2. Informational References
[7] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[8] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[9] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
Cao Expires July 14, 2006 [Page 13]
Internet-Draft Response Authentication January 2006
Author's Address
Feng Cao (editor)
Cisco Systems
170 West Tasman Drive
MS: SJC-21/2
San Jose, CA 95134
USA
Email: fcao@cisco.com
Cao Expires July 14, 2006 [Page 14]
Internet-Draft Response Authentication January 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Cao Expires July 14, 2006 [Page 15]
