[Spread-users] Re: Spread authentication module and SASL

[Michael Fair]

> > I'm new to Spread so please forgive my ignorance.
> >
> > I'm interested in using Spread as the backbone of
> > an IRC server network (perhaps even extending it
> > to clients).
>
> The open-licensed version of Spread won't perform too well in this
> scenario, because it doesn't include the wide-area communication
> protocol AFAIK; I doubt that the broadcast protocol will be adequate
> over multicast tunnels, unless your IRC network is very closely
> coupled and using untunneled multicast.

I wasn't aware that the Open Source version was missing
functionality from what was in the white papers.  There didn't
seem to be any references to that in the documentation.  Thanks
for the update.  (I actually hadn't had the opportunity to try
anything other than a couple machines on my local subnet now
I'll know why when it doesn't work)

> The IRC server protocol itself tries to form a nondirected acyclic
> graph over a mesh of possible connections, and the message transport
> is then a pruned flood-fill over this graph.  This will not sit
> well with Spread; I have in the past considered writing an adapter
> daemon that speaks both IRC and some reliable, multipath meshed
> multicast protocol, to act as a proxy for the IRC server.
>
> Ordering is not an issue in IRC, which reduces actual need to that
> of a meshable, reliable multicast transport that can cope with
> ad-hoc changes in wide-area architecture without restart.

The primary purpose of the project wasn't to create a really
great IRC server network or even to implement the IRC RFCs
correctly.  It was more a relatively simple application that
I could proactice using the Spread Toolkit with.  However,
your notes are very well taken.  Besides, who says that
ordering couldn't be important to an IRC network (certainly
at least CAUSAL would be valuable). ;)

Ultimately I figured that what I would be writing was an
IRC server for clients to connect to.  The servers would
connect up to the Spread netowrk and there'd be a one-to-one
mapping between end user channels and Spread groups.
Each end user would get their own channel for private
messages sent directly to them and only the host IRC
server for that end user would be subscribed to it.
Each server would track which channels the local users
were talking on, subscribe to them, send messages on their
behalf, and leave if no local clients were talking on
that channel.  If an end user sends a message directly to
another user, the Server the end user was connected to
would simply post a message using the username as the
group name.

All commands used to administrate users, channel
operators, user modes, whois queries, etc would
be left for some later implementation.

Furthermore, I'd planned on writing it using the
Perl API.  As you can see performance isn't my
highest priorty at the moment, it's just practice.



> > Has SASL been considered for use as the authentication
> > and security communication layer between Spread clients
> > and Servers?
>
> One could embed it in the protocol.  I have a rough decode
> of the binary client-server protocol at
> http://www.roughtrade.net/spread/spread-client-proto.txt
>
> > I also thought that if SASL could be incorporated
> > into the server, then a more dynamic configuration
> > could be made possible by having Spread daemons
> > authenticate themselves to each other and request
> > inclusion into the network (this would of course be
> > bi-directional to ensure no one is taking advantage
> > of the opportunity to present a "man in the middle"
> > attack during a net partition).


> The Spread interdaemon protocol is not connection-based,
> which would make SASL a hard call.  Have you looked at
> Secure/Flush Spread, which could give you relatively
> strong levels of encryption and membership?

The primary advantage in this situation would be that there
are already a number of backend plugins available for it
(SQL db, passwd file, LDAP, special binary format, NTLM)
and rolling your own new one is becoming almost trivial
(the auxprop plugin makes pretty short work of adding
new protocols).


However, if dynamic (re)configuration of a Spread network
is a desired feature then surely the interdaemon protocol
at some point has to take on an outsider making some kind
of a request to join.  It wouldn't be that hard to have the
interdaemon protocol use some algorithm to select an
"authenticator" and a "secondary authenticator" and whenever
a "request to join" shows up let the authenticator deal
with it.  At this point, while a lot of daemons might
be "watching" the interaction, there are only two speakers
which makes it very much like a "session initiation" at
which you are now squarely inside SASL's targetted purpose.

Daemons (most likely via their config) could advertise
themselves as potential authenticators (so that not
every daemon out there has a copy of the credential
store) and the interdaemon protocol would always assure
a primary and secondary authenticator was available
assuming a sufficient number of authenticator daemons
were in the current network (or partition thereof).

It would be the responsibility of the administrators
to ensure that the credenail database for each of the
authenticators was synchronized.

I guess I just always think of OSPF when I think of
reliable routing networks..... It can run over multicast
and doesn't have any problem with dynamic additions
to the pool of routers.  Perhaps some methods can be
pulled from there?

Of course what's been presented here pretty much sums
up the extent of my group communication knowledge.  My
only prior multicast experience has been with OSPFv2
and even that was a relatvely small installation.  I
do have a lot more experience with system administration
which is where I learned my SASL knowledge about
deploying and using SASL.

-- Michael --