[olsr-dev] olsrd secure plugin

[Sven-Ola Tuecke]

Hi Jon,

most crypto/key/trustsystems will introduce a centralized instance into the 
system - or (worse) make things really complicated. I personally have 
arguments against both ;-) According to the KISS papers - the current secure 
plugin will do what I suggest, simply rip people off their anon hideout and 
offer a valid email address for administrative purposes to the community.

Regards, Sven-Ola

""Jon Andersson"" <(spam-protected)> schrieb im Newsbeitrag 
news:(spam-protected)
> Hello,
>
> I would suggest that you looked a bit further, and considered updates to 
> the
> security plugin, e.g.
> - automatic generation, change and/or update of the static, pre-shared key
> (Static keys makes my skin crawl...)
> - automated re-keying to exclude users
> - authenication of users
> - etc...
>
> The solution selected in the security plugin (static, pre-shared key) was
> only meant as a simple proof of concept.
>
> Unfortunately we never got around to changing it to something better :-(
>
> I know there has been made extensions on the security plugin that covers
> parts of what I described above, but the paper describing it has not been
> publiched yet.
>
> Regards,
>
> Jon
>
>
>>thanks for your reply. Well, here in Berlin we are working on a small
>>registry system to manage IPs and participants. For now, nearly all users
>>are cooperative which means there is always a chance to make an email note
>>to the one injecting wrong/disfunct HNA4s.
>>
>>To be prepared for the things to come its always good to have options. One
>>of these options will be the secure plugin - we may distribute the key via
>>email just to make sure the database entry of a participant is correct. If
>>rejecting HNAs is not an option, there are plenty of methods left for
>>adjusted responses to administrative/technical problems anyhow.
>>
>>Regards, Sven-Ola
>>
>>"Andreas "Tønnesen"" <(spam-protected)> schrieb im Newsbeitrag
>>news:(spam-protected)
>>>
>>> Hi Sven,
>>>
>>> The secure plugin only uses a SHA-1 hash function from openSSL
>>as far as I
>>> can remember. I just used the openSSL lib since it is the most 
>>> widespread
>>> lib for theese things. I think it's a good idea to use a much
>>smaller lib,
>>> (or perhaps include hashing code in the plugin?). All you really
>>need is a
>>> hashing function, so if MatrixSSL supports SHA-1/MD5 etc. (which I guess
>>> it does), it should work fine :)
>>>
>>> Regarding your HNA blocking question that is a rather tricky
>>one. This has
>>> been discussed before and I belive we came to the conclusion
>>that it would
>>> not be supported in officcial olsrd code. The problem is that
>>this kind of
>>> functionallity has to be distributed if we are to avoid routing loops.
>>> I think the best way is to create a plugin that will broadcast a set of
>>> IPs to ignore when parsing HNA messages. But then there is the security
>>> issue...
>>> I fully agree that this would be a useful feature but IMO it can only be
>>> done if it is distributed.
>>>
>>> - Andreas
>>>
>>>
>>>> Hello oncemore,
>>>>
>>>> while I'am in questioning mode - the secure olsr plugin rely on the
>>>> OpenSSL
>>>> library which is really huge (in terms of flash/disk space usage). Is
>>>> there
>>>> a chance to link it against MatrixSSL?
>>>>
>>>> Regards,
>>>> Sven-Ola
>>>>
>>>>
>>>> _______________________________________________
>>>> olsr-dev mailing list
>>>> (spam-protected)
>>>> https://www.olsr.org/mailman/listinfo/olsr-dev
>>>>
>>>
>>>
>>> ---------
>>> Andreas Tønnesen
>>> http://www.olsr.org
>>> _______________________________________________
>>> olsr-dev mailing list
>>> (spam-protected)
>>> https://www.olsr.org/mailman/listinfo/olsr-dev
>>
>>
>>_______________________________________________
>>olsr-dev mailing list
>>(spam-protected)
>>https://www.olsr.org/mailman/listinfo/olsr-dev
>>
>>
>
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev