Subject: RE: name canonicalization review - canonicalization service?

From: "John Brezak" <[email-masked]>
Date: Mon, 4 Dec 2000 13:26:39 -0800

Entries on ACLs in the Win2000 implementation are based on the SID -
where the SID is the unit of authorization. The Kerberos principal name
is not used for access control. In DCE this is also the case - access
control is based on the UUIDs not principals.

Name canonlicalization is not a mechanism for access control. If a
service is needed to handle lookup of service names to canonical names,
LDAP would easiliy be able to handle this.

> -----Original Message-----
> From: Ken Raeburn [mailto:[email-masked]]
> Sent: Tuesday, November 28, 2000 7:02 PM
> To: [email-masked]
> Subject: Re: name canonicalization review - canonicalization service?
> 
> 
> 
> Martin Rex pointed out a number of problems with name
> canonicalization.  Many of them were simply ways in which it couldn't
> be used (e.g., generic hostnames mapping to multiple machines, when
> you don't know which you'll connect to), or how it really ought to
> work parallel to and in conjunction with DNS aliases to avoid
> surprising the end user.
> 
> The main omission Martin brought up, I believe, is the lack of the
> ability to do secure name canonicalization anywhere outside of an
> AS_REQ or TGS_REQ.
> 
>  * gss_canonicalize_name needs this service, to permit (pre)populating
>    ACLs (and I could imagine some Kerberos situations where this might
>    be the case too); the specification of the GSS_Canonicalize_name
>    function specifically says it's for use with ACL entries
> 
>  * You can't set up ACLs with "whatever ldap/host.dom.ain@FOO maps to
>    at run time", since the mapping can't be performed.
> 
> These could be addressed by a KDC service which did *only* name
> canonicalization, securely; this should IMNSHO be as integral to the
> Kerberos service as name canonicalization itself.  (Or reverse it: If
> this canonicalization service isn't integral to the Kerberos spec, the
> optimization of name canonicalization as part of KDC_REQ processing
> shouldn't be either.)  Using the TGS isn't good enough -- the
> principal name you want to canonicalize may be one for which service
> tickets are prohibited by site policy.
> 
> But no one has suggested anything.
> Well, I keep suggesting removing name canonicalization, but no one
> seems interested. :-)
> 
> Even if we add such a service, gss_canonicalize_name will require a
> round-trip to the KDC, while text in RFC 2744 suggests that
> gss_canonicalize_name is supposed to be much more efficient than
> actually going through the authentication steps.  (Granted, that's
> just the C bindings document, and such things should be a matter for
> the generic GSSAPI spec.)
> 
> How does gss_canonicalize_name work in the Microsoft implementation?
> 
> Adding such a service might also permit more flexibility in name
> canonicalization, for example, making "ftp/[email-masked]" an
> alias for "ftp/[email-masked]", which I believe is impossible
> with the current mechanism, so I can't just type "ftp gnuftp" and have
> the right magic happen, as I can with normal DNS canonicalization.
> (For that to fully work, name canonicalization as part of the AS and
> TGS would have to change.  But the right thing, IMNSHO, would've been
> to design name canonicalization well, and *then* look at optimizing
> the combination with AS and TGS exchanges.)
> 
> Do people think we need such a service?
> Should it be in kerberos-revisions?
> Should kerberos-revisions be finalized without any such facility?
> 
> Ken
> 
> P.S.  RFC 2743 specifies the use of DNS to canonicalize a supplied
> hostname for GSS_C_NT_HOSTBASED_SERVICE.  Perhaps a future Update 2
> should address the security issues here somehow, and perhaps change
> that specification.
>

---

From: Ken Raeburn <[email-masked]>
Date: 04 Dec 2000 16:41:05 -0500

> 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.

> 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?

Ken

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 4 Dec 2000 17:35:25 -0500

I would say that a new KDC protocol is called for whereby properly
authenticated clients can ask the KDC to canonicalize principal names.

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.

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

--

---

From: Ken Raeburn <[email-masked]>
Date: 05 Dec 2000 00:23:12 -0500

> populate ACLs with a batch job.

Not authenticate *as*, since AS_REQ canonicalization isn't secure, but
authenticate *to*, provided the KDC policy permits it, which it might
not.

The batch job shouldn't be any different -- if you don't have tickets,
you can't ask the KDC anything.

> canonicalization. If the client knows and can rely on a simple rule for

From earlier discussions, it seems that's likely not to be the case.
At least, not in any way you'd hard-code in an application.

"John Brezak" <[email-masked]> writes:
> [JBrezak] Now you really are turning Kerberos into a name service.

I'd say name canonicalization does that already.  The TGS_REQ
canonicalization is an optimization of name service query and ticket
acquisition -- at least, it has never looked like anything else to me.

> [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.

> 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] 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.

---

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

> control is based on the UUIDs not principals.

When I read the DCE manuals, it explicitly mentioned that DCE explicitly
offers name-based authentication.  One of the reasons is (application)
interoperability with standard Kerberos 5.  As far as I recall, the
protocol spec under discussion is the "standard" Kerberos 5...

> LDAP would easiliy be able to handle this.

You're kidding.

The Kerberos revisions document is about to be completed.
Adding a requirement for LDAP access into every Kerberos 5 KDC and
secure LDAP queries into every Kerberos 5 client is probably not
what the people on this list are looking for.  Not only because
it's incompatible with the installed base, would seriously
bloat the architecture and would delay the kerberos revisions
spec by at least two more years.

I know that Microsoft's incarnation of GSS-API (called SSPI) is
broken and incomplete in particular concerning the name-based
authentication, credentials acquisition and service principals,
but the other two rfc-1964 compliant Kerberos GSSAPI mechanisms
with true GSS-API v2 that I know (Cybersafe and MIT) are very
usable with plain GSS-API v2 - no dirty hacks and additional
APIs necessary to work around bugs and shortcomings.

LDAP for name canonicalization would require that the Kerberos
implementation must do it internally, below the GSS-API, or
distributed gssapi-based applicatoins will not be able to use it.

One of the *serious* drawbacks of LDAP lookups would be the
additional (network) overhead.  It would be a serious no-no
to have a lookup during authentication, but even for name canonicalization
during gss_canonicalize_name(), LDAP lookups would kill performance
of most maintenance functions.  Why does Microsoft put the PAC into
the ticket?  Why don't you look up that information via LDAP with
the name from the name based authentication?  We all know the
answer: performance, complexity, reliability.

-Martin

---

From: "Booker C. Bense" <[email-masked]>
Date: Wed, 6 Dec 2000 14:23:17 -0800 (PST)

On Wed, 6 Dec 2000, Martin Rex wrote:

> John Brezak wrote:
> >
>
> >
> > Name canonlicalization is not a mechanism for access control.

- If it's available, it will be used as one. Regardless of the
wisdom of the concept, it's just too easy to make that additional
step. In many ways, the only thing an authority service really does
is "name canonicalization".

> > If a

- I also see a chicken and egg problem. How do you authenticate to
LDAP to do the name lookup?[1] At our site the mapping between real world
name [2] and kerberos principal is something we work pretty hard to give
users a knob to control who can and can not view this information.
It's been a real stumbling block to deploying W2k. Perhaps this is not
an issue in the debate, I haven't been following the technical
arguements well enough to say for sure. ( I must admit I consider this
whole thing to be a blecherous hack, however much we need a secure
naming service kerberos is the wrong place to put it. )

- IMHO, kerberos should stick to authentication and leave name
canonicalization to a true authority service. To me it seems
clear from this debate that you can't get it right unless you
give up the idea that a principal IS the unique identifier of
a user. Unless you add something like a SID or uuid and an
authority model to go with it, you can't reliably specify
between the "real" and "fake" principals.

- Booker C. Bense

[1]- The arguement about user principals may not apply in this case,
but if you have to use the name canonicalization service to find the
ldap service name to to use the name canonicalization service....

[2]- It's much more than just that mapping, pretty much connecting
any data to the kerberos principal is considered to be a potential
privacy issue. Your principal must be public, but the mapping of that
principal to any other data is not.

---

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

> naming service kerberos is the wrong place to put it. )

I agree with your sentiment, if you're addressing the W2k hacks...

In Win2k there is no need to perform the out-of-band lookup nor to
authenticate the lookup because the KDC adds all the relevant
information (the "user profile") to the users' tickets. And the Win2k
services don't use Kerberos principal names but Windows SIDs for
authorization.

> between the "real" and "fake" principals.

Right. Hence my Other-Names extension suggestions. If you authorize
access using names other than Kerberos principal names (and certainly,
all modern OS kernels that I know of do -- i.e., Unix uses UIDs/GIDs,
Windows uses SIDs+RIDs, and so on).

> principal to any other data is not.

Hmmm.

Nico
--

---

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

> answer: performance, complexity, reliability.

And one more reason: the data that makes up the profile can be protected
in such a way that only the user it refers to can read it because only
the [Win2k] KDC performs the lookup, and only during pre-authenticated
AS_REQs.

This means that services need not be so priviledged that they can
enumerate all valid users via the name service, and so on, because they
don't have to be. This means that anonymous and semi-anonymous lookups
need not be allowed in the name service.

This is a feature trumpeted in various places in the MS AD docs, in
their classes and so on. And I don't blame them, as they have been
criticised before for allowing such anonymous lookups in NT4 domains.

Nico
--