[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/