[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Security requirements for identification
Hi Pekka,
thanks for the posting, some questions below...
> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Pekka Nikander
> Enviado el: miercoles, 24 de septiembre de 2003 9:50
> Para: Multi6 WG; hipsec@honor.trusecure.com
> Asunto: 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/msg0
> 0056.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.)
I am not sure if i understand this...
I mean, we do care about recognizing the other end of a communication,
right?
Usually, when a host establish a communication, the host wants to establish
the communications with a certain host, it is not the case that we want to
communicate with any host available. So this is expressed by the ip address
of the target host. This means that we do care who the other end is.In other
words, IP addresses are used today for recognizing the other end.
So perhpaps i don't agree with a statement from your previous mail:
"1a) To me, identification for mobility and multi-homing seems to
be the easiest one. There we are only interested in gaining
assurance that the peer remains the same. That is, for the
sole purpose of mobility or multi-homing, we do not really
care with whom we are communicating with, but only that the
peer end-point is not changed in mid-communication due to
mobility, multi-homing, or attacks based on mobility or
multi-homing mechanisms."
I guess we always care with who we are communicating with i.e. we always
need a permanent identifier -
This is true for at least for one end of the communication, the end that is
initiating the communication. Perhaps the server side of the communication
does not know who the initiator is and perhaps he doesn't even care, (as
long as it remains the same)
If you use a transient identifier, actually you are using two identifiers:
first the IP address as a permanent identifier to recognize the host and
then the transient identifier to recongnize the host when it changes its
address.
So i guess that what is needed is:
- a permanent identifier (so you can talk with who you really want to talk)
- A locator (so you can reach it)
- something to bind them (which can be a transient identifier, but you can
use some other stuff)
So i would say that ephemeral identifiers are not enough to provide
identification support for multi-homing and mobility support, we need more,
i.e. permanent identifiers.
Regards, marcelo
>
> 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
>
>
>