Subject: name canonicalization

From: Ken Raeburn <[email-masked]>
Date: Thu, 3 Aug 2000 15:30:25 -0400

An issue was mentioned briefly yesterday in the WG meeting that had
come up in December on the ietf-cat list, namely the possibility of
caching of the results of name canonicalization (i.e., the mapping
from supplied name to canonical name).

As far as I can recall, there was no satisfactory conclusion reached,
but my impression was that you couldn't cache such information because
you couldn't know when it might change.  And, following through on
this, if you always request name canonicalization, maybe there's no
point in caching any credentials other than the initial TGT, and
*maybe* some inter-realm TGTs?

If the mapping has a lifetime, what is it?  Equal to, shorter than,
longer than the ticket (or TGT) lifetime?

Whatever the intent is here should really be documented....

---

From: Jonathan Trostle <[email-masked]>
Date: Mon, 07 Aug 2000 10:46:28 -0700

The names should be cached with the ticket. So the lifetime of the mapping is
limited by the ticket lifetime. But these mappings are pretty static anyway.

What I haven't seen addressed in the kerb-revisions is how the client learns
about the mappings so it can cache them with the ticket. One possibility is to
use the following structure:

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

which should be encrypted and placed in either a padata or ticket extensions
field in the TGS reply message. The advantage of the padata field is that it
results in a smaller ticket.

Jonathan

---

From: Ken Raeburn <[email-masked]>
Date: 07 Aug 2000 16:18:16 -0400

Jonathan Trostle <[email-masked]> writes:
> The names should be cached with the ticket.

Okay.  Next question: Does the mapping always apply to that hostname
when used in other hostname-based principal names, or is it just for
the specific principal name that was in the request?

>  So the lifetime of the mapping is
> limited by the ticket lifetime.

I don't think that automatically follows, but okay, let's look at
that.

Turning this around, if the guaranteed lifetime of the mapping is
short, the KDC must limit the lifetime of the issued ticket, and the
client is not allowed to make use of the information after the ticket
expires.  *This should be explicit.*

And, for example, if two random names map to the same target principal
name, even if the client chooses to retain only one of the tickets,
perhaps the one with later expiration time, each mapping must be
discarded when the corresponding ticket lifetime expires.

>  But these mappings are pretty static anyway.

In the case of hostnames, they aren't always, and we can't require it.
And in many environments, I would expect the principal name mapping to
be based on the host name mapping.

> about the mappings so it can cache them with the ticket.

Doesn't the client know what it asked for?

Ken

---

From: Jonathan Trostle <[email-masked]>
Date: Mon, 07 Aug 2000 15:31:30 -0700

>the specific principal name that was in the request?

Just for the specific principal name in the request.

>In the case of hostnames, they aren't always, and we can't require it.

Can you give an example here?

>Doesn't the client know what it asked for?

But the client doesn't know the other names for the principal.

---

From: Sam Hartman <[email-masked]>
Date: 08 Aug 2000 00:56:54 -0400

We were discussing name canonicalization at MIT today and I realized
that it is significantly under specified.  For example, let's say that
I want to log into athena.dialup.mit.edu.  This is roughly an RR that
resolves to a random cname record for load balancing.  I could see
doing one of:

* look up host/athena.dialup.mit.edu and getting back something like
  host/cvp.mit.edu  and thus logging into cvp.mit.edu (completely
  ignoring the DNS lookup)

* Doing the DNS lookup, finding that athena.dialup resolves to
  cvp.mit.edu and looking up a compound like
  host/athena.dialup.mit.edu/cvp.mit.edu which maps simply to
  host/cvp.mit.edu if cvp.mit.edu is a valid mapping for
  athena.dialup.mit.edu else returns an error.

It might be OK to defer standardization of how name canonicalization
is used until after revisions is done, but it fairly clear to me that
the current text is not enough to know how to use the feature.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 08 Aug 2000 09:47:28 -0500

I believe the intent of the name cononicialization was to relieve
the client of having to lookup host to realm name mappings 
by letting the KDC do it, and that this was to be done after DNS lookups. 

Is there any simple language to add to the draft which would allow
this? I know that the issues of caching, and using this with systems like 
athena.dialup.mit.edu bring up additional posibilities.  

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Ken Raeburn <[email-masked]>
Date: 09 Aug 2000 15:18:01 -0400

> Can you give an example here?

The athena.dialup example is one, though it could be argued that
"athena.dialup.mit.edu" should be its own service, with keys on
multiple hosts.  (The MIT code's problem with server clusters also
suggests that that approach is better.)

How about running imap service for a couple divisions of a company on
the same server, so imap/[email-masked] and
imap/[email-masked] are mapped to
the same principal?  Then you decide to separate them.

How about mapping imap/[email-masked] to
imap/[email-masked] because that's the canonical name of
the host running the service?  Until you move the service to a newer
server.

Or mapping all of
{imap,pop,ftp,moira,ipsec,xyzzy}/[email-masked] to
host/[email-masked] because, after all, all the servers are
running with the same privileges.  Later on, you get paranoid, and put
each server in a separate address space, with a different unprivileged
(or mostly unprivileged) user id that can only access its own data
store, and definitely can't access the host key that would give away
everything on the system.

Okay, most of these are "pretty static", but my point is that they can
change.  I don't think the frequency of change is really the point.

> But the client doesn't know the other names for the principal. 

Why does it need to?  In the unlikely event that the client uses
multiple names for the same service, it'll learn that they're all
aliases.  Should we really go to the effort of looking up and sending
seven or twelve alias names just in case the client uses a second one
from the set?  DNS doesn't.

> by letting the KDC do it, and that this was to be done after DNS lookups. 

In the athena.dialup case, doing the two lookups separately leaves a
window where the results you get back don't match.  I.e., the mapping
changes between the two lookups, or the servers are out of sync.
It's conceivable that in some similar instance, the target of the
alias could be moved across realms too.

And of course there's the issue of using possibly-spoofed DNS data to
determine what principal to authenticate to....

Ken

---

From: Jonathan Trostle <[email-masked]>
Date: Wed, 09 Aug 2000 15:19:46 -0700

>the same principal?  Then you decide to separate them.

Looks like they are in different realms so I don't see how they map to the same principal.

>the host running the service?  Until you move the service to a newer

Once again, the realms are different. But if they were the same, then the old ticket will be valid if the new service has the same key as before. If not, hopefully the client is smart enough to ask for a new ticket when it receives the error.

>everything on the system.

If the new services start with the old key, and then change their keys to their new keys, then the old tickets will still be valid. If not, then hopefully the client is smart - see preceding example.

>from the set?  DNS doesn't.

To maximize the use of the ticket cache. There may be multiple clients. Take your last example with 6 different clients. All requesting the same ticket, 6 different times. The returned names allow the last 5 to get the ticket out of the ticket cache.

Jonathan

---

From: Sam Hartman <[email-masked]>
Date: 09 Aug 2000 18:32:24 -0400

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas> I believe the intent of the name cononicialization was to
    Douglas> relieve the client of having to lookup host to realm name
    Douglas> mappings by letting the KDC do it, and that this was to
    Douglas> be done after DNS lookups.

I thought the intent was also to avoid trusting insecure DNS to
canonicalize user input into a host name.  Without this use, I don't
think name canonicalization is useful enough to justify the
complexity.  With these uses, I think there are open issues.

---

From: Ken Raeburn <[email-masked]>
Date: 09 Aug 2000 20:40:56 -0400

> Looks like they are in different realms so I don't see how they map

(Please wrap your lines to be less than 80 columns.)

Why not?  The description of KRB_AS_REP generation in
kerberos-revisions-06 section 3.1.3 suggests to me that the
canonicalized name may be in a different realm than the one supplied
by the client.  (I note, though, that that description does not
provide for canonicalization of the service name in an AS_REQ in it's
not the ticket-granting service.)

If that's only supposed to be possible in some cases, and not others,
please explain the difference, keeping in mind that user principals
can be used as service names (policy permitting).

> then the old ticket will be valid if the new service has the same
> key as before.

In the MIT implementation, at least, the principal name in the
credentials is checked against the expected name(s).  I don't find
anything in section 3.2.3 that explicitly suggests this should be
done, but the pseudocode in A.10 does.

So the new server had better be looking for its old name, if the
tickets are to be valid.

>   If not, hopefully the client is smart enough to ask
> for a new ticket when it receives the error.

That's asking for more smarts in the application than I would want to
ask for, and it is all the applications, not the Kerberos library code
itself, that has to know how to do this, because the Kerberos library
doesn't know how to transmit the authenticator to the server.  And
some of the protocols (e.g., Kerberos rlogin) only give you one
attempt to authenticate.  Do we want to require this additional work
on the part of Kerberos application writers?

It's not clear to me if a GSSAPI-KERBEROS implementation could
iterate, sending one authenticator, getting an error back, and sending
another, without alerting the application, but perhaps it could.  Even
if so, GSSAPI is not the only use of Kerberos.

> If the new services start with the old key, and then change their
> keys to their new keys, then the old tickets will still be valid. If
> not, then hopefully the client is smart - see preceding example.

See preceding comments about dumb applications.  I'd keep the old key
active a while.

Part of the point of expressing a short lifetime is so that the window
during which both sets of keys need to be active can be made small.
If it can be made small enough, the process of moving the services
from the shared protection domain to separated ones may dominate, and
if the service is actually shut off during the change, perhaps the old
and new keys never will need to be active at the same time.

> To maximize the use of the ticket cache. There may be multiple
> clients. Take your last example with 6 different clients. All
> requesting the same ticket, 6 different times. The returned names
> allow the last 5 to get the ticket out of the ticket cache.

If they're for the same service, they'd likely be using the same name,
so I assume you're referring to different services mapping to a single
common principal.  Isn't it better, though, to use different
principals (and more to the point, different keys) for different
services, so if one becomes compromised you haven't given away all the
rest?

Ken

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 16 Aug 2000 11:11:09 -0500

There has been quite a lot of discussion on name canonicalization and referrals
which has died down without consciences. This was a feature being added to 
kerberos-revisions at the request of Microsoft, yet no one at Microsoft has 
made any comments. 

The changes to kerberos revisions where based somewhat on:
<draft-swift-win2k-krb-referals-01.txt> 
"Generating KDC Referrals to locate Kerberos Realms", January 2000
M.Swift, J. Brezek
But not all of it are included in the revisions. 

I would like to get this resolved, as this appears to be the main 
unresolved issue with the Kerberos Revision, which we want to get
to last call this month!

Some issues:

Can this be used to look up a service, like service/foo and have
foo expanded to a full host name. i.e. to service/foo.domain@realm
(My option: yes)

Can foo be replaced with bar, i.e. service/bar.domain.realm
(My option: maybe, only if foo was not a FQDN)

Could the service be replaced, like ftp/foo to host/bar.domain@realm
(My option: no)

Could user return with user@realm2?
(My option: yes only if realm was not specified.) 

Can this be used inplace of DNS for host names? If so, this implies
that the ticket should be obtained before the connection from 
to server is made, since the server may change. 
(My option: no)

What about caching?
(My option: good question, what does W2K do today?)

--