TIR BOF Group H. Kaplan Internet Draft Oracle Intended status: Standards Track July 12, 2013 Expires: January 30, 2014 An Identity Key-based and Effective Signature for Origin-Unknown Types draft-kaplan-stir-ikes-out-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 12, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Kaplan, et al Expires January 2014 [Page 1] Internet-Draft STIR IKES OUT July 2013 Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document describes a mechanism and format for signing source identity information of communication requests, in a manner capable of crossing multiple communication protocol types - even if the origin's protocol type is unknown. This is useful for providing E.164 and other forms of Caller-ID reputability for various communication protocols, such as SIP, XMPP, WebRTC, H.323, and SS7/ISUP. Table of Contents 1. Terminology...................................................2 2. Introduction..................................................3 3. Overview of Operations........................................4 4. Background....................................................5 4.1. Identity Types: E.164 vs. Number Codes vs. Email-style...8 4.2. Determining Canonical E.164 Numbers and Number Codes.....9 4.3. Determining Canonical Email-style Names.................10 4.4. Call-forwarding Issues..................................11 5. IKES Generator Behavior......................................12 6. IKES Verifier Behavior.......................................14 7. IKES Information Field.......................................17 8. Usage in SIP.................................................19 9. Usage in XMPP................................................21 10. Usage in SS7/ISUP...........................................22 10.1. SIP-SS7 Interworking...................................24 11. Usage in H.323 and ISDN.....................................24 12. Open Issues.................................................25 13. Security Considerations.....................................25 14. IANA Considerations.........................................26 15. Acknowledgments.............................................27 16. References..................................................27 16.1. Normative References...................................27 16.2. Informative References.................................27 Author's Address................................................28 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". Kaplan Expires January 2014 [Page 2] Internet-Draft STIR IKES OUT July 2013 Caller-ID: the identity of the originator of a communications request, such as a SIP INVITE call setup request or MESSAGE instant message request. Technically the Caller-ID is only what is displayed to receiving users, and does not necessarily have to be the source of the call. For the purposes of this document this distinction is not important. E.164 number: a phone number in international E.164 format, which is understood by the originating and receiving entities to represent a globally unique number, regardless of any syntactic encoding for a domain portion. Changing the domain portion would not fundamentally change the identity of the resource. Number code: a nationally-specific number which is not representable as an E.164 number. Examples of number codes include two or three digit emergency service numbers, N11-type numbers in NANP, and inter-carrier common short codes. Email-style name: a 'user@domain' format identity, for which the user portion is scoped to the domain portion; removing or changing the domain portion would fundamentally change the identity of the user. Source identity: the E.164 number, number code, or email-style name used for identifying the originator of a message to the receiving user; i.e., the identity used for "Caller-ID". Destination identity: the E.164 number, number code, or email-style name of the original destination of a message; i.e., the original called party. NANP: North American Numbering Plan. This document is not specific to North America, but the term "NANP" is used in some cases. It is assumed the reader is generally familiar with E.164 numbers, asymmetric key cryptography concepts, and the SIP-Identity mechanism defined in [RFC4474]. 2. Introduction In order to provide source identity assurance (i.e., authentic Caller-ID), the SIP-Identity mechanism defined in [RFC4474] cryptographically signs certain SIP request header fields and the message body, stores the resulting signature in a SIP 'Identity' header, and defines the process by which a receiving node can verify the signature and thereby validate the source identity. Kaplan Expires January 2014 [Page 3] Internet-Draft STIR IKES OUT July 2013 Unfortunately, the [RFC4474] signature is not usable if the request is forwarded/routed by many common types of SIP Back-to-back User- Agents (B2BUAs), nor if the request crosses from SIP to another protocol such as XMPP, H.323 or SS7/ISUP. Even in pure SIP scenarios, B2BUAs are likely to be in the request path, making [RFC4474] unusable in practice. Furthermore, [RFC4474] is not sufficient for use in validating source identities that are treated as E.164 numbers. Unlike 'user@domain' email-style identities, an E.164 number is a national or global identity and not scoped within a domain. Authenticating the domain that sent the identity is not sufficient to determine if that domain can actually represent the E.164 identity. Without such proof, any domain could claim any E.164 number. This document proposes a new signature-based mechanism that is usable in more complex scenarios, including those crossing B2BUAs and disparate protocol types. This document does *not* define how the public keys or Certificates used for validation are stored nor retrieved, nor how the public-key/certificate is determined to be authoritative for the identity. That portion of the overall solution is still being discussed in the IETF, and could be documented separately. This document only proposes how the identity signature itself could be created and encoded, such that it is usable once a certificate authority model and means of retrieving certificates are defined. [Note: apologies about the term 'IKES' - this was not meant to cause confusion with Internet Key Exchange (IKE), but rather to provide something more important: a cute name for the draft, at least for baseball fans (Go Red Sox!)] 3. Overview of Operations This section provides an informative (non-normative) high-level overview of the mechanisms described in this document. Imagine the case where Alice, who has the home proxy of example.com and a US National number of 212-555-1010, wants to communicate with Bob in example.org.uk, who has the international E.164 number +443069991010. Alice is using SIP, so she generates an INVITE and puts her Address of Record (AoR) in the From header field of the request by using 'sip:2125551010@example.com' as the From URI. She then sends the INVITE to a proxy for her domain, which authenticates the request as well as Alice's ability to use the identity that is populated in the From header field. Kaplan Expires January 2014 [Page 4] Internet-Draft STIR IKES OUT July 2013 The proxy, or some other system of the domain with the same knowledge, knows that Alice's SIP AoR is logically the international E.164 number '12125551010', and generates a string based on the source and destination identity numbers, with additional information to prevent replay attacks. This IKES information string is then encoded into a new SIP header field, along with a cryptographic signature of the hash of the information string. The key used for the signature is a private key, for which a corresponding public key is used by Bob's domain to verify the Caller-ID. The proxy, as the holder of the private key for Alice's E.164 number, is asserting that the originator of this request has been authenticated and that she is authorized to claim the identity that appears in the From header field. How the public key is retrieved or determined by Bob's domain to be authoritative for the E.164 phone number is beyond the scope of this document. The INVITE request from Alice's domain might be inter-worked to other protocols, such as SS7 or H.323, and Bob's domain might not even use SIP as its communication protocol. So long as Bob's domain receives the same IKES information and signature, it can determine if the originating Caller-ID is valid for the given message action type. When Bob's domain receives the request, it verifies the IKES information and signature provided in whatever protocol field Bob's domain uses, and thus can validate that the Caller-ID is valid for the request. For phone-number identities, Alice and Bob's domains need to have a means of providing and retrieving public keys in such a way that Bob's domain can know the holder of the private key is authorized to assert the E.164 number, regardless of what domain it originated from. For email-style identities, the same must be known for an assertion of Alice's domain name but not her specific user identity; instead, so long as Bob knows example.com signed the message, he can believe it is from Alice in example.com. 4. Background The general concept of IKES is to generate a cryptographic signature similar to that in [RFC4474], except only for information that is necessary and sufficient to provide Caller-ID reputability. The information being signed is constrained so as to be protocol- agnostic, work through intermediaries, and with a resulting value that can work through and fit in the least-extensible protocol: SS7/ISUP. Kaplan Expires January 2014 [Page 5] Internet-Draft STIR IKES OUT July 2013 Similar to [RFC4474], IKES concatenates specific information from the request into a string which is hashed, and the resulting hash is signed using the signer's private key; a verifier generates the same information from the message, generates the hash and verifies the signature using the public key of the signer. As noted previously, this document does not specify how the public key is retrieved, nor how it is authenticated to legitimately represent the identity it claims to be authoritative for. For example the public key might be retrieved from DNS, with the DNS query key representing the international E.164 number or email-style domain name and the DNS authority being trusted as the identity authority; or it might be retrieved in a certificate using HTTP, with a web-style PKI of a common trusted root Certificate Authority. The IKES information and signature is exchanged between parties, by encoding it into defined fields of the various protocols and transporting it in their messages. For example by encoding it in a defined SIP header, XMPP XML element, or SS7/ISUP parameter. Gateway devices that interconnect the supported protocols need to copy the IKES information and signature from one protocol's field to another, although in the SS7/ISUP case this can be achieved by some intermediaries that are not the actual gateways, as described later. Naturally, this mechanism only works if the IKES information successfully transits from the signer to the verifier. It might be possible to use an alternative means of exchanging the IKES information other than in the messages themselves, but that is beyond the scope of this document. To provide protocol agnosticism, this document maps message types and fields from each of the supported protocols into an abstract type number space. This is necessary for consistent hash creation in both the signer and verifier roles. For example, a dialog- creating SIP INVITE request, XMPP session-initiation iq stanza, H.323 Call Setup, and ISUP IAM are all considered a new session initiation request with a message type of single character value 'I' when used in the hash input-string creation. Other protocols wishing to support IKES need to define their own mapping to the values defined in this document. The information necessary to provide identity assurance, replay protection, and prevent cut-paste attacks is encoded into an 'IKES Information Field' (IKES-IF) string, and included in the message of the various protocols. This IKES-IF is what is actually hashed and signed. The receiving verifier generates some of the same information from protocol-specific headers (e.g., from the SIP From URI) and performs a string comparison with the received IKES-IF before calculating the hash and signature verification. Kaplan Expires January 2014 [Page 6] Internet-Draft STIR IKES OUT July 2013 The protocol agnostic information in the IKES-IF covered by the IKES signature includes: the message type, source identity and type, the destination identity and type, a timestamp, sequence number, and a public-key index. Unlike [RFC4474], bodies in the message are not covered by the signature; IKES is used to provide caller-id reputability, and nothing more. The source and destination identities are determined by generating either a "canonical" international E.164 or "canonical" email-style name from the given protocol's relevant fields. For example in SIP, the From and To URIs are used for this process. As explained later, however, it is the canonical form of the identities that are used for signing - not their literal string format encoded in the message. Thus even though a SIP message may contain a SIP URI of "sip:(212)555-1212@example.com", the signer internally generates a canonical form of an E.164 number as "12125551212", and signs that canonical form without actually changing the SIP URI in the message itself. When the identities being signed are E.164 numbers, a copy of the canonical form of the source and destination identities are also encoded in the IKES-IF. The verifier still has to generate the information from the protocol's normal fields (e.g., SIP From/To URIs), but having them also encoded in the IKES-IF helps detect failures quickly without having to perform public key cryptography, and aids in troubleshooting. The IKES Verifier performs validation of the message in a similar fashion as [RFC4474], by validating the signature for the message given the values received. Instead of using the received SIP Call- ID and Cseq pair to check a local cache for a unique signature, an IKES Verifier uses the IKES-provided sequence number value for such a cache instead. The IKES-provided timestamp is used to detect stale signatures, similar to the use of the SIP Date header field value in [RFC4474]. The combination of identities, sequence number, timestamp and message type fields provide protection against replay and cut-and-paste attacks, as described in the security section. The public-key index field is used to indicate which of multiple public-keys a signer used to sign the message with, and thus which one the verifier should use to verify with. This is necessary to allow updating public-keys without Internet-wide synchronization, as well as to allow multiple public-keys to be useable for a given identity so that there can be multiple signers for a given E.164 number. Kaplan Expires January 2014 [Page 7] Internet-Draft STIR IKES OUT July 2013 4.1. Identity Types: E.164 vs. Number Codes vs. Email-style Most modern IP-based real-time communications protocols support two forms of source 'user' identities that IKES also provides a signature for: phone numbers, and "email-style" names. Due to confusion in common SIP usage, and to provide clarity on the differences involved and how IKES treats them, this section provides a background on the differences between the two identity forms. IKES handles phone numbers in two ways: as international E.164 numbers, and as nationally-specific number codes. For the former case, IKES requires the phone number to be converted into a canonical international E.164 number format. For example, in SIP even if the From or To URI encode a phone number only using a regional or national format/length-of-digits, the IKES process requires adding the necessary country-code and regional prefix, to form the source or destination identity used for IKES. IKES also considers toll-free 1-8xx type numbers to be "E.164" numbers, even though technically they are not. Nationally-specific number codes are numbers that are not E.164 numbers, nor are private numbering plan numbers, but are instead number codes used for specific purposes within national numbering plans. Examples of these are N11 codes in the NANP, two or three digit emergency numbers such as 112, and inter-carrier common short codes. Even if they cannot be used as caller-id numbers, they are destination numbers and thus IKES needs to support them. The important point is that they, like E.164 numbers, are not scoped to the domain name portion of a URI. E.164 numbers are defined by the ITU as a sequence of up to 15 digits, including the leading country-code digit(s). They are of a global scope, meaning any two different E.164 numbers are globally unique and identify distinct logical entities. Any two equal E.164 numbers identify the same logical entity no matter where they are received from; they may not be from the same human, or phone/device, or even same the service provider, but in general users understand them to represent the same logical calling entity/organization. In this document, the term "email-style names" are identifiers of the form 'user@domain', where the domain defines and limits the scope of authority of the user portion. In other words, for an email-style name the authority of the user portion is the domain after the '@' sign, and there is no confusion that the user 'alice@example.com' is the same as the user 'alice@invalid.com'. They may happen to be from the same Alice the human, but in general users understand they are distinct communication identities. Kaplan Expires January 2014 [Page 8] Internet-Draft STIR IKES OUT July 2013 In theory, the protocol scheme of the 'user@domain' should also be considered a scoping element - i.e., 'sip:alice@example.com' and 'xmpp:alice@example.com' should be distinct identities - in practice, however, this is never the case except for some unique situations such as the username 'admin' or 'help'. IKES ignores the protocol scheme currently, and only deals with the 'user@domain' portion. [Open issue: should the scheme matter? If so, there will be no way to go across different protocols] Complications arise in SIP, because although E.164 numbers are processed correctly as globally unique identities, they are often encoded in email-style URI format; they are received in email-style format but are processed as E.164 numbers regardless. While there is a defined encoding for E.164 numbers in SIP, using the 'tel' URI scheme format, it is rarely used for SIP request source or destination identifiers. Instead, the SIP URI format is used with a 'sip' scheme, with or without a 'user=phone' parameter; for example 'sip:+1212551212@example.com' is processed by SIP devices as the E.164 number '12125551212', ignoring the domain portion. For the purposes of this document, the term "email-style" name does *NOT* apply to E.164 numbers or naiotnally-specific number codes encoded in SIP URI form; instead, those are still termed and considered E.164 numbers or nationally-specific number codes. If the verifying domain/node processes the received message's source identity as an E.164 number, or displays it to their end users as such - no matter what encoding format it takes on-the-wire - then the verifying domain/node MUST use the verification rules defined for E.164 numbers. 4.2. Determining Canonical E.164 Numbers and Number Codes In [RFC4474] the SIP From and To header fields are covered by the signature; if the From or To URI change by the time they reach the verifier, the signature would become invalid. Unfortunately, From and To URIs are changed quite frequently by middleboxes, as described in [draft-fromto-change]. This document proposes that the important components of the To and From URI that need to be protected are the source and target identity, not the whole header fields, and not even the whole URIs; just the E.164 number, number code, or email-style name. One of the difficulties with signing the URI username portion for E.164 numbers, however, is that even the username number changes frequently along the SIP routing path. It may be prefixed with leading digits used for local routing purposes, or it may translated to/from a local or national numbers rather than the full E.164 Kaplan Expires January 2014 [Page 9] Internet-Draft STIR IKES OUT July 2013 number, or it may have visual separators encoded in the username portion. Therefore, if the originating domain simply signs the From/To username as a string of digits, and the digits get changed by the time the request reaches the verifying domain, the verification will fail. To prevent this from happening, part of the IKES signing and verification process involves determining a 'canonical' source and/or destination E.164 number or number code, if the request's source or destination identities are of an E.164 type or number code type, instead of email-style names. The process for determining a canonical E.164 number cannot be fully specified in this document, because it will likely depend on the specific policies used within the local domain. For example one domain may only use local number formatting and need to convert all To/From user portions to E.164 by prepending country-code and region code digits; another domain might prefix usernames with trunk- routing codes and need to remove the prefix. Regardless of the process used, the resulting canonical E.164 numbers used by both the signing and verifying systems MUST result in an ASCII string of only digits without whitespace or visual- separators, starting with the country-code digit(s). This canonical representation of the E.164 number is used as input to the hash calculation during signing and verifying process. Likewise for nationally-specific number codes, the IKES process generates a canonical representation of the number code. A leading country-code is prepended to the number code, to indicate the national numbering plan they are for. Although the canonical representations are implicitly generated from the received message, rather than being simply explicitly copied from the URI, a copy of each canonical source/destination number is inserted in the message for certain protocols (e.g., SIP and XMPP), to detect mismatches quickly and aid troubleshooting. 4.3. Determining Canonical Email-style Names If the originating domain intends the source or destination identities to be "email-style" names rather than phone numbers, then it MUST generate a canonical form of the name when it generates the IKES information that is signed. The process for this results in a simple user@domain formatted string, without whitespace, without a scheme or parameter or additional resource information. Kaplan Expires January 2014 [Page 10] Internet-Draft STIR IKES OUT July 2013 4.4. Call-forwarding Issues Many communication services offer a "call forwarding" feature, whereby a user can have communication requests that were originally destined to them, forwarded on to other destination identities. This can cause issues for caller-id authentication mechanisms such as IKES, because IKES needs to know the destination identity in order to prevent cut-paste attacks. The destination identity is thus included in the string that is signed by the IKES Generator. Therefore, if the destination identity encoded in the protocol message changes, some means of determining the original one needs to be available for IKES to succeed. In SS7/ISUP, the process of forwarding/redirecting the call changes the Called Party Number value to the new destination identity, and copies the original destination identity into an Original Called Number parameter, along with generating other redirection information. Thus for SS7 it is not difficult to determine the identity for IKES to use in signature validation. For SIP, in theory the process of call forwarding leaves the To header field URI unchanged, while only the Request-URI changes to the new destination identity. In practice, however, most systems follow the SS7 model and change the To URI to be the new destination identity. SIP has a means of recording the original destination identity: either in History-Info header fields per [RFC4244], or in Diversion header fields per [RFC5806]. In order to help determine the original destination identity, IKES encodes the one it used for signing in the new SIP header field used for IKES. Regardless of the specific protocol mechanics, however, call- forwarding introduces a significant weakness in any caller-id verification mechanism. Imagine if a malicious Bob could re-use the IKES information from a call he received from a bank or airline, for example, to then generate new calls to Charlie and other random users. At a protocol layer, Bob could simply behave as if the call was being forwarded. It would appear to Charlie that there is a valid caller-id from the bank or airline, when it's really Bob abusing the system. Ultimately the receiver of the message that verifies the IKES information needs to determine if the IKES-protected identities are valid for the final user that receives the call. In other words, if Alice calls Bob, and Bob forwards all his calls to Charlie, then Charlie's verification system has to determine if Charlie trusts calls being forwarded from Bob (i.e., whether Charlie allows Bob to forward calls to him). Kaplan Expires January 2014 [Page 11] Internet-Draft STIR IKES OUT July 2013 This document does not define a specific means of performing this forwarding-party authorization, but the author believes some guidelines should be given for how to display the caller-id properly in such scenarios, or perhaps how to use XCAP or other means for end users to provision trusted call-forwarders. This is left as an open issue for now. 5. IKES Generator Behavior This document defines a mechanism by which the sender of communications messages can cryptographically assert the authenticity of the originator's E.164, number code, or email-style identity; this role is called an IKES Generator. The IKES generator may be an end host such as a PC or mobile phone, or it may be the originating Enterprise or Service Provider. Whoever has an appropriate private key for a given identity, and the means to authenticate the message originated from the indicated identity, can be an IKES Generator for the message. Any entity which performs the role of IKES Generator MUST possess the private encryption key of an asymmetric key pair that can be used to sign for a given E.164 number, number code, or email-style domain name, depending on the source identity type. The public key half of this pair must be available to any receiver of the message, such that the receiver will be able to verify the sender sent the message and can claim the source identity. This may involve using certificates signed by a trusted third-party, identifying the E.164 number, number code, or domain name; or it may involve some other means of retrieving the public key for the given E.164 number, number code, or domain name. The exact means of retrieving and authenticating the public key is beyond the scope of this document. The IKES mechanism relies on the node or domain asserting the source identity to perform some form of authentication for the identity it asserts. For example, in SIP it may digest-challenge a request before signing. If the IKES Generator does not perform sufficient authentication of the source identity, then it only impacts the legitimacy of E.164 numbers it is responsible for, or email-style names for its own domain - it does not impact the legitimacy of E.164 numbers it cannot claim to represent. Kaplan Expires January 2014 [Page 12] Internet-Draft STIR IKES OUT July 2013 The role of the IKES Generator is to perform the following steps, in order, and sign the resulting information. The specific steps it MUST perform are: Step 1: The IKES Generator MUST map the protocol-specific message type into a generic IKES 'message type' value. For example a SIP INVITE is the message type 'I'. This message type value is encoded into the message and signed, to prevent cut-paste attacks. Step 2: The IKES Generator MUST extract the canonical identity of the sender from the appropriate message field, into a new string referred to as the 'source identity'. For example in SIP, this would be the logical international E.164, number code, or email-style source identity in the From header field URI, canonicalized into a new string used for signing. The type of the identity MUST also be determined: either an E.164, number code, or email-style type. This type information will be encoded in the message and signed, to prevent obfuscation attacks. If the IKES Generator cannot verify the source identity claim, it MUST NOT generate or insert IKES fields. Doing otherwise is not in the best interest of the IKES Generator, as it would be signing an assertion for an identity it does not know to be accurate, and thus may lead to impacting the reputation of its assertions. Step 3: The IKES Generator MUST extract the canonical identity of the target identity from the appropriate message field, into a new string referred to as the 'destination identity field'. For example in SIP, this would be the international E.164 number, number code, or email-style source identity in the To header field URI, canonicalized into a new string used for signing. The canonical destination identity is also encoded into the message, useful for both troubleshooting and call-forwarding scenarios as described later. The type of the destination identity MUST also be determined: either an international E.164 number, number code, or email-style type. This type information will be encoded in the message and signed, to prevent obfuscation attacks. Kaplan Expires January 2014 [Page 13] Internet-Draft STIR IKES OUT July 2013 Step 4: The IKES Generator MUST generate a new sequence number, which is encoded into the message and signed. The sequence number-space size is 24-bit, and the value increases by one every time an IKES Generator creates a new signature for any message of any message type. The sequence number is encoded into the message and signed, in order to prevent replay attacks within the timestamp's validity window. Step 5: The IKES Generator MUST generate a value for the current time based on UTC, referred to as the 'timestamp'. The timestamp value is encoded into the message itself and included in the signature calculation, and is used by the IKES Verifier to detect stale signatures and prevent replay/cut-paste attacks. Step 6: The IKES Generator MUST form a string of the information generated in previous steps as well as the private key's index, create a hash of the string, and generate the IKES signature using its appropriate private key for the source identity. The signature is encoded into the message, and used by the IKES Verifier to validate the source identity for the given message type. Finally, the IKES Generator MUST forward the message normally. 6. IKES Verifier Behavior This document introduces a new logical role for communication entities called an IKES Verifier. When an IKES Verifier receives a message containing an IKES signature, it may inspect the signature to verify the source identity for the message. Typically, the results of the verification are provided as input to an authorization process that is outside the scope of this document. If an IKES signature is not present in a message or is invalid, it is up to local policy to dictate what action should occur, such as forwarding a call request to an attendant or IVR, or anonymizing the source identity and blocking it from being displayed or used, or even rejecting the request. In order to verify the identity of the sender of a message, an entity acting as a verifier MUST perform the following steps, in the order here specified. Kaplan Expires January 2014 [Page 14] Internet-Draft STIR IKES OUT July 2013 Step 1: The verifier MUST map the protocol-specific message type into a generic IKES 'message type' value. For example a SIP INVITE is the message type 'I'. This forms the initial value in the IKES-IF string. If the specific protocol being used has the IKES-IF string available, the verifier MAY immediately check that the IKES-IF 'msg- type' value matches the verifier's generated one. This is an optimization step, to detect mismatches quickly. Step 2: The verifier MUST extract the canonical identity of the sender from the appropriate message field. For example in SIP, this would be the E.164, number code, or email-style source identity in the From header field URI, internally converted into a canonical form. The type of the identity MUST also be determined: either an E.164 or email-style type. The identity type and canonical value are the next set of values for the IKES-IF string. If the specific protocol being used has the IKES-IF string available, the verifier MAY immediately check that the IKES-IF 'source-id' value matches the verifier's generated one. This is an optimization step, to detect mismatches quickly. Step 3: The verifier MUST extract the canonical identity of the destination identity from the appropriate message field. For example in SIP, this would be the E.164, number code, or email-style identity in the To header field URI, internally converted into a canonical form. The type of the destination identity MUST also be determined: either an E.164 or email-style type. The identity type and canonical value are the next set of values for the IKES-IF string. If call-forwarding/redirection has occurred, then the original target number/name is used for the destination identity. Determining whether redirection has occurred, and where to get the destination identity in such a case, is protocol-specific and covered in later sections for the specific protocol usage. The verifier MUST validate that the destination identity encoded in the message either identifies the resource it will forward the message to, or that the resource it will forward the message to is willing to accept messages addressed for that identity. How the verifier determines the destination identity is of such a type is beyond the scope of this document. One example would be using a Kaplan Expires January 2014 [Page 15] Internet-Draft STIR IKES OUT July 2013 list of URI's the forwarded-to user has populated on the verifier through a service/account portal. If the specific protocol being used has the IKES-IF string available, the verifier MAY immediately check that the IKES-IF 'dest-id' value matches the verifier's generated one. This is an optimization step, to detect mismatches quickly as well as to detect redirections in some cases. Step 4: The verifier MUST validate the received IKES-IF timestamp falls within ten minutes of local time: either 10 minutes earlier or later than local system time in UTC. This avoids the need to synchronize clocks, and allows time for messages to be sent through multiple intermediaries/domains. If the public key obtained in Step 6 is from a certificate, the verifier must furthermore ensure that the value of the timestamp falls within the validity period of the certificate. Step 5: The verifier generates the full IKES-IF string from the fields determined above in previous steps, along with the received IKES-IF sequence number and public key index value. The verifier MUST verify it has not received this same IKES-IF string in the past 20 minutes (1200 seconds). The purpose of this step is to prevent replay attacks. Since the IKES-IF string contains the sequence number, as well as the identities and other fields, this check will prevent the same message from being replayed. If the IKES-IF had been received previously, then it is either a replay attack or forked messages that have merged at the verifier. In either case the redundant/repeated message(s) can be rejected. Step 6: The verifier MUST acquire the public key for the source identity. The process for doing this is beyond the scope of this document. Step 7: The verifier MUST verify the IKES signature, following the procedures for generating the hashed digest-string described in Section 7. If a verifier determines that the signature on the message does not correspond to the reconstructed IKES-IF string, then it must reject Kaplan Expires January 2014 [Page 16] Internet-Draft STIR IKES OUT July 2013 the message or perform the actions local policy dictates for invalid source identities. Step 8: If all of the above checks pass/succeed, then the verifier MUST remember the valid IKES-IF string for the next 20 minutes, in order to be able to perform Step 5 for future messages. The IKES-IF string MUST NOT be remembered if it was not valid (i.e., if this Step 8 was not reached). Otherwise an attacker could generate invalid IKES-IF messages to prevent legitimate calls. 7. IKES Information Field This document specifies an 'IKES Information Field' (IKES-IF), which is a UTF-8 string formatted in a specific manner. The IKES-IF is the canonical string created by the IKES Generator that is then hashed and signed; and the IKES-IF is re-created by the Verifier and the signature verifies its hash. The IKES-IF string's 'match-fields' portion contains information that is determined from other message fields, while the 'valid- fields' portion contains information added by the IKES Generator for the purposes of IKES. For SIP and XMPP protocol usages defined in this document, the entire IKES-IF literal string is itself encoded into the message in a new SIP header or XMPP XML element. This is done to provide quick mismatch detection and for troubleshooting purposes. For SS7, H.323, and native ISDN, the IKES-IF information is encoded in a different manner in the message fields, due to the constraints of SS7/ISUP parameter sizes. In particular, the 'match-fields' portion is only auto-generated by both the IKES Generator and Verifier, while the 'valid-fields' portion is encoded in specific protocol fields. However the same full IKES-IF string is used for the hashing and signing, regardless of the protocol. Kaplan Expires January 2014 [Page 17] Internet-Draft STIR IKES OUT July 2013 Note that this section only defines the field syntax, not the protocol-specific encoding; those are defined in the protocol- specific sections later in this document. The ABNF grammar for the IKES-IF is: ikes-if = match-fields "=" valid-fields match-fields = msg-type "=" source-id "=" dest-id valid-fields = sequence "=" key-index "=" timestamp msg-type = CHAR source-id = identity dest-id = identity identity = domain-based / global-e164 / number-code / token domain-based = "D:" user "@" host global-e164 = "G:" *DIGIT number-code = "C:" *DIGIT sequence = 1*8 DIGIT ;values 1 - 16777215 key-index = 1*4 DIGIT ;values 1 - 1023 timestamp = date-time ;from [RFC3339] For example, a SIP INVITE from the E.164 number '12125551212' to the E.164 number '443069991010', of sequence number 1216, using public- key index number 4, with an IKES signature generated at 1:15:30PM UTC on July 16, 2013, would result in the following IKES-IF string: I=G:12125551212=G:443069991010=1216=4=2013-07-16T13:15:30Z This string would then be hashed, and the resulting hash would be signed using the appropriate private key. The IKES-IF string is also encoded in its literal form in a new SIP header field defined later, as well as in a new XMPP XML element defined later. The same example, but to the US-based number code '911', would result in the following IKES-IF string: I=G:12125551212=C:1911=1216=4=2013-07-16T13:15:30Z When an email-style domain-based identity is used for the source or destination identities, the canonical form of the user@domain identity is also included in the IKES-IF in the 'domain-based' field, so that the signature covers the identity. For example, a SIP INVITE from the canonical name 'alice@foo.com' to 'bob@bar.co.uk', of sequence number 1216, using public-key index number 4, with an IKES signature generated at 1:15:30PM UTC on July 16, 2013, would result in the following full IKES-IF string: I=D:alice@foo.com=D:bob@bar.co.uk=1216=4=2013-07-16T13:15:30Z Kaplan Expires January 2014 [Page 18] Internet-Draft STIR IKES OUT July 2013 The above string would be then hashed and signed, using a private key valid for asserting the domain foo.com. Having a source identity of one type and a destination identity of a different type is completely valid. Therefore an example such as this is possible: I=G:12125551212=D:bob@bar.co.uk=1216=4=2013-07-16T13:15:30Z The 'msg-type' field is a single character representing the message action type: for example an 'I' for call/session initiation request, 'U' for mid-session change request, 'X' for session transfer request, or 'M' for instant-message request. The appropriate message type field value to use for specific protocol messages is defined in later sections, for each protocol. The 'source-id' and 'dest-id' fields represent the source identity and destination identity of the message. For E.164-based identities, the 'global-e164' syntax is used; for email-style identities, the 'domain-based' syntax is used. The 'sequence' field represents a sequence number. The sequence number MUST be guaranteed to be unique for each message, for at least 10 minutes (600 seconds) after the time field value. Message retransmission at the protocol transport layer MUST NOT generate a new sequence number, and thus the same signature value will be used for retransmissions. In other words, IKES authentication and validation occur at a layer above the transport layer. The sequence number prevents replay attacks within the valid duration of the timestamp. The 'key-index' field identifies which specific public-key index to use. Regardless of whether DNS or HTTP or some other mechanism is used for retrieving the public key, there will likely be more than one active public-key for a given domain name or E.164 phone number. The 'timestamp' field identifies the UTC time at which the IKES-IF was generated. A verifier will only accept a time value of up to 10 minutes early or 10 minutes late. Since this field is also signed, it cannot be changed and thus helps prevent replay attacks. 8. Usage in SIP This document defines a new SIP header field for carrying the IKES- IF data and signature: the 'Likes-If' header, for "Literal IKES-IF". The format of the Likes-If header field is as follows, using the previously defined ABNF fields: Kaplan Expires January 2014 [Page 19] Internet-Draft STIR IKES OUT July 2013 likes-if = "Likes-If" HCOLON ikes-if *(SEMI ikes-param) ikes-param = sig-info / generic-param sig-info = sig-value SEMI sig-alg sig-value = "sig" EQUAL DQUOT base64 DQUOT ;from [RFC5802] sig-alg = "alg" EQUAL token An example of this header field is as follows (note this is all one line without whitespace, but shown separately for readability): Likes-If: I=G:12125551212=G:16035551010=116=4=2013-07-16T13:15:30Z ;sig="ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1 pxAr3VgrB0SsSAaifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TO QXHMmz6uEo3svJsSH49thyGnFVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU /pryhVn9Yc6U=";alg=rsa-sha1 The 'sig-value' field contains a base-64 encoded signature of the hash of the ikes-if value. The hashing and signing algorithm is specified by the 'sig-alg' field, following the same parameter behavior as the 'alg' parameter in [RFC4474]. This document currently only specifies sha1WithRSAEncryption as described in [RFC3370], and thus the 'alg' type of 'rsa-sha1'. The following mapping is used for SIP request method types to IKES message types: o An out-of-dialog INVITE request is the IKES message type 'I'. o An in-dialog INVITE, UPDATE, and INFO request is the IKES message type 'U'. o A BYE request is the IKES message type 'B'. o A MESSAGE request is the IKES message type 'M'. o A PUBLISH request is the IKES message type 'P'. o A SUBSCRIBE request is the IKES message type 'S'. o A NOTIFY request is the IKES message type 'N'. o An OPTIONS request is the IKES message type 'Q'. o A REGISTER request is the IKES message type 'R'. o A REFER request is the IKES message type 'X'. Note: PRACK, ACK and CANCEL methods do not have corresponding IKES message types. The source identity SHOULD be the canonical form of the identity in the From header field URI. The destination identity SHOULD be the canonical form of the identity in the To header field URI. If the canonical destination identity generated form the To URI does not match the 'dest-id' in the Likes-If header field, then call- forwarding might have occurred. The verifier SHOULD check any received History-Info ([RFC4244]) or Diversion ([RFC5806]) header field values, to see if they match the identity in the 'dest-id' Kaplan Expires January 2014 [Page 20] Internet-Draft STIR IKES OUT July 2013 field, and if so then it MAY use that matching value to continue the verification processing. 9. Usage in XMPP This document defines a new XMPP XML child element of the 'message', 'presence', and 'iq' elements for carrying the IKES-IF data: the 'likesIf' element, for "Literal IKES-IF". The element value's type is an xs:token data type, and contains the full IKES-IF data string defined in section 7 for 'ikes-if'. [note: alternatively we could define the ikes-if fields to be syntactically broken out into distinct XML elements/attributes] It is TBD how the signature and algorithm information are encoded, for example in another XML child element, or whatever. The following mapping is used for XMPP stanza types to IKES message types: o An iq stanza of type "set" with a jingle action attribute of "session-initiate" is the IKES message type of 'I'. o An iq stanza of type "set" with a jingle action attribute of "content-add", "content-modify", or "content-remove" is an IKES message type 'U'. o An iq stanza of type "set" with a jingle action attribute of "session-terminate" is the IKES message type of 'B'. o Other iq stanza types are currently undefined for IKES. o A message stanza with no type or of type "normal" is the IKES message type 'M'. o A message stanza of the type "chat" is the IKES message type 'I'; this follows the model of a SIP INVITE for MSRP sessions. o A message stanza with a jabber multy-user chat "invite" element is the IKES message type 'X'; this follows the model of a SIP REFER. o A presence stanza of type "subscribe" or "unsubscribe" is the message type 'S'. o A presence stanza of type "subscribed" is the message type 'N'. o A presence stanza with no 'type' attribute is currently undefined. [note: what is the correct semantics of this? It appears to server multiple message roles/types for SIP, for example] o [note: is there an XMPP type for transferring a media session? That would be IKES message type 'X'] The source identity SHOULD be based on the 'from' attribute of the stanza. The destination identity SHOULD be based on the 'to' attribute of the stanza. Kaplan Expires January 2014 [Page 21] Internet-Draft STIR IKES OUT July 2013 10. Usage in SS7/ISUP The SS7/ISUP protocol allows new ISUP parameter types to be defined, but doing so would require many SS7 devices to change behavior. The SS7 market is fairly stagnant, and in the final stages of life, making such a change untenable. Therefore, instead of defining a new ISUP parameter type, IKES uses existing ISUP parameters to carry its data: the sequence number is carried in the ISUP Call Reference parameter using a fixed/defined point code; the signature, key index, and timestamp are carried in the User-to-User Information parameter; the source identity is the Calling Party Number, and the destination identity is either the Called Party Number or carried in the Original Called Number parameter if the call has been redirected. There is no guarantee the optional ISUP parameters used by IKES will successfully transit the PSTN. The odds are high for short hops - for example across a single link/connection, or possibly within a single SS7 carrier - but it will rarely make it across multiple SS7 carriers or across international links. The expectation is that SS7 usage will continue to decline and be replaced with SIP interconnection, making IKES more and more usable end-to-end. SS7 support for IKES only supports voice call service through ISUP, and not instant messages such as would be sent as SMS in SS7/MAP. Also, only en bloc signaling is supported, and not overlap signaling. Although ISUP parameters can be up to 255 octets long, in practice the User-to-User Information parameter is restricted to 131 octets. This makes it more complicated for IKES to use, and is why the operations defined in this section are cumbersome. Instead of encoding the IKES-IF as one long string, the individual components are encoded as discrete fields in binary form. The IKES sequence number is encoded as the reference number in the Call Reference parameter, with a fixed point code yet to be defined/reserved. The IKES key index, timestamp, signature, and algorithm are encoded in the User-to-User Information parameter based on the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Kaplan Expires January 2014 [Page 22] Internet-Draft STIR IKES OUT July 2013 | 128 octet signature | \ / / \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | key index |alg| timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 'signature' field is the 128 binary bytes of the IKES signature. This is only sufficient to hold the signature based on a 1024-bit key. If a longer key is necessary, IKES cannot work through SS7. The 'key index' field is a 10-bit unsigned integer, and identifies the IKES public-key index value. The 'alg' field identifies the signature algorithm. This document currently only specifies sha1WithRSAEncryption as described in [RFC3370], and that this algorithm has the 'alg' value of 0x00. Future algorithms need to specify one of the remaining 3 possible values for this field if they wish to transit SS7. The 'timestamp' field identifies the lower 12 bits of the IKES timestamp, when converted to number of seconds that have elapsed since 00:00:00 UTC, Thursday, January 1, 1970 (known as Unix time). Leap seconds do not matter, since the generator and verifier do not need to have accurately synchronized clocks. When an IKES Generator creates this value, or an SS7/ISUP gateway converts an IKES-IF into the ISUP parameters, it takes the IKES-IF info-field UTC time and converts it to Unix time and encodes the lower 12 bits into this ISUP UUI parameter's timestamp field. The signature, however, is calculated over the full UTC timestamp as encoded in an IKES-IF info-field. An IKES Verifier or ISUP gateway receiving this ISUP parameter timestamp field, which needs to either verify the signature or convert the parameters into a different IKES-IF encoding form, needs to be able to re-create the full *original* UTC time from these lower 12 bits, or else the signature will fail. This can be accomplished because 12 bits represent 4096 seconds of time, and the verifier can assume the originator generated the parameters within a 1200 second window of local time (either 600 seconds earlier, or 600 seconds in the future); if the originator generated it outside of that window, then the resulting IKES-IF string will fail the signature check anyway. Therefore, the verifier need only compare the received lower 12 bits against its valid local Unix time range, and generate a full UTC timestamp that fits within the window and has the same lower 12 bit value - there can be only one such value. Kaplan Expires January 2014 [Page 23] Internet-Draft STIR IKES OUT July 2013 If it cannot fit in the valid range, then it knows the signature is stale; if it does fit but the resulting signature check still fails then either it is an invalid caller-id, or the signature is so stale as to have wrapped the 12-bit seconds value by being over 4096 seconds old, or something else is wrong with the IKES-IF. Regardless of the verification result, the full UTC timestamp can be successfully recreated for all successful signature result cases, and might be incorrectly recreated for cases where the IKES result would be a failure anyway. The following mapping is used for ISUP message types to IKES message types: o An IAM message is the IKES message type of 'I'. o An REL message is the IKES message type of 'B'. o Other ISUP message types are currently undefined for IKES. The IKES source identity is the Calling Party Number parameter. The IKES destination identity is either the Called Party Number, or the Original Called Number if the call has been redirected. Both identities need to be canonicalized to a global E.164 number, if they are a local or national format. 10.1. SIP-SS7 Interworking A likely use-case for IKES is the need to transit an SS7 carrier between SIP domains. This can be accomplished by the SIP-SS7 gateway itself, by interworking the SIP IKES-IF to/from the SS7 parameters described earlier. Another possibility is to have a SIP-only device generate the information to/from an ISUP body following the [SIP-I] or [SIP-T] model. So long as the SS7 gateway supports SIP-I or SIP-T, including the Call Reference and User-to-User Information parameters, this can be a viable alternative. It is not uncommon for SBCs, Application Servers, and other call control systems to have the ability to generate SIP-I/SIP-T ISUP bodies and parameters from SIP header field information, and vice-versa. Since the market for such devices is still flourishing, it is reasonable to expect support for such an IKES interworking model. 11. Usage in H.323 and ISDN Both the H.323/H.225 and native ISDN/Q.931 protocols support adding new optional fields to their defined messages, but like SS7 it is unlikely doing so would result in vendors making the necessary Kaplan Expires January 2014 [Page 24] Internet-Draft STIR IKES OUT July 2013 changes because the market for H.323 and ISDN is dying and getting replaced with SIP. So our choices are to either use existing fields, or ignore H.323 and ISDN as use-cases for IKES. This decision is still TBD and an open issue for the STIR Working Group. If we choose to use existing fields, the same model as that used for SS7 can be used for H.323: the format and information defined for the ISUP User-to-User Information parameter previously, would be encoded into the H.323 user-data user-information field. ISDN Q.931 also supports a User-to-User Information field, limited to 131 octets like the one in SS7/ISUP; but its Call Reference field cannot be used the way the SS7/ISUP one can, because the ISDN one is already used for other purposes today. Suitable H.323 and ISDN fields for the IKES sequence number would have to be found. For both H.323 and ISDN, the following mapping could be used for messages: o A SETUP message is the IKES message type of 'I'. o A RELEASE message is the IKES message type of 'B'. o Other H.323 or ISDN message types are currently undefined for IKES. [Note: more needs to be defined for H.323 and for native ISDN, if the WG decides it's worth the effort] 12. Open Issues There are still many open issues in this draft. It is currently a straw-man proposal. Some of the bigger open issues are: o Whether support for SS7 is worth specifying or not. o Whether using the SS7/ISUP Call Reference parameter is possible or not. o Whether instant messages for SMS in SS7/MAP needs to be handled as well or not. o Whether support for H.323 and native ISDN is worth specifying or not, and if so then how to encode the fields. o Specific details for XMPP encoding syntax, and stanza handling. o Whether 1024-bit key size is sufficient or not. o Whether IKES should replace RFC 4474 or not. o How to handle forwarding-party authorization for call- forwarding scenarios. 13. Security Considerations The considerations in [RFC4474] generally apply to this document's proposed mechanism as well, and will not be repeated here. There Kaplan Expires January 2014 [Page 25] Internet-Draft STIR IKES OUT July 2013 are several additional security consideration when using this mechanism, however, as follows: 1) The IKES mechanism does not sign the Contact URI value, and thus a malicious party can change the value without detection. For most SIP use scenarios, this is no worse than [RFC4474], since Record-Route and Path header fields can be added into [RFC4474] signed SIP requests as well to accomplish the same malicious goal. The Contact URI is usable, however, in cases where Record- Route and Path do not apply, for example to generate subsequent out-of-dialog requests to a GRUU Contact; in such cases the IKES mechanism is weaker than [RFC4474]. 2) The IKES mechanism does not sign the SIP message body, and therefore much of the SDP can be changed without detection. Although [RFC4474] only signs bodies when they are in requests - which is not always the case for SDP - if the SDP body *is* in the request then [RFC4474] assures the Verifier that it has not been changed by any node beyond the Authenticator. For SDP, such assurance does not guarantee media identity (see [draft- baiting]), but [RFC4474] is better than nothing. The IKES mechanism does not do this because in practice SDP is constantly changed as requests pass through intermediate domains, and is thus a wasted effort. Furthermore, it would reveal that the SDP had been changed, which service providers might not want to reveal to certain parties. 3) The IKES mechanism does not always prevent malicious replay attacks if the verifying domain uses multiple, separate verification systems to verify caller-ids. In such a case, it's possible for replayed messages sent within the valid time window to be received on different verifier systems, so that each verifier would not detect it as a replay because they didn't receive the original message. One solution to this is for all the verifiers to use a common database to hold and retrieve the previously accepted IKES-IF strings for the time window duration. Such a solution, however, would be complicated to manage and is likely unnecessary given the current threat model. 14. IANA Considerations This document makes no request of IANA yet - if this document moves forward, then requests of IANA will be made here. Kaplan Expires January 2014 [Page 26] Internet-Draft STIR IKES OUT July 2013 15. Acknowledgments The idea of being able to canonicalize SIP To/From URIs into E.164 numbers comes from Brian Rosen. The idea of IKES in general is not new, and has been discussed for years in the IETF. Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 16. References 16.1. Normative References [RFC4474] Peterson, J., Jennings, C., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 16.2. Informative References [RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. [RFC5806] Levy, S., Mohali, M., "Diversion Indication in SIP", RFC 5806, March 2010. [SIP-I] ITU-T, Q.1912.5, and Q.761-Q.764. [SIP-T] Vemuri, A., Peterson, J., "Session Initiation Protocol for Telephones (SIP-T): Context and Architectures", RFC 3372, September 2002. [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG objects", RFC 3204, December 2001. [draft-baiting] Kaplan, H., "The SIP Identity Baiting Attack", draft-kaplan-sip-baiting-attack-02, February 2008. Kaplan Expires January 2014 [Page 27] Internet-Draft STIR IKES OUT July 2013 Author's Address Hadriel Kaplan Oracle Email: hadriel.kaplan@oracle.com Kaplan Expires January 2014 [Page 28]