[OLSR-users] Some updated on 0.4.4
Thu May 6 18:10:23 CEST 2004
Security is not my area of expertise - but here are my comments.
First of all, I do agree that a certificate solution would probably be
better in many ways. But the MANET is supposed to be without any kind of
centrelaized services and IMO this kind of break with that
philosophy(atleast of you demand the rootCA to always be reachable for
revocation lists, initial signing etc.). There are many questions that
must be answered for scenarioes with rootCAs. Who is to decide who
should be the rootCA? Should one operate with backup/reelection of
rootCAs if the rootCA node looses connection? What kind of process
should lead to a revocation/issuing of a sertificate?
If there is to be no dynamic in the scenario(eg. revocation/issuing)
then why not just have a fixed database of public keys and go for a
assymetric signing scenario?
I can see scenarios where a shared key can be used. As an example a
shared key could e.g. be saved into a SIM card that does the actual
signing so that the key never leaves the card, which all users insert
into their nodesand which could be replaced on a daily basis.
But ofacuse - a shared key is probably no optimal solution and the
secure OLSR solution is going to support(but not yet implement) all
different kind of encryption/signing schemes due to a flexible message
header. So in future versions a sertificate solution might be
implemented - but there are just so much more work that has to be done
in addition to the signing/timestamp exchange proccess for such a
solution to work.
Alexander Morlang wrote:
> Andreas Tønnesen wrote:
>> Hi all,
>> Just some words on what will be added on 0.4.4.
>> I am currently working on a security plugin for olsrd that will be a
>> part of olsrd 0.4.4. This functionality will ensure integrity in the
>> MANET by the use of a shared key and freshness will be ensured by a
>> timestamp exchange functionallity. The protocol itself will be
>> described in my master thesis and in a paper later on. I can't say
>> just how well documented or tested this plugin will be in the 0.4.4
>> realease but I figure it will be interesting for some anyways.
> Isn't a certificate based signing with some kind of a rootCA instead of
> a shared key more usable?
> As soon as there are more user, it would be impossilble to keep the
> sharedkey "secret", changing the key on a few hundred nodes would be not
> that easy.
>> Besides that I will update the gateway tunneling code used in this paper:
>> so that it is usable without all the obscure pre-configuration needed
>> as of now - but this will probably not happen in the 0.4.4 release.
>> In my work at Thales Communications I have implemented a IP(v4)
>> address autoconfiguration plugin(and daemon) that I hopefully can
>> release into the public domain soon. However I cannot assure that this
>> plugin will be GPL licensed. This work will be documented in a
>> Internet draft and probably a paper in the near future.
>> Minor issues that will be updated in 0.4.4 are some RFC compliance
>> issues(HNA IPv6 messages and route calculation based on WILL_ALWAYS),
>> some more options in the configuration file and some more work on the
>> link-layer information(but this is far from beeing usable as of yet).
>> And finally - as my master is soon finished I am looking for a
>> _interesting_ job(Unix, C, network...) ;)
>> - Andreas T
UniK University Graduation Center
University of Oslo
More information about the Olsr-users