Network Working Group J. Rosenberg Internet-Draft C. Jennings Intended status: Standards Track Cisco Systems Expires: September 2, 2018 March 1, 2018 Bootstrapping STIR Deployments with Self-Signed Certs and Callbacks draft-rosenberg-stir-callback-00 Abstract Robocalling has become an increasing problem in the Public Switched Telephone Network (PSTN). A partial remedy for it is the provision of an authenticated caller ID in the PSTN, which today is lacking. Secure Telephone Identity Revisited (STIR) provides this through the usage of signed payloads in Session Initiation Protocol (SIP) calls. However, STIR deployment requires a global certificate system which allows for worldwide issuance of certifications that attest to which numbers a provider is responsible for. Such a system is likely to take years to rollout. To accelerate STIR deployment, this draft proposes a technique wherein STIR can be used without certificates that attest to number ownership. This is done through a combination of self-signed certificates, reverse callbacks and cached validations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 2, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. Rosenberg & Jennings Expires September 2, 2018 [Page 1] Internet-Draft STIR Callbacks March 2018 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 4. Interactions with RFC 8226 . . . . . . . . . . . . . . . . . 8 5. SS7 Interactions . . . . . . . . . . . . . . . . . . . . . . 9 6. Formal Protocol Specification . . . . . . . . . . . . . . . . 9 6.1. Originating Agent Behavior . . . . . . . . . . . . . . . 9 6.1.1. On Receipt of incoming INVITE . . . . . . . . . . . . 9 6.1.2. On Receipt of a Verifying INVITE . . . . . . . . . . 10 6.2. Terminating Agent Behavior . . . . . . . . . . . . . . . 10 6.2.1. On Receipt of Incoming INVITE . . . . . . . . . . . . 10 6.2.2. On Receipt of a Response to the Verifying INVITE . . 11 6.2.3. On expiration of the timer . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7.1. Attacks from the Calling Agent . . . . . . . . . . . . . 12 7.2. Attacks from the Called Agent . . . . . . . . . . . . . . 13 7.3. Attacks from the agent receiving the Verifying INVITE . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8.1. sip-verify Option Tag . . . . . . . . . . . . . . . . . . 14 8.2. Response Code 471 . . . . . . . . . . . . . . . . . . . . 14 8.3. Response Code 472 . . . . . . . . . . . . . . . . . . . . 14 8.4. Verify-Call Header . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Problem Statement Robocalling has become an increasing problem in the Public Switched Telephone Network (PSTN). Efforts to prevent it - such as the do- not-call list - have so far proven ineffective. Recently, robocallers have gotten even more crafty, and are tailoring the caller ID of incoming calls to match the area codes and exchanges of Rosenberg & Jennings Expires September 2, 2018 [Page 2] Internet-Draft STIR Callbacks March 2018 the recipients in order to increase the likelihood that targets pick up the phone. Part of the reason robocalling is possible is that the PSTN doesn't provide a way to authenticate caller ID. This problem has gotten worse through the deployment of the Session Initiation Protocol (SIP) [RFC3261] along with widespread availability of APIs (as an example, Twilio), which allow third parties to easily, at low cost, place calls with desired caller IDs to anywhere in the world. To remedy this, the Secure Telephony Identity (STIR) working group has undertaken to provide a way for e2e authenticated caller ID in SIP-based networks [RFC8224] [RFC8225] [RFC8226]. The core concept is to enable a signature over the SIP INVITE, the signature covering key SIP fields including the From header field containing the caller ID. The signature uses a certificate which is signed by an entity to whom the target has a trust chain, and more importantly, the certificate claims as part of its structure, the phone numbers that the calling party is permitted to claim. The primary challenge to deployment of STIR is the certification process. It requires a global certification system which can issue certificates to providers across the world, and furthermore, has the processes and database accesses required to assert the set of phone numbers owned by any carrier using the system. This is likely to require coordination amongst telcos, governments, regulators, and telco providers across the globe. Its scope of complexity is similar to ENUM [RFC2916] , which required a similar global infrastructure. ENUM was never successfully deployed. This document proposes a way to accelerate STIR deployments by relaxing the need for any such certification authority. It works with traditional self-signed certificates, and requires only that the calling domain and receiving domain support the protocol defined in this specification. This makes it much easier to deploy. If and when certificates with number ownership are deployed, they can easily co-exist with this proposal, phasing it out over time. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Rosenberg & Jennings Expires September 2, 2018 [Page 3] Internet-Draft STIR Callbacks March 2018 3. Overview of Operation Consider the following reference architecture: +----------+ | | | c.com | | | +-----+----+ | | +-------+-------+ | | | SIP | +----------+ | Core | +----------+ | | | Phone | | | | a.com +-----+ Network +-----+ b.com | | | | | | | +----+-----+ | | +-----+----+ | +---------------+ | | | ++ ++ || || ++ ++ Alice Bob (tel:2) (tel:1) Alice and Bob are telephone subscribers with phone numbers 2 and 1 respectively, using service providers a.com and b.com respectively. These two providers are connected to each other over a SIP network, which provides routing of calls between providers. A key assumption in this proposal is that this core network accurately routes calls to a specific number in a way which attackers cannot circumvent easily. It also assumes that sufficient portions of this core phone network are now SIP based, enabling delivery of SIP extension values between the originating and terminating providers. This second constraint is identical to in-band STIR. Note however that this proposal does not require SIP to the endpoints; it only assumes SIP between the originating and terminating call agents. While those agents could be SIP proxies or B2BUA, they could also be traditional circuit switched agents with SIP interfaces. We refer to this generically as a call agent. Alice places a call to Bob's telephone number. It arrives at Alice's agent - the calling agent. The calling agent has a self-signed certificate (the solution also works with traditional domain based Rosenberg & Jennings Expires September 2, 2018 [Page 4] Internet-Draft STIR Callbacks March 2018 certificates). Alice's agent uses this certificate to sign the INVITE as specified in [RFC8224] and [RFC8225]. The INVITE includes a Supported header field with the value stir-callback. This passes through the core SIP network, which ultimately delivers the call to the receiving agent based on traditional SIP routing logic. When the call arrives at Bob's agent, it verifies the signature per [RFC8224]. Bob's agent maintains a cache, called the validation cache, which is a mapping from caller IDs to public keys. When the call arrives, Bob checks whether the caller ID matches an entry in the cache. If there is no match - which is the case for the first call from this caller ID - Bob's agent performs a verifying callback to check the validity of the caller ID. To perform this callback, Bob's agent holds onto the incoming INVITE from Alice, and generates a completely separate INVITE, targeted back towards the number from the incoming caller ID. The verifying INVITE includes a Require header field with the value stir-callback. It also includes SDP, though the contents of this SDP are not relevant as they will never be used. The verifying INVITE also includes the Verify-Call header field. This header field is populated with value taken from the Identity header field of the incoming INVITE from Alice. The SIP core network will route the verifying INVITE towards the agent which owns Alice's number. There are three possible cases to consider. 1. The CallerID was correct. In this case, the verifying INVITE will return to one of Alice's call agents. The agent sees the presence of the Require: stir-callback header field. This tells the agent that this is not actually a real call to be completed towards Alice, but rather, a verifying callback to check that Alice's agent really meant to place the original call. As such, Alice's agent extracts the certifcate and signature values from the Verify-Call header field, and checks if they reprsent a valid certificate for signatures from Alice. If it is correct, Alice's agent rejects the INVITE with a 471 response code. This is a new response code which means the call itself should not proceed, but the receiving agent recognizes the the information in the Verify- Call header field as valid. Alice's agent creates a signature over the Call-ID in the incoming INVITE as well as the value in the Verify-Call header field, and includes this signature in the response, in the Verify-Call header field. When this error code reaches Bob's agent, Bob's agent verifies the signature using the public key from the inbound INVITE. Once this has verified, Rosenberg & Jennings Expires September 2, 2018 [Page 5] Internet-Draft STIR Callbacks March 2018 Bob's agent knows that the caller-ID in the original INVITE was valid. Bob's agent adds the caller-ID to its cache of validated numbers and associates it with the public key from the certificate. Any future calls with this certificate and caller ID from that source will be trusted and not require the verifying callback. The sequence diagram for this case: Alice's SIP Core Bob's Agent Agent Bob | | | | |-------------->| | | |INVITE tel:1 | | | |From: tel:2 | | | |Call-ID: X | | | |Supported: | | | | stir-verify | | | | |--------------->| | | |INVITE tel:1 | | | |From: tel:2 | | | |Call-ID: X | | | |Supported: | | | | stir-verify | | | | | | | | | | | |<-------------- | | | |INVITE tel:2 | | | |From: tel:1 | | | |Call-ID:Y | | | |Require: | | | | stir-verify | | | |Verify-Call: X | | | | | | |<--------------| | | |INVITE tel:2 | | | |From: tel:1 | | | |Call-ID:Y | | | |Require: | | | | stir-verify | | | |Verify-Call:X | | | | | | | |-------------->| | | |471 | | | |Call-ID: Y | | | |Verify-Call: | | | | sig(X,Y) | | | | |--------------->| | Rosenberg & Jennings Expires September 2, 2018 [Page 6] Internet-Draft STIR Callbacks March 2018 | |471 | | | |Call-ID: Y | | | |Verify-Call: | | | | sig(X,Y) | | | | | | | |<---------------| | | |ACK | | | |Call-ID: Y | | |<--------------| | | |ACK | |--------------->| |Call-ID: Y | |INVITE | | | |From: tel:1 | | | |To: tel:2 | | | |Call-ID:X | | | | | | | |<---------------| | | |200 OK | | | |Call-ID:X | | |<---------------| | | |200 OK | | | |Call-ID: X | | |<--------------| | | |200 OK | | | |Call-ID: X | | | | | | | | | | | | | | | | | | | | | | | 1. Alice's agent presented a false caller ID, and the agent which owns that false caller ID supports this extension. The verifying INVITE will route through the SIP core but arrive at a different agent, that of c.com. That agent supports the stir-verify option tag. However, when goes to validate the values from the Verify- Call header field, it will fail. In that case, it rejects the INVITE with a 472 response code. This is another new response code, which means the call itself should not proceed, and furthermore, the receiving agent did not recognize the information in the Verify-Call header field as valid. When Bob's agent receives this, it rejects the incoming INVITE with a 472 as well, informing Alice's agent that it rejected the call due to an invalid caller ID. 2. Alice's agent presented a false caller ID, and the agent which owns that false caller ID does not support this extension. When the verifying INVITE arrives at c.com's agent, it will reject the INVITE as normal with a 420 response code due to the presence of Rosenberg & Jennings Expires September 2, 2018 [Page 7] Internet-Draft STIR Callbacks March 2018 the unsupported Require option tag. This is routed back to Bob's agent. The receipt of a 420 could signify a malicious caller ID, but could also indicate that there was an intermediate PSTN gateway in the SIP core, in which case the caller ID could be authentic. In this case, Bob's agent MAY complete the call towards the caller. Each agent builds its own cache of validated certificates for caller ID values. These caches do not need to be shared between providers; they are purely localized to a single administrative entity. The cache entries are invalidated based on the lifetime of the certificate, or through the receipt of an incoming INVITE whose caller ID matches a cache entry, but with a different public key in the certificate. This can happen legitimately due to a number port. In such a case, the receiving agent removes the cache entry and re- performs the validation callback. Open Issue: Should a new public key invalidate previos ones or should multiple public keys for same caller ID be allowed. The design proposed here uses an INVITE in the reverse direction, rather than an OPTIONS request or another extension, to maximize the probability that the verifying call actually traverses the SIP core. The significant number of SBCs and other entities which are not likely to pass OPTIONS or non-INVITE requests makes this the best approach for success. It also ensures that the same policy that would be use to route a real call, routes the verifying call. The presence of the Require header field in the verifying INVITE is critical to the operation of the solution. It prevents the verifying INVITE from actually ringing a real phone, which would be quite annoying. 4. Interactions with RFC 8226 This mechanism provides a technique for deploying STIR prior to the availability of RFC 8226 certificates. It also works nicely in conjunction with incremental deployment of RFC 8226. In the case where an originating agent supports both this specification and RFC 8226, it would use the RFC 8226 certificates which cryptographically assure its ownership of the number in the From header field. When this is received at the terminating agent, if that agent supports both RFC 8226 and this specification, it first checks for the presence of the RFC 8226 certificate. If present and valid, it proceeds with the call and no verifying callback is required. If the certificate is RFC 8226 compliant but the number Rosenberg & Jennings Expires September 2, 2018 [Page 8] Internet-Draft STIR Callbacks March 2018 does not match the one in the From header field, or there was no RFC 8226 certificate present, the verifying INVITE is generated. The consequence of this co-existence is that the volume of verifying callbacks decreases as RFC 8226 is deployed, and the overall system provides verified caller ID the entire time. 5. SS7 Interactions In reality, significant portions of the PSTN traffic between carriers remain powered by SS7 and not SIP. If that happens, the verifying INVITE might hit an SS7 gateway which is not an agent acting on behalf of Alice. There are two subcases. In one case, the SS7 gateway does not support this extension. When that happens, the INVITE is rejected with a 420. As described above, Bob's agent will pass the call to Bob. If however the SS7 gateway does support this extension, it still rejects the request with a 420 error code. This is because the overall system - the PSTN - does not support the extension and the call cannot be passed through the PSTN. TODO: consider specifying an SS7 gateway function and corresponding SS7 extension; this extension needs only a single bit to pass through the SS7 network, and two bits in the call rejection message. It is worth noting that SS7 extensions may be needed to pass the PASSporT information. Need to investigate if that is possible. 6. Formal Protocol Specification This specification defines behavior for two entities - an originating agent and a terminating agent. An entity acting as an originating or terminating agent can be a proxy or a B2BUA. However, it MUST be the registrar of record for the user on whose behalf it operates. 6.1. Originating Agent Behavior 6.1.1. On Receipt of incoming INVITE When an originating agent is acting as an outbound proxy on behalf of the user and receives an outbound INVITE from a user (no Require header field with a value of stir-verify), it MUST include a Supported header field in the INVITE with a value of stir-verify. It MUST add an entry to a table, the pending transactions table. Rosenberg & Jennings Expires September 2, 2018 [Page 9] Internet-Draft STIR Callbacks March 2018 Furthermore, the originating agent MUST follow the procedures defined in [RFC8224] and [RFC8225] to compute a passport and create a signature over it. It MAY utilize either a self-signed certificate or a traditional domain based certificate. 6.1.2. On Receipt of a Verifying INVITE When an originating agent receives an INVITE with a Require header field containing the value stir-verify, it MUST examine the INVITE for the presence of a Verify-Call header field. If this header field is not present, the originating agent MUST reject the INVITE with a 400 error code. If the header field is present, the agent extracts the value there, and checks that it represets a valid PASSporT signature using any self singned certificates for the caller ID. If it is valid, it MUST reject the incoming INVITE with a response code of 471. If it is not valid, it MUST reject the incoming INVITE with a 472 response code. A response with a 471 response code MUST contain a signature, placed into the Verify-Call header field in the response. This signature is computed by taking the caller ID from the incoming INVITE, concatenating it with the value present in the Verify-Call header field, and then using that as an input to the signature function. TODO: provide detailed spec on signature function. Open Issue: is this signature in 471 needed? 6.2. Terminating Agent Behavior 6.2.1. On Receipt of Incoming INVITE When a terminating agent receives an incoming request for a user on whose behalf it operates, it checks for the existence of the Supported header field with a value of stir-verify. If not present, the agent SHOULD pass the call to the targeted user. If present, the agent behaves as follows. The agent SHOULD maintain a validation cache. This cache is indexed by E.164 number, and contains as a value the public key of the certificate for the agent that was validated as being authoritative for that number. The agent extracts the number from the From header field of the incoming INVITE. It performs the validation processing defined in [RFC8224] to verify the signature. Once validated, it checks the value of the From header field against the cache. Rosenberg & Jennings Expires September 2, 2018 [Page 10] Internet-Draft STIR Callbacks March 2018 If there is a matching cache entry, and the public key in the cache entry matches that of the certificate, the agent SHOULD forward the original INVITE towards the called party. If there is a matching cache entry, but the public key in the cache entry does not match that of the certificate, the agent MUST invalidate the cache entry and proceed as if there was no match. If there was no matching entry in the cache, the agent constructs a new INVITE header field. The Request-URI and To header field of this INVITE MUST match that of the From header field from the incoming INVITE. The From header field MUST be set to the value from the To header field in the incoming INVITE. The request MUST contain a Require header field with value stir-verify. The request MUST contain any valid SDP offer [RFC3264]. This request MUST then be sent towards the request URI in the same way it would have been sent had it been received from its own user. The agent sets a timer, with a RECOMMENDED value of 5 seconds. This represents the maximum amount of time the agent will wait for a response to the verifying INVITE before passing the call onwards to the the target of the incoming call. 6.2.2. On Receipt of a Response to the Verifying INVITE If the terminating agent receives a 471 response to the verifying INVITE, it MUST look for the presence of a Verify-Call header field in the response. If not present, the original INVITE is rejected with a 472, and it MUST NOT add an entry to its validation cache. The signature from this Verify-Call header field is verified, and checked to match against the public key used in the incoming INVITE. If not valid, the original INVITE is rejected with a 472, and it MUST NOT add an entry to its validation cache. If the signature is valid, It SHOULD add an entry to its validation cache. This cache is indexed by the caller ID present in the From header field of the original INVITE. Its value is the public key from the certificate in the incoming INVITE. If the terminating agent receives a 472 response to the verifying INVITE, it MUST NOT add an entry to its validation cache. It SHOULD reject the original INVITE with a 472 error response. If the terminating agent receives a 420 response to the verifying INVITE, it MUST NOT add an entry to its validation cache. It SHOULD forward the original INVITE towards the called party. Rosenberg & Jennings Expires September 2, 2018 [Page 11] Internet-Draft STIR Callbacks March 2018 6.2.3. On expiration of the timer If the 5 second timer fires before a response has been received to the verifying INVITE, the agent SHOULD CANCEL the verifying INVITE. It SHOULD forward the original INVITE towards the called party. 7. Security Considerations The primary purpose of this specification is to improve the security of caller ID in the public SIP-based phone network. We can consider three actors in the system, and examine malicious behavior from each. These actors are the caller, the callee, and the agent receiving the verifying INVITE. 7.1. Attacks from the Calling Agent The primary attack the caller can launch is to place a call with a faked caller ID. Preventing this attack is the primary purpose of this specification. This specification prevents it under the assumption that the SIP core network provides forward routability, and therefore, the caller ID is valid if the agent that placed the call, would also receive a call placed towards that callerID. This relationship is verified with the signature over the callerID in both INVITE requests. It is possible in this system for the calling agent to lie about the callerID, but for the fake caller ID to be associated with the number space owned by that agent. In that case, the calling agent can verify its own faked caller ID. However, since the originating agent is in purview of the usage of its own numbers, there is little that can be done to solve this attack, and in many regards it is not an attack. As an example, outbound call center calls frequently "lie" about the caller ID by placing the company main number in the callerID. Since both are owned by the same administrative entity, this is an acceptable use case. In a different attack, the calling agent is malicious. It doesn't lie about its callerID in the outbound INVITE. However, when the verifying call arrives, the calling agent rejects it with a 472, indicating that the caller ID was faked. The only affect of this action would have is to cause the verify call placed by the calling agent to be rejected, and therefore seems to serve no purpose. An additional consideration is whether the mechanism specified here can be used as a denial of service attack. Consider a malicious originating agent which purposefully inserts a fake caller ID, not to be delivered to the called party, but to trigger a verifying INVITE to the agent which actually owns that phone number. Indeed, based on Rosenberg & Jennings Expires September 2, 2018 [Page 12] Internet-Draft STIR Callbacks March 2018 this specification, the terminating agent will in fact generate such an INVITE. However, since the attacker must emit a single INVITE in order to cause the terminating agent to generating a single INVITE, there is no amplification possible. 7.2. Attacks from the Called Agent Consider the case where the called agent is malicious. The calling agent A is not malicious, and places a legitimate call with a valid caller ID (tel:2) to agent B. Agent B places a new call (not a verifying call) to a third agent, agent C, using the same Call-ID as the incoming INVITE it just received, and claims the caller ID tel:2. When agent C places a verifying call for this caller ID, tel:2, it will be routed back to agent A. In this case, because there is in fact a valid call in progress from agent A with that caller ID, the verifying call will succeed. This will cause agent C to believe that agent A legitimately owns the caller ID tel:2, and agent C now caches the certificate from agent B. Agent B is now free, at will to place calls towards agent C with the fake caller ID. This is prevented through the usage of the signatures in the 471 response codes. In this attack, the signature used by A to sign the response will use its own public certificate. This will not match the one used in the inbound INVITE from B to C which triggered the verifying call. Therefore, B will reject the incoming INVITE and will not update its validation cache. 7.3. Attacks from the agent receiving the Verifying INVITE In the case where the caller is malicious, and so is the agent receiving the verifying INVITE, it is possible (even without collusion) that the agent receiving the verifying INVITE responds with a 471 to the verifying INVITE, even though it doesn't actually own the number in question. It might do this in an attempt to pollute the cache of the called agent with an invalid entry. This is prevented through the usage of signatures in the 471 response. Since the agent receiving the verifying INVITE is not the same as the calling agent, and there is no collusion in which private keys are shared, the signature in the 471 will not match that of the incoming INVITE. This will cause the incoming INVITE to be rejected, and no valid cache entry is added. 8. IANA Considerations This specification registers a new SIP option code and two new response codes. Rosenberg & Jennings Expires September 2, 2018 [Page 13] Internet-Draft STIR Callbacks March 2018 8.1. sip-verify Option Tag This section registers a new SIP option-tag, sip-verify. The required information for this registration, as specified in RFC 3261, is: Name: sip-verify Description: This option code indicates support for verification of caller ID using a verifying INVITE. When present in a Supported header field, if informs the recipient that it can, and should, generate a verifying INVITE to confirm the caller ID. When present in a Require header field, it tells the receiving agent that the purpose of the INVITE is to validate that a prior call had been placed, and that the INVITE should not actually be passed to the target of the INVITE. 8.2. Response Code 471 This section registers a new SIP response code, 471. The required information for this registration, as specified in RFC 3261, is: RFC Number: NOTE TO RFC-EDITOR: replace with the RFC number of this specification. Response Code Number: 471 Default Reason Phrase: Caller ID Verified 8.3. Response Code 472 This section registers a new SIP response code, 472. The required information for this registration, as specified in RFC 3261, is: RFC Number: NOTE TO RFC-EDITOR: replace with the RFC number of this specification. Response Code Number: 472 Default Reason Phrase: Caller ID Not Verified 8.4. Verify-Call Header TODO Rosenberg & Jennings Expires September 2, 2018 [Page 14] Internet-Draft STIR Callbacks March 2018 9. Acknowledgments Thanks for Richard Barnes for identifying the attacks described in the Security Considerations section. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, . [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, "Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 8224, DOI 10.17487/RFC8224, February 2018, . [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, . 10.2. Informative References [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, DOI 10.17487/RFC2916, September 2000, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity Credentials: Certificates", RFC 8226, DOI 10.17487/RFC8226, February 2018, . Rosenberg & Jennings Expires September 2, 2018 [Page 15] Internet-Draft STIR Callbacks March 2018 Authors' Addresses Jonathan Rosenberg Cisco Systems Email: jdrosen@jdrosen.net Cullen Jennings Cisco Systems Email: fluffy@iii.ca Rosenberg & Jennings Expires September 2, 2018 [Page 16]