Re: [Babel-users] About an authentication extension

[Juliusz Chroboczek]

> I see, however the project has already been accepted so i will have to
> do it anyway :(

Good.

Perhaps you can tell us more about the project, so we can work together at
tweaking its parameters to make sure it is useful to the wider Babel
community?  Preferably on the list, since there's a number of competent
people here, but if for some reason you prefer private mail to Toke and
myself, that's okay too.

-- Juliusz

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] About an authentication extension

[Toke Høiland-Jørgensen]

Rodrigo Garcia  writes:

> I see, however the project has already been accepted so i will have to
> do it anyway :(
>
> Maybe i can think not to use random numbers but something to make it
> more difficult that a false ciphertext be accepted by other nodes.

Well, the way you avoid this is to do a proper signature. You could do
something like SIGN(CONCAT(prefix, router_id, nonce)) and use that as
your token. The exact information you use for the signature has to be
decided based on your threat analysis, which is why I suggested you take
a step back and do one. For instance, you may want to add a timestamp so
you can expire signatures after a while.

> Thanks, i will use the references to point out the vulnerabilities.

Good luck! :)

-Toke

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] About an authentication extension

[Rodrigo Garcia]

I see, however the project has already been accepted so i will have to
do it anyway :(

Maybe i can think not to use random numbers but something to make it
more difficult that a false ciphertext be accepted by other nodes.

Thanks, i will use the references to point out the vulnerabilities.

El 10/09/17 a las 13:13, Toke Høiland-Jørgensen escribió:
>> Yes, but a node does not have the private key, so it can't create *new*
>> encrypted tokens by its own.
> 
> Not necessarily. In general, even if you don't know the private key,
> changing the ciphertext can still change the plaintext after decryption.
> Especially, since in your scheme an attacker only needs to change a
> single byte (holding the random number attached to a prefix) to get a
> new valid token for that prefix.
> 
> For RSA in particular, don't encrypt things with the private key; see
> https://stackoverflow.com/questions/44261028/modification-of-rsa-encrypted-cipher-text
> and this answer linked from there:
> https://crypto.stackexchange.com/questions/15997/is-rsa-encryption-of-a-cryptographic-hash-with-a-private-key-the-same-as-signatu







___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] About an authentication extension

[Denis Ovsienko]

>Right, I see. Are you familiar with the HMAC extension to babel
>(RFC7298)? That does something different (it prevents nodes that don't
>know the shared secret from participating in the network at all, but
>does not restrict which prefixes each node can export). However, it may
>be useful to read at least parts of it to help you formulate the
>requirements for your own scheme.

RFC 4593 is a good starting point.

-- 
Denis Ovsienko



___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] About an authentication extension

[Toke Høiland-Jørgensen]

Rodrigo Garcia  writes:

>> But if everyone knows how to decrypt all the tokens they are not really
>> secret; so it basically becomes the same as a signature, no? Except if
>> it's *not* signed you may be able to spoof other values by changing the
>> ciphertext of a valid token you already own (not sure how susceptible
>> public crypto is to this)...
>> 
>
> Yes, but a node does not have the private key, so it can't create *new*
> encrypted tokens by its own.

Not necessarily. In general, even if you don't know the private key,
changing the ciphertext can still change the plaintext after decryption.
Especially, since in your scheme an attacker only needs to change a
single byte (holding the random number attached to a prefix) to get a
new valid token for that prefix.

For RSA in particular, don't encrypt things with the private key; see
https://stackoverflow.com/questions/44261028/modification-of-rsa-encrypted-cipher-text
and this answer linked from there:
https://crypto.stackexchange.com/questions/15997/is-rsa-encryption-of-a-cryptographic-hash-with-a-private-key-the-same-as-signatu

-Toke

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] About an authentication extension

[Rodrigo Garcia]

El 08/09/17 a las 07:37, Toke Høiland-Jørgensen escribió:
>> Hi, i wanted to reduce the risk of ip spoofing as an academic excercise.
> 
> I'm all for academic exercises, I'm just suggesting that it'll be
> helpful to define (on the protocol level) what you are trying to protect
> against. I.e., which nodes should be prevented from doing what?
> 

> Right, I see. Are you familiar with the HMAC extension to babel
> (RFC7298)? That does something different (it prevents nodes that don't
> know the shared secret from participating in the network at all, but
> does not restrict which prefixes each node can export). However, it may
> be useful to read at least parts of it to help you formulate the
> requirements for your own scheme.
> 

I reviewd the HMAC extension but not in detail because i realized that
as you say it does not protect nodes against ip spoofing.

> But if everyone knows how to decrypt all the tokens they are not really
> secret; so it basically becomes the same as a signature, no? Except if
> it's *not* signed you may be able to spoof other values by changing the
> ciphertext of a valid token you already own (not sure how susceptible
> public crypto is to this)...
> 

Yes, but a node does not have the private key, so it can't create *new*
encrypted tokens by its own.

> 
> So why not put that into a sub-TLV of the update?
> 

To tell the truth i saw how HMAC did and thougth it was a good idea to
define a new TLV, but not really considered about sub-TLV.

>> To prevent a node to just capture a token then reuse it a node should
>> have a big ammount of encrypted tokens and send different ones, the
>> random number is just to make then different and to make it more
>> difficult to guess the private key.
> 
> So what happens if a node runs out of tokens? How is another node
> supposed to deal with an update that has no corresponding token? Always
> ignore it? For how long?
> 

If a node runs out of Tokens and a malicious node got all of them that
is a problem.

I was planning that a node should select a token from it's set of tokens
based on the seqno and prefix, the former should change in time so a
different token is to be send every time the seqno changes.

> How does this interact with the other preference rules of Babel? Loop
> avoidance in particular; if there's an non-feasible signed route but a
> feasible unsigned route, is a node allowed to pick the unsigned one?

To tell the truth i haven't analized the efect on loop avoidance, but i
guess for flexebility sake a node should consider feasibility first than
authentication. So it is a condition that a route proves to be feasible
before even trying to check if it is correctly authenticated.


___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] About an authentication extension

[Toke Høiland-Jørgensen]

Rodrigo Garcia  writes:

> El 08/09/17 a las 05:28, Toke Høiland-Jørgensen escribió:
>> Rodrigo Garcia  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?
>> 
>
> Hi, i wanted to reduce the risk of ip spoofing as an academic excercise.

I'm all for academic exercises, I'm just suggesting that it'll be
helpful to define (on the protocol level) what you are trying to protect
against. I.e., which nodes should be prevented from doing what?

> I tried 3 routers and two of them advertising the same network prefix,
> at first 1st and 2nd router exchange routing information and established
> a link then let them sending ICMP ping.
>
> Secondly, the 3rd router starts advertising the same prefix as the 2nd
> and, then the 3rd router is intetionally put closer than 2nd to make it
> advertise a better metric.
>
> After some time 1st router prefers to take the route to the 2nd
> network prefix through 3rd. 2nd stoped to receive the ICMP packets
> from 1st, and 3rd started receiving ICMP packets from 1st instead.

Right, I see. Are you familiar with the HMAC extension to babel
(RFC7298)? That does something different (it prevents nodes that don't
know the shared secret from participating in the network at all, but
does not restrict which prefixes each node can export). However, it may
be useful to read at least parts of it to help you formulate the
requirements for your own scheme.

>>> 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).
>
> The tokens are not signed, they're just encrypted with a *private key*
> wich no single node owns. Instead a node must use the corresponding
> *public key* of the private key (wich is only used by a central entity
> to generate the encrypted set of tokens unique to every node)

But if everyone knows how to decrypt all the tokens they are not really
secret; so it basically becomes the same as a signature, no? Except if
it's *not* signed you may be able to spoof other values by changing the
ciphertext of a valid token you already own (not sure how susceptible
public crypto is to this)...

>>> Every decrypted token has the form:
>>>
>>> _
>>>
>>> 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?
>
> Yes, on an update a node must send a token which shows that it really
> owns the prefix it is being advertising.

So why not put that into a sub-TLV of the update?

> To prevent a node to just capture a token then reuse it a node should
> have a big ammount of encrypted tokens and send different ones, the
> random number is just to make then different and to make it more
> difficult to guess the private key.

So what happens if a node runs out of tokens? How is another node
supposed to deal with an update that has no corresponding token? Always
ignore it? For how long?

>>> 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...
>> 
>
> Yes it is, in practical terms i was planning that only a set of
> important nodes use the authentication method.
>
>>> 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.
>
> Yes it will be, but for flexibilty and network traffic sake, i think a
> node could forward also not authenticated updates (without the encrypted
> token) then if a node receives an update *with* the encrypted token it
> should 

Re: [Babel-users] About an authentication extension

[Rodrigo Garcia]

El 08/09/17 a las 05:28, Toke Høiland-Jørgensen escribió:
> Rodrigo Garcia  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?
> 

Hi, i wanted to reduce the risk of ip spoofing as an academic excercise.

I tried 3 routers and two of them advertising the same network prefix,
at first 1st and 2nd router exchange routing information and established
a link then let them sending ICMP ping.

Secondly, the 3rd router starts advertising the same prefix as the 2nd
and, then the 3rd router is intetionally put closer than 2nd to make it
advertise a better metric.

After some time 1st router prefers to take the route to the 2nd network
prefix through 3rd. 2nd stoped to receive the ICMP packets from 1st, and
3rd started receiving ICMP packets from 1st instead.

Here some logs (Sorry I could't get time to translate this to english)
https://git.laotrared.net/LaOtraRed-dev/babeld-lor/src/master/doc-lorauth/spoofing-tests1.md

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

The tokens are not signed, they're just encrypted with a *private key*
wich no single node owns. Instead a node must use the corresponding
*public key* of the private key (wich is only used by a central entity
to generate the encrypted set of tokens unique to every node)

>> Every decrypted token has the form:
>>
>> _
>>
>> 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?

Yes, on an update a node must send a token which shows that it really
owns the prefix it is being advertising.

To prevent a node to just capture a token then reuse it a node should
have a big ammount of encrypted tokens and send different ones, the
random number is just to make then different and to make it more
difficult to guess the private key.

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

Yes it is, in practical terms i was planning that only a set of
important nodes use the authentication method.

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

Yes it will be, but for flexibilty and network traffic sake, i think a
node could forward also not authenticated updates (without the encrypted
token) then if a node receives an update *with* the encrypted token it
should *prefer* that update over common ones and if it is valid then
forward it.

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

ok, (lol)

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

Thanks, i think i'll give it a try.

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users

Re: [Babel-users] About an authentication extension

[Toke Høiland-Jørgensen]

Rodrigo Garcia  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:
>
> _
>
> 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

___
Babel-users mailing list
Babel-users@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users