Re: [Babel-users] [babel] Reworked implementation of Babel-over-DTLS

[STARK, BARBARA H]

> I’ve finally managed to rework my implementation of Babel-over-DTLS
> (spoiler: it seems to be working).  Thanks to Juliusz for the help.

Cool. This is great.



> It is unclear to me how the user interface to provide certificates and private
> keys should look like, and if we prefer CA certificates or self-signed.  
> Perhaps
> the draft should be more specific about that.

Since no one else answered, here are my opinions...

My reading of the babel-dtls draft (and DTLS references) is 2 types of 
certificates are mentioned: X.509 is mandatory and Raw Public Key is optional. 
Raw Public Key has no signature (self or CA). X.509 can be self-signed or 
signed by someone else (i.e., a CA). In all cases, the implementation needs 
(somehow) to be configured with the certificates it trusts for use with Babel. 
If CAs are going to be trusted to sign usable-for-my-Babel-network certs, then 
the implementation needs to be configured with CA X.509 certificates that are 
trusted by the owner of the Babel network.

For a basic implementation, I would suggest having a Babel trust store for 
certificates that are directly trusted for use with Babel (independent of 
whether or how they are signed). If the certificate is in the Babel trust 
store, it's trusted.

If you also want to support CA-signed trust of X.509 certificates (that are not 
yet in the Babel trust store), then you need a store of trusted Babel CA 
certificates. This store MUST NOT be the same trust store used for any web 
browsers or software updates, etc. It MAY be a trust store of CAs trusted to 
sign certificates for devices allowed to operate on this (local or virtually 
local) network. Even if you support CA-signed, you can store received 
certificates signed by trusted CAs in the "directly trusted" Babel store for 
future direct trust. 

As for user interface: One way to do this simply would be to allow a person to 
provide a file (for trusted certificates) with one or more certificates in PEM 
format. For the device's own certificate, you could probably get it to generate 
its own (self-signed certificate) and then provide a file with the certificate 
in PEM format (that you can then load into other devices). Since the 
certificate was locally generated, it will already have the private key -- so 
you won't need to deal with that. All certificate-generating utilities support 
PEM. If you're running a CA that will generate all the certificates and 
associated private keys, you'll need to see what file formats that CA 
implementation supports, for exporting certificates and private keys. Then 
support that. PEM will likely be supported, but you'll need to see how 
Certificate+Key gets done.

Barbara


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

[Babel-users] Reworked implementation of Babel-over-DTLS

[Antonin Décimo]

Hello lists,

I’ve finally managed to rework my implementation of Babel-over-DTLS
(spoiler: it seems to be working).  Thanks to Juliusz for the help.
You can get the code by doing

git clone -b dtls2 https://github.com/MisterDA/babeld

The code requires the mbedTLS library (version 2.16) [1].

The code is still heavily instrumented (lots of printfs…).  While this
code is not carefully tested, it is meant to eventually implement the
protocol described in

https://tools.ietf.org/html/draft-ietf-babel-dtls

Known issues:

  - no interoperability testing has been done yet;
  - we don’t timeout neighbours properly, which makes us vulnerable to
delayed packets;
  - there is no user interface to provide certificates and keys, they
are all hard-coded in the DTLS library.


It is unclear to me how the user interface to provide certificates and
private keys should look like, and if we prefer CA certificates or
self-signed.  Perhaps the draft should be more specific about that.


You can test this code by saying something like:

babeld -C 'interface eth0 unicast true dtls true'


The "unicast true" flag tells babeld to send all TLVs but Hello TLVs
over unicast, "dtls true" tells babeld to use DTLS on the selected
interface.  The "unicast" flag is required for Babel-over-DTLS to
operate as expected.  Use "dtls-protocol-port" to specify a port.  The
default port is hard-coded to 5, a port number has been requested
to IANA.


[1]: https://tls.mbed.org/

--
Antonin Décimo

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