[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  
> 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: <http://mail.jabber.org/pipermail/jdev/attachments/20090115/cf8d5aaa/attachment-0003.bin>

More information about the JDev mailing list