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

Re: Question re HIP dependency & some architectural considerations

Hi Pekka,

I include some comments mostly about the reasoning behind your conclusions, since i agree with your conclusions

El 26/07/2004, a las 13:41, Pekka Nikander escribió:

To me, it remains an interesting question how to support API evolution.
One architectural possibility would be to use HIP as an example:
- convert AIDs into EIDs at the API level
- use EIDs to establish the end-to-end context
- map EIDs to IP addresses when sending packets out

This is how hip works today, right? 

Yes, more or less.  However, the details in various implementations
are different.

i mean in the HIP case:
AID==HIT
EID==HI

Yes, with the addition that the AID can also be an LSI instead of a HIT,
and there has been some discussions of allowing the AID to be a
routable IP address of the peer host.

I guess that what it seems that we need is to support routable AIDs,
and provide the means to securely bind them to the corresponding EID,
right?


Well, I think so.  But, at least for the time being, I remain puzzled
about what does the "secure binding" mean, exactly.  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.
I mean, suppose the Host A is communicating with Host B, then Host A identifies Host B through its AID i.e. AIDB. So as matter of fact, AIDB is not internal to host B, since it is used by Host A (even though packets from Host A to Host B don't really carry AIDB in the address field of the IP header)
But i guess that you meant something different by that AID never leave the hosts...

[Side Note: Also, i think that the AID should be used as IP address (i.e. locator) for the initial packets, since i believe it would allow to delay the security checks to the moment you need to start using an alternative address.
I mean, initial packets just use the AID as the IP address contained in the received packet (no additional security checks are required) and then if you need to change locators, you start performing more complex.
But this is one step ahead i guess and it doesn't really belong to this part of the reasoning]


The problems are created by the desire to be backwards compatible
with referrals and with non-RFC1958-conformant applications. For them,
the AID needs to be a routable IP address that can be used to reach
the peer. Hence, for them the AID does appear outside of the host, both
conceptually and in practise.

The security problem is created when the host that uses the AID does
not have a corresponding EID-level association with the peer identified
with the AID. One needs to have a secure enough way to tell whether the
peer has an EID or not, and if it does, what its EID is. There are
obviously various approaches in providing assurance, such as using CGA
(and some bit in the address to indicate whether CGA is used or not),
using WIMP, using opportunistic HIP, etc.


I think i agree with you, but my reasoning is more focused on the AID rather than the EID. I see the EID as being a security tool while the AID being the actual identity token. I mean, at the end of the day, what we really care is that apps communicate with they think they are communicating with.

I am concerned about an attack that would be something along these lines

consider 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. for instance the application level ACLs will be based on AID, right?

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)

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)

As you mention lower, this secure binding can be provided be CGAs or other means (like using as AID the IP address used as locator, as long no other locator is used)


I tend to believe that just using some end-to-end protocol might be
secure enough. That would obviously be vulnerable to man-in-the-middle
attackers, but so is current IP. However, I am worried about the case
where a MitM attacker hands over a different EID to the initiating host,
thereby creating a false AID-to-EID mapping at that host, and then using
the multi6 protocol to claim that the AID-IP-address is no longer reachable.
Such an attack can potentially cause quite a lot of harm, but of course
only if the host can be lured to try to make a contact to the AID.
However, that is easy enough in many cases.

I fail to see what that mitm role adds to this scenario.. i mean couldn't just a random attacker launch this attack? why does the attacker need to intercept existing packets for doing this? can he just start a new communication with the goal of stealing a given (well known) AID?



Using CGA based AIDs seems to provide enough security. 

Well, i reach the same conclusion  :-)
CGAs seems a good approach to deal with these issues

 However, if
we want to pursue that further, we would have to consider the IPR.


Yes.

regards, marcelo

--Pekka Nikander