Internet DRAFT - draft-cao-sip-response-identity
draft-cao-sip-response-identity
SIP F. Cao, Ed.
Internet-Draft Cisco Systems
Expires: July 14, 2006 January 10, 2006
Response Identity in Session Initiation Protocol
draft-cao-sip-response-identity-00
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
The mechanism for securely providing responder's identity in response
message is missing in the current Session Initiation Protocol. Due
to different call scenarios, the exact response identity is hard to
guess through the existing response message. This draft describes
some extensions for providing SIP response identity and two security
mechanisms for verifying the integrity of response identity. It does
so by defining new header fields as well as one new response code.
Furthermore, the issue of how to require the presence of response
identity in one SIP dialog is also discussed with one solution.
Cao Expires July 14, 2006 [Page 1]
Internet-Draft Response Identity January 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Response Identity with DAS . . . . . . . . . . . . . . . . 4
3.2. Response Identity with AIB . . . . . . . . . . . . . . . . 6
3.3. Enforcement on Response Identity . . . . . . . . . . . . . 7
4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 7
4.1. DAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. AIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Enforcement on Response Identity . . . . . . . . . . . . . 9
5. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . . 9
5.1. DAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. AIB . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.3. Enforcement on Response Identity . . . . . . . . . . . . . 10
6. Syntax and Examples . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. Header Field Names . . . . . . . . . . . . . . . . . . . . 14
8.2. 431 'Failed Responder Identity Response Code . . . . . . . 15
8.3. One new option tag: responder-id . . . . . . . . . . . . . 15
8.4. One new warn-code: 380 . . . . . . . . . . . . . . . . . . 15
9. Contributors' Address . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informational References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Cao Expires July 14, 2006 [Page 2]
Internet-Draft Response Identity January 2006
1. Introduction
This document provides enhancements for addressing security concerns
on response messages in Session Initiation Protocol (SIP [1]).
Because the mechanism for securely providing responder's identity
inside response message is missing in the current SIP, some holes are
left open for several kinds of malicious attacks through SIP
response.
For example, if a rogue proxy can sniff the SIP requests from Proxy-1
to Proxy-2, it can spoof the addresses and URIs of Proxy-2 and send
the response back to Proxy-1, before the expected response from
Proxy-2. Without any security mechanism to verify response identity,
Proxy-1 and the initiator of SIP requests will be deceived by the
faking response from the rogue proxy. This allows the rogue proxy to
conduct malicious 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.
The identity of SIP response is more complicated than that of SIP
request. First, SIP response may be originated by any intermediate
SIP proxies instead of the desired SIP UAS. Because SIP UAC may send
requests to SIP UAS without any previous association, these
intermediate SIP proxies may not be known or verified by SIP UAC
before hand. Second, the presence of the exact responder for SIP
response is not clearly defined, which is different from From field
for SIP request. In general, it is obvious that To field cannot be
used as described above. Due to backward compatibility, some other
existing header fields, such as Contact and Reply-to, have their own
meanings and can not be relied on in all the scenarios.
In this document, some extensions are demonstrated to insert the
identity of SIP response in response message. Two security
mechanisms are outlined to verify the integrity of response identity.
One is Domain-based Authentication Service (DAS), the other
Authenticated Identity Body (AIB). Furthermore, the issue of how to
require the presence of response identity in one SIP dialog is also
discussed with one solution.
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
Cao Expires July 14, 2006 [Page 3]
Internet-Draft Response Identity January 2006
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])
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 extensions are introduced to announce the exact response identiy
along with the specified security mechanism for verifying it. Both
DAS and AIB are analyzed as the security mechanisms. One solution is
demonstrated on how to require the presence of response identity in
one SIP dialog.
3.1. Response Identity with DAS
SIP response identify is crucial for proceeding the dialog and
providing the desired services. In the current SIP, UAC might guess
the identity of the responder of the received SIP response message
through the response code and some header fields. But there is no
defined mechanism for clarifying that identify and verifying it.
The following requirements should be addressed:
o The identities of both UAs and proxies should be covered
o The mechanism should be backward compatible.
o The identity should be clearly specified for the responder of the
SIP response message.
o The integrity of SIP response should be covered along with the
responder identify
The following example is used in this document to demonstrate the
mechanisms in many sections:
Cao Expires July 14, 2006 [Page 4]
Internet-Draft Response Identity January 2006
UAC <------> Proxy-1 <------> Proxy-2 <-----> UAS
UAC: alice@source.com
Proxy-1: px1@source.com
Proxy-2: px2@destination.com
UAS: bob@destination.com
Alice sends an INVITE request to Bob. Proxy-2 receives the request
and informs Alice of the response code 183 Session Progress, along
with two new header fields called Responder and Responder-Info:
Responder: claimer=px2@destination.com;
verify-method=DAS;
Responder-Info: https://www.destination.com/certs;alg=rsa-sha1
Identify: akfjiqiowrgnavnvnnfa2o3fafanfkfjakfjalkf203urjafskjfaf
Jprqiyupirequqpiruskfka3i91emgiow20mjaf
[Identity needs to be recalculated]
The field of claimer specifies the exact identity of the responder.
The field of verify-method indicates the secure mechanism for
verifying the identify of the responder.
There are several security methods covered in this document to
support this mechanism:
o DAS
o AIB (See the next section)
For DAS, the mechanism is similar to [3]. Some headers, including
the new header field introduced in this document, and the body of the
message are used to compute a hash. This hash is signed with
certificate for Proxy-2's domain (destination.com), and the final
output is inserted into the header field Identity introduced by [3].
One new header field, Responder, is introduced to specify the exact
responder and related authentication method. Responder-Info is
another new header field introduced to to indicate where to acquire
the certificate for the claimer of the responder.
For DAS, the proxy servers can obtain the certificate of DAS for the
responder through Responder-Info. The digest in Identity can be
verified for the responder identity. If there is a mismatch, the
proxy server may replace the response code with the new defined
reponse code, 431 Failed Responder Identity, for indicating the
problem as early as possible.
There are some advantages for adopting DAS to address response
identity. It satisfies all the requirements listed above. It is
based on domain authentication service, which allows the relevant
Cao Expires July 14, 2006 [Page 5]
Internet-Draft Response Identity January 2006
proxies to insert the response identity on behalf of UA. DAS allows
the involved intermediate parties to verify the response identity.
This flexibiltiy helps to detect the response identity problem as
early as possible and prevent some malicious attacks through response
messages.
But there is one shortcoming for DAS about its ability for supporting
anonymity. As the responder identity has to be clearly put into the
header of the response message, there is no way to hide it from all
the intermediate parties involved in the same dialog.
3.2. Response Identity with AIB
When the responder may not reveal its identity to all the
intermediate parties involved in the same dialog, anonymity is
desired by the responder to reveal its identiy to its specified
parties. AIB is proposed here as the security mechanism to support
anonymity in end-to-end scenarios and end-to-middle scenarios.
The same example is used here to demonstrate AIB. Alice sends an
INVITE request to Bob. Proxy-2 receives the request and informs Alice
of the response message, along with two new header fields called
Responder and Responder-Info:
Responder: claimer=px2@destination.com; verify-method=AIB
Responder-Info: https://www.destination.com/certification;
alg=rsa-sha1
"Responder" specifies "AIB" as the security mechanism for verifying
response identity. "Responder-Info" provides the links for obtaining
the related security parameters for AIB to verify responder identity.
The AIB portion in the response message body should cover the minimum
set of {To, From, Call-ID, CSeq, Date, Responder}. Any additional
headers may be put into AIB by the responder for enhancing the
integrity of the response message.
It is up to the responder to decide if it wants to hide its identity
and who can see its identity.
If Proxy-2 decides not to hide its identiy, Proxy-2 can put both
"Responder" and "Responder-Info" into response header, and signed the
AIB portion by its private keys. Then each party involved in the
same dialog is able to check the identity. In this case, either
Proxy-1 or Alice can verify the responder identity by obtaining
Responder, Responder-Info and AIB portion.
Cao Expires July 14, 2006 [Page 6]
Internet-Draft Response Identity January 2006
If Proxy-2 wants to hide its identity from intermediate parties,
Proxy-2 MUST NOT put "Responder" and "Responder-Info" into response
header. Instead, AIB portion inside response message body should be
encrypted by the public key (or certificate) of Alice, and signed by
Proxy-2's own private key. In this case, only the originator Alice
knows the response identity and the way to verify it. Proxy-1 can be
prevented from identifying the responder.
AIB provides the desired security mechanism for anonymity protection
for some responders. But the overhead of insert AIB into the
response message is much higher. Another tradeoff is AIB may block
the verification of response identity in the intermediate parties,
which can delay the earliness of detection on the malicious attacks
from rogue parties. End-to-middle security for SIP response needs to
be explored in some scenarios.
3.3. Enforcement on Response Identity
The initiator of SIP request has to require the response identity for
enforcing response indentity in its dialog. One new option tag in
"Require:" is defined for this purpose:
Require: responder-id
In some cases, the relevant proxy might insert this option into SIP
request on behalf of the initiator.
When receiving SIP request with "Require: responder-id", the
responder must provide its identity in its response using the
mechanisms introduced in the above sections.
One exception is that some policies defined for the responder do not
allow its identity to be revealed to the initiator of SIP request.
Instead of providing its identity in its response, the responder
should use one new warn-code inside "Warning" to give its reason:
Warning: 380 Responder Identity Cannot be Revealed
In this case, the responder should understand the potential
consequence for hiding its identity. The intiator (or the proxy that
inserts "Require: responder-id") may not accept the response without
the required response identity, and the dialog may be cancelled.
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.
Cao Expires July 14, 2006 [Page 7]
Internet-Draft Response Identity January 2006
4.1. DAS
When UAS sends the response, UAS must accurately generate the new
header fields as the responder.
For DAS, UAS must populate Responder inside the SIP response. In
addition, the URI as claimer inside Responder must be consistent with
what UAS registers in its domain. Note the URI as claimer may be
different from other header fields, such as Reply-To, Contact, and
To, in some scenarios. Please see Proxy Server Behavior for Identity
and Responder-Info.
When it receives the corresponding SIP response, UAC can verify the
identify of the responder. For DAS, the certificate of DAS for the
responder should be obtained to verify the digest in Identity.
UAC may receive the response code 431 Failed Responder Identity. In
this case, UAC should choose to avoid the verification of the
responder identity. UAC should treat it as a failure and may
terminate the dialog.
4.2. AIB
When UAS wants to provide response identity with AIB, UAS must decide
if it wants to hide its identity from some intermediate parties
involved in the same dialog.
If not, UAS can display both "Responder" and "Responder-Info" into
response header, choose AIB portion, and sign the AIB portion by its
private key inside the response message body.
Otherwise, UAS MUST NOT put "Responder" and "Responder-Info" into
response header. Instead, AIB portion inserted response message body
should be encrypted by the public key (or certificate) of initiator
of SIP request, and signed by UAS's own private key. In this case,
only the initiator knows the response identity and how to verify it.
If UAS wants to reveal its identity to specified proxies involved in
the same dialog, end-to-middle security mechanisms can be applied
here to embed the encrypted context in S/MIME for those proxies.
When it receives the corresponding SIP response, UAC can verify the
identify of the responder. For AIB, the certificate of the responder
should be obtained to verify the digest of AIB portion inside the
response body.
UAC may receive the response code 431 Failed Responder Identity. In
this case, UAC should choose to avoid the verification of the
responder identity. UAC should treat it as a failure and may
Cao Expires July 14, 2006 [Page 8]
Internet-Draft Response Identity January 2006
terminate the dialog.
4.3. Enforcement on Response Identity
UAC of SIP request has to put the new option tag in the request
header:
Require: responder-id
When receiving SIP request with "Require: responder-id", UAS must
provide its identity in its response using the mechanisms introduced
in the above sections.
The exception is that UAS cannot reveal its identity due to the
policy control. Instead of providing its identity in its response,
UAS should provide its warning through one new warn-code:
Warning: 380 Responder Identity Cannot be Revealed
When receiving the response without the expected response identity,
UAC checks if warning is present. If "Warning: 380 Responder
Identity Cannot be Revealed" is inside response header, UAC realizes
that responder wants to hide its identity. UAC should decide if it
is willing to trust the response and continue the dialog, or
terminate the dialog.
5. Proxy Server Behavior
The extensions in this document require new processing and parsing
for proxy servers. Their behaviors are described in this section.
5.1. DAS
The proxy server may provide the domain authentication service for
outgoing SIP response. When a SIP response is received without the
header Responder, the proxy server may insert the identity of the
sender as the responder along with Responder-Info and Identity.
After receiving the SIP response with a new header field Responder,
the proxy servers may verify the responder identity in order to
detect the mismatched identity as early as possible.
For DAS, the proxy server can obtain the certificate of DAS for the
responder through Responder-Info. The digest in Identity can be
verified for the responder identity.
If there is a mismatch, the proxy should save the response and start
Cao Expires July 14, 2006 [Page 9]
Internet-Draft Response Identity January 2006
a timer waiting for the response with matched digest. When the timer
expires, the proxy should decide what response should be sent back.
One option is to modify the saved response by replacing the response
code with "431 Failed Responder Identity" for announcing the problem.
In some scenarios, the proxy servers may relay the SIP responses
without checking the responder identity and modifying any fields
including response codes.
5.2. AIB
After receiving the SIP response with a new header field Responder,
the proxy may find out if AIB is the security mechanism for verifying
the responder identity. If yes, the proxy may obtain the certificate
of the responder through Responder-Info. The digest can be generated
through AIB portion to compare with the one carried inside the
response message body.
If there is a mismatch, the proxy should save the response and start
a timer waiting for the response with matched digest. When the timer
expires, the proxy should decide what response should be sent back.
One option is to modify the saved response by replacing the response
code with "431 Failed Responder Identity" for announcing the problem.
In some scenarios, the proxy servers may relay the SIP responses
without checking the responder identity and modifying any fields
including response codes.
If Responder is not present in response message, the proxy may ignore
the response identity. In some special scenarios related to end-to-
middle security, the proxy may need to look into the message body to
figure out if it is allowed to decrypt AIB portion. Once the AIB
portion is decrypted, the proxy has to check if Responder is included
for response identity verification. If yes, the digest is generated
again to compare with the one carried inside the message body. If
there is a mismatch, the operations for proxy are similar to the
above.
5.3. Enforcement on Response Identity
In some scenarios, the relevant proxy may insert "Require:
responder-id" into the SIP request asking for the response identity.
If the proxy is the reponsder after receiving SIP request with
"Require: responder-id", it must provide its identity in its
response using the mechanisms introduced in the above sections.
The exception is that the proxy cannot reveal its identity due to its
policy control. Instead of providing its identity in its response,
the proxy should provide its warning through one new warn-code:
Cao Expires July 14, 2006 [Page 10]
Internet-Draft Response Identity January 2006
Warning: 380 Responder Identity Cannot be Revealed
The relevant proxy that inserts "Require: responder-id" should check
the response identity inside the response message. If the response
provides no response identity, it should check if warning is present.
If "Warning: 380 Responder Identity Cannot be Revealed" is inside
response header, the proxy realizes that responder wants to hide its
identity. it can decide if it is willing to trust the response and
continue the dialog, or terminate the dialog.
6. Syntax and Examples
Four new SIP headers are introduced in this document. Responder,
Responder-Info, and Response-Authorization appear in the response.
Response-Authentication is eligible in the request.
Responder = "Responder" HCOLON responder-param
Responder-param = claimer-param *( SEMI verify-param)
claimer-param = "claimer" EQUAL (name-addr / addr-spec)
verify-param = "verify-method" EQUAL ("DAS" / "AIB" / token)
Note: token in verify-param can be extended to cover other
verification method, such as AIB(See Appendix A in detail).
Responder-Info = "Responder-Info" HCOLON responder-info-param
responder-info-param = LAQUOT absoluteURI RAQUOT
*( SEMI security-param)
security-param = "alg" EQUAL token
For DAS, the responder's identity is the digest in Identity header.
This digest is generated by including the following elements of the
SIP response in a bit-exact string in this specified order.
o addr-spec in To
o addr-spec in From
o addr-spec of claimer field in Responder
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
inthe message (in the ABNF for SIP, the message body).
In summary, digest-string for Identity header in the SIP response is
Cao Expires July 14, 2006 [Page 11]
Internet-Draft Response Identity January 2006
digest-string = addr-spec ":" addr-spec ":"
addr-spec ":" callid ":" 1*DIGIT SP method
":" SIP-Date ":" message-body
Similar to [3], this digest-string is hashed and signed with the
certificate for the domain. The mandatory procedure is
sha1WithRSAEncryption as described in RFC 3371 with base64 encoding
as described in RFC 3548.
Here is one sample response from Bob in the above example. DAS is
specified as the security mechanism.
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP px1.source.com;branch=z9hG4bKnashds8
;received=101.37.45.98
Via: SIP/2.0/UDP px2.destination.com;branch=bfajk34lk2
;received=121.56.12.1
To: Bob <sip:bob@destination.com>;tag=a6c85cf634
From: Alice <sip:alice@source.com>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sip:bob@192.0.2.4>
CSeq: 314159 INVITE
Responder: claimer=bob@destination.com; verify-method=DAS
Responder-Info: https://www.destination.com/certificate;alg=rsa-sha1
Identity: oiurw20984oij12kfqfknrewqfhgahg198431ufadsafafdag32r4189f
hafaaafi298r3398i32uip293gDFQqireu904328FQWlkafqroiewrjafaf
k189ahffahjf4289981
Content-Length: 0
[*Identity: needs to be recalculated]
The AIB portion in the response message body should cover the minimum
set of {To, From, Call-ID, CSeq, Date, Responder}. Any additional
headers may be put into AIB by the responder for enhancing the
integrity of the response message.
Another example is to illustrate the response from Proxy-2. Proxy-2
provides its identity through AIB.
SIP/2.0 100 Trying
Via: SIP/2.0/UDP px1.source.com;branch=z9hG4bKnashds8
;received=127.101.56.17
To: Bob <sip:bob@destination.com>
From: Alice <sip:alice@source.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Cao Expires July 14, 2006 [Page 12]
Internet-Draft Response Identity January 2006
Max-Forwards: 50
Date: Thu, 21 Apr 2005 16:28:56 GMT
Responder: claimer=px2@destination.com; verify-method=AIB
Responder-Info: https://www.destination.com/certification;
alg=rsa-sha1
Content-Type: multipart/mixed; boundary=unique-boundary-1
--unique-boundary-1
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserA 3569844526 3569844526 IN IP4 source.com
s=Session SDP
c=IN IP4 px2.destination.com
t=0 0
m=audio 61020 RTP/AVP 0
a=rtpmap:0 PCMU/8000
--unique-boundary-1
Content-Type: multipart/signed;
protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary68
Content-Length: 742
--boundary68
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
To: Bob <sip:bob@destination.com>
From: Alice <sip:alice@source.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Date: Thu, 21 Apr 2005 16:28:56 GMT
Responder: claimer=px2@destination.com; verify-method=AIB
--boundary68
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s;
handling=required
H77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6vhJhjH776tbB9HG4
T6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnjTrfvbnj756tbB9HG4VQdT
hJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4oirDAFqre570
AFAwqoireikf5287REW
Cao Expires July 14, 2006 [Page 13]
Internet-Draft Response Identity January 2006
--boundary42--
--unique-boundary-1--
[*digest needs to be recalculated for this message]
7. Security Considerations
This document provides the extension for SIP response identity along
with two security mechanisms for verifgying it.
There are some advantages for the proposed mechanisms in this
document. The new header fields inside SIP response provide the
desired responder identity, and are backward compatible with [1].
Anonymity is also addressed through one security mechanism. These
two proposed security mechanisms can be used to detect the rogue
response identities and prevent some malicious attacks through SIP
responses.
When AIB is used for hiding response identity from intermediate
parties, end-to-middle security should be explored for allowing some
intermediate proxies to check the response identity.
Another security concern is about the response authentication.
Because the current SIP response relies on TLS and TLS is often
absent on many hops, the whole response message may be compromised,
let alone the defined response identity in this document. Another
internet draft [6] is underway to provide complementary enhancement
on SIP response authentication.
This document is 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 four new SIP headers: Responder, Responder-
Info, 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-
Cao Expires July 14, 2006 [Page 14]
Internet-Draft Response Identity January 2006
registry under http://www.iana.org/assignments/sip-parameters.
Header Name: Responder
Compact Form: (none)
Header Name: Responder-Info
Compact Form: (none)
8.2. 431 'Failed Responder Identity Response Code
This document registers a new SIP response code which is described in
Section 3.1. It is used when the responder of the SIP response
cannot be verified successfully. 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: 431
Default Reason Phrase: Failed Responder Identity
8.3. One new option tag: responder-id
This document registers a new option tag which is described in
Section 3.3. It is used when the initiator of SIP request wants the
responder to provide its identity.
http://www.iana.org/assignments/sip-parameters.
Option tag:
Name: responder-id
Description: responder-id is used by the intiator of SIP
request. It asks the responder of that SIP request to
provide its identity with its response.
8.4. One new warn-code: 380
This document registers a new warn-code which is described in Section
3.3. It is used when the responder wants to indicate that it is
unwilling to reveal its identity after receiving "Require:
responder-id" in SIP request.
http://www.iana.org/assignments/sip-parameters.
Warn-code:
Code: 380
Description: Due to its policy control, the responder may not
be allowed to reveal its identity. When the SIP request asks
for response identity, the responder can give out its warning
Cao Expires July 14, 2006 [Page 15]
Internet-Draft Response Identity January 2006
by this new code.
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
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
Cao Expires July 14, 2006 [Page 16]
Internet-Draft Response Identity January 2006
Identity Body (AIB) Format", RFC 3893, September 2004.
[6] Cao, F. and C. Jennings, "Response Authentication in Session
Initiation Protocol", draft-cao-sip-response-auth-01 (work in
progress), December 2005.
[7] Metz, C., "OTP Extended Responses", RFC 2243, November 1997.
11.2. Informational References
[8] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[9] 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.
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
Cao Expires July 14, 2006 [Page 17]
Internet-Draft Response Identity January 2006
Author's Address
Feng Cao (editor)
Cisco Systems
170 West Tasman Drive
MS: SJC-09/2
San Jose, CA 95134
USA
Phone: +1 408 525-9988
Email: fcao@cisco.com
Cao Expires July 14, 2006 [Page 18]
Internet-Draft Response Identity 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 19]
