the backwards dialog when the user is authorized to assert the
identity given in the From header field, and if they are not, an
Identity header is not provided.
For further information on the problems of response identity and the
potential solution spaces, see [15].
6. Verifier Behavior
This document introduces a new logical role for SIP entities called a
server. When a verifier receives a SIP message containing an
Identity header, it may inspect the signature to verify the identity
of the sender of the message. Typically, the results of a
verification are provided as input to an authorization process that
is outside the scope of this document. If an Identity header is not
present in a request, and one is required by local policy (for
example, based on a per-sending-domain policy, or a per-sending-user
policy), then a 428 ’Use Identity Header’ response MUST be sent.
In order to verify the identity of the sender of a message, an entity
acting as a verifier MUST perform the following steps, in the order
here specified.
Step 1:
The verifier MUST acquire the certificate for the signing domain.
Implementations supporting this specification SHOULD have some means
of retaining domain certificates (in accordance with normal practices
for certificate lifetimes and revocation) in order to prevent
themselves from needlessly downloading the same certificate every
time a request from the same domain is received. Certificates cached
in this manner should be indexed by the URI given in the Identity-
Info header field value.
Provided that the domain certificate used to sign this message is not
previously known to the verifier, SIP entities SHOULD discover this
certificate by dereferencing the Identity-Info header, unless they
have some more efficient implementation-specific way of acquiring
certificates for that domain. If the URI scheme in the Identity-Info
header cannot be dereferenced, then a 436 ’Bad Identity-Info’
response MUST be returned. The verifier processes this certificate
in the usual ways, including checking that it has not expired, that
the chain is valid back to a trusted certification authority (CA),
and that it does not appear on revocation lists. Once the
certificate is acquired, it MUST be validated following the
procedures in RFC 3280 [9]. If the certificate cannot be validated
(it is self-signed and untrusted, or signed by an untrusted or
unknown certificate authority, expired, or revoked), the verifier
MUST send a 437 ’Unsupported Certificate’ response.
Step 2:
The verifier MUST follow the process described in Section 13.4 to
determine if the signer is authoritative for the URI in the From
header field.
Step 3:
The verifier MUST verify the signature in the Identity header field,
following the procedures for generating the hashed digest-string
described in Section 9. If a verifier determines that the signature
on the message does not correspond to the reconstructed digest-
string, then a 438 ’Invalid Identity Header’ response MUST be
returned.
Step 4:
The verifier MUST validate the Date, Contact, and Call-ID headers in
the manner described in Section 13.1; recipients that wish to verify
Identity signatures MUST support all of the operations described
there. It must furthermore ensure that the value of the Date header
falls within the validity period of the certificate whose
corresponding private key was used to sign the Identity header.
7. Considerations for User Agent
This mechanism can be applied opportunistically to existing SIP
deployments; accordingly, it requires no change to SIP user agent
behavior in order for it to be effective. However, because this
mechanism does not provide integrity protection between the UAC and
the authentication service, a UAC SHOULD implement some means of
providing this integrity. TLS would be one such mechanism, which is
attractive because it MUST be supported by SIP proxy servers, but is
potentially problematic because it is a hop-by-hop mechanism. See
Section 13.3 for more information about securing the channel between
the UAC and the authentication service.
When a UAC sends a request, it MUST accurately populate the From
header field with a value corresponding to an identity that it
believes it is authorized to claim. In a request, it MUST set the
URI portion of its From header to match a SIP, SIPS, or TEL URI AoR
that it is authorized to use in the domain (including anonymous URIs,
as described in RFC 3323 [3]). In general, UACs SHOULD NOT use the
TEL URI form in the From header field (see Section 11).
Note that this document defines a number of new 4xx response codes.
If user agents support these response codes, they will be able to
respond intelligently to Identity-based error conditions.
The UAC MUST also be capable of sending requests, including mid-call
requests, through an ’outbound’ proxy (the authentication service).
The best way to accomplish this is using pre-loaded Route headers and
loose routing. For a given domain, if an entity that can instantiate
the authentication service role is not in the path of dialog-forming
requests, identity for mid-dialog requests in the backwards direction
cannot be provided.
As a recipient of a request, a user agent that can verify signed
identities should also support an appropriate user interface to
render the validity of identity to a user. User agent
implementations SHOULD differentiate signed From header field values
from unsigned From header field values when rendering to an end-user
the identity of the sender of a request.
8. Considerations for Proxy Servers
Domain policy may require proxy servers to inspect and verify the
identity provided in SIP requests. A proxy server may wish to
ascertain the identity of the sender of the message to provide spam
prevention or call control services. Even if a proxy server does not
act as an authentication service, it MAY validate the Identity header
before it makes a forwarding decision for a request. Proxy servers
MUST NOT remove or modify an existing Identity or Identity-Info
header in a request.
9. Header Syntax
This document specifies two new SIP headers: Identity and Identity-
Info. Each of these headers can appear only once in a SIP message.
The grammar for these two headers is (following the ABNF [6] in RFC
3261 [1]):
Identity = "Identity" HCOLON signed-identity-digest
signed-identity-digest = LDQUOT 32LHEX RDQUOT
Identity-Info = "Identity-Info" HCOLON ident-info
*( SEMI ident-info-params )
ident-info = LAQUOT absoluteURI RAQUOT
ident-info-params = ident-info-alg / ident-info-extension
ident-info-alg = "alg" EQUAL token
ident-info-extension = generic-param
The signed-identity-digest is a signed hash of a canonical string
generated from certain components of a SIP request. To create the
contents of the signed-identity-digest, the following elements of a
SIP message MUST be placed in a bit-exact string in the order
specified here, separated by a vertical line, "|" or %x7C, character:
o The AoR of the UA sending the message, or addr-spec of the From
header field (referred to occasionally here as the ’identity
field’).
o The addr-spec component of the To header field, which is the AoR
to which the request is being sent.
o The callid from Call-Id header field.
o The digit (1*DIGIT) and method (method) portions from CSeq header
field, separated by a single space (ABNF SP, or %x20). Note that
the CSeq header field allows linear whitespace (LWS) rather than
SP to separate the digit and method portions, and thus the CSeq
header field may need to be transformed in order to be
canonicalized. The authentication service MUST strip leading
zeros from the ’digit’ portion of the Cseq before generating the
digest-string.
o The Date header field, with exactly one space each for each SP and
the weekday and month items case set as shown in BNF in RFC 3261.
RFC 3261 specifies that the BNF for weekday and month is a choice
amongst a set of tokens. The RFC 2234 rules for the BNF specify
that tokens are case sensitive. However, when used to construct
the canonical string defined here, the first letter of each week
and month MUST be capitalized, and the remaining two letters must
be lowercase. This matches the capitalization provided in the
definition of each token. All requests that use the Identity
mechanism MUST contain a Date header.
o The addr-spec component of the Contact header field value. If the
request does not contain a Contact header, this field MUST be
empty (i.e., there will be no whitespace between the fourth and
fifth "|" characters in the canonical string).
o The body content of the message with the bits exactly as they are
in the Message (in the ABNF for SIP, the message-body). This
includes all components of multipart message bodies. Note that
the message-body does NOT include the CRLF separating the SIP
headers from the message-body, but does include everything that
follows that CRLF. If the message has no body, then message-body
will be empty, and the final "|" will not be followed by any
additional characters.
For more information on the security properties of these headers, and
why their inclusion mitigates replay attacks, see Section 13 and [5].
The precise formulation of this digest-string is, therefore
(following the ABNF [6] in RFC 3261 [1]):
digest-string = addr-spec "|" addr-spec "|" callid "|"
1*DIGIT SP Method "|" SIP-date "|" [ addr-spec ] "|"
message-body
Note again that the first addr-spec MUST be taken from the From
header field value, the second addr-spec MUST be taken from the To
header field value, and the third addr-spec MUST be taken from the
Contact header field value, provided the Contact header is present in
the request.
After the digest-string is formed, it MUST be hashed and signed with
the certificate for the domain. The hashing and signing algorithm is
specified by the ’alg’ parameter of the Identity-Info header (see
below for more information on Identity-Info header parameters). This
document defines only one value for the ’alg’ parameter: ’rsa-sha1’;
further values MUST be defined in a Standards Track RFC, see Section
14.7 for more information. All implementations of this specification
MUST support ’rsa-sha1’. When the ’rsa-sha1’ algorithm is specified
in the ’alg’ parameter of Identity-Info, the hash and signature MUST
be generated as follows: compute the results of signing this string
with sha1WithRSAEncryption as described in RFC 3370 [7] and base64
encode the results as specified in RFC 3548 [8]. A 1024-bit or
longer RSA key MUST be used. The result is placed in the Identity
header field. For detailed examples of the usage of this algorithm,
see Section 10.
The ’absoluteURI’ portion of the Identity-Info header MUST contain a
URI which dereferences to a resource containing the certificate of
the authentication service. All implementations of this
specification MUST support the use of HTTP and HTTPS URIs in the
Identity-Info header. Such HTTP and HTTPS URIs MUST follow the
conventions of RFC 2585 [10], and for those URIs the indicated
resource MUST be of the form ’application/pkix-cert’ described in
that specification. Note that this introduces key lifecycle
management concerns; were a domain to change the key available at the
Identity-Info URI before a verifier evaluates a request signed by an
authentication service, this would cause obvious verifier failures.
When a rollover occurs, authentication services SHOULD thus provide
new Identity-Info URIs for each new certificate, and SHOULD continue
to make older key acquisition URIs available for a duration longer
than the plausible lifetime of a SIP message (an hour would most
likely suffice).
The Identity-Info header field MUST contain an ’alg’ parameter. No
other parameters are defined for the Identity-Info header in this
document. Future Standards Track RFCs may define additional
Identity-Info header parameters.
This document adds the following entries to Table 2 of RFC 3261 [1]:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
Identity R a o o - o o o
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o o o o
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
Identity-Info R a o o - o o o
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o o o o
Note, in the table above, that this mechanism does not protect the
CANCEL method. The CANCEL method cannot be challenged, because it is
hop-by-hop, and accordingly authentication service behavior for
CANCEL would be significantly limited. Note as well that the
REGISTER method uses Contact header fields in very unusual ways that
complicate its applicability to this mechanism, and the use of
Identity with REGISTER is consequently a subject for future study,
although it is left as optional here for forward-compatibility
reasons. The Identity and Identity-Info header MUST NOT appear in
CANCEL.
10. Compliance Tests and Examples
The examples in this section illustrate the use of the Identity
header in the context of a SIP transaction. Implementers are advised
to verify their compliance with the specification against the
following criteria:
o Implementations of the authentication service role MUST generate
identical base64 identity strings to the ones shown in the
Identity headers in these examples when presented with the source
message and utilizing the appropriate supplied private key for the
domain in question.
o Implementations of the verifier role MUST correctly validate the
given messages containing the Identity header when utilizing the
supplied certificates (with the caveat about self-signed
certificates below).
Note that the following examples use self-signed certificates, rather
than certificates issued by a recognized certificate authority. The
use of self-signed certificates for this mechanism is NOT
RECOMMENDED, and it appears here only for illustrative purposes.
Therefore, in compliance testing, implementations of verifiers SHOULD
generate appropriate warnings about the use of self-signed
certificates. Also, the example certificates in this section have
placed their domain name subject in the subjectAltName field; in
practice, certificate authorities may place domain names in other
locations in the certificate (see Section 13.4 for more information).
Note that all examples in this section use the ’rsa-sha1’ algorithm.
Bit-exact reference files for these messages and their various
transformations are supplied in Appendix B.
10.1. Identity-Info with a Singlepart MIME body
Consider the following private key and certificate pair assigned to
’atlanta.example.com’ (rendered in OpenSSL format).
-----BEGIN RSA PRIVATE KEY-----
MIICXQIBAAKBgQDPPMBtHVoPkXV+Z6jq1LsgfTELVWpy2BVUffJMPH06LL0cJSQO
aIeVzIojzWtpauB7IylZKlAjB5f429tRuoUiedCwMLKblWAqZt6eHWpCNZJ7lONc
IEwnmh2nAccKk83Lp/VH3tgAS/43DQoX2sndnYh+g8522Pzwg7EGWspzzwIDAQAB
AoGBAK0W3tnEFD7AjVQAnJNXDtx59Aa1Vu2JEXe6oi+OrkFysJjbZJwsLmKtrgtt
PXOU8t2mZpi0wK4hX4tZhntiwGKkUPC3h9Bjp+GerifP341RMyMO+6fPgjqOzUDw
+rPjjMpwD7AkcEcqDgbTrZnWv/QnCSaaF3xkUGfFkLx5OKcRAkEA7UxnsE8XaT30
tP/UUc51gNk2KGKgxQQTHopBcew9yfeCRFhvdL7jpaGatEi5iZwGGQQDVOVHUN1H
0YLpHQjRowJBAN+R2bvA/Nimq464ZgnelEDPqaEAZWaD3kOfhS9+vL7oqES+u5E0
J7kXb7ZkiSVUg9XU/8PxMKx/DAz0dUmOL+UCQH8C9ETUMI2uEbqHbBdVUGNk364C
DFcndSxVh+34KqJdjiYSx6VPPv26X9m7S0OydTkSgs3/4ooPxo8HaMqXm80CQB+r
xbB3UlpOohcBwFK9mTrlMB6Cs9ql66KgwnlL9ukEhHHYozGatdXeoBCyhUsogdSU
6/aSAFcvWEGtj7/vyJECQQCCS1lKgEXoNQPqONalvYhyyMZRXFLdD4gbwRPK1uXK
Ypk3CkfFzOyfjeLcGPxXzq2qzuHzGTDxZ9PAepwX4RSk
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIC3TCCAkagAwIBAgIBADANBgkqhkiG9w0BAQUFADBZMQswCQYDVQQGEwJVUzEL
MAkGA1UECAwCR0ExEDAOBgNVBAcMB0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAa
BgNVBAMME2F0bGFudGEuZXhhbXBsZS5jb20wHhcNMDUxMDI0MDYzNjA2WhcNMDYx
MDI0MDYzNjA2WjBZMQswCQYDVQQGEwJVUzELMAkGA1UECAwCR0ExEDAOBgNVBAcM
B0F0bGFudGExDTALBgNVBAoMBElFVEYxHDAaBgNVBAMME2F0bGFudGEuZXhhbXBs
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAM88wG0dWg+RdX5nqOrU
uyB9MQtVanLYFVR98kw8fTosvRwlJA5oh5XMiiPNa2lq4HsjKVkqUCMHl/jb21G6
hSJ50LAwspuVYCpm3p4dakI1knuU41wgTCeaHacBxwqTzcun9Ufe2ABL/jcNChfa
yd2diH6DznbY/PCDsQZaynPPAgMBAAGjgbQwgbEwHQYDVR0OBBYEFNmU/MrbVYcE
KDr/20WISrG1j1rNMIGBBgNVHSMEejB4gBTZlPzK21WHBCg6/9tFiEqxtY9azaFd
pFswWTELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkdBMRAwDgYDVQQHDAdBdGxhbnRh
MQ0wCwYDVQQKDARJRVRGMRwwGgYDVQQDDBNhdGxhbnRhLmV4YW1wbGUuY29tggEA
MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEADdQYtswBDmTSTq0mt211
7alm/XGFrb2zdbU0vorxRdOZ04qMyrIpXG1LEmnEOgcocyrXRBvq5p6WbZAcEQk0
DsE3Ve0Nc8x9nmvljW7GsMGFCnCuo4ODTf/1lGdVr9DeCzcj10YUQ3MRemDMXhY2
CtDisLWl7SXOORcZAi1oU9w=
-----END CERTIFICATE-----
A user of atlanta.example.com, Alice, wants to send an INVITE to
bob@biloxi.example.org. She therefore creates the following INVITE
request, which she forwards to the atlanta.example.org proxy server
that instantiates the authentication service role:
INVITE sip:bob@biloxi.example.org SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.example.org>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
When the authentication service receives the INVITE, it authenticates
Alice by sending a 407 response. As a result, Alice adds an
Authorization header to her request, and resends to the
atlanta.example.com authentication service. Now that the service is
sure of Alice’s identity, it calculates an Identity header for the
request. The canonical string over which the identity signature will
be generated is the following (note that the first line wraps because
of RFC editorial conventions):
sip:alice@atlanta.example.com|sip:bob@biloxi.example.org|
a84b4c76e66710|314159 INVITE|Thu, 21 Feb 2002 13:02:03 GMT|
sip:alice@pc33.atlanta.example.com|v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
The resulting signature (sha1WithRsaEncryption) using the private RSA
key given above, with base64 encoding, is the following:
ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa
ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=
Accordingly, the atlanta.example.com authentication service will
create an Identity header containing that base64 signature string
(175 bytes). It will also add an HTTPS URL where its certificate is
made available. With those two headers added, the message looks like
the following:
INVITE sip:bob@biloxi.example.org SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Bob <sip:bob@biloxi.example.org>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Max-Forwards: 70
Date: Thu, 21 Feb 2002 13:02:03 GMT
Contact: <sip:alice@pc33.atlanta.example.com>
Identity:
"ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa
ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U="
Identity-Info: <https://atlanta.example.com/atlanta.cer>;alg=rsa-sha1
Content-Type: application/sdp
Content-Length: 147
v=0
o=UserA 2890844526 2890844526 IN IP4 pc33.atlanta.example.com
s=Session SDP
c=IN IP4 pc33.atlanta.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
atlanta.example.com then forwards the request normally. When Bob
receives the request, if he does not already know the certificate of
atlanta.example.com, he dereferences the URL in the Identity-Info
header to acquire the certificate. Bob then generates the same
canonical string given above, from the same headers of the SIP
request. Using this canonical string, the signed digest in the
Identity header, and the certificate discovered by dereferencing the
Identity-Info header, Bob can verify that the given set of headers
and the message body have not been modified.
10.2. Identity for a Request with No MIME Body or Contact
Consider the following private key and certificate pair assigned to
"biloxi.example.org".
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQC/obBYLRMPjskrAqWOiGPAUxI3/m2ti7ix4caqCTAuFX5cLegQ
7nmquLOHfIhxVIqT2f06UA0lOo2NVofK9G7MTkVbVNiyAlLYUDEj7XWLDICf3ZHL
6Fr/+CF7wrQ9r4kv7XiJKxodVCCd/DhCT9Gp+VDoe8HymqOW/KsneriyIwIDAQAB
AoGBAJ7fsFIKXKkjWgj8ksGOthS3Sn19xPSCyEdBxfEm2Pj7/Nzzeli/PcOaic0k
JALBcnqN2fHEeIGK/9xUBxTufgQYVJqvyHERs6rXX/iT4Ynm9t1905EiQ9ZpHsrI
/AMMUYA1QrGgAIHvZLVLzq+9KLDEZ+HQbuCLJXF+6bl0Eb5BAkEA636oMANp0Qa3
mYWEQ2utmGsYxkXSfyBb18TCOwCty0ndBR24zyOJF2NbZS98Lz+Ga25hfIGw/JHK
nD9bOE88UwJBANBRSpd4bmS+m48R/13tRESAtHqydNinX0kS/RhwHr7mkHTU3k/M
FxQtx34I3GKzaZxMn0A66KS9v/SHdnF+ePECQQCGe7QshyZ8uitLPtZDclCWhEKH
qAQHmUEZvUF2VHLrbukLLOgHUrHNa24cILv4d3yaCVUetymNcuyTwhKj24wFAkAO
z/jx1EplN3hwL+NsllZoWI58uvu7/Aq2c3czqaVGBbb317sHCYgKk0bAG3kwO3mi
93/LXWT1cdiYVpmBcHDBAkEAmpgkFj+xZu5gWASY5ujv+FCMP0WwaH5hTnXu+tKe
PJ3d2IJZKxGnl6itKRN7GeRh9PSK0kZSqGFeVrvsJ4Nopg==
-----END RSA PRIVATE KEY-----
-----BEGIN CERTIFICATE-----
MIIC1jCCAj+gAwIBAgIBADANBgkqhkiG9w0BAQUFADBXMQswCQYDVQQGEwJVUzEL
MAkGA1UECAwCTVMxDzANBgNVBAcMBkJpbG94aTENMAsGA1UECgwESUVURjEbMBkG
A1UEAwwSYmlsb3hpLmV4YW1wbGUuY29tMB4XDTA1MTAyNDA2NDAyNloXDTA2MTAy
NDA2NDAyNlowVzELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAk1TMQ8wDQYDVQQHDAZC
aWxveGkxDTALBgNVBAoMBElFVEYxGzAZBgNVBAMMEmJpbG94aS5leGFtcGxlLmNv
bTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAv6GwWC0TD47JKwKljohjwFMS
N/5trYu4seHGqgkwLhV+XC3oEO55qrizh3yIcVSKk9n9OlANJTqNjVaHyvRuzE5F
W1TYsgJS2FAxI+11iwyAn92Ry+ha//ghe8K0Pa+JL+14iSsaHVQgnfw4Qk/RqflQ
6HvB8pqjlvyrJ3q4siMCAwEAAaOBsTCBrjAdBgNVHQ4EFgQU0Z+RL47W/APDtc5B
fSoQXuEFE/wwfwYDVR0jBHgwdoAU0Z+RL47W/APDtc5BfSoQXuEFE/yhW6RZMFcx
CzAJBgNVBAYTAlVTMQswCQYDVQQIDAJNUzEPMA0GA1UEBwwGQmlsb3hpMQ0wCwYD
VQQKDARJRVRGMRswGQYDVQQDDBJiaWxveGkuZXhhbXBsZS5jb22CAQAwDAYDVR0T
BAUwAwEB/zANBgkqhkiG9w0BAQUFAAOBgQBiyKHIt8TXfGNfpnJXi5jCizOxmY8Y
gln8tyPFaeyq95TGcvTCWzdoBLVpBD+fpRWrX/II5sE6VHbbAPjjVmKbZwzQAtpp
P2Fauj28t94ZeDHN2vqzjfnHjCO24kG3Juf2T80ilp9YHcDwxjUFrt86UnlC+yid
yaTeusW5Gu7v1g==
-----END CERTIFICATE-----
Bob (bob@biloxi.example.org) now wants to send a BYE request to Alice
at the end of the dialog initiated in the previous example. He
therefore creates the following BYE request, which he forwards to the
’biloxi.example.org’ proxy server that instantiates the
authentication service role:
BYE sip:alice@pc33.atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.org>;tag=a6c85cf
To: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 231 BYE
Content-Length: 0
When the authentication service receives the BYE, it authenticates
Bob by sending a 407 response. As a result, Bob adds an
Authorization header to his request, and resends to the
biloxi.example.org authentication service. Now that the service is
sure of Bob’s identity, it prepares to calculate an Identity header
for the request. Note that this request does not have a Date header
field. Accordingly, the biloxi.example.org will add a Date header to
the request before calculating the identity signature. If the
Content-Length header were not present, the authentication service
would add it as well. The baseline message is thus:
BYE sip:alice@pc33.atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS 192.0.2.4;branch=z9hG4bKnashds10
Max-Forwards: 70
From: Bob <sip:bob@biloxi.example.org>;tag=a6c85cf
To: Alice <sip:alice@atlanta.example.com>;tag=1928301774