[Babel-users] About an authentication extension

[Toke Høiland-Jørgensen]

Rodrigo Garcia <strysg at riseup.net> writes:

> Hello, i've been working on an extension to the babel protocol to
> authenticate updates using RSA. It's mostly an academic excercise and i
> have planned the first functional versions in a month or so.

What are you trying to achieve? What is your threat model?

> The main idea is to make that a *central entity* generates a set of
> encrypted tokens using a RSA *private key*. The set of tokens is
> unique to every node on the network and every node receives it's
> unique set of tokens, a network prefix and the *public key* from the
> central entity.

You're basically talking about signed tokens here, right? Why do they
need to be encrypted? This sounds a little bit like you're rolling your
own crypto (which is generally a bad idea). I'd suggest you make
absolutely sure you have your primitives defined, and also define the
problems you are going to solve (threat model etc).

> Every decrypted token has the form:
>
> <network_prefix>_<randomnumber>
>
> example:
>
> 80.0.2.0/24_48003818
> 80.0.2.0/24_41106879

So what you are authenticating is that this router is authorised to
export this prefix? What's the purpose of the random number? How are you
preventing an intermediate router from just grabbing a token from
another router and reusing it?

> I was planning to use encrypted tokens of 512 octets.

Holy cow; you realise that on some mediums a single token will take up
the entire available package size, right? And you presumably need a
token for each prefix? Why do you need such big signatures? ed25519
signatures fit in 64 bytes, for instance, and that will lower the
computational cost as well...

> Every node must send a token from it's unique set of tokens on every
> route update. When a node receives an update, it tries to decrypt the
> token using the *public key* of the central entity and checks if the
> decrypted token contains the network prefix being advertised.

So the tokens are propagated across the entire network? That is *a lot*
of extra traffic.

> If so, the update is taken, if not it is ignored.
>
> So I came to define a new TLV named lorauth
>
>  0                   1                     2
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |     Type=29   |           Length              |
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>  |      Clen                     |  Cipher...
>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>
> Clen: Length of encrypted token
> Cipher: Encrypted Token
>
> But as the Cipher length is 512 it needs 2 octets in _Length_, so here
> the questions:
>
> * If I use 2 octets will this extension be compatible with other
> extensions according to rfc - 7557 ?

Nope, implementations that don't understand your extension are going to
choke on your TLVs...

> * I'm guessing it take lots of extra work to every node by decrypting
> on every update, but a node may be less restrictive and only *prefer*
> updates authenticated this way, than common updates. Can you think of
> better ideas to reduce the need of decrypting?

Depends on what you are trying to achieve. I'd suggest taking a step
back and defining this instead of jumping into an implementation.

-Toke