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 May 18, 2008.
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.
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.
2. Notational Conventions
3. Analysis of SIP-Identity with SBCs
3.1. SIP-Identity with SBCs
3.1.1. Validate the Signature
3.1.2. Destroy Existing Signature
3.1.3. Create New Identity
3.1.4. Sign the New Identity
3.2. Transport Address as Identifier
4.1. Identity Media Signature
4.2. Authentication Service
5. Proof of Identity Techniques
5.2.1. SRTP after DTLS optional
5.3.1. ICE Public Key SDP Attribute
5.3.2. New STUN attributes
7. Security Considerations
7.1. Device Disclosure
8. Operational Differences from RFC4474
10.3. Request without SDP
12. IANA Considerations
13.1. Normative References
13.2. Informational References
Appendix A. ToDo List
Appendix B. Changes From Previous Versions
B.1. Changes from 00 to 01
§ Authors' Addresses
§ Intellectual Property and Copyright Statements
SIP Identity (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) [RFC4474] 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.
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 P-Asserted-Identity (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.) [RFC3325] 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.
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 ICE (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) [I‑D.ietf‑mmusic‑ice]. This mechanism is also extensible, in order to be usable by future mechanisms which need signed SDP attributes
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.
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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
This section examines how SIP Identity (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) [RFC4474] operates with SBCs(Section 3.1 (SIP-Identity with SBCs)) or certain back-to-back user-agents (B2BUAs), and how SIP Identity uses transport addresses as identifiers (Section 3.2 (Transport Address as Identifier)).
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.
The functions of SBCs, and why they do what they do, is mainly detailed in [I‑D.ietf‑sipping‑sbc‑funcs] (Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen, A., and M. Bhatia, “Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments,” February 2010.). 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:
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
+---------+ +---------+ +---------+ +---------+ |SP1-SBC-1|-|SP1-SBC-2|--|SP2-SBC-1|--|SP2-SBC-2| +---+-----+ +---------+ +---------+ +-+-------+ | | | | +--------------+ +------+-------+ |SIP User Agent| |SIP User Agent| | Enterprise-A | | Enterprise-B | +--------------+ +--------------+
| Figure 1: Two Service Providers with SBCs Between Two Enterprises |
Enterprise-A can populate the "From:" address in its SIP requests using E.164 telephone numbers (e.g., 'sip:+email@example.com;user=phone') or using a SIP URI (e.g., 'sip:firstname.lastname@example.org'). The characteristics of each choice, as the message traverses the SBCs operated by another administrative domain (service providers) are described below:
Per RFC4474, the SBC would validate the incoming SIP request. This requires a public key operation to be performed against the SIP request.
[[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.]]
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.
SBCs and B2BUAs typically modify the media transport addresses and thus invalidate the RFC4474 signature. This prevents downstream systems from validating original signature.
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.
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.
The new identity creates difficulties with downstream whitelists, call routing, and reputation systems. For example, downstream systems may sometimes see the identity +email@example.com when the request is routed through certain SBCs, and may see a different identity, +firstname.lastname@example.org, 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.
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:
- E.164 telephone numbers:
- The SBC would remove the original domain name and substitute its own domain on the right-hand side.
- SIP URIs:
- 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:email@example.com to sip:firstname.lastname@example.org.
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.
SIP Identity signs the SDP so that the IP address (contained in the SDP) provides identity. From [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.):
"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."
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., [I‑D.ietf‑hip‑base] (Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, “Host Identity Protocol,” October 2007.), [I‑D.farinacci‑lisp] (Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” March 2009.), [I‑D.carpenter‑idloc‑map‑cons] (Carpenter, B., “General Identifier-Locator Mapping Considerations,” June 2007.), [I‑D.whittle‑ivip‑arch] (Whittle, R., “Ivip (Internet Vastly Improved Plumbing) Architecture,” March 2010.)).
The presence of media relays (e.g., TURN (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.) [I‑D.ietf‑behave‑turn]), 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.
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 ICE (Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” October 2007.) [I‑D.ietf‑mmusic‑ice], 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.
The operation of SIP-Identity-Media is similar to RFC4474 and uses authentication service proxies much like RFC4474. The basic steps are:
The following figure shows how the Authentication Service and the media validation is performed. The figure assumes the endpoints themselves perform the media validation.
: 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 | | : | : | | : :
| Figure 2: Message Flow |
- Step 1:
- 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.
- Step 2:
- 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. [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]
- Step 3:
- 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.
- Step 4:
- 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.
- Step 5:
- If the validation was successful, the terminating endpoint's authentication service forwards the INVITE to the endpoint.
- Step 6:
- 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.
- Step 7:
- 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.
- Step 8:
- The terminating endpoint can reliably and honestly indicate calling party information ("caller-id") and ring the phone.
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 Section 5 (Proof of Identity Techniques).
The SIP headers that are signed, for the signature placed into the Identity-Media-Signature header are:
The hash is formed of these elements:
digest-string = addr-spec "|" addr-spec "|" Method "|" SIP-date "|" attrib-bodyhash-list
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.
The Identity-Info header points to where the authentication service's certificate can be retrieved from.
The authentication service examines the SIP message body to build the Identity-Media header. For each message body found, in the order found:
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:
Identity-Media: BPH="e32je3j23cjek3dz","a=fingerprint", BPH="8fj289r3i892381c"
This Identity-Media header, along with the headers and portions of headers described in Section 4.1 (Identity Media Signature) are all signed by the authentication service. The resulting signature is placed on the new Identity-Media-Signature header.
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 (Section 5 (Proof of Identity Techniques)). 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.
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.
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 Section 4.1 (Identity Media Signature)), and places that signature into the new Identity-Media-Signature header. The SIP request is then sent outside of the originating domain.
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.
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.
TLS uses the "fingerprint" attribute to provide a hash of the certificate in the SDP. The fingerprint attribute is defined by [RFC4572] (Lennox, J., “Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP),” July 2006.) for TLS.
DTLS uses the same "fingerprint" attribute originally described for TLS. The syntax is described in [I‑D.ietf‑sip‑dtls‑srtp‑framework] (Fischl, J., Tschofenig, H., and E. Rescorla, “Framework for Establishing an SRTP Security Context using DTLS,” March 2009.).
[[Discussion Point: Is there interest in having identity without SRTP??]]
DTLS is only necessary to prove identity with DTLS; SRTP (Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” March 2004.) [RFC3711] 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):
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
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. SDP Capability Negotiation (Andreasen, F., “SDP Capability Negotiation,” March 2010.) [I‑D.ietf‑mmusic‑sdp‑capability‑negotiation] might be a useful consideration for this functionality.
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.
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.
The new attribute is called "ice-pub-key", which may appear on the session level, media level, or both.
Two new STUN attributes are defined to carry the plaintext challenge and the encrypted response.
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.
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.
This is sent in a STUN Binding Response from the offerer to the answerer, and contains the encrypted result of the PK-CHALLENGE.
In [I‑D.tschofenig‑hiprg‑host‑identities] (Tschofenig, H., Ott, J., Schulzrinne, H., Henderson, T., and G. Camarillo, “Interaction between SIP and HIP,” February 2008.), 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.
The following figure shows the syntax of the new SIP header fields using ABNF (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.) [RFC4234]
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
| Figure 3: ABNF for new SIP headers |
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 (Section 5.3 (ICE)).
ice-pub-key = token ; BASE64 encoded public key
| Figure 4: ABNF for new SDP attribute |
[[some of RFC4474's security considerations also apply.]]
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 Connected Identity (Elwell, J., “Connected Identity in the Session Initiation Protocol (SIP),” June 2007.) [RFC4916].
If this isn't desired, there are two solutions:
RFC4474 imposes one public key operation for the authentication service and one for validation. If Connected Identity (Elwell, J., “Connected Identity in the Session Initiation Protocol (SIP),” June 2007.) [RFC4916] 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.
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.
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.
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.
The mechanism described in this document has the following advantages over RFC4474:
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.
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.).
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.
(lines folded for readability)
INVITE sip:email@example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 To: Bob <sip:firstname.lastname@example.org> From: Alice <sip:email@example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:firstname.lastname@example.org> 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
| Figure 5: Example with DTLS |
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:
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="
| Figure 6: SIP Headers Inserted by Authentication Service |
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).
This is the INVITE as it left the SIP user agent (lines folded for readability):
INVITE sip:email@example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 To: Bob <sip:firstname.lastname@example.org> From: Alice <sip:email@example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:firstname.lastname@example.org> 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
| Figure 7: Example with ICE |
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):
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="
| Figure 8: Headers Inserted by Authentication Service |
This example shows how a SIP request without SDP is signed.
Message as sent by the UAC (lines folded for readability)
MESSAGE sip:email@example.com SIP/2.0 Via: SIP/2.0/TCP user1pc.example.com;branch=z9hG4bK776sgdkse Max-Forwards: 70 From: sip:firstname.lastname@example.org;tag=49583 To: sip:email@example.com Call-ID: firstname.lastname@example.org CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 Watson, come here.
| Figure 9: Example with no SDP |
The authentication service would add the following headers to the above message:
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="
| Figure 10: added headers |
The mechanism described in this paper is derived from Jon Peterson and Cullen Jennings' [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.), which was formerly a document of the SIP working group.
Thanks to Hans Persson for his suggestions which improved this document.
This document will add new IANA registrations for its new STUN attributes.
[[This section will be completed in a later version of this document.]]
|[I-D.ietf-behave-turn]||Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” draft-ietf-behave-turn-16 (work in progress), July 2009 (TXT).|
|[RFC2119]||Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).|
|[RFC4474]||Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” RFC 4474, August 2006 (TXT).|
|[RFC3711]||Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, “The Secure Real-time Transport Protocol (SRTP),” RFC 3711, March 2004 (TXT).|
|[I-D.ietf-sip-dtls-srtp-framework]||Fischl, J., Tschofenig, H., and E. Rescorla, “Framework for Establishing an SRTP Security Context using DTLS,” draft-ietf-sip-dtls-srtp-framework-07 (work in progress), March 2009 (TXT).|
|[RFC4572]||Lennox, J., “Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP),” RFC 4572, July 2006 (TXT).|
|[RFC4234]||Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” RFC 4234, October 2005 (TXT, HTML, XML).|
|[RFC4916]||Elwell, J., “Connected Identity in the Session Initiation Protocol (SIP),” RFC 4916, June 2007 (TXT).|
|[I-D.tschofenig-hiprg-host-identities]||Tschofenig, H., Ott, J., Schulzrinne, H., Henderson, T., and G. Camarillo, “Interaction between SIP and HIP,” draft-tschofenig-hiprg-host-identities-06 (work in progress), February 2008 (TXT).|
|[I-D.ietf-hip-base]||Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, “Host Identity Protocol,” draft-ietf-hip-base-10 (work in progress), October 2007 (TXT).|
|[I-D.farinacci-lisp]||Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, “Locator/ID Separation Protocol (LISP),” draft-farinacci-lisp-12 (work in progress), March 2009 (TXT).|
|[I-D.carpenter-idloc-map-cons]||Carpenter, B., “General Identifier-Locator Mapping Considerations,” draft-carpenter-idloc-map-cons-01 (work in progress), June 2007 (TXT).|
|[I-D.whittle-ivip-arch]||Whittle, R., “Ivip (Internet Vastly Improved Plumbing) Architecture,” draft-whittle-ivip-arch-04 (work in progress), March 2010 (TXT).|
|[I-D.ietf-mmusic-ice]||Rosenberg, J., “Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols,” draft-ietf-mmusic-ice-19 (work in progress), October 2007 (TXT).|
|[I-D.ietf-sipping-sbc-funcs]||Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen, A., and M. Bhatia, “Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments,” draft-ietf-sipping-sbc-funcs-09 (work in progress), February 2010 (TXT).|
|[RFC3325]||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 (TXT).|
|[I-D.ietf-mmusic-sdp-capability-negotiation]||Andreasen, F., “SDP Capability Negotiation,” draft-ietf-mmusic-sdp-capability-negotiation-13 (work in progress), March 2010 (TXT).|
|Cisco Systems, Inc.|
|170 West Tasman Drive|
|San Jose, CA 95134|
|71 Third Ave.|
|Burlington, MA 01803|
Copyright © The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
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 email@example.com.