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

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


El 26/07/2004, a las 20:47, Pekka Nikander escribió:

... 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.


I think i see what you mean.
But this locally generated AID does not support referrals of any kind, right?

[...<x-tad-bigger>]
</x-tad-bigger>
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.


okey, it is important to define if this is a long term goal that we are pursuing

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.

Okey, but suppose that we the multihoming solution is based in cgas, in order to be secure and backward compatible at the same time. then wouldn't it make sense to make ACLs based on CGAs?

I guess we are back to the long term goal issue here.

If we design a solution that provides CGAs, we are providing the apps with a secure-enough AID, so they can start using it as an identifier to authorization and so on. This doesn't seems very aligned with the goal of having apps deal with the EID directly

[I mean if we move to the hip plane, HITs are suitable to be used as identity tokens to perform authorization by apps, do you think that appd will start using the HIT or they will move to the HI directly?]

Bottom line, is that if we provide a transition tool such as the CGA (which provides security to some degree), this may be an obstacle to moving towards the "real" identifier later on.

FWIW i still don't know if a 64 bit long hash is good enough for a long term solution, so i kind of like the POV of having a long term ids that provide additional security for the future. I am concerned that adopting CGAs as a transition mechanism may cause that later on it may be difficult to get rid of them.

Regards, marcelo