Proposal for using NAPTR/URI records

[Simo Sorce]

On Tue, 2015-02-24 at 10:34 -0600, Nico Williams wrote:
> On Tue, Feb 24, 2015 at 8:49 AM, Simo Sorce <simo at redhat.com> wrote:
> > On Mon, 2015-02-23 at 22:59 -0600, Nico Williams wrote:
> > > [...]
> >
> > I do not see how exposing KKDCP in DNS is any different from current DNS
> > SRV records, therefore I do not see why it requires additional security
> > considerations.
> >
> > Can you explain ?
> 
> Check out this thread (all of it, particularly Viktor D.'s and Sam
> H.'s comments):
> 
> https://www.ietf.org/mail-archive/web/ietf/current/msg91915.html
> 
> It's not that it can't be done.  But that it requires care.
> 
> Again, if I use a locally-configured proxy, or a proxy that is
> co-located with the KDCs of the target realm, then no problem.  If I
> use a DNS RRset that could point to a different host, and to boot I
> don't use DNSSEC, then I now I have a problem.

Well given KErberos is built to run on untrusted networks ... I'd be
surprised if we have a problem. Esp with preauth and (in future) PAKE to
make things more robust.

> OTOH, it's probably not a big deal, we just need to think through the
> security considerations:
> 
>  - TGS exchanges leak little information about the client principal
> (mostly the Ticket they are using, and in the case of user2user
> Kerberos, the user2user TGT of the peer).
> 
>  - AS exchanges leak the cname and crealm, but could be tunneled in
> FAST w/ anon PKINIT, yielding protection for the cname, but not much
> protection for the crealm (since, after all, if we're talking to an
> MITM, they could have used a different host:port for each realm for
> which they saw a query for a proxy).
> 
>  - anything else?

Ok so your concern is disclosure of information regarding realm and
client principal.

The realm is a lost cause, given you put the realm name in DNS to start
with. If you do that I think it is safe to assume the admin does not
have a problem disclosing the realm name.

The principal name is another story, but given that one is always leaked
(also when using SRV records) it is more a matter of local policy rather
than a problem with advertising via DNS.

It may make sense to warn admins that if they want more privacy they are
strongly advised to use FAST with Anonymous tickets as the armoring.
But that is a general privacy concern, I do not see it as specific to
the advertising of KDC locations/protocols via DNS.

> BTW, the better forum for this is the KITTEN WG list.

It may be a security consideration in an RFC if we come up with one,
agreed.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York