[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

About AID security (was Re: Question re HIP dependency & some architectural considerations)

...  Anyway, the AID
is primarily a thing that is internal to the host.  For simple
applications, the AID never leaves the host since the IP address in
the wire is conceptually different from the AID, even if they happen
to have the same binary value.

I am not sure i understand this statement, about AID never leaving the host.

Well, as you suggest, lets consider A talking to B. To be exact, let B
be associated with AID_B, EID_B and IP_B. Now, in order to be able to
communicate with B, A needs values for the three items. In the _generic_
case, AID_B *may* be locally generated by A, is used only with the API in A,
and never leaves A. As long as we only consider simple applications hosted
at A, this works, even if the binary value of AID_B had not whatsoever
relationship with the binary values of EID_B and IP_B.

Hence, from the above PoV, AID_B is internal to A, and never leaves A.
If so, there are no security problems.

Now, if we return to the suggested case where AID_B = IP_B, we bump
into the (security) problems. We have to be very careful about the
exact details of the semantics. For example, what does it mean if
a host performs a connect(AID_B) system call,
a) when B is a Multi6 supporting host, but A has no multi6 association,
b) when B is a Multi6 supporting host, but A does have multi6 association,
c) when B is not a Multi6 supporting host.
[And the same considerations for all other socket system calls.]

Then you need to consider the attack scenarios, and I think that there is
at least 2 * 1.5 * 2 = 6 possibilities, corresponding to
1: a) B supports multi6 b) B does not support multi6
2: a) A has multi 6 association, b) A does not have multi6 association
3: a) attacker simulates multi6 b) attacker simulates non-multi6 host

I see the EID as being a security tool while the AID being the actual
identity token.


Well, to me AID is merely a hack to support old badly designed apps.
In the longer run, I would like to see all apps to migrate to use
explicit, public key based or otherwise secure EIDs.

I mean, at the end of the day, what we really care is
that apps communicate with they think they are communicating with.


Sure.  But our views do differ in what is our main focus, supporting
current applications securely or supporting future and upgraded apps.
I think we need to do both, but we may need to do compromises on one
class in order to better support the other class.

[C]onsider the following situation:

Suppose that we have host A and host B and each one has its EIDA,
EIDB and AIDA and AIDB

Now suppose they have a mean to securely authenticate the EIDs so
Host A knows for sure that it is communicating with the owner of
EIDB and also Host B knows that it is communicating with the owner
of EIDA

Now, the point is that the applications only knows the other party
of the communication through the AIDs, so they will act upon this.


Sure, but ...

for instance the application level ACLs will be based on AID, right? 

... relying on IP addresses for access control is silly.  Hence, I would
not worry *too* much about it.

Now a secure binding between the AID and the EID is required here,
since if not i can easily steal someone's AID (which is AFAICS the
valid application level identity) as long as i have a valid EID
(which i can prove ownership of)


For simple applications, the AIDs could be generated locally.  In that
case the problem would not exist.  For the case where AID = IP, you
can use return routability, and you get the security to match the
current one, expect that there are future attacks.

That is why i think the problem as providing a secure binding
between the AID and the EID (assuming that the EID ownership can
be easily proven because the inherent crypto features of the EID)

I guess we basically agree, but just look at the problem from slightly
different angles. As I wrote above, I tend to take the AIDs as ephemeral
and locally generated, and consider the AID = IP as a special case.
Maybe that stance is plainly wrong. You consider the case of AID = IP
being the base line, and argue from there. For multi6, maybe your
point of view is more fruitful.

I fail to see what that mitm role adds to this scenario.. 

The attacks I worry about are various kinds of future attacks; i.e.,
I assume that there will necessarily be an initial return routability
test in the case where  AID = IP.  In order to pass that test, you
have to be a MitM, or at least eavesdrop traffic.

--Pekka