[13086] in athena10
Re: [Debathena] #1384: Disable DNS canonicalization for Kerberos
daemon@ATHENA.MIT.EDU (Debathena Trac)
Sun Dec 28 21:53:23 2014
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@mit.edu>
Cc: debathena@mit.edu
To: geofft@mit.edu, andersk@mit.edu, ghudson@mit.edu
Date: Mon, 29 Dec 2014 02:53:13 -0000
Reply-To:
Message-ID: <057.5c657f35fb72c0a4f5b6f78f71065290@mit.edu>
In-Reply-To: <042.c9c2be0400160755d5b10fcd112754e7@mit.edu>
Content-Transfer-Encoding: 8bit
#1384: Disable DNS canonicalization for Kerberos
-----------------------+---------------------------------------
Reporter: geofft | Owner:
Type: defect | Status: new
Priority: normal | Milestone: The Distant Future
Component: -- | Resolution:
Keywords: | Fixed in version:
Upstream bug: |
-----------------------+---------------------------------------
Description changed by andersk:
Old description:
> Use of Kerberos in the Athena environment currently involves using DNS
> for canonicalization, an insecure practice called out in RFC 4120 (the
> krb5 RFC):
> > one should not rely on an unprotected DNS record to map a host alias to
> the primary name of a server, accepting the primary name as the party
> that one intends to contact, since an attacker can modify the mapping and
> impersonate the party.
>
> Athena basically uses Kerberos DNS canonicalization (forward and reverse
> lookup) as a user experience measure: users expect to be able to do
> things like `ssh athena.dialup`, `remctl xvm-remote help`, etc. without
> providing the long name. In particular, the `.mit.edu` suffix needs to be
> appended, and names like `linux.mit.edu` need to be expanded to canonical
> names like `linerva.mit.edu` (or, in the case of `athena.dialup.mit.edu`,
> one of several possible canonical names), before the name becomes
> something suitable to turn into the name portion of a Kerberos service
> key.
>
> But since DNS is completely insecure, an attacker can spoof the DNS
> response and canonicalize, say, `linux` to `some-random-server.mit.edu`,
> which they might legitimately own a keytab for, and the login would
> succeed. Deployment of DNSSEC would basically solve this issue, but as
> far as I'm aware there are no real plans to deploy DNSSEC at MIT.
>
> Turning off canonicalization is mostly straightforward, but doing so
> right now would break the UX mentioned earlier. So this ticket is
> primarily about software changes needed to make the UX work as well,
> without trusting DNS.
>
> Here are a couple of approaches. For merely fully-qualifying a domain
> name:
> * Active Directory solves this in a straightforward manner by issuing a
> domain-joined server a `host/machine@EXAMPLE.COM` key as well as a
> `host/machine.example.com@MACHINE.EXAMPLE.COM` one. We could do that: I
> don't see a security issue in creating `host/linerva@ATHENA.MIT.EDU` etc.
> keytabs, but maybe I'm not thinking hard enough. This requires no client
> changes.
> * We can also have the Kerberos libraries process `/etc/resolv.conf`,
> which would let them know how unqualified names should be fully-
> qualified.
>
> For resolving aliases:
> * We could just have servers carry keys for all their aliases (that
> people log in through). This would mean that athena.dialup's keytab
> would need a key for each `athena.dialup` alias (`x.dialup`, etc.) and
> each servers' own aliases (`ant`, `cvp`, etc.), which would be slightly
> awkward but certainly manageable.
> * The KDC has support for
> [http://k5wiki.kerberos.org/wiki/Projects/Aliases aliases], which seem to
> be ways for the server and KDC to agree that a certain name is an alias
> for an existing principal, and that the same key should be used. I'm not
> sure what needs to be done on the server side to configure aliases on a
> key in a keytab.
> * There's a [http://k5wiki.kerberos.org/wiki/Projects/Trust_KDC-
> local_name_resolution project on the krb5 wiki] talking about doing DNS
> resolution on the KDC, which should be significantly more trustworthy
> than doing it on the client. It looks like the implementation is that
> you'll ask the TGS for a service ticket for `host/linux`, and get a
> service ticket for `host/linerva.mit.edu` back.
> * You could also imagine combining the above two approaches: keeping
> aliases in the KDC database (and not trusting DNS anywhere), but
> returning the canonical name to the client.
>
> I think that, in addition to `rdns = false` in `krb5.conf`, this also
> requires `GSSAPITrustDns No` in `ssh_config`. Also note that the Kerberos
> libraries in Ubuntu have a bug (fixed in in krb5 1.10.2) that seems to
> effectively make `rdns = true` unconditionally set, so we'll need to get
> a security update through for that.
>
> In terms of deployment strategy, it'd be nice to find a solution that
> doesn't break existing clients or servers, but allows clients to opt in
> to be more secure without breaking their functionality. I think all of
> the above solutions allow unmodified clients, that continue to
> canonicalize hostnames in DNS, to still work. Some of the above solutions
> don't involve coordinating with server maintainers; some involve adding
> more keys to the keytab, or configuring aliases server-side.
>
> (Like #529, this is not entirely a Debathena bug, but this is the most
> convenient place to keep track of it, especially as it interacts with our
> security policy re `GSSAPIDelegateCredentials`, `GSSAPIKeyExchange`, and
> friends.)
New description:
Use of Kerberos in the Athena environment currently involves using DNS for
canonicalization, an insecure practice called out in RFC 4120 (the krb5
RFC):
> one should not rely on an unprotected DNS record to map a host alias to
the primary name of a server, accepting the primary name as the party that
one intends to contact, since an attacker can modify the mapping and
impersonate the party.
Athena basically uses Kerberos DNS canonicalization (forward and reverse
lookup) as a user experience measure: users expect to be able to do things
like `ssh athena.dialup`, `remctl xvm-remote help`, etc. without providing
the long name. In particular, the `.mit.edu` suffix needs to be appended,
and names like `linux.mit.edu` need to be expanded to canonical names like
`linerva.mit.edu` (or, in the case of `athena.dialup.mit.edu`, one of
several possible canonical names), before the name becomes something
suitable to turn into the name portion of a Kerberos service key.
But since DNS is completely insecure, an attacker can spoof the DNS
response and canonicalize, say, `linux` to `some-random-server.mit.edu`,
which they might legitimately own a keytab for, and the login would
succeed. Deployment of DNSSEC would basically solve this issue, but as far
as I'm aware there are no real plans to deploy DNSSEC at MIT.
Turning off canonicalization is mostly straightforward, but doing so right
now would break the UX mentioned earlier. So this ticket is primarily
about software changes needed to make the UX work as well, without
trusting DNS.
Here are a couple of approaches. For merely fully-qualifying a domain
name:
* Active Directory solves this in a straightforward manner by issuing a
domain-joined server a `host/machine@EXAMPLE.COM` key as well as a
`host/machine.example.com@EXAMPLE.COM` one. We could do that: I don't see
a security issue in creating `host/linerva@ATHENA.MIT.EDU` etc. keytabs,
but maybe I'm not thinking hard enough. This requires no client changes.
* We can also have the Kerberos libraries process `/etc/resolv.conf`,
which would let them know how unqualified names should be fully-qualified.
For resolving aliases:
* We could just have servers carry keys for all their aliases (that
people log in through). This would mean that athena.dialup's keytab would
need a key for each `athena.dialup` alias (`x.dialup`, etc.) and each
servers' own aliases (`ant`, `cvp`, etc.), which would be slightly awkward
but certainly manageable.
* The KDC has support for
[http://k5wiki.kerberos.org/wiki/Projects/Aliases aliases], which seem to
be ways for the server and KDC to agree that a certain name is an alias
for an existing principal, and that the same key should be used. I'm not
sure what needs to be done on the server side to configure aliases on a
key in a keytab.
* There's a [http://k5wiki.kerberos.org/wiki/Projects/Trust_KDC-
local_name_resolution project on the krb5 wiki] talking about doing DNS
resolution on the KDC, which should be significantly more trustworthy than
doing it on the client. It looks like the implementation is that you'll
ask the TGS for a service ticket for `host/linux`, and get a service
ticket for `host/linerva.mit.edu` back.
* You could also imagine combining the above two approaches: keeping
aliases in the KDC database (and not trusting DNS anywhere), but returning
the canonical name to the client.
I think that, in addition to `rdns = false` in `krb5.conf`, this also
requires `GSSAPITrustDns No` in `ssh_config`. Also note that the Kerberos
libraries in Ubuntu have a bug (fixed in in krb5 1.10.2) that seems to
effectively make `rdns = true` unconditionally set, so we'll need to get a
security update through for that.
In terms of deployment strategy, it'd be nice to find a solution that
doesn't break existing clients or servers, but allows clients to opt in to
be more secure without breaking their functionality. I think all of the
above solutions allow unmodified clients, that continue to canonicalize
hostnames in DNS, to still work. Some of the above solutions don't involve
coordinating with server maintainers; some involve adding more keys to the
keytab, or configuring aliases server-side.
(Like #529, this is not entirely a Debathena bug, but this is the most
convenient place to keep track of it, especially as it interacts with our
security policy re `GSSAPIDelegateCredentials`, `GSSAPIKeyExchange`, and
friends.)
--
--
Ticket URL: <https://athena10.mit.edu/trac/ticket/1384#comment:5>
Debathena <http://debathena.mit.edu>
MIT Debathena Project
