[icecast] a new directory service

[Allen Landsidel]

At 09:43 PM 10/17/2001 -0600, you wrote:

>The chances of someone sucessfully attacking a target of their choice is
>quite slim in this system, unless they can assume control of the server
>machine or assume control of the source machine.   In either of those
>situations, it would matter little what security method was used.

Well they can also attack any system in between to set up a Mallory (as the 
guy in the middle is called) and dupe you.  It's just a matter of 
intercepting the packets bound for the directory server, connecting them to 
your own, and then connecting from your directory server to the real 
one.  Then you're altering things in real time, and it's totally 
transparent.. This is a "big" problem no matter what sort of double-blind 
system you use however.

>Public keys are not really as easy to use as everyone would like.  If
>needed it can be done.  And I have no doubts that at some point
>something like this will get in there, but there's little reason to do
>so right now.

Well I beg to differ on the first point.  A simple method is to just have 
the server generate it's keypair on initial startup/installation and then 
serve up the public key when requested.  It's a little harder on machines 
on both ends to do the encryption, but horsepower is disgustingly cheap 
these days.

Consider the following simple protocol:

1) Client connects to server and downloads the servers public key.
2) Client encrypts it's own public key (or a private per-session key) with 
the key it downloaded in step #1 and sends it.
3) Both ends initiate encrypted communication.

This is simple and perfectly secure so long as the client trusts that it 
indeed got the actual servers public key.  This can be accomplished by 
using multiple methods of key verification, or by using a known-good public 
key server which signs the key transfer with it's own known-good key.

There are several packages out there that can automate a great deal of this 
in code.. it's just a matter of using a wrapper for all your socket calls 
that has an internal "encrypted=true|false" state.

This isn't foolproof itself to a determined adversary, but it would stop 
all but the most determined and sophisticated attacks.

>If you think there are scenarios that aren't being considered, or you
>feel strongly that sniffing attacks are sufficiently dangerous, then by
>all means speak up :)

I just did. ;)  I don't think that the situation currently warrants this 
level of paranoia; However, I don't think it would add any harm or much 
effort to add it in.  Kind of like not limiting ourselves to 640K like 
someone once did for us.. still haunting us in some ways to this very day. ;)

--- >8 ----
List archives:  http://www.xiph.org/archives/
icecast project homepage: http://www.icecast.org/
To unsubscribe from this list, send a message to 'icecast-request at xiph.org'
containing only the word 'unsubscribe' in the body.  No subject is needed.
Unsubscribe messages sent to the list will be ignored/filtered.