Internet DRAFT - draft-kaplan-stir-ikes-out
draft-kaplan-stir-ikes-out
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]
