One document matched: draft-wing-sip-identity-media-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-behave-turn SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-behave-turn.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4474 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml">
<!ENTITY rfc3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY I-D.ietf-sip-dtls-srtp-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-dtls-srtp-framework.xml">
<!ENTITY rfc4572 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4572.xml">
<!ENTITY rfc4234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml">
<!ENTITY rfc4916 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4916.xml">
<!ENTITY I-D.tschofenig-hiprg-host-identities SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-hiprg-host-identities.xml">
<!ENTITY I-D.ietf-hip-base SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-hip-base.xml">
<!ENTITY I-D.farinacci-lisp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.farinacci-lisp.xml">
<!ENTITY I-D.carpenter-idloc-map-cons SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.carpenter-idloc-map-cons.xml">
<!ENTITY I-D.whittle-ivip-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.whittle-ivip-arch.xml">
<!ENTITY I-D.ietf-mmusic-ice SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice.xml">
<!ENTITY I-D.ietf-sipping-sbc-funcs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-sbc-funcs.xml">
<!ENTITY rfc3325 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml">
<!ENTITY I-D.ietf-mmusic-sdp-capability-negotiation SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-sdp-capability-negotiation.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc sortrefs="no" ?>
<?rfc colonspace='yes' ?>
<?rfc tocindent='yes' ?>
<rfc category="std" docName="draft-wing-sip-identity-media-01" ipr="full3978">
<front>
<title abbrev="SIP Identity using Media Path">SIP Identity using Media
Path</title>
<author fullname="Dan Wing" initials="D." surname="Wing">
<organization abbrev="Cisco Systems">Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>dwing@cisco.com</email>
</address>
</author>
<author fullname="Hadriel Kaplan" initials="H." surname="Kaplan">
<organization>Acme Packet</organization>
<address>
<postal>
<street>71 Third Ave.</street>
<city>Burlington</city>
<region>MA</region>
<code>01803</code>
<country>USA</country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email>hkaplan@acmepacket.com</email>
<uri></uri>
</address>
</author>
<date year="2007" />
<abstract>
<t>The existing SIP identity mechanism (RFC4474) creates a signature
over the SIP body, including the entire SDP. As part of their normal
operation, Session Border Controllers (SBCs) and SIP Back-to-Back User
Agents (B2BUAs) modify various fields in the SDP which breaks that
signature.</t>
<t>This document defines a new identity mechanism which operates with
SBCs and B2BUAs. This new identity mechanism creates a signature over
certain SIP headers and certain SDP lines, and uses both SIP signaling
and the media path to perform its identity function.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t><xref target="RFC4474">SIP Identity</xref> provides cryptographic
identity for SIP requests. It provides this protection by signing
certain SIP header fields (Contact, Date, Call-ID, CSeq, To, and From)
and the SIP message body. The SIP message body typically contains the
SDP.</t>
<t>In cases where the originating, authenticating domain directly
connect to the terminating, validating domain, RFC4474 has questionable
value. The reason is that in such cases TLS can simply be used for the
communication between the edge proxies of each domain, which not only
provides additional security properties (e.g., encryption), but is also
more efficient and protects all signaling messages. The real value of
RFC4474 lies in cases where SIP signaling crosses multiple domains,
belonging to different organizations. Unfortunately, in the presence of
SBCs or B2BUAs that are in a different trust domain than the calling
party or called party, SIP Identity provides the same security
properties as using <xref target="RFC3325">P-Asserted-Identity</xref>
between those same trust domains, if it succeeds at all. In most cases
it would probably fail, and force the UAC to re-send its request without
any Identity mechanism if it wanted to establish communication.</t>
<t>The mechanism described in this document provides cryptographic
assurance of the endpoint's identity by signing certain SIP headers,
much like RFC4474. However, unlike RFC4474 which signs the entire SDP,
the mechanism described in this document signs only certain SDP
attributes, and not all the same SIP headers. The remote endpoint is
expected to validate the signature over the SIP headers and specified
SDP attributes, to initiate a proof of possession test over the media
path, which proves the session has been established with the "From:"
party in the SIP header. Mechanisms to perform this proof of possession
are shown using DTLS and using a small extension to <xref
target="I-D.ietf-mmusic-ice">ICE</xref>. This mechanism is also
extensible, in order to be usable by future mechanisms which need signed
SDP attributes</t>
<t>Readers of this document are expected to be familiar with RFC4474,
"Enhancements for Authenticated Identity Management in the Session
Initiation Protocol (SIP)", which defines the Identity and Identity-Info
header fields. A future version of this document will have less reliance
on RFC4474.</t>
</section>
<section title="Notational Conventions">
<t>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 <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Analysis of SIP-Identity with SBCs">
<t>This section examines how <xref target="RFC4474">SIP Identity</xref>
operates with SBCs(<xref target="sip-identity-with-sbc"></xref>) or
certain back-to-back user-agents (B2BUAs), and how SIP Identity uses
transport addresses as identifiers (<xref
target="transport-address-identifier"></xref>).</t>
<section anchor="sip-identity-with-sbc" title="SIP-Identity with SBCs">
<t>After an authorization agent signs a SIP request, the SIP request
traverses SBC(s) operated by other trust domains and finally arrives
at the destination domain. If all of those intervening SBCs support
SIP Identity, those SBCs will validate the request's signature,
destroy the existing signature, create a new identity for the request,
and sign the request's new identity. These necessary SBC actions
(described in detail below) provide the same identity assurance as
using P-Asserted-Identity between trust domains.</t>
<t>The functions of SBCs, and why they do what they do, is mainly
detailed in <xref target="I-D.ietf-sipping-sbc-funcs"></xref>.
Regardless of the architectural implications of their actions, the
fact is their functions are often performed as a SIP request/response
traverses across SIP domains. Other B2BUAs in the path sometimes also
perform functions which invalidate an RFC4474 signature. With regard
to RFC4474, the SBC functions which impact the signature are:</t>
<t><list style="symbols">
<t>Replacing IP addresses in SDP body parts</t>
<t>Replacing the Contact URI</t>
<t>Modifying the Call-ID</t>
<t>Modifying the CSeq</t>
</list></t>
<figure anchor="without_enterprise_sbc"
title="Two Service Providers with SBCs Between Two Enterprises">
<preamble>The following diagram shows two service providers (SP1 and
SP2), and each has an SBC at the edge of their respective networks.
Each of these SBCs would rewrite the IP addresses in the SDP. There
may be an SBC in the Enterprise as well, however that SBC would own
the appropriate Enterprise domain certificate and re-sign the
request, and thus logically appear as the Enterprise User
Agent</preamble>
<artwork align="center"><![CDATA[
+---------+ +---------+ +---------+ +---------+
|SP1-SBC-1|-|SP1-SBC-2|--|SP2-SBC-1|--|SP2-SBC-2|
+---+-----+ +---------+ +---------+ +-+-------+
| |
| |
+--------------+ +------+-------+
|SIP User Agent| |SIP User Agent|
| Enterprise-A | | Enterprise-B |
+--------------+ +--------------+]]></artwork>
<postamble></postamble>
</figure>
<t>Enterprise-A can populate the "From:" address in its SIP requests
using E.164 telephone numbers (e.g.,
'sip:+17005551008@example.com;user=phone') or using a SIP URI (e.g.,
'sip:john.doe@example.com'). The characteristics of each choice, as
the message traverses the SBCs operated by another administrative
domain (service providers) are described below:</t>
<section title="Validate the Signature">
<t>Per RFC4474, the SBC would validate the incoming SIP request.
This requires a public key operation to be performed against the SIP
request.</t>
<t>[[computationally expensive. Will use TLS or IPSEC instead
(doesn't require public key operation for every SIP request), or
will rely on ACLs or a dedicated link or dedicated network.]]</t>
<t>This creates a natural incentive for the service providers to use
transitive trust between themselves, rather than RFC4474, due to the
computational expense of the per-call public key operations on each
SIP request. For similar reasons, there is a natural incentive for
the service providers to not even validate an enterprise's RFC4474
signature but rather to rely on a contract or rely on TLS or IPSEC
to ensure the SIP signaling originated from the enterprise. Since
service providers do not allow Enterprises to be transitive domains,
they only allow From-URI domains of the enterprise, and thus do not
need a per-request 4474-style signature from the Enterprise at the
first ingress hop.</t>
</section>
<section title="Destroy Existing Signature">
<t>SBCs and B2BUAs typically modify the media transport addresses
and thus invalidate the RFC4474 signature. This prevents downstream
systems from validating original signature.</t>
<t>Because the original signature is invalidated by the first SBC,
no other network (SP2 nor Enterprise-B) can validate the original
signature. This means all downstream entities (in the example above,
SP2 and Enterprise-B) are relying wholly on SP1 to validate the
signature. This creates transitive trust which is undesirable - a
single bad actor or compromised system anywhere along the path can
compromise the entire identity system. Note this does not require
malicious intent within the trust domain - a weak or mis-configured
entry point into the trust chain of service providers compromises
the entire trust chain.</t>
</section>
<section title="Create New Identity">
<t>In order to generate a SIP Identity signature (in the next step),
the SBC requires the private key associated with the domain of that
From: address. Because the SBC and the initiator of the SIP request
are different entities, it is unlikely the SBC will possess the
initiating domain's private key. Thus, the SBC will have to create a
new identity -- using its domain -- for the request, if it wants to
provide RFC4474.</t>
<t>The new identity creates difficulties with downstream whitelists,
call routing, and reputation systems. For example, downstream
systems may sometimes see the identity +14085551212@example.com when
the request is routed through certain SBCs, and may see a different
identity, +14085551212@example.net, when the request is routed
through different SBCs. Such different routing might be done due to
network outages or for cost savings (e.g., evening rates). Due to
these different identities, the domain name no longer has much
meaning -- for E.164 telephone numbers, the user-part becomes the
entire identity. In some sense that's appropriate; if the user-part
is truly a global-scope E.164 number, then the domain portion is
essentially meaningless. It might as well have been a tel-URI,
except that making it a SIP-URI is more common and allows rfc4474 to
be used.</t>
<t>A SBC might receive an identity containing an E.164 phone number
or containing a SIP URI. When forming a new identity, the SBC
performs different steps for each of those cases:</t>
<t><list style="hanging">
<t hangText="E.164 telephone numbers:"><vspace
blankLines="0" />The SBC would remove the original domain name
and substitute its own domain on the right-hand side.</t>
<t hangText="SIP URIs:"><vspace blankLines="0" />Unlike E.164
telephone numbers, the SBC is not able to simply substitute its
domain name for the enterprise's domain name due to user-part
name collisions. There is only one unappealing solution: use the
so-called escape-hack from email. For example, the SBC could
rewrite sip:john.doe@example.com to
sip:john.doe%example.com@sp1.example.net.</t>
</list></t>
</section>
<section title="Sign the New Identity">
<t>Finally, the SBC will sign the new identity, using the private
key associated with the new identity. This private key is known to
the SBC (because it is the SBC's domain name). This function incurs
a public key operation for that SIP request.</t>
</section>
</section>
<section anchor="transport-address-identifier"
title="Transport Address as Identifier">
<t>SIP Identity signs the SDP so that the IP address (contained in the
SDP) provides identity. From <xref target="RFC4474"></xref>:</t>
<t><list style="empty">
<t>"This mechanism also provides a signature over the bodies of
SIP requests. The most important reason for doing so is to protect
Session Description Protocol (SDP) bodies carried in SIP requests.
There is little purpose in establishing the identity of the user
that originated a SIP request if this assurance is not coupled
with a comparable assurance over the media descriptors."</t>
</list></t>
<t>RFC4474 ties an identifier (IP address) with the identity (SIP
"From:" address), which is counter to ongoing efforts in the IETF to
split identifiers from identity (e.g., <xref
target="I-D.ietf-hip-base"> </xref>, <xref
target="I-D.farinacci-lisp"></xref>, <xref
target="I-D.carpenter-idloc-map-cons"></xref>, <xref
target="I-D.whittle-ivip-arch"></xref>).</t>
<t>The presence of media relays (e.g., <xref
target="I-D.ietf-behave-turn">TURN</xref>), which may be used by an
attacker, means that relying exclusively on such identifiers is risky.
For example, if an attacker were able to cause re-use of the (signed)
transport address within the replay window, the attacker can
successfully impersonate the identity.</t>
<t>Additionally, RFC4474's tying of identities to IP address causes a
failure in certain NAT scenarios when the source transport address of
arriving media does not agree with the SDP. While not written down in
a standard at this time, if both endpoints are using <xref
target="I-D.ietf-mmusic-ice">ICE</xref>, the ICE username and password
(sent in SDP and signed by RFC4474) can be reliably used to establish
identity. However, if either endpoint does not support ICE, the
arriving media will be considered fraudulent because the arriving
media does not match with the RFC4474-signed SDP.</t>
</section>
</section>
<section title="Operation">
<t>The operation of SIP-Identity-Media is similar to RFC4474 and uses
authentication service proxies much like RFC4474. The basic steps
are:</t>
<t><list style="symbols">
<t>A new header, Identity-Media, is created containing the names of
certain SDP attributes from SDP bodyparts, and containing a hash of
non-SDP bodyparts.</t>
<t>Several SIP headers and the Identity-Media header are all signed
(as detailed in <xref target="identity_media_signature"></xref>),
and the result is placed in Identity-Media-Signature.</t>
<t>The receiving domain validates the signature, and if the request
is an invitation to establish a media channel, performs a proof of
identity validation using DTLS, TLS, ICE, or HIP over the media
path.</t>
</list></t>
<figure anchor="call_flow" title="Message Flow">
<preamble>The following figure shows how the Authentication Service
and the media validation is performed. The figure assumes the
endpoints themselves perform the media validation.</preamble>
<artwork align="center"><![CDATA[
: Service :
Enterprise-A : Provider-1 : Enterprise-B
: :
Auth. : B2BUA or : Auth.
Endpoint-A Service : SBC : Service Endpoint-B
| | : | : | |
1. |--INVITE->| : | : | |
2. | sign : | : | |
3. | |-INVITE-->|-INVITE-->| |
4. | | : | : validate |
5. | | : | : |-------->|
6. |<=========tls, dtls, ice, or hip=========>|
7. | | : | : | validated
8. | | : | : | ring phone
| | : | : | |
: :]]></artwork>
<postamble></postamble>
</figure>
<t><list style="format Step %d:">
<t>Originating endpoint prepares to send an INVITE and chooses the
identity-challenge technique it supports, and indicates that in the
SDP it generates. Described in this document are identity challenges
for TLS, DTLS, ICE, and HIP. It then sends the INVITE to its local
SIP proxy.</t>
<t>Originating endpoint's authentication service creates a new
header, Identity-Media, containing certain attribute names from the
SDP (e.g., "a=fingerprint", "a=ice-pub-key"). The authentication
service then creates a signature over certain SIP headers (e.g.,
From, To) and this new Identity-Media header. The resulting
signature is inserted into the new Identity-Media-Signature header.
An Identity-Info header is added, pointing to this domain's
certificate. The INVITE, with these additional headers, is forwarded
to the next administrative domain. <vspace blankLines="0" /> [NOTE:
alternatively, we could allow the UAC to create the Identity- Media
header with the attributes it wants signed, then have the auth
server sign them and insert the signature header - this would be
more flexible]</t>
<t>The next administrative domain has an SBC (or B2BUA). The SBC
modifies or rewrites certain SDP fields. Most typically an SBC will
modify the "m" and "c" lines. These modifications do not break the
signature, so long as the SBC doesn't remove the headers
Identity-Media, Identity-Media-Signature, or Identity-Info, and do
not remove or alter the signed attributes from the SDP.</t>
<t>The terminating endpoint's authentication service receives the
INVITE. It validates that the signature contained in the
Identity-Media-Signature header, and validates that the signing
certificate is owned by the originating domain from step 2. This
validation is done by using the certificate pointed to in the
Identity-Info header, which MUST match the domain in the From:
address.</t>
<t>If the validation was successful, the terminating endpoint's
authentication service forwards the INVITE to the endpoint.</t>
<t>The terminating endpoint chooses a compatible identity-challenge
technique from the INVITE (TLS, DTLS, ICE, or HIP), and performs
that challenge. Described in this document are identity challenges
for TLS, DTLS, ICE, and HIP.</t>
<t>All of the identity challenges (TLS, DTLS, ICE, and HIP) cause
the exchange of either a certificate or a public key in the media
path. The terminating endpoint compares the certificate or public
key with the fingerprint in the (signed) Identity-Media header
(originally created in step 2). If they match, the terminating
endpoint completes the identity challenge exchange. After
completion, the originating endpoint has proven (to the terminating
endpoint) that the originating endpoint knows the private key
associated with the certificate (or public key) signed in step 2.
The terminating endpoint has now validated the identity of the
originating endpoint.</t>
<t>The terminating endpoint can reliably and honestly indicate
calling party information ("caller-id") and ring the phone.</t>
</list></t>
<section anchor="identity_media_signature"
title="Identity Media Signature">
<t>In RFC4474, a signature is formed over some SIP headers and over
the entire body (which most typically contains SDP). In this
specification, some SIP headers are signed but only specific SDP
attributes that provide cryptographic identity are signed (e.g.,
"a=fingerprint" and its value). The specific SDP attributes that are
signed depends on which cryptographic identity technique(s) is used;
see section <xref target="techniques"></xref>.</t>
<t>The SIP headers that are signed, for the signature placed into the
Identity-Media-Signature header are:</t>
<t><list style="symbols">
<t>The AoR of the UA sending the message, or addr-spec of the From
header field (referred to occasionally here as the 'identity
field').</t>
<t>The addr-spec component of the To header field, which is the
AoR to which the request is being sent.</t>
<t>The SIP method.</t>
<t>[NOTE: Contact, CSeq and Call-Id not included]</t>
<t>The Date header field, with exactly one space each for each SP
and the weekday and month items case set as shown in the BNF in
RFC3261. RFC3261 specifies that the BNF for weekday and month is a
choice amongst a set of tokens. The RFC2234 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-Media mechanism MUST contain a Date header.</t>
<t>The Identity-Media header field value.</t>
</list></t>
<figure>
<preamble>The hash is formed of these elements:</preamble>
<artwork><![CDATA[
digest-string = addr-spec "|" addr-spec "|"
Method "|" SIP-date "|"
attrib-bodyhash-list
]]></artwork>
<postamble>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.</postamble>
</figure>
<t>The Identity-Info header points to where the authentication
service's certificate can be retrieved from.</t>
</section>
<section title="Authentication Service">
<t>The authentication service examines the SIP message body to build
the Identity-Media header. For each message body found, in the order
found:</t>
<t><list style="symbols">
<t>if the body part is application/sdp, the authentication service
retrieves only the cryptographic attributes from the SDP (as
described in <xref target="techniques"></xref>), and appends that
information to the Identity-Media header.</t>
<t>otherwise, for all other body parts, the body part is hashed
using SHA-1, and the first 96 bytes are appended to the
Identity-Media header using "BPH=".</t>
</list></t>
<figure>
<preamble>For example, A SIP request with three bodyparts:
text/plain, application/sdp, and image/jpg, the Identity-Media
attribute would contain a bodypart hash of the text/plain part,
certain SDP attribute lines from the application/sdp bodypart
(a=fingerprint in this example), and a bodypart hash of the
image/jpg bodypart:</preamble>
<artwork><![CDATA[
Identity-Media: BPH="e32je3j23cjek3dz","a=fingerprint",
BPH="8fj289r3i892381c"
]]></artwork>
<postamble></postamble>
</figure>
<t>This Identity-Media header, along with the headers and portions of
headers described in <xref target="identity_media_signature"></xref>
are all signed by the authentication service. The resulting signature
is placed on the new Identity-Media-Signature header.</t>
</section>
<section title="Validation">
<t>The validation service can be performed by the remote endpoint
itself or by a device acting on behalf of the endpoint. The validation
service first checks the signature in the Identity-Media-Signature
field. If this is valid, the endpoint (or its validation service
operating on its behalf) then initiates a DTLS, TLS, ICE, or HIP
identity proof (<xref target="techniques"></xref>). This causes the
originating endpoint to prove possession of its private key that
corresponds to the certificate (or public key) that was signed by the
remote domain's authentication service.</t>
</section>
</section>
<section anchor="techniques" title="Proof of Identity Techniques">
<t>Four techniques are described below, TLS, DTLS, ICE, and HIP. Each
provides a means to cryptographically prove the identity signed by the
authentication service in SIP is the same as the identity on the media
path.</t>
<t>Each of these techniques work similarly -- a fingerprint of the
certificate (or, with ICE, the public key itself) is included in the
SDP. The authentication service creates a new Identity-Media header and
places into that header those SDP attribute names associated with that
technique. The authentication service then creates a signature over
specific SIP headers (see <xref
target="identity_media_signature"></xref>), and places that signature
into the new Identity-Media-Signature header. The SIP request is then
sent outside of the originating domain.</t>
<t>The receiving domain validates the Identity-Media-Signature. If
successful, the SIP request is forwarded to the end system. The end
system initiates a TLS, DTLS, ICE, or HIP session and validates that the
(signed) certificate fingerprint presented in the SIP signaling matches
the certificate presented in the TLS, DTLS, ICE, or HIP exchange. If
they match, and the TLS, DTLS, ICE, or HIP exchange completes
successfully, the local endpoint has validated the identity of the
remote endpoint.</t>
<t>Note: Due to SIP forking, the calling party may receive many identity
challenges, each incurring a public key operation to prove identity.
Mechanisms to deal with this are for future study.</t>
<section title="TLS ">
<t>TLS uses the "fingerprint" attribute to provide a hash of the
certificate in the SDP. The fingerprint attribute is defined by <xref
target="RFC4572"></xref> for TLS.</t>
</section>
<section title="DTLS">
<t>DTLS uses the same "fingerprint" attribute originally described for
TLS. The syntax is described in <xref
target="I-D.ietf-sip-dtls-srtp-framework"></xref>.</t>
<section title="SRTP after DTLS optional">
<t>[[Discussion Point: Is there interest in having identity without
SRTP??]]</t>
<t><figure>
<preamble>DTLS is only necessary to prove identity with DTLS;
<xref target="RFC3711">SRTP</xref> does not need to be used
afterwards. Obviously, using SRTP provides significant benefits
over continuing to use RTP, because an attacker can inject bogus
RTP after a successful validation of identity which is quite
undesirable. The SDP for doing RTP after a DTLS exchange might
be signaled in SDP by using "RTP/AVP" rather than "RTP/SAVP"
(lines folded for readability):</preamble>
<artwork><![CDATA[
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0 18
a=fingerprint:SHA-1
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
]]></artwork>
<postamble></postamble>
</figure>Of course, it would be desirable to more clearly indicate
this somehow in SDP. The example above collides with non-standard,
but deployed, "best-effort" media encryption mechanisms. <xref
target="I-D.ietf-mmusic-sdp-capability-negotiation">SDP Capability
Negotiation</xref> might be a useful consideration for this
functionality.</t>
</section>
</section>
<section anchor="ice_extension" title="ICE">
<t>ICE doesn't have inherent support for public/private keys. If
public keys were sent with other ICE attributes, there can be a real
risk of an ICE connectivity check exceeding the MTU. ICE lacks a
mechanism to fragment such large messages. It is also bandwidth
inefficient to send multiple ICE connectivity checks containing public
keys, either as retransmissions or with multiple candidates. Thus, for
ICE, the public key is sent in SDP and the public key's fingerprint is
exchanged on the media path -- opposite of TLS, DTLS, and HIP.</t>
<section title="ICE Public Key SDP Attribute">
<t>The offerer includes its public key, which it will use for the
subsequent PK-CHALLENGE and PK-RESPONSE, in its SDP. The syntax is a
BASE64-encoded version of the endpoint's public key.</t>
<t>The new attribute is called "ice-pub-key", which may appear on
the session level, media level, or both.</t>
</section>
<section title="New STUN attributes">
<t>Two new STUN attributes are defined to carry the plaintext
challenge and the encrypted response.</t>
<section title="PK-CHALLENGE">
<t>This is sent in a STUN Binding Request, and contains the bits
to be encrypted by the private key. Up to 256 bits can be included
in the challenge. When a STUN Binding Request is received
containing this attribute, the contents of the PK-CHALLENGE are
encrypted using the private key, and the result is included in the
PK-RESPONSE attribute of the Binding Response.</t>
<t>The PK-CHALLENGE MUST be the same for each candidate address
that is being tested for connectivity. If this requirement is not
followed, the peer will incur a public key operation for every ICE
connectivity check, which is not reasonable or necessary.</t>
</section>
<section title="PK-RESPONSE">
<t>This is sent in a STUN Binding Response from the offerer to the
answerer, and contains the encrypted result of the
PK-CHALLENGE.</t>
</section>
</section>
</section>
<section title="HIP">
<t>In <xref target="I-D.tschofenig-hiprg-host-identities"></xref>, a
new attribute "key-mgmt:host-identity-tag" is defined which contains
the hash of the public key used in the subsequent HIP exchange. This
can be utilized and signed exactly like the "fingerprint" attribute
for TLS or DTLS.</t>
</section>
</section>
<section anchor="abnf" title="ABNF">
<figure anchor="abnf_sip" title="ABNF for new SIP headers">
<preamble>The following figure shows the syntax of the new SIP header
fields using <xref target="RFC4234">ABNF</xref></preamble>
<artwork><![CDATA[
identity-media = "Identity-Media" HCOLON
attrib-bodyhash-list
attrib-bodyhash-list = attrib-bodyhash *(COMMA attrib-bodyhash)
attrib-bodyhash = quoted-attrib | quoted-bodyparthash
quoted-attribute = DQUOTE attribute DQUOTE ; SDP "a=" line
quoted-bodyhash = "BPH" EQUAL DQUOTE bodyparthash DQUOTE
bodyparthash = 32HEXDIG
identity-media-sig = "Identity-Media-Signature" HCOLON
signature
signature = DQUOT 32HEXDIG DQUOT
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]]></artwork>
<postamble></postamble>
</figure>
<t></t>
<figure anchor="abnf_sdp" title="ABNF for new SDP attribute">
<preamble>The following figure shows the syntax of the new SDP
attribute containing the ICE public key. This is used only by
endpoints implementing the ICE proof of identity technique (<xref
target="ice_extension"></xref>).</preamble>
<artwork><![CDATA[
ice-pub-key = token ; BASE64 encoded public key]]></artwork>
<postamble></postamble>
</figure>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>[[some of RFC4474's security considerations also apply.]]</t>
<section title="Device Disclosure">
<t>Although the mechanism described in this paper allows SBCs to be
used with a cryptographic identity scheme, it does expose the identity
of the user's certificate. If a unique certificate is installed on
each user's device, the remote party will be able to discern which
device is terminating the call. This problem is more pronounced when
SIP retargeting occurs in conjunction with <xref
target="RFC4916">Connected Identity</xref>.</t>
<t>If this isn't desired, there are two solutions:</t>
<t><list style="symbols">
<t>All devices under the control of the user will need to have the
same certificate (and associated private key) installed on
them.</t>
<t>The device needs to manufacture a new self-signed certificate
(or public key) for each call, and populate the appropriate SDP
attributes with that certificate (or public key). This is possible
because the identity service described in this paper does not
require the same certificate or public key to be used on every
call.</t>
</list></t>
</section>
</section>
<section title="Operational Differences from RFC4474">
<t>RFC4474 imposes one public key operation for the authentication
service and one for validation. If <xref target="RFC4916">Connected
Identity</xref> is used, only one additional public key operation is
necessary for the header signature validation; the expense of the DTLS,
TLS, or ICE public key operation has already been incurred by both
parties and is not repeated.</t>
<t>RFC4474 includes the Contact URI in the signed headers. That is not
required by this mechanism because it adds no security property, and
will fail validation when crossing SBCs and B2BUA's. It is of dubious
security value because Via/Record-Route can be inserted for response
interception regardless, and some requests don't contain a Contact
anyway (e.g., MESSAGE). It does not provide any replay/copy-paste
protection either, for the same reasons.</t>
<t>RFC4474 includes the CSeq in the signed headers. That is not required
by this mechanism because it adds little security, and will fail
validation when crossing SBCs and B2BUA's in some cases. It is of little
security value because it provides no protection from cut-paste attack
for different targets, and although it would prevent replay attack
within the same session, since the media key-related SDP portions are
signed anyway, replaying the request will not do anything useful.</t>
<t>RFC4474 includes the Call-Id in the signed headers. That is not
required by this mechanism because it adds little security, and will
fail validation when crossing SBCs and B2BUA's in some cases. It is of
little security value because it provides no protection from cut-paste
attack for different targets, and although it would prevent replay
attack for the same target, since the media key-related SDP portions are
signed anyway, replaying the request will not do anything useful.</t>
<t>The mechanism described in this document has the following advantages
over RFC4474:</t>
<t><list style="symbols">
<t>Only the edge network needs to create signatures on SIP requests
-- not every intervening SBC,</t>
<t>The original cryptographically-provable identity is preserved
across any number of SBCs, B2BUA's, etc.</t>
<t>SBCs, B2BUA's, and other "middle-boxes" in intermediate domains
do not need to be upgraded or changed in order for the originating
and terminating domains to use this new mechanism.</t>
</list></t>
</section>
<section title="Limitations">
<t>For the identity procedure described in this document to function,
every device -- including Session Border Controllers -- on the path MUST
permit DTLS, TLS, ICE, or HIP messages to be exchanged in the media
path. Further, those devices MUST NOT interfere with the signed SDP
attributes or the new SIP headers necessary for Identity Media to
operate.</t>
<t>For the technique described in this document to function, all on-path
SIP elements -- SBCs, B2BUAs, and SIP proxies -- MUST NOT interfere with
the signed headers. The identity mechanism described in this document is
not harmed if on-path SIP elements alter the SDP (e.g., by deleting
non-signed attributes, connection addresses, etc.).</t>
</section>
<section anchor="examples" title="Examples">
<section title="DTLS">
<t>This example shows how two a=fingerprint lines in SDP would
populate the Identity-Media SIP header field. The following is an
example of an INVITE created by the endpoint.</t>
<figure anchor="example_dtls" title="Example with DTLS">
<preamble>(lines folded for readability)</preamble>
<artwork><![CDATA[
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=- 6418913922105372816 2105372818 IN IP4 192.0.2.1
s=example2
c=IN IP4 192.0.2.1
t=0 0
m=audio 54113 RTP/SAVP 0
a=fingerprint:SHA-1
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
m=video 54115 RTP/SAVP 0
a=fingerprint:SHA-1
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB]]></artwork>
</figure>
<figure anchor="media_fingerprints_example"
title="SIP Headers Inserted by Authentication Service">
<preamble>The SIP proxy performing the Media Identity authentication
service would then insert the following three SIP headers into the
message. The Identity-Media header contains all of the SDP attribute
lines that are signed and the Identity-Media header contains the
signature of all of the relevant SIP headers and of the
Identity-Media header. Lines are folded for readability:</preamble>
<artwork><![CDATA[
Identity-Info: <https://atlanta.example.com/atlanta.cer>
;alg=rsa-sha1
Identity-Media: "a=fingerprint","a=fingerprint"
Identity-Media-Signature:
"ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa
ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn
FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U="]]></artwork>
</figure>
</section>
<section title="ICE">
<t>With ICE, the public key is exchanged in the signaling path (in
SDP) rather than in the media path (as is done with TLS, DTLS, and
HIP).</t>
<figure anchor="example_ice" title="Example with ICE">
<preamble>This is the INVITE as it left the SIP user agent (lines
folded for readability):</preamble>
<artwork><![CDATA[
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=- 6418913922105372816 2105372818 IN IP4 192.0.2.1
s=example2
c=IN IP4 192.0.2.1
t=0 0
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
a=pub-key:ejfiwj289ceucuezeceEJFjefkcjeiquiefekureickejfeefe
uirujejfecejejejkfeJJCEIUQQIEFJCQUCJCEQUURIE09dnjkeefjek
m=audio 54113 RTP/AVP 0
a=candidate:1 1 UDP 2130706431 192.0.2.1 54113 typ host]]></artwork>
</figure>
<t></t>
<figure anchor="media_fingerprints_ice"
title="Headers Inserted by Authentication Service">
<preamble>The SIP proxy performing the Media Identity authentication
service would then insert the following three SIP headers into the
message. The Identity-Media header contains the ICE public key
attribute and the Identity-Media header contains the signature of
all of the relevant SIP headers and of the Identity-Media header
(lines are folded for readability):</preamble>
<artwork><![CDATA[
Identity-Info: <https://atlanta.example.com/atlanta.cer>
;alg=rsa-sha1
Identity-Media: "a=pub-key"
Identity-Media-Signature:
"jjsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI+p6q5TOQXHMmz6uEo3svJsSH49th8qc
efQBbHC00VMZr2k+t6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0Ssjcd
VcunyaZucyRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Jcqe="]]></artwork>
</figure>
</section>
<section title="Request without SDP">
<t>This example shows how a SIP request without SDP is signed.</t>
<figure anchor="example_no_sdp" title="Example with no SDP">
<preamble>Message as sent by the UAC (lines folded for
readability)</preamble>
<artwork><![CDATA[
MESSAGE sip:user2@example.com SIP/2.0
Via: SIP/2.0/TCP user1pc.example.com;branch=z9hG4bK776sgdkse
Max-Forwards: 70
From: sip:user1@example.com;tag=49583
To: sip:user2@example.com
Call-ID: asd88asd77a@1.2.3.4
CSeq: 1 MESSAGE
Content-Type: text/plain
Content-Length: 18
Watson, come here.]]></artwork>
</figure>
<t></t>
<figure anchor="example_no_sdp_after_auth" title="added headers">
<preamble>The authentication service would add the following headers
to the above message:</preamble>
<artwork><![CDATA[
Identity-Info: <https://atlanta.example.com/atlanta.cer>
;alg=rsa-sha1
Identity-Media:
BPH="MZr2k+t6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxA"
Identity-Media-Signature:
"diOPoQZYOy2wrVghuhcsMbHWUSFxI+p6q5TOQXHMmz6uEo3svJsSH49th8qcjjsR
bHC00VMZr2k+t6efQBVmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB09JcVc
unyaZucyRlBYYQTLqWzJ+KVhPKbfU/pryhVnqeSsjcd="]]></artwork>
</figure>
</section>
</section>
<section title="Acknowledgements">
<t>The mechanism described in this paper is derived from Jon Peterson
and Cullen Jennings' <xref target="RFC4474"></xref>, which was formerly
a document of the SIP working group.</t>
<t>Thanks to Hans Persson for his suggestions which improved this
document.</t>
</section>
<section title="IANA Considerations">
<t>This document will add new IANA registrations for its new STUN
attributes.</t>
<t>[[This section will be completed in a later version of this
document.]]</t>
</section>
</middle>
<back>
<references title="Normative References">
&I-D.ietf-behave-turn;
&rfc2119;
&rfc4474;
&rfc3711;
&I-D.ietf-sip-dtls-srtp-framework;
&rfc4572;
&rfc4234;
&rfc4916;
&I-D.tschofenig-hiprg-host-identities;
&I-D.ietf-hip-base;
&I-D.farinacci-lisp;
&I-D.carpenter-idloc-map-cons;
&I-D.whittle-ivip-arch;
&I-D.ietf-mmusic-ice;
</references>
<references title="Informational References">
&I-D.ietf-sipping-sbc-funcs;
&rfc3325;
&I-D.ietf-mmusic-sdp-capability-negotiation;
</references>
<section title="ToDo List">
<t><list style="symbols">
<t>Add Table-2 of RFC3261</t>
<t>re-use RFC4474 response code for failures, or invent new
ones?</t>
<t>describe what occurs if both SIP-Identity-Media and SIP-Identity
are both used?</t>
</list></t>
</section>
<section title="Changes From Previous Versions">
<section title="Changes from 00 to 01">
<t><list style="symbols">
<t>Removed "Contact" header from signature. SBCs need to change
it.</t>
<t>Removed "Call ID" header from signature. This header often
contains an IP address, so many SBCs change it.</t>
<t>Removed "CSeq" header from signature. This header is sometimes
changed by SBCs and B2BUA's.</t>
<t>include SDP attribute names in Identity-Media signature. This
allows any attribute to be signed.</t>
<t>Old "Identity-Fingerprints" header renamed to "Identity-Media",
and only attribute names are listed in it, not attribute
values.</t>
<t>Old "Identity-Media" header renamed to
"Identity-Media-Signature".</t>
<t>Described how to sign SIP requests without an SDP body part,
and with a mix of SDP and non-SDP bodyparts.</t>
</list></t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 05:09:17 |