Subject: name canonicalization in kerb revisions

From: Jonathan Trostle <[email-masked]>
Date: Tue, 05 Dec 2000 16:56:39 -0800

Two things that should be considered for name canonicalization in the kerberos revisions:

(1) Ticket extension to return list of alias names to the client in a TGS_REP message, signed with session key from the ticket:

KRB-TE-REFERRAL  :: =  SEQUENCE { 
      referred-realm[0]                   Realm, 
      referred-server-names[1]    SEQUENCE OF PrincipalNames OPTIONAL 
	} 

(2) Language to encourage clients to canonicalize short names into the corresponding long name (possibly an alias): Clients MUST be capable of canonicalizing short names into long names and using the long name in the TGS_REQ message, in order to preserve interrealm interoperability. (Since a KDC that is presented with a short name may be unable to refer the client to the appropriate realm.) The client MUST check that the user entered short name is a prefix of the long name resulting from canonicalization.

Jonathan

---

From: Ken Raeburn <[email-masked]>
Date: 06 Dec 2000 03:19:12 -0500

> Two things that should be considered for name canonicalization in the kerberos revisions:

(Once again, please wrap your lines to < 80 columns.)

> (2) Language to encourage clients to canonicalize short names into
> the corresponding long name (possibly an alias): Clients MUST be
> capable of canonicalizing short names into long names and using the
> long name in the TGS_REQ message, in order to preserve interrealm
> interoperability. (Since a KDC that is presented with a short name
> may be unable to refer the client to the appropriate realm.) The
> client MUST check that the user entered short name is a prefix of
> the long name resulting from canonicalization.

I'm not clear on what you're saying here.  If you're referring to
principal name canonicalization, how can a client do the
canonicalization and *then* send off its TGS_REQ message, if TGS_REQ
is the only way to do the canonicalization?  And what does one name
being a prefix of another have to do with it?

Your use of "short name" and "long name" make me think maybe you're
talking about hostnames, but then we still have the open question of
doing DNS canonicalization securely, and again I don't see how the
prefix check helps.  Just because you get back a DNS response saying
"fileserver-1" is a CNAME for "fileserver-1.raeburn.org" doesn't mean
I'm not spoofing...

---

From: Jonathan Trostle <[email-masked]>
Date: Wed, 06 Dec 2000 16:17:00 -0800

>is the only way to do the canonicalization?  And what does one name

I'm saying that the client should do the conversion from the short name
to the long name. Assuming that the possible DNS completions from the
client's DNS completion list will only yield one possible principal name
(in other words, that the order of the DNS completion list doesn't matter),
then spoofing can at most lead to DoS attack. But the client would not
canonicalize the alias to the DNS canonical name. 

Regarding the gss_canonicalize_name function, would the following work?
gss_canonicalize_name does the conversion of the short name to the 
long name. Then the long name is inputted into init_sec_context. The
target name argument in init_sec_context is IN/OUT and the mechanism
returns the canonical name in the target name argument. This works for
both Kerberos and X.509 certificates, assuming the X.509 cert contains
the alias DNS names as subjectAltName extensions. 

>"fileserver-1" is a CNAME for "fileserver-1.raeburn.org" doesn't mean

I don't understand your example - fileserver-1 is not a domain name. Is it 
supposed to be a short name?

Jonathan

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Dec 2000 11:12:39 -0500

>       referred-server-names[1]    SEQUENCE OF PrincipalNames OPTIONAL 

Unfortunately, I would imagine that the list of aliases of an SPN may be
infinite.

Consider a setup where any SPN of the form <service>/fqdn@REALM is
always canonicalized to an SPN of the same form and fqdn but with a
service name of 'host'.

Then all SPNs of the form <service>/fqdn@REALM in such a realm would
have an infinite list of aliases.

I suppose one could make a distinction between aliases in general and
official aliases.

> (2) Language to encourage clients to canonicalize short names into the corresponding long name (possibly an alias): Clients MUST be capable of canonicalizing short names into long names and using t…

Hmmm. Either that or the KDC and the client must perform hostname
lookups in the same way (in DNS terms: they must have the same search
list). But I agree.

> Jonathan

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: 07 Dec 2000 18:27:45 -0500

> canonicalize the alias to the DNS canonical name. 

We have arbitrary constructed principal names based on user-provided
names (of hosts, users, whatever), and we have canonical principal
names, and various kinds of host names.  What's a "short name" and
what's a "long name", and what do you mean by "canonicalization", in
this particular context?

Now it sounds to me like maybe you're thinking of hostnames, and doing
"canonicalization" only by tacking on domain names (and not doing
CNAME processing).  But that doesn't help if the KDC canonicalization
converts "ftp/ftp.foo.com" into
"host/[email-masked]", even if the DNS has a
CNAME record for ftp.foo.com.

> the alias DNS names as subjectAltName extensions. 

So how does either the application or gss_canonical_name get from GSS
name "ftp@ftp" to Kerberos principal name "host/mongo-server.foo.com"?

> supposed to be a short name?

See above confusion about terminology.

---

From: Jonathan Trostle <[email-masked]>
Date: Fri, 08 Dec 2000 23:12:10 -0800

>name "ftp@ftp" to Kerberos principal name "host/mongo-server.foo.com"?

ftp@ftp -> ftp/ftp.foo.com (on the client by making DNS queries on the
completed ftp prefix, a spoofer can force a completion to a nonexistent 
name, or the client gets the correct name).
ftp/ftp.foo.com goes into the TGS_REQ
the response from the KDC contains the canonical name: host/mongo-server.
foo.com

Jonathan