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?

[...]

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