Thanks David for your insight. On Fri, Jun 18, 2010 at 9:10 PM, Dave Cridland <[email protected]> wrote: > On Fri Jun 18 15:08:17 2010, paddy joesoap wrote: >> >> Hi all, >> >> Does XMPP support the idea of restricting certain types of s2s >> authentication by IP addresses or DNS names? >> >> > No.
I thought as much ;-) > > >> For example, I may want to permit SASL External over TLS communication >> with IP addresses, 1.2.3.4 and 5.6.7.8 but will allow IP address >> a.b.c.d access via dialback. >> >> > However, nothing at all prevents a server from doing that - I don't think > any do right now, but that's no barrier at all. It'd be more likely to > define such authentication requirements in terms of peer domains, rather > than IP addresses. Absolutely. I agree about DNS names. However, as I put my firewall hat on, I think of network access control best practice NIST-800-41 and PCI-DSS for example, where access control rules SHOULD consider ip addresses rather than DNS names. Again, this helps to avoid the issue of DNS MITM attacks, a problem noted by the XMPP documenation (particularly with dialback and serverless p2p scenarios). > In some cases, it might even be desirable to have no authentication other > than the session emanates from a known IP address. This is an interesting point regarding no authentication. What scenarios have you in mind? Perhaps in a serverless p2p scenario? My previous XMPP/Firewall posts received some feedback that TLS should be used and SASL authentication should be used. I know that in practice, this is not always the case, for example dialback may be used between legacy s2s systems, internal corporate clients may communicate in the clear with the server, where SASL authentication may be used. In both of these scenario's (perhaps a requirement by a corporate policy to have unencrypted internal messages) one could perform deep packet inspection using a firewall or IDS. This inspection maybe part of a regulatory requirement at the expense of privacy! > > Much of what you're discussing is outside the scope of the standards, and > the protocol, and has a lot more to do with what individual implementors > have decided to offer. I thought as much and that is what I was hoping. So in this case, a firewall (network or locally hosted) can be used to emulate such a requirement ;-) In this case, I could write layer-7 rules that examine incoming packets for <STARTTLS> and <Dialback> XMPP tags where certain source IP address (or source DNS name) can only use packets with either or both of these tags. In that way, one could control what domain can use what authentication method. Another interesting observation in terms of XMPP access control that I haven't seen is controlling file transfers from leaving the internal network. Perhaps a security policy states that internally XMPP clients can send files to one another via the XMPP server. I understand that XMPP can dictate who can send files to whom based on their JID. The problem here is that, once that client leaves the corporate environment and logs in remotely (perhaps from home) the corporate policy may be broken. As traffic would pass through port 7777 of the firewall (a stateful rule permits all outgoing traffic) because the JID-based access control permits it. In this case, a firewall rule would need to be created to block such file transfer by the XMPP file transfer proxy (openfire). Thus, employing both the JID-based access control and the firewall-based access control one has a reasonable level of confidence that a security policy requirement is being upheld. I hope I have captured the access control granularity of XMPP correctly. > > Dave. > -- > Dave Cridland - mailto:[email protected] - xmpp:[email protected] > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade >
