On Jan 15, 2009, at 10:19, Peter Saint-Andre wrote:
Another is to use XEP-233.AFAIK, no servers implement that yet, and in any case it was designedfor a slightly different use case (basically situations in which DNS SRVresults don't tell you the hostname of the connection manager you're talking to because load balancers are in use).
Besides, XEP-233 isn't any more secure than the SRV lookup.* If you can't trust the name from the SRV lookup that sent you to this (possibly fake) server, why can you now trust the value provided via XEP-233 from that server? * If you trust the XEP-233 result because you've got a secure channel (STARTTLS) and trusted their certificate, then why can't you now trust the SRV result?
From my own observations and experiences, Deployments involving GSSAPI require significant planning, and is almost always undertaken because of the organization's security policy. I've not seen such a policy that mandating GSSAPI, but then ignored issues around network name resolution.
So back to the original poster:My recommendation for your library would be to rely on the (FQDN of the) hostname used to establish the XMPP/TCP connection, but make sure you have a way to manually bypass DNS SRV for establishing said connection (i.e. explicit hostname for the socket connection). If the users of the library are willing to trust the hostname enough to get to the point where authentication is attempted, then odds are they're willing (or rather, required) to trust that hostname in obtaining the service principal credentials.
-- Matthew A. Miller [email protected]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
