[Psi-Devel] GSSAPI / Kerberos single-signon

[Justin Karneges]

On Saturday 10 November 2007 1:52 pm, Simon Wilkinson wrote:
> On 10 Nov 2007, at 21:40, Justin Karneges wrote:
> > On Saturday 10 November 2007 1:16 pm, Simon Wilkinson wrote:
> >> that patch. In particular, it's important that the SASL libraries use
> >> the FQDN of the server being connected to (after any SRV resolution),
> >> rather than the domain of the user's JID, when providing the service
> >> name to Cyrus. I don't know if Psi is doing this, but it's worth
> >> checking, as it seems to be the single largest cause of client side
> >> problems with GSSAPI.
> >
> > We were wondering about this as well.  Do you have any reference/
> > spec that
> > shows we should use the target server being connected to?
>
> There's not that much that's useful specification wise in this space
> at the moment (and it's all going to change again when domain based
> naming for GSSAPI becomes widely available). I've had a number of
> conversations on the jdev and kerberos mailings list about this which
> I can dig up some references for if that would help, and it's also
> worth looking at what the email clients do in this space, too.
>
> The best I can give you at the moment is in terms of this reference
> from the SASL headers:
>
> /* initialize a client exchange based on the specified mechanism
> *  service       -- registered name of the service using SASL (e.g.
> "imap")
> *  serverFQDN    -- the fully qualified domain name of the server
> */
>
> That is, Cyrus expects you to pass a FQDN in for the server, not an
> alias. Compare this with the language in RFC4752 (which defines the
> GSSAPI SASL mechanism), which says that the GSSAPI identity of the
> server is '"service at hostname" where "service" is the service name
> specified in the protocol's profile, and "hostname" is the fully
> qualified host name of the server' - so you have to be able to tell
> the GSSAPI mechanism the FQDN of the server it's connecting to.
>
> Neither DIGEST-MD5 (RFC2831) nor PLAIN (RFC4616) use the FQDN for
> anything, so setting it to the correct value should have no effect.
> It's what all of the other Jabber GSSAPI implementations that I am
> aware of are now doing.

I've done a bunch of investigation on this now and indeed this seems to be how 
Kerberos is supposed to work.  Unfortunately, automatically deriving the FQDN 
through SRV introduces a small security issue I think.

If the user does not assert the FQDN to connect to, and this value is instead 
derived insecurely (e.g. through insecure DNS SRV), then an attacker could 
trick the client into connecting to a different FQDN, such as a machine 
controlled by the attacker.  The client will only connect to a machine for 
which it can obtain a ticket though, so this limits the attack only to other 
kerberos services on the same domain.  Since the protocol type is included in 
the principal name, I believe this would additionally mean that only other 
authorized XMPP servers that the user is able to obtain tickets for could be 
used in an attack.

I suspect most networks would only have one XMPP server, and if they have many 
then it is probably due to a cluster setup, in which case they are all 
effectively the same service and are all legit.  Ensuring that only legit 
XMPP services exist on the network is something under control of the network 
administrator, so a well-tightened network should not be at risk.  However, 
even here at work we already have two XMPP services with unique 'xmpp/foo' 
principal entries in Active Directory: the main one, and my test box.  
Therefore, I could hijack connections and route them to my test box if I was 
so inclined.

The other issue is if a user logs into multiple kerberos domains 
simultaneously.  If I kinit to school and to work, and each one has an XMPP 
service, then when I connect to the school XMPP it would be possible for an 
attacker to make me connect to the work XMPP instead.

What does this all mean?  I propose an extra field in the account 
settings: "Server FQDN".  The field could be filled in by the paranoid, to 
plug the above holes.  If left blank, then the authentication process would 
attempt to derive the value.

-Justin