-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Sep 17, 2001 at 01:59:03PM -0700, rillian wrote:> Unfortunately, anything more secure requires a shared secret, and thus > and ssl-connection over which to send it.Not necessarily. There's always public-private key encryption, which wouldn't be too hard to implement. Of course, now we run into the trust problem of receiving a server key over the Internet and all, but that's just being pedantic and not appropriate for this discussion.> For example, running the > contents of the update through the hash in addition to the password > would let the server verify each update directly and block replay > attacks. Of course, this assumes the connection in between is more > vulnerable than the server and/or the client's machine, so perhaps in > practice it's so much better. Still, I think it's worth trying to do > this right.I'd love to see the backend connection to the directory server being run through an SSL tunnel. Not being a programmer, though, I don't know of the scope of effort it would take to implement that. Something for Jack to answer. The real question comes down to this: What is the value of the data we're trying to protect? Conceivably, someone could hijack the connection and send false data back to the directory server. Maybe just mess with your listing, maybe a form of DoS. Perhaps you might be able to inject something that would mess with the directory server itself. I think, though, that if that were the case, you'd be able to break things even if it was running over SSL. Sure, I'd rather have everything encrypted. Whether or not that's feasible, though... - -- "Nothing's the same anymore." - Cmdr. Jeffrey Sinclair, Babylon-5, "Chrysalis" -----BEGIN PGP SIGNATURE----- Comment: For info see http://www.gnupg.org iD8DBQE7pnMiAmwSMwnpLHgRAj0JAKCfwPVMqe3zJea+UzhFMtZRPUNycACdFAVq xzbqgDCHieyMTBwLQJF0mLk=vRxC -----END PGP SIGNATURE----- --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
Forgive the lack of antecendents. I just now joined the list, but will respond generally to what I saw in the list archives. I think jack's suggestion of distinguishing between static and time-depended data is a smart one. I would also suggest that many of the ranking issues people are concerned about can be addressed through the description field. Punting things like 'now playing' to a metadata stream seems like a good idea. Directory servers can watch this directly and add it to their displays if they think that's worthwhile. The ttl field does provides some time-dependence capabilities, and it can be abused by setting it too short as well as too long. The latter case can be solved though a no-ping expiry policy on the directory server as jack suggested. Probably we should just design so '0' is also an acceptable setting, and let individual maintainers decide on a minimum individually. The ttl field in dns is mostly there to control propagation through a distributed cache. Are we planning something like that for the icecast directory(ies)?> auth > authorization string. this is a md5sum of of some > random data. > ex.: echo 'jack@xiph.org|Jack Moffitt|password' | md5sumAs written, this adds little security over sending the password in plaintext. Some folks at mit recently wrote a nice summary of how to do secure auth over the web: http://cookies.lcs.mit.edu/pubs/webauth:tr.pdf Unfortunately, anything more secure requires a shared secret, and thus and ssl-connection over which to send it. For example, running the contents of the update through the hash in addition to the password would let the server verify each update directly and block replay attacks. Of course, this assumes the connection in between is more vulnerable than the server and/or the client's machine, so perhaps in practice it's so much better. Still, I think it's worth trying to do this right.> We could add a second tag 'rate', which could be in kHz for audio, and > in fps for video based streams. We could also add a 'channels' to > describe the number of audio channels (it's not unlikely we will see > surround sound Ogg streams) and maybe a 'size' for picture size (ex.: > 160x120).I think a separate table is needed with stream urls and this specific metadata, all of which sits under the more general data like stream name, homepage and description. That easily takes care of both mirrors and alternate bitrate versions of the same content. All the extra bits get complicated fast, but bitrate, samplerate, number of channels, and size seem like a good starting point. Maybe 'size' should be replaced by 'format' which can be the resolution/aspect ratio for video and the surround format for audio. You might also want some sort of sub-description that could say things like 'Pacific Mirror'. Otherwise, the general layout looks good. Program 'guides' for a particular station with scheduled programming is another nice feature, but it's somewhat orthogonal to what jack has suggested. I do think it's perfectly reasonable for the same software to support it, but we should think about it as a separate piece of information. Anybody know if here's an xml working group for program listings? :) IMHO, -r --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> I'd love to see the backend connection to the directory server being > run through an SSL tunnel. Not being a programmer, though, I don't know of > the scope of effort it would take to implement that. Something for Jack to > answer.It would take a bit of effort. And it would also be totally useless. What benefit would it provide? You're publishing the information publically anyway :) jack. --- >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@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.