Subject: RE: name canonicalization review - canonicalization service?

From: "John Brezak" <[email-masked]>
Date: Tue, 5 Dec 2000 14:11:45 -0800

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Monday, December 04, 2000 9:23 PM
> To: [email-masked]
> Subject: Re: name canonicalization review - canonicalization service?
> 
> 
> "John Brezak" <[email-masked]> writes:
> > [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.
> 
> Um, no, not if the target principal in question is not allowed to be
> used as a service.  I.e., KDC will let the principal act as a client,
> or participate in user-to-user authentication, but won't issue tickets
> encrypted in the principal's long-term secret key, since they could be
> attacked offline.  That, in combination with preauth mechanisms, might
> be used as a way to further protect the secret key from exposure, for
> the really paranoid.
> 
> And if the specified principal can be used as a normal service, the
> server name in the issued tickets will tell the application all it
> needs to know, at least for that one operation.  And if the
> application needs to make use of any other alias information provided
> in the ticket extension, well, then you've got that name service
> functionality piggy-backed on a TGS_REQ exchange.
> 
> The only problem is, IMO, we need a standard secure way to get the
> information without requiring a successful TGS_REQ exchange.

[JBrezak] A standard way when principal names are being used for
authorization in this example?

> 
> > 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.
> 
> Yes, *if* KDC policy doesn't prohibit issuing tickets.
> 
> > [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.
> 
> I don't see it that way.  Kerberos principal names have for a long
> time been a means of expressing a unique identity, that could be used
> directly for access control if the designer of the authorization
> scheme so desired.  If we don't have a standalone name
> canonicalization scheme, that ability is to some degree lost.

[JBrezak] The problem is that there is now a possible indirection
between the principal name being used for authentication and
what is used for authorization. In cases where the authorization
data in the ticket is being used for access control mechanism,
there apparently is not a problem. However where the principal
name is being used from the ticket, the name may not correspond
to a principal name on an ACL. Worst case for such a service is that
the canonical client principal name will be used on the ACL.

> 
> > > > 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.
> 
> Suggesting a couple things that we might try, and which might work
> depending on the target realm's software and configuration, isn't a
> solution.  Unless we make one of them (mandate LDAP, or insist that
> KDC policy cannot prohibit tickets from being issued) or something
> else be the standard way of getting this information, we still have no
> portable way to make gss_canonicalize_name work.

[JBrezak] I still prefer that a name service be used for lookups when
using
authenticated principal names for authorization. LDAP is an example of
such
a widely available name service, I don't see the need for designing
another
lookup service just for binding authorization principals (subjects) to
authentication principals if one already exists. I'd suggest that if you
want to construct a new lookup service, that it isn't part of Kerberos-
revisions since it is intended to bridge authentication to name-based
authorization.

---

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

> authorization in this example?

Yes.

> what is used for authorization. In cases where the authorization

No, the indirection is between the set of names that can be used for
an authentication entity and the "true" name of the entity, where they
used to be one and the same.

> the canonical client principal name will be used on the ACL.

Well, yes, clearly, but how do we get to that point?

> revisions since it is intended to bridge authentication to name-based

To name-based anything besides authentication, really.  Auditing,
perhaps: Connections initiated by service principal
foo/penguin.quux.com should be logged ... but what if that's not the
canonical name?  Accounting: Use of a service by user joe is charged
to account #12345, but is his Kerberos principal in the local realm or
another one at the company?  Any time you want to specify the
canonical authentication names of entities without authenticating to
them as services.  The current spec only provides for certain uses;
anything else, and you just lose.

I could turn it around and suggest that the whole business of
permitting the login or other initial authentication of users from
multiple realms (AS_REQ canonicalization), or the providing of
multiple services by a single account, should be separate from the
actual authentication itself, and handled through a different service
that's consulted before Kerberos.  Then Kerberos would be just the
authentication service, and not authentication plus a piece of a name
service.

---

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

> revisions since it is intended to bridge authentication to name-based

Sure, but that is not what you implemented in Win2k. In Win2k you avoid
the use of the name service by putting all the information that services
might need about a user in the user's Kerberos tickets.

I believe there's an advantage in your Win2k approach over that which
you now propose for the rest of us, namely that the user profile
lookups are performed by the KDC only and then only on behalf of
[pre-]authenticated users. Whereas in the solution you now suggest the
remote services can only perform the lookup as themselves; IFF the user
forwards sufficient credentials can the service perform the name
service lookups as the user

The clear disadvantage of the Win2k profiles-in-tickets approach lies in
platform interoperability, or, rather, lack thereof.

I suppose the question boils down to: is the "Authenticated Users"
special group worth the bother? And if so, how should Kerberos supposrt
that concept?

Nico
--