[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Security requirements for identification
In my previous message (to hipsec&ipv6 ml) I proposed dividing
identification to the following three subcategories:
a) identification in mobility and multi-homing
b) identification in referral or rendezvous
c) identification in other, e.g. administrative, contexts
I also discussed rendezvous and referral, in order to
make the point that identifying a node and locating it
are really two distinct functions.
The previous message is available at
http://www1.ietf.org/mail-archive/working-groups/ipv6/current/msg00056.html
In this message I will try to analyze the security
requirements for identification in the sense of a)
and b). Analyzing c) in isolation does not make any
sense, since the security requirements depend on the
context. In the end of this message, I try to give
some conclusions based on the analysis; if you are
busy, you may want to see the conclusions first.
I am focusing here solely on the identification
function, and not touching the security requirements
of the location function. It should be noted, however,
that these two are related in real life. Analyzing that
is for another message.
a) identification for mobility and multi-homing
-----------------------------------------------
As I wrote earlier, here we are only interested in gaining
assurance that the peer remains the *same*. That is, we
do not really care *whom* we are communicating with, but
only that the peer end-point is not changed in mid-
communication. (We probably did care the "real identity"
of the peer when we first initiated the communication, but
that is a different issue, with different security
requirements.)
There are two basic dangers related identification in mobility
and multi-homing. One is connection hijacking, i.e., somebody
"stealing" the connection and replacing one of the peers without
being noticed. The other, less obvious one, is flooding.
Flooding is an attack where a genuine peer lies about its
location(s), with the purpose of choking a victim on excess
traffic. That is, the attacker claims to move/be better
reachable at the location of a victim, thereby directing the
traffic to the victim.
Flooding is a serious attack since the amounts of redirected
traffic can be large. Consider a public streaming server.
Anyone can make a connection to it, and start downloading a
stream. For the stream to run, acknowledgments must be sent
back. This is easy, since an attacker can open a stream,
redirect the stream (using some mobility or multi-homing
mechanism) to a victim address, and *continue* sending
acknowledgments. Anticipating when and what kinds of acks to
send is easy enough. This makes the stream running independent
on the actions by the poor victim.
Hence, for the purpose of mobility and multi-homing, the
identification mechanism has to keep sure that the peer really
remains the same, on all changes of locators. Furthermore, the
mechanism must not blindly trust what the peer claims about its
locations, but must check that the same peer really *is*
at all the claimed addresses.
If we really do not care who the initial peer really is,
then a simple protocol is sufficient; the protocol first
creates a shared secret between the peers and then uses
the secret to verify persistence of the identity. The
protocol may even be vulnerable to MitM attackers in its
initialization state; our requirement states that a MitM
attacker is equally good to the "real" intended peer,
since we don't care about the "real identity".
The requirements can be summarized as follows:
R1. Verification that the peer is the same one
after all changes of locators.
R2. Verification that the same peer is reachable
at all claimed (and used) locations.
The MIPv6 RR protocol is a (somewhat convoluted) example of
a protocol fulfilling the requirements. (It also fulfills
other, Mobile IPv6 specific security requirements.)
b) identification for referral or rendezvous
--------------------------------------------
In the case of referral or rendezvous, an initiating party
possesses an identifier that it wants to use as a means
of identifying another party. The target party may have
no idea of the intentions of the first party, and it may
have never met the first party. In other words, the parties
do not share any state but the identifier itself and any
state in the target party that is associated with the
identifier.
From a security point of view, the requirement is that
the party that responds to a communication request really
is the party denoted by the identifier, and someone else.
That is, the requirement is that the target party really
is the intended target party.
If we assumed that everybody is honest, any unique bit
string would serve well as an identifier. The initiating
party just sends the bit string to the target party, and
asks the target party to verify that the bit string really
is its identifier. The problem is that we cannot necessarily
assume everybody to be honest.
If we assume dishonest parties, we get two sub cases. In
the first case, the initiating party must send the identifier
in clear, for some reason, or the identifier is otherwise
public and known by the dishonest parties. In the second
case, the initiating party is able to keep the identifier in
secret.
In the first case, the only secure way of performing
identification seem to be public key cryptography (or any of
its variants, like zero knowledge protocol). The reason for
this is the following. Since the identifier is public
knowledge, we cannot use the identifier directly. Instead,
there must be some secret that only the right party
knows and is able to prove to know. The identifier and the
secret must be linked. Only public key crypto (or a variant)
seems to fulfill these requirements.
The second case is more interesting, since it allows for
some simple cryptographic protocols that show to the
target party that the initiating party knows its secret
identifier without revealing it, and where the target
party is conversely able to show to the initiator that it
also knows the secret identifier. In effect, in this
case the identifier is a shared secret. However, it is
also almost completely impractical, since one cannot
share such a secret with anyone, nor put it into a public
directory. (There are some special cases where this kind
of identification may be useful, but one cannot build a
generic Internet wide architecture on such assumptions.)
Hence, if we want to do referral and rendezvous in a
secure way, we seem to need public keys as identifiers.
It looks best to use public keys as primary identifiers.
It is also possible to use public keys only as secondary
identifiers, and bind them to some primary identifiers,
but that costs more since it requires a PKI. Using public
keys directly as primary identifiers does not, as such,
require a PKI.
To summarize, the requirement is
R3. Verification that the target party really is the
party denoted by the identifier.
With public identifiers and under the assumption that there
may be man-in-the-middle or masquerading attackers, public
keys (or variants) seem like the only known technology
that securely fulfills this requirement. It should be noted,
however, that we do not necessarily need to care about
potential man-in-the-middle or masquerading attackers.
Whether to do so or not is a design choice.
Discussion
----------
To my best knowledge, the discussion above describes the
essence of the difference between the current architecture
and one where identifiers and locators are separated.
In the current architecture, the mobility and multi-homing
problem does not exist, since one is not allowed to change
ones locators on the fly. What comes to rendezvous and
referral, the practice of using locators as identifiers
offers a somewhat weak but very important form of security.
Effectively, the practice limits the number of potential
attackers hugely, from all nodes in the Internet to only
those nodes that are on the path between the initiating
party and the target address.
It is extremely important to understand that if we really
separate identifiers and locators, we become more vulnerable.
Fortunately the class of potential attackers will not be
everyone in the Internet, but only those that can tamper
with the identifier -> locator mapping or otherwise get
on the path between the initiating party and some locator.
Conclusions
-----------
Separating identifiers and locators has security implications.
To address these, we basically have a number of possibilities:
1) Design a _secure enough_ identifier -> locator mapping
service, thereby limiting the potential attackers to
those that can either tamper with the service or otherwise
receive packets sent to the (initially used) locator.
What is "secure enough" is a design choice. The service
must be dynamic because it must be possible to update
the set of locators.
2) Decide to use public keys as primary identifiers,
and rely on public key cryptography for identification.
3) Design a _secure enough_ identifier -> public key mapping
service, thereby limiting the potential attackers
to those that can tamper with the service. This is
effectively a PKI, but not necessarily as secure as what
people traditionally understand with a PKI. The difference
to 1) is that here we are not vulnerable to attackers that
just get to the path but can't tamper with the service.
The service may be fairly static, since there is seldom
need to chance one's public key.
4) Go only half way, and stop where the identifiers can
be still used as (limited) locators. The class of
attackers depends heavily on details, and cannot be
easily summarized.
I refrain from making comments on any practical designs (like
DNS), since that requires one to consider also other aspects
but security.
Questions
---------
Does this analysis help?
Do we have other choices but the four outlined above?
Should create an I-D from this and the previus message? If so,
should it be accepted by some WG as a working item?
--Pekka Nikander