[jdev] GSSAPI and service hostname
Matthew A. Miller
linuxwolf at outer-planes.net
Thu Jan 15 12:02:24 CST 2009
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 designed
> for a slightly different use case (basically situations in which DNS
> SRV
> results 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
linuxwolf at outer-planes.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2238 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20090115/cf8d5aaa/attachment-0003.bin>
More information about the JDev
mailing list