Subject: [kitten] submitted draft-yu-kitten-kerberos-kdc-does-aliases-00

From: Tom Yu <[email-masked]>
Date: Mon, 18 Feb 2013 18:40:55 -0500

I've submitted this document as one component of the effort to remove
dependence on insecure DNS for canonicalizing hostnames in service
principal names.  I would like the Working Group to consider it for
adoption.

From: [email-masked]
Subject: New Version Notification for draft-yu-kitten-kerberos-kdc-does-aliases-00.txt
To: [email-masked]
Date: Mon, 18 Feb 2013 15:21:29 -0800

A new version of I-D, draft-yu-kitten-kerberos-kdc-does-aliases-00.txt
has been successfully submitted by Tom Yu and posted to the
IETF repository.

Filename:	 draft-yu-kitten-kerberos-kdc-does-aliases
Revision:	 00
Title:		 Kerberos Ticket flag indicating KDC support for resolving hostname aliases
Creation date:	 2013-02-18
Group:		 Individual Submission
Number of pages: 5
URL:             http://www.ietf.org/internet-drafts/draft-yu-kitten-kerberos-kdc-does-aliases-00.txt
Status:          http://datatracker.ietf.org/doc/draft-yu-kitten-kerberos-kdc-does-aliases
Htmlized:        http://tools.ietf.org/html/draft-yu-kitten-kerberos-kdc-does-aliases-00

Abstract:
   This document specifies a Kerberos Ticket flag that indicates that
   the Key Distribution Center (KDC) can resolve hostname aliases in
   service principal names.  This document updates RFC 4120.

The IETF Secretariat

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 25 Feb 2013 15:21:54 -0500 (EST)

Hi Tom,

I just got a chance to give this a careful read.
It certainly seems relevant to the working group, as part of our plan to 
provide a migration path away from relying on insecure DNS.

I do wonder whether anyone thinks that the language in section 3 is 
confusing, referring to forward versus reverse resolution, as opposed to 
forward versus forward+reverse resolution, as the parentheticals state.
I think that the parentheticals make it clear enough, but other input is 
welcome.

-Ben

On Mon, 18 Feb 2013, Tom Yu wrote:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Greg Hudson <[email-masked]>
Date: Mon, 25 Feb 2013 15:52:07 -0500

> principal names.  I would like the Working Group to consider it for

I'm in favor of adopting this item.  I don't have any comments to make
since the concept is simple and the draft is quite short.

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Feb 2013 14:53:14 -0600

Hi Tom,

This is a very good idea, but I'm curious how to implement this.

Consider a case where the KDCs for the realm where a client will begin
to search for some service name supports this feature, but it issues a
referral to another realm that doesn't, and the subsequent TGS
exchange fails because the referred-to realm's KDCs don't know that
sname.  How should a client recover?  Should it attempt DNS
canonicalization in that case and retry at the realm that did not know
the original sname?  Or should it give up?  Or should it act according
to local configuration?

Other questions/comments:

 - what does the kdc-resolves-aliases flag mean when a service finds
it set on a Ticket?  Do we need a section indicating *service*
behavior?

 - all KDCs for a given realm must support this feature before setting
this flag.  Section 4 should say this.  (I.e., it must be possible to
upgrade a realm's KDCs piecemeal.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Feb 2013 14:57:38 -0600

Also:

 - I suppose this flag really only means that the clients shouldn't
bother with DNS canonicalization, but what about DNSSEC?

 - Must KDCs canonicalize aliases, or is it OK for a KDC to expect (or
know that) services to know their own aliases and share the same key
(or derived keys?) for the aliases of the canonical names?

 - Further to the last question, if the new flag is set in a service
ticket, should services decide to stop trying all keys to decrypt
service tickets for which they have no explicit keytab entry?
(Heimdal has code to do that.)

 - How long can the meaning of this flag be cached for on clients?  On servers?

   This gets to rollback issues.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Mon, 25 Feb 2013 16:14:22 -0500

> (Heimdal has code to do that.)

I don't think this draft intends to change the way KDCs perform service
aliasing.  It's only a hint to the client that DNS canonicalization of
service names isn't desired.

The way service aliasing is done today, the KDC returns a ticket for
whatever server principal name the client requested, and the service has
to figure out what to do with a ticket which might be for an alias of
the service.  In MIT krb5 and Heimdal, that means ignoring the ticket
server principal name if the keytab is iterable.

>    This gets to rollback issues.

I can't imagine the answer being anything other than "for the lifetime
of the ticket."  There's no reason a KDC has to start setting this
ticket flag the moment it has service aliasing support, so I don't see a
rollback issue.

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Feb 2013 15:34:45 -0600

> server principal name if the keytab is iterable.

OK, got it.  That's fair.

> ticket flag the moment it has service aliasing support, so I don't see a

OK, but note that this constrains rollback operations.  This should be stated.

Nico
--

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 26 Feb 2013 08:01:06 -0800

>> principal names.  I would like the Working Group to consider it for

I support this document.

As nico points out, the behavior in the cross realm case needs to be clarified.

I think "start domain" picks behavior make sense since its the "owner" of the client principal and the admin whom should care how much to "protect" the user.

Love