Subject: RE: name canonicalization review - canonicalization service?

From: "John Brezak" <[email-masked]>
Date: Mon, 4 Dec 2000 17:45:44 -0800

inline.

> -----Original Message-----
> From: Nicolas Williams [mailto:[email-masked]]
> Sent: Monday, December 04, 2000 2:35 PM
> To: Ken Raeburn
> Cc: [email-masked]
> Subject: Re: name canonicalization review - canonicalization service?
> 
> 
> I would say that a new KDC protocol is called for whereby properly
> authenticated clients can ask the KDC to canonicalize principal names.

[JBrezak] Now you really are turning Kerberos into a name service.

> 
> I.e., clients authenticating with a kerberos ticket for any user or
> service principal should be able to ask the KDC to 
> canonicalize a given
> principal name.

[JBrezak] In the original proposal for NC, the list of aliases was
returned in a ticket extension. However this was left out of the
document because it was considered to be a performance optimization. But
this list would give the client/server the needed information to be able
to let the gss_canonicalize_name() api function.

- Ticket extension data for aliases to optimize caching
KRB-TE-REFERRAL  :: =  SEQUENCE { 
      referred-realm[0]                   Realm, 
      referred-server-names[1]    SEQUENCE OF PrincipalNames OPTIONAL 
	} 

The TE is signed with the ticket's session-key.

If the user needed to find out a canonical name for a principal, it
could make a TGS request for that principal and specify
name-canonicalization. The resulting ticket would have the canonical
name in the sname/srealm and the ticket extension would have the known
aliases.

> 
> Alternatively gss_canonicalize_name() will have to be prepared to
> authenticate as the given principal name in order to 
> canonicalize it, if
> that given PN is not a canonical name to begin with. This may 
> not always
> be possible, certainly not in applications where one is trying to
> populate ACLs with a batch job.
> 
> Yet another alternative, for SPNs anyways, is algorythmic
> canonicalization. If the client knows and can rely on a 
> simple rule for
> how all canonical SPNs in a given realm are formed then it may be able
> to perform PN canonicalization off-line with no assistance 
> from the KDC.
> E.g., if all SPNs in a given realm are always of the form
> host/fqdn@REALM, then obviously, telnet/a-given-fqdn@REALM should be
> canonicalized to host/same-fqdn@REALM. This approach is somewhat
> problematic however, as there is no way to confirm that the 
> alias SPN is
> actually _valid_ as an alias (one might want to have the KDC reject
> requests for telnet/fqdn@REALM, rather than canonicalize the SPN).
> 
> Nico
> 
> 
> On Mon, Dec 04, 2000 at 04:41:05PM -0500, Ken Raeburn wrote:
> > "John Brezak" <[email-masked]> writes:
> > > Name canonlicalization is not a mechanism for access control. If a
> > 
> > No, but Kerberos principal names can be, and name 
> canonicalization has
> > now become a part of handling names.

[Jbrezak] ACLs generally contain canonical representations of a user -
UID, UUID, SIDs that are specific to the authorization implementation.
If one were to contruct an authorization mechansim that used a canonical
principal name as a subject name for authz, then I agree that a service
can be contructed to handle this. However you are trying to bridge
Kerberos between authentication and authorization.

> > 
> > > service is needed to handle lookup of service names to 
> canonical names,
> > > LDAP would easiliy be able to handle this.
> > 
> > So, which do you recommend -- that we mandate LDAP access to the
> > database as part of all Kerberos implementations, or that 
> we offer no
> > portable way to make gss_canonicalize_name work for the Kerberos
> > mechanism?

[Jbrezak] LDAP is one way or the request a ticket with the ticket
extension above.

> > Ken
> --

---

From: Martin Rex <[email-masked]>
Date: Wed, 6 Dec 2000 22:10:11 +0100 (MET)

> [JBrezak] Now you really are turning Kerberos into a name service.

NO.  Adding name canonicalization in the ticket request is the
feature that introduces the "name service" functionality.
You did that.

Seperate-from-Authentication name canonicalization is required
to provide the original authentication service in a consistent fashion.

> name in the sname/srealm and the ticket extension would have the known

Yuck!  This looks like a very dirty hack to me.

What about the canonicalization of user principal names -- from
what I read on this list, there are KDCs that don't issue TGS
for users?

Portable gssapi based applications distinguish authenticated
entities only by their canonical name, there is no user vs service
distinction, because all SPKM and similar gssapi mechanisms
don't have/offer such a distinction.

When "maintaining" huge ACLs (i.e. >1000 entries being displayed
to the user/admin), you would request tons of individual tickets
that are trashed.  Are there any limits in the KDCs on the amount
of tickets (session keys) that can be generated per second
(I'm not a cryptographer, but to me it sounds like draining
 entropy from the KDC in this fashion.)

I'd really prefer a seperate request and reply that doesn't
result in the creation of a ticket for the name that is to
be canonicalized.

> Kerberos between authentication and authorization.

No, not at all.
If the authentication system doesn't play games with names,
the out-of-band canonicalization is not necessary at all.

It is the invention of the canonicalization during the ticket request
that will require the out-of-band name canonicalization to retain
the originally consistent authentication service.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 7 Dec 2000 10:51:38 -0500

> inline.

Same.

> [JBrezak] Now you really are turning Kerberos into a name service.

:)

Yeah. I see. Upon further reflection I would agree that to add such a
service would, in effect, enable the sort of semi-anonymous lookups that
I was decrying elsewhere in that post.

Thus I retract the above call for a new KDC service.

> to let the gss_canonicalize_name() api function.

The list of aliases could, technically, be infinite. No?

> name in the sname/srealm and the ticket extension would have the known

The user can find the canonical principal name in this way without this
extension.

I had missed the symmetry between UPN and SPN canonicalization. As far
as Kerberos is concerned there is no real difference between UPNs and
SPNs, but I had obviously lost sight of that.

[...]
> Kerberos between authentication and authorization.

Isn't bridging "between authentication and authorization" what
Microsoft, effectively, did by putting user profiles in tickets?

I understand what it is that putting user profiles in tickets achieves,
or at least I think I do:

 - enables the use of the special group identity "Authenticated Users"
   in ActiveDirectory (LDAP) ACLs that protect data relevant to users'
   profiles. By putting the information in the ticket (that the user had
   to initially pre-authenticate to obtain -- thus we have an
   authenticated user) the lookup of the user's profile, by the services
   the user uses, is rendered unnecessary. Thus only authenticated users
   (not services) ever lookup user profiles in the name service (LDAP).

 - optimizes the login process by rendering user profile lookups
   unnecessary following Kerberos network authentication.

I believe that the first of the above benefits of carrying user profiles
in Kerberos tickets could have been achieved differently, without resort
to adding platform-specific data into Kerberos tickets (except for the
OtherNames extension I have mentioned before).

> [Jbrezak] LDAP is one way or the request a ticket with the ticket

But if a service must use a name service to perform the
canonicalization, it must really do so as itself, in which case the
"Authenticated Users" special group is rendered significantly less
useful, or it must impersonate the given PN to the name service --
something not always possible.

A TGS request seems like the way to go.

Nico
--