On 20/01/14 00:09, Matthew Wild wrote: > On 19 January 2014 21:28, Daniel Pocock <dan...@pocock.com.au> wrote: >> On 19/01/14 10:46, Dave Cridland wrote: >> >> On Sun, Jan 19, 2014 at 8:43 AM, Daniel Pocock <dan...@pocock.com.au> wrote: >>> As mentioned in the other email, FOSDEM is coming up, maybe that will be >>> an opportunity to discuss in person? (Please don't let my .au domain >>> deceive you, I'm based in central Europe) >> >>> Sadly, I don't think Matt is joining us this time around; perhaps this might >>> change his mind, though. There'll certainly be other Prosody developers >>> present, though, I'd hope. > I wasn't, but I'll see what I can do. > >> Just some initial discussion points for the Debian implementation, if >> anybody could comment on any of these areas we could start building up a >> wiki about it and that will evolve into the project plan: >> >> a) the DSA team always prefer to use packages from the stable distribution >> (or the stable backports), is there any compelling reason we should not use >> those versions for this project? Here they are: >> http://packages.qa.debian.org/p/prosody.html >> - stable= 0.8.2 >> - backports = 0.9.1 >> I see 0.9.2 is on the Prosody web site - to get that into backports probably >> takes at least three weeks anyway > I strongly recommend 0.9.x if you can - we put in a lot of work > improving lots of things, in areas such as performance and security > enhancements. > >> b) Debian Developers have been given RTC passwords for TURN and SIP and >> hopefully XMPP. They are hashed using HA1 for DIGEST/HMAC algorithms such >> as SIP and TURN. Can XMPP use these password hashes or do we need to hash >> them in some other format? > Sure, Prosody has pluggable authentication, whatever format you have > should be pretty easy to use. > >> c) the user passwords are available in two ways: we can supply a text file >> directly to the server (see the format used by reTurn, link below) or via a >> FreeRADIUS server with the rlm_digest module - can Prosody use either of >> these solutions or do we need to come up with something else? > We don't have a RADIUS plugin yet, but it's on my todo.
I'd also like to see RADIUS support added to a TURN server (there are three free TURN servers, none supports it yet) One sticking point is that RADIUS uses HMAC instead of DIGEST, so the existing rlm_digest in the FreeRADIUS server can't help. So I rewrote it for HMAC, but the FreeRADIUS team have suggested it needs a bigger overhaul and that hasn't happened yet. https://github.com/FreeRADIUS/freeradius-server/pull/367 http://www.resiprocate.org/RADIUS On the client side, we use freeradius-client C library for SIP in reSIProcate but a) something that integrates with an event loop seems more desirable for scalability reasons, integration with boost:asio (in reTurn), etc b) to handle the FreeRADIUS community suggestion that we use long extended attributes, we may need to completely drop freeradius-client and use the client lib from FreeRADIUS itself as a starting point None of this blocks the Debian.org project thought, please feel free to copy it into your issue tracker/wishlist for Prosody and whenever either of us starts doing more with this, maybe we can collaborate on some aspects of it. > >> reTurn users.txt sample (we use HA1 in the third column now): >> https://github.com/resiprocate/resiprocate/blob/master/reTurn/users.txt > That seems trivial, is the SHA1 just a plain SHA1 of the password? or > is it salted or what? There is no salt. It is the plain HA1 used for DIGEST MD5 (just like HTTP) A1 = username:realm:password H(A1) = MD5(username:realm:password) One other gotcha: when we hash, we are using the full AoR as the username in the authentication algorithm. In the SIP world, many softphones default to using the username part of the AoR only, e.g typical default, A1 = pocock:rtc.debian.org:secretpassword Debian.org A1 = poc...@debian.org:rtc.debian.org:secretpassword If you do support RADIUS one day, then the RADIUS server never lets you see the H(A1) value: instead, you have to a) construct a DIGEST-style challenge to the client b) receive the response string (usually a hash of some kind) from the client c) send your server-side copy of the challenge data and the client supplied response string to the RADIUS server d) the RADIUS server than gives you a YES/NO response - it never gives out the HA1 for your own computations >> d) IPv6 - any new stuff we do in Debian has to be dual stack, should this be >> fine with Prosody? > Ah, this is a little tricky if restricted to only with > stable/backports. Prosody 0.9.x supports IPv6, however it requires a > newer version of lua-socket to support it. Upstream are going slow > with releasing, but they have issued a release candidate which is > packaged and available in unstable and testing. I don't think it would > be hard to backport. I think it will be good to test that a little first and aim to make it part of the Debian.org deployment. I don't mind waiting a little bit for that to be sorted out. It will be good for Prosody to have this on day one, many people around Debian are keen on IPv6 and they may look at it with slightly less enthusiasm if that is not there the first time they see it. >> e) other dependencies, e.g. databases. Debian infrastructure currently uses >> PostgreSQL (no MySQL) but if possible, using no database at all, keeping >> each process somewhat self-contained. Looking at the package dependencies, >> I see that several databases are suggested. Could anybody comment on just >> how compelling it is to use a full SQL database, can we happily use the >> sqlite3 driver, etc? > Prosody uses the filesystem by default, and this works fine for all > but the largest installations. If you need SQL then yes, we support > Postgres or SQLite, but I don't think you gain anything except perhaps > interop with other applications (but there are other ways to achieve > that too). > >> f) collaboration with the SIP infrastructure: is there any practical way to >> share presence services, chat messages or anything else just yet? We don't >> have any presence server for SIP right now, it would be nice to plan the >> strategy for that alongside the XMPP planning > Probably a little more work, but something I'd love to investigate > further. I know there are various SIP<->XMPP things around, including > some based on Prosody, but I'm not really in the SIP world enough to > know the full state of things. We have this in reSIProcate, it is an XMPP-SIP gateway aimed at the iChat client, I've never actually used it for anything myself though: https://svn.resiprocate.org/viewsvn/resiprocate/main/apps/ichat-gw/ The PDF in the doc directory gives some explanation, it says it aims to support audio calls so it is not clear whether it will help for messaging or presence, but it may be a useful foundation to build something on This would not be essential for the first stage of the Debian.org deployment either, but it would be nice to start documenting it on the wiki for a future upgrade of the debian.org RTC environment.
