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