[29034] in Kerberos
Re: Is "SPN advertisement" or well-known SPNs a security hole?
daemon@ATHENA.MIT.EDU (Ken Raeburn)
Mon Jan 14 18:22:59 2008
In-Reply-To: <422369.96913.qm@web46012.mail.sp1.yahoo.com>
Mime-Version: 1.0 (Apple Message framework v753)
Message-Id: <0BDE1437-5297-4561-A852-950422AE3CD9@mit.edu>
From: Ken Raeburn <raeburn@mit.edu>
Date: Mon, 14 Jan 2008 18:03:43 -0500
To: Srinivas Kakde <srinivas.kakde@yahoo.com>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Jan 14, 2008, at 16:57, Srinivas Kakde wrote:
> Hello,
>
> There is an old posting to samba-technical
>
> http://lists.samba.org/archive/samba-technical/2007-July/054354.html
>
> This message says: From a security standpoint, allowing the server
> to specify its
> service principal is a "bad idea".
>
> Why it a bad idea?
Basically, you're no longer authenticating the server as the entity
you want to talk to, merely as the entity it says it is. Consider:
I type in "ftp foo.bar.com".
An attacker intercepts my TCP connection establishment, spoofs a DNS
reply, brings up a system on foo's address while it's down for some
reason, or otherwise gets me to connect to a box that isn't foo.bar.com.
If, at this point, I let the server tell me what name to authenticate
to, it may say quux.bar.com. So, I ask my KDC for credentials to
authenticate me to quux.bar.com; it gives them to me, and I
authenticate to the server.
So now I'm connected to, and have authenticated to, a server that is
not the one I specified.
If I'm not monitoring an interactive session carefully, but am
running some GUI that connects, fetches (or deletes) a file, and
disconnects, I may never see anything that would tell me something
went wrong. So I may delete file X from the wrong system, fetch the
wrong version of a file, etc.
I may use a bogus account set up in my name by someone who
compromised a machine (which may not even be in the same company,
thanks to cross-realm authentication, and possibly someday PKCROSS),
or I may just be redirected to one of my accounts that I didn't want
to use for the operation.
If you use the name as supplied by the user (or as retrieved securely
from a trusted source), it's not such a problem, if the protocol is
designed right. (If you just send an authenticator, and then conduct
the rest of your session in the clear with no protection, it's still
not much better than not authenticating at all, even if you use the
requested-server name. A compromised system could just discard the
authenticator and say "okay, you're logged in".)
There's a proposal at the IETF (draft-ietf-kitten-gssapi-domain-based-
names) which would help address this, by letting you specify in the
server principal name both the hostname providing the service *and* a
user-supplied domain name for the service. It does require that the
KDC have more information about which services are provided by which
hosts, but better supports services where there may be multiple
providing hosts and they may be looked up by insecure means (e.g.,
you get back three DNS SRV records from your nameserver, and you're
not using DNSSEC). However, the proposal isn't finalized yet.
Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
