Subject: Crossrealm Referal

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 12 Feb 2001 15:50:19 -0600

Jonathan Trostle presented a paper at the ISOC - NDSS last week:

 "Implementation of Crossrealm Referral Handling in the MIT Kerberos Client"
   Jonathan Trostle, Irina Kosinovsky and Michael M. Swift

            Abstract
 The Windows 2000 Kerberos implementation [1,2]
 uses a different approach to solve the Kerberos realm
 resolution problem than has traditionally been used by
 MIT Kerberos implementations....

I asked Jonathan to work with the authors and John Brezak (who received an 
acknowledgment in the paper) to document the protocols used in the paper as 
a draft RFC. These use the name canonicalization with the TGS. I understand that
before the Kerberos working group was formed, there was a similar document by John
and maybe this can be revised instead, but that it was decided to incorporate the 
changes into the revisions. This has not worked well, holding up the revisions, as 
there are still many questions and concerns about the approach taken by Microsoft.

I would like to see the revisions go forward with the canonicalization
for the AS_REQ, and this new draft to cover the TGS. This will allow the
WG to concentrate on the revisions, while allowing indepenent discussing the
merit of these new features. 

-- 

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

---

From: Martin Rex <[email-masked]>
Date: Tue, 13 Feb 2001 20:58:14 +0100 (MET)

> merit of these new features. 

I am strongly opposed to include the currently proposed 
name canonicalization with the Kerberos revisions document.

It should either be fixed or removed!

It is broken because this behaviour will create a seriously mis-behaving
Kerberos gssapi mechanism.  To work under the GSS-API model,
a seperate-from-ticket-request name lookup/canonicalization will be
required, and it MUST be optional.

There is a serious problem with Microsoft's W2K Kerberos, and I really
want the Kerberos revisions spec NOT to bless this incompatibility
and GSS-API architecture violation and I especially don't want to
see it being promoted any further.

If you don't know what I'm talking about:
Take a standalone (i.e. domain-less and directory-less) W2K pro and
attach it to a MIT Kerberos KDC.  Create a Kerberos hostbased service
principal for this workstation and try to (a) install these credentials
on the W2K machine and (b) try to accept security contexts with these
credentials on the W2K machine using Microsoft's Kerberos.
-- It's impossible!

There is another problem with Microsoft's approach to implement
service principals purely by name canonicalization which is even
present with an Active directory, namely that host-specific instances
of a distributed service can not use host-specific credentials while
operating under a common user account.

Although these are more an operational and API issues than Kerberos
protocol issues, I really think the Kerberos group should NOT be totally
ignorant of the Kerberos 5 gssapi mechanism spec and its (non-)future.

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Tue, 13 Feb 2001 14:28:47 -0600

> name canonicalization with the Kerberos revisions document.

So are most others. That is why it is being split out. At the San Diego IETF
we agreed to leave the AS usage for name canonicalization in the revisions 
but not the TGS usage. If I understand your arguments below they all deal
with the TGS usage. The draft I have asked Johnathan and Microsoft to put 
together would cover what they are doing with the TGS usage.

> It should either be fixed or removed!

In effect the broken parts are being removed to the seperate draft
where we can continue the arguments, and get it fixed, while letting
the revisions go forward.  

> ignorant of the Kerberos 5 gssapi mechanism spec and its (non-)future.

I would hope that we are addressing these issues, by seperating them out from 
the revisions. Am I missing something?

--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 13 Feb 2001 16:11:32 -0500 (EST)

> It should either be fixed or removed!

Personally, I think everything having to do with canonicalization and
referrals should be removed from revisions.  These are controversial
features that are not part of the core Kerberos functionality, and it is
clear (to me at least) that we do not have concensus on them.  We should
not publish a kerberos-revisions that includes these features without
havin reached concensus, and we should not hold up kerberos-revisions any
longer for them either.  Move them into their own document, so we can move
the new Kerberos spec along.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Feb 2001 18:01:07 -0500

If I may.

There have been two kinds of complaints about the principal name
canonicalization extensions to Kerberos, if I remember correctly:

1. Cross-realm referrals in AS_REPs are insecure.

2. SPN canonicalization breaks GSS-API:

    a. SPN canonicalization in TGS_REPs somehow make gss_canonicalize()
       useless.

    b. PN canonicalization breaks the GSS-API since the API cannot
       handle PNs that change, or something like that.

(1) was taken care of in a long thread on this list. I believe that
there is no security problem there since AS exchanges used to
authenticate users to local hosts MUST be followed by validation of TGTs
so obtained. No new DoS attack is introduced either, since AS_REPs are
already spoofable (thus the required TGT validation step).

(2a) is somewhat debatable. Gss_canonicalize() is not required to nor
does it validate PNs, it merely canonicalizes them as per a given
mechanism. I'm not sure what that means exactly, but it certainly does
not mean that, say, Kerberos PNs are checked to be valid PNs (i.e., that
the PNs exist in their named realms).

The point about gss_canonicalize() may be somewhat confusing since
"canonicalization" in GSS parlance does not have the same meaning as
"canonicalization" in Kerberos parlance.

Introducing PN canonicalization in AS and TGS exchanges does not, in my
view (correct me if I'm wrong) have any impact on GSS.

If introducing PN canonicalization in AS and TGS exchanges adversely
affects the GSS-API (the API spec and the C bindings spec), then that
means that the API is BROKEN. Other mechanisms might involved
fluctuating PNs and GSS specs could be written for such mechanisms, but
they too would break the API.

GSS-API is not the only API for GSS. There is also SSPI.

That said, as I skim the GSS-API RFCs (2743 and 2744), I find that there
is a GSS_Inquire_context() API funtion which should allow GSS-API
applications to handle Kerberos PN canonicalization just fine.

Thus I think that at most the GSS API spec might need to be revised in
order to deal with Kerberos PN canonicalization, but a cursory look
makes me think that no changes will be needed to the spec.

Now, that's for the complaints that I remember. Maybe I remember wrong;
please correct me if I do.

Kerberos PN canonicalization DOES have some benefits:

 - no more trying multiple SPNs (telnet/host.fqdn@REALM,
   host/host.fqdn@REALM, etc...) at the application level

 - administrative flexibility, though this is a double edged sword. I
   posted about the problems with respect to namespace consistency and
   integrity and feedback to administrators that I experienced when I
   tested Kerberos PN canonicalization in Windows 2000

Others can probably expand on the benefits of Kerberos PN
canonicalization better than I can.

I also think it silly to allow UPN canonicalization in AS exchanges, but
disallow SPN canonicalization in TGS exchanges. There's a symmetry issue
here since UPNs can in fact be used as SPNs and vice-versa.

Using Kerberos PN canonicalization does not break implementations that
don't know about it either. Or shouldn't anyways, since canonicalization
has to be requested by clients and since servers see only an additional
flag, IIRC.

My two cents.

Are there good reasons to exclude Kerberos PN canonicalization from the
spec?

Nico

--

---

From: Derek Atkins <[email-masked]>
Date: 14 Feb 2001 18:25:06 -0500

> already spoofable (thus the required TGT validation step).

No, this is not necessarily true.  If the person at the keyboard is
the attacker, (meaning they are at the login keyboard and also have
access to the network from somewhere else), they can spoof the AS_REQ
such that the client requests a TGT for which the person sitting at
the keyboard (the attacker) knows the password.  This resulting TGT is
perfectly valid, and can successfully be used for any "kerberos"
validation.  However, it is in no way the "correct" TGT nor is it what
the client really should have obtained.

So, no, I do not consider this to be "ok" as it is.  I would like to
see revisions go forward without AS_REQ canonicalization.  Just rip
out that text and move forward.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Feb 2001 22:59:00 -0500

We've been through this. We agreed that the issue there lies in how
authorization is done. Period. Systems that don't now support PN canon
will not be affected. Period. Systems that do should authorize
correctly (i.e., based on the canon principal name, not the original
name).

Authorization based on canonical PNs is not a difficult concept.

Nico

--

---

From: Sam Hartman <[email-masked]>
Date: 15 Feb 2001 03:54:03 -0500

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> On Tue, 13 Feb 2001, Martin Rex wrote:
    >> Douglas E. Engert wrote: > > I would like to see the revisions
    >> go forward with the canonicalization > for the AS_REQ, and this
    >> new draft to cover the TGS. This will allow the > WG to
    >> concentrate on the revisions, while allowing indepenent
    >> discussing the > merit of these new features.
    >> 
    >> I am strongly opposed to include the currently proposed name
    >> canonicalization with the Kerberos revisions document.
    >> 

    Jeffrey> Personally, I think everything having to do with
    Jeffrey> canonicalization and referrals should be removed from
    Jeffrey> revisions.  These are controversial features that are not
    Jeffrey> part of the core Kerberos functionality, and it is clear
    Jeffrey> (to me at least) that we do not have concensus on them.
    Jeffrey> We should not publish a kerberos-revisions that includes
    Jeffrey> these features without havin reached concensus, and we
    Jeffrey> should not hold up kerberos-revisions any longer for them
    Jeffrey> either.  Move them into their own document, so we can
    Jeffrey> move the new Kerberos spec along.

I certainly tend to agree with this.  I think many of us went along
with the proposal to keep TGS name canonicalization at San Diego
because we could not come up with specific criticism not because we
were comfortable that it had been reviewed enough and was a good idea
to include in revisions.

If Martin believes that even TGS canonicalization is broken then that
is a compelling enough reason for me to want to see it also removed
and go on with Kerberos revisions as our primary focus.

Yes, name canonicalization of some form is important (although I
remain unconvinced it should be canonicalization within Kerberos
instead of some other layer).  However, I believe that it is possible
to produce a protocol that works for a significant number of people
without name canonicalization--the current MIT and Heimdal
implementations seem to do this.

So, I believe that name canonicalization standardization can in fact
wait on the core Kerberos spec.

Thus, for any section of NC that still needs discussion my preference
is to remove and discuss in parallel/after revisions.

Obviously if the WG feels that TGS canonicalization must be in even if
there are concerns, we should work to resolve these concerns post
haste.

I disagree with Nicolas's characterization of the AS canonicalization
discussion.  I do not believe that consensus was reached, or if
consensus was reached, he was not part of that consensus.  From my
vantage, it looked like both sides were starting to repeat the same
arguments over and over again, and that several participants realized
that no progress was being made and stopped.  Silence is not always
consensus.  I think the AS issues will only be resolved by an
in-person meeting or if that is impossible a conference call.  I
believe that email has been ineffective so far at reaching agreement
and we must either agree to disagree or try other channels.

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Feb 2001 12:36:30 +0100 (MET)

> "canonicalization" in Kerberos parlance.

Canonicalization in GSS-API, in particular for gss_canonicalize_name()
is to populate Acccess Control Lists (ACLs) on the acceptor side
(traditionally this is the "server" side).

> view (correct me if I'm wrong) have any impact on GSS.

It does.  If you add name canonicalization to a existing Kerberos with
GSS-API without adjusting gss_canonicalize_name() to support the same
canonicalization, you will break the GSS-API functionality and
distributed applications will probably no longer be able to operate
on such a broken GSS-API mechanism.

> they too would break the API.

Nope. 
The GSS-API spec is an extremely good abstraction and with the exception
of how gss_add_cred() is specified, it is extremely consistent.

The DCE guys (who originally invented GSS-API) have implemented name
services in a fashion that works fine with GSS-API.  It's out-of-band.

Squeezing name canonicalization into the authentication protocol exchange
is an optimization that can not be modelled in a generic fashion.
It is a good way to tie applications to a particular type of authentication
mechanism -- this is something companies like Microsoft prefer to do,
but we at the IETF shouldn't do it!

The GSS-API was designed so that an application could be portable,
i.e. one can replace the GSS-API mechanism without having to rewrite
any application code.  And this idea works extremely well, *I* know
what I'm talking about, that's been my job for the last 5 years.

> GSS-API is not the only API for GSS. There is also SSPI.

The SSPI is Microsoft's variant of GSS-API.  The acutal spec is mostly ok,
however it does have some design flaws, and these are very annying if one
tries to look at it with the abstraction level of GSS-API.  Authentication
is flawed and name-based authentication is severely flawed.
But the worst of all is that Microsoft has shipped at least a dozen
different implementations of NTLM that violate their own spec in many
subtle ways.  The result is that you don't get anywhere near the portability
or SSP abstraction that the spec initially suggests.  It takes a lot
of time and patience to figure out all the bugs and design suitable
workarounds that work reliably.

The net result is that a Win32 SSPI-based application will not only
be non-portable among diffent SSPs (e.g. NTLM and Kerberos), it
will even be non-portable across different incarnations of the
same SSP!  You have to test every single Platform (Win95,Win95,WinMe,
WinNT 3.51, WinNT4, W2K) and several service packs of each, find
out the particular incompatibilities and bugs and add suitable
workarounds.  I know what I'm talking about, I have built a
GSS-API wrapper so that our customers may use NT Single Sign-On
with our GSS-API based application.  It was a real pain to install
and examine the bugs of so many Platform and service packs.

My company ships a large distributed application, and it can load an
arbitrary third-party shared-library based gssapi mechanism at runtime.
I haven't touched my GSS-API code during the last 3 years and it is
*exactly* the same code on all of our supported platforms
(5 commercial Unix, Linux, *all* Win32, MacIntosh, OS/2, AS/400, OS/390)
during these last three years 10 different vendors of gssapi mechanism
showed up to become a supported third-party GSS-API mechanism supplier.
I can support all of them without a single application code change on
any platform.

Three years ago a quite large customer asked whether we could support
NTLM single sign-on for Microsoft-only installations.  So I wrote
a wrapper that makes SSPI look like a regular GSS-API mechanism and
becomes usable with our application.  I have to add new workarounds for
bugs in NTLMSSPI about twice a year and update the wrapper DLL,
either old bugs that I hadn't yet noticed or new bugs or incompatibilities
that appear with a new platform or new service pack.  And that is *only* to
make Microsoft's different version of the NTLM SSP interoperate.

> applications to handle Kerberos PN canonicalization just fine.

We're not discussing whether it's possible to change an application to
work around the design flaw of a gssapi mechanism that we want to commit,
but whether we actually need to commit a design flaw in Kerberos that
will break it's gssapi mechanism interface.

> makes me think that no changes will be needed to the spec.

It is really very valuable to have an API spec that allows me to replace
an old GSS-API mechanism with a new one *without* having to throw away
existing applications (=installed base)!

> canonicalization better than I can.

Fine.  Define a seperate API for it.  Don't cramp it into existing
protocol exchanges, because this will definitely break the installed
base.  I would really appreciate a seperate name service that
allowed name canonicalization and service location.  I would be
willing to participate in defining a GSS-API extension that allows
to use the name service.  I would change my application so that
future version will be able to use the name service from gssapi
mechanism that provide one.  All of this will not impact the
installed base!

> has to be requested by clients and since servers see only an additional

There's a very good chance that it breaks GSS-API based applications,
either by chance or intention.  W2K Kerberos is an obvious BAD example.

-Martin

---

From: Ken Raeburn <[email-masked]>
Date: 15 Feb 2001 07:47:27 -0500

> required, and it MUST be optional.

I did send off some email December 11th, during the IETF conference,
<[email-masked]>, which is in the mailing
list archive, with some ideas on how to address some of the problems I
see with name canonicalization, including this one.  Have you had a
look?

I'd rather have a new message exchange for canonicalization, but
that'd be more brand-new stuff going in, without implementation
experience, and my suggestion, while a bit of a hack, is a relatively
small change to the spec.  (And still something on which I've got no
implementation experience to relate, unfortunately.)

Ken

---

From: Ken Raeburn <[email-masked]>
Date: 15 Feb 2001 08:24:35 -0500

> and we must either agree to disagree or try other channels.

I think you're right -- and if Martin and John are going to be at the
next IETF, that may give us a good opportunity.

Ken

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Feb 2001 14:47:09 +0100 (MET)

Hi Ken,

> see with name canonicalization, including this one.  Have you had a

Yes, I read your message.  I was quite happy to see very early in the
discussion that you understand that there are issues with GSS-API that
should be addressed.

Although a seperate KDC-lookup during gss_canonicalize_name() might
technically solve the problem, I would strongly prefer if
gss_canonicalize_name() would *NOT* do any network communication under
the covers at all.  It would seriously impact application performance
and reliability (of at least our installed base).

Adding an GSS-API extension that allows name lookups would be best
way to go and applications that are going to use it will be able to
deal with the constraints of performance and reliability.
The *BIG* advantage of a seperate extension would be that the
issue of looking up a particular instance of a distributed service
to get the host-based service name and the destination address
could be performed at the GSS-API level in a generic and portable
fashion.

Ripping the hostname out of a canonicalized hostbased service principal
in the Ticket reply from the KDC to use it for establishing the
network connection for the AP_* exchange may be something that a
native Kerberos client is able to do, but this cannot be made to
work under the abstraction model of GSS-API!  When using a seperate
name lookup API, it is possible to define a *generic* (optional) extension
to GSS-API to canonicalize a service name into a host-specific service
principal and return the connection information with it.

> implementation experience to relate, unfortunately.)

I agree: it should be an optional extension and go into a seperate
document.

What I really *NOT* like to see is that name canonicalization is
actively used to deceive people about flawed implemenations that
lack true hostbased service principals, which are absolutely required
for implementing distributed services in a generic fashion
(like at the GSS-API level).  Such a flawed implementation should
be fixed!

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 09:13:33 -0500

Fine. When is the next IETF meeting?

Nico

--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 09:02:06 -0500

Inline.

> (traditionally this is the "server" side).

Does gss_canonicalize_name() *validate* PNs today? Or does it just
canonicalize the *form* of the PN?

This is the key distinction.

> on such a broken GSS-API mechanism.

See above. I suspect the answers to the two questions above are: No and
Yes. I'll look at MIT's sources later today.

> of how gss_add_cred() is specified, it is extremely consistent.

I'll look at this. But I think the key to PN canon and GSS-API is
probably in the acquire/inquire functions.

> services in a fashion that works fine with GSS-API.  It's out-of-band.

Doing PN canon out-of-band has some flaws:

 - you must get authentication in the OOB protocol right
 - most designers would allow anonymous or semi-anonymous lookups

I think MS went to a lot of trouble to make it possible to not require
anonymous or semi-anonymous lookups in their name services.

Some of their technical approach is rather disgusting and seems tied to
stinking business models (i.e., to tie customers to their software).

But this, PN canon, is not one of those disgusting things.

And I think that the goal of not having to allow anonymous or
semi-anonymous lookups of name service data during normal operations is
more than worthwhile.

I did a search for Kerberos, NT5 and so on a few months ago and found a
number of minutes from conferences in 96 and 97 where MS described some
of their innovations, including PN canon, GSS-TKEY (another worthwhile
piece of work), ticket authz data and signatures (here they screwed up,
IMHO). There's been several years to figure out how to do things right.

> but we at the IETF shouldn't do it!

There's no requirement to use PN canon. You can avoid it successfully,
even when interoperating with implementations that support PN canon.

You just don't request PN canon in AS_REQs and TGS_REQs, and you must
know the canon PNs ahead of time (as you must today without PN
canon!!).

Thus no problem. Not even with GSS-API, not even with PN-based ACLs.
Keeping such ACLs consistent is an administrator's job, with or without
PN canon; besides, admins can get at the raw data needed to *validate*
PNs in ACLs, off-line or OOB.

> what I'm talking about, that's been my job for the last 5 years.

How many GSS-API apps do you know that can be made to work with another
mechanism with zero source changes? To be sure there are some, but I
doubt that's true of the MIT apps.

Besides, the RFCs allow for mechanisms where PNs can change during
authentication/session setup, thus the gss_inquire_context() call. It's
there for a reason, and it's not MS's fault that some app developers did
not take notice.

> is flawed and name-based authentication is severely flawed.

How can the spec be mostly ok and yet be so flawed?

> workarounds that work reliably.

I won't defend MS on this. I also hear that they typo'ed the Kerberos v5
GSS mech OID! Sigh.

> and examine the bugs of so many Platform and service packs.

I believe it. WHat has this got to do with PN canon?

> I can support all of them without a single application code change on

Cool! Do your apps call gss_inquire_context()?

[...]

> will break it's gssapi mechanism interface.

It seems to me that GSS-API was designed to be workable with many kinds
of mechanisms. Apps need only use the API correctly in order to work
with all mechanisms.

But let me repeat: PN canon is optional. If you don't use it, you're not
affected. Regardless users must know valid PNs, and without PN canon
they must know valid canon PNs.

> existing applications (=installed base)!

I didn't mean that API needs updating, only that I might have missed
some problem with the API and PN canon that would require updating the
API. See above, particularly about PN canon being optional.

> mechanism that provide one.  All of this will not impact the

There is an installed base of AD and W2k. There is an installed base of
other implementations of Kerberos/GSS. Have you examples of such
breakage, module OS bugs and administrative errors?

> either by chance or intention.  W2K Kerberos is an obvious BAD example.

Prove it.

Clients that don't support PN canon cannot be affected.

Servers that don't support PN canon should not be affected.

KDCs that don't support PN canon should not be affected.

And there are clients and servers that do support PN canon and work,
modulo OS bugs.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 09:12:13 -0500

Inline.

> were comfortable that it had been reviewed enough and was a good idea

There's nothing in the above, nothing technical. What's the source of
your opposition?

> implementations seem to do this.

See my response to Martin Rex from today.

> wait on the core Kerberos spec.

Well, yes, this is true. Are there good technical reasons to make it wait?

The MS W2k/AD installed base may soon be as large and larger than any
other Kerberos/GSS implementation's. If there's nothing technically
wrong with a proposal and it becomes a defacto standard, then to refuse
to bless that defacto standard can marginalize the standards body.

> is to remove and discuss in parallel/after revisions.

Oh well.

> there are concerns, we should work to resolve these concerns post

I think PN canon in AS_REPs must be excluded if PN canon in TGS_REPs is
excluded.

> and we must either agree to disagree or try other channels.

I thought that Ken Raeburn and I reached a consensus. The protocol
aspect of UPN cross-realm referrals is as secure as Kerberos has been so
far. On the authorization aspect of UPN cross-realm referrals I'd say we
also reached a consensus: it would improper and broken to authorize
access base on non-canon PNs or to authorize access to resuorces named
by non-canon PNs.

For those of us who are Unix centric (as I am), consider this: PAM does,
in fact, support PN canon. PAM apps need only pam_get_item(PAM_USER)
after calling pam_authenticate and proceed as if that had been the
original value of PAM_USER. FreeBSD PAM apps already support this.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 09:42:41 -0500

[...]

> and reliability (of at least our installed base).

Aha! Without "network communication under the covers at all"
gss_canonicalize_name() cannot VALIDATE principal names. It can only
validate and canonicalize their FORM.

Just what I state elsewhere in this thread.

Kerberos PN canonicalization, by virtue of being part of the AS and TGS
exchanges, thus resulting in errors or tickets, not only canonicalizes
PNs, it also confirms that they EXIST and are VALID.

Gss_canonicalize_name() is NOT affected.

[...]

> I agree: it should be an optional extension and go into a seperate

PN canonicalization is optional. Yes, I know you were referring to OOB
PN canon.

> (like at the GSS-API level).  Such a flawed implementation should

Is that true of W2K/AD? I know that MS uses Kerberos PN canon to keep
per-host keys/accounts to a minimum, namely MS wants and keeps one SPN
per-host.

This works even when W2K servers run non-priviledged apps, because W2K
does not allow apps access to the local keytab, instead W2K apps use IPC
to communicate with a daemon (LSA) that performs all
authenticator/ticket validation (well, GSS token processing).

I must say, I like that approach.

Solaris/SEAM seems to have a similar approach since putting a complete
GSS-API/Kerberos/DH implementation in the kernel would be unrealistic.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 12:14:56 -0500

BTW, we can certainly test your theory of a security bug in xrealm
AS_REP referrals.

Implementations which do not support PN canon should not be vulnerable
(they should drop spoofed AS_REPs that are xrealm referrals).

Implementations which do support PN canon should not be vulnerable (they
should log in the user as the canonical user, not as the spoofed alias
with no further priviledges and access than the canonical user would
have had if he/she had logged in as him/herself to begin with).

Nico

--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 12:32:09 -0500

As promised below, I looked at MIT's implementation of
krb5_gss_canonicalize_name(). It's a noop; it just copies the
input_name. A comment states that the triviality of this function is due
to the one-mechanism nature of MIT's GSS-API implementation. But it
would be almost as trivial if multiple mechanisms were supported.

Read on.

Let me quote the relevant RFC (2743):

   This routine reduces a GSS-API internal name input_name, which may in
   general contain elements corresponding to multiple mechanisms, to a
   mechanism-specific Mechanism Name (MN) output_name by applying the
   translations corresponding to the mechanism identified by mech_type.
   The contents of input_name are unaffected by the
   GSS_Canonicalize_name() operation.  References to output_name will
   remain valid until output_name is released, independent of whether or
   not input_name is subsequently released.

I note that there is no requirement that GSS_Canonicalize_name() verify
the validity, the existence of the names it canonicalizes.

I note also that among the errors that GSS_Canonicalize_name() is
allowed to return there is NO error that GSS_Canonicalize_name() can use
to indicate that the given input_name does not exist.

Given this, I think we can only conclude that Kerberos PN
canonicalization has ZERO effect on the operation, implementation or
behaviour of GSS_Canonicalize_name(). If this is not true for some
implementation, then that must be an implementation error.

I believe that the controversy over gss_canonicalize_name() is due
merely to confusion due to the different meanings attached to the verb
"to canonicalize" in the GSS-API spec versus the Kerberos PN canon
additions.

Nico

--

---

From: Derek Atkins <[email-masked]>
Date: 15 Feb 2001 12:40:32 -0500

> Fine. When is the next IETF meeting?

Minneapolis, March 18-23.  See www.ietf.org

-derek

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Feb 2001 19:32:11 +0100 (MET)

> This is the key distinction.

Kerberos:    no, yes
many SPKM1:  no, half-yes
others:      yes and no, half-yes or yes

The GSS-API spec requires only a canonical encoding (which can be emitted by
gss_export_name), it doesn't require validation or transformation.
This is a gssapi *mechanism* issue, and in case the mechanism spec
is silent about it, then it's an implementation issue.

Some mechanisms I've seen do validate names during gss_canonicalize_name(),
most don't.  All Kerberos mechanisms that *I* have seen don't seem to
do validation.  As there is no requirement to do any validation, it
should not be done when it's not necessary.  For some mechanism
it may even be impossible, e.g. directory-free X.509-based SPKM-like
mechanisms.

>  - most designers would allow anonymous or semi-anonymous lookups

a) not an issue.  it is the job of those who create the standard to
   solve this so that implementors can not get it wrong

b) allowing anonymous or semi-anonymous lookups is not a problem
   by itself.  By semi-anonymous do you mean that the client remains
   anonymous, but the reply contains information that enables the
   client to verify that the transformation is secure (authentic)?

   You MUST use secure transformations/canonicalizations
   for every operation underneath GSS-API, be it gss_import_name(),
   gss_canonicalize_name(), gss_init_sec_context(), gss_accept_sec_context()
   gss_acquire_cred(), etc...  i.e. when the transformation includes
   lookup on a central server/database/directory, the reply must be
   authenticated by the client (the client must verify that the reply
   wasn't modified, and that it is from an authority that the
   client trusts.)

> IMHO). There's been several years to figure out how to do things right.

I'm not a Kerberos guru and I didn't know about their canonicalization
until I tried to set up a hostbased service on W2K pro standalone
attached to an MIT KDC (as I mentioned before, it's impossible).

> know the canon PNs ahead of time (as you must today without PN

With GSS-API I don't request any tickets ever.
I call gss_acuquire_cred() and gss_init_sec_context().
There is no choice how the AS_REQs and TGS_REQs are performed at
the GSS-API level.

> PNs in ACLs, off-line or OOB.

ACLs are application-specific constructs.  The application creates and
maintains them.  ACLs contain a identifier as the lookup key (for GSS-API,
tthis is the name of the authenticated identity) and application-specific
data which the application uses to perform authorization decisions.
The identifier is created with the API primitives of the authentication
API which the application uses.

> doubt that's true of the MIT apps.

100% of the applications for which I have implemented GSS-API support. ;-)

The NFSv4 guys believe they're portable (I told them why I doubt it).

It is quite possible to get it right, but people that start with
a Kerberos background and a simple client-server architecture in mind
or both seem to get it wrong frequently, sometimes completely wrong.
Someone who starts writing an app with a SPKM-like gssapi mechanism
is significantly more likely to get it right.  It's best to
start with both, SPKM and Kerberos from the beginning.

> there for a reason, and it's not MS's fault that some app developers did

I really doubt that any text in rfc2743/44 is misleading in such a fashion.
The one thing that has been permitted on my request is that an initiator
that doesn't know about the identity of the acceptor may start
without passing a target name into gss_init_sec_context() while still
requesting mutual authentication.  After successful security context
establishment, the initiator may then inquire the context to find
the true name of the authenticated acceptor.  In this specific situation
gss_inquire_context() is permitted to return an acceptor name
that was never passed into gss_init_sec_context().

> How can the spec be mostly ok and yet be so flawed?

It took me 3 painful years, I don't have the time or willingness
to brag here.  Let's stick to the discussion of Kerberos revisions.

(you may look for comments in the following source:
  ftp://ftp.sap.com./pub/ietf-work/gssapi/gsskrb5/gsskrb5-1b3.zip

> I won't defend MS on this. I also hear that they typo'ed the Kerberos v5

Really? The OID that I see at the SSPI level on the tokens is correct.
I would have noticed if it was wrong.

> Cool! Do your apps call gss_inquire_context()?

No.

But my gsstest tool verifies its correct operation anyways.

> of mechanisms. Apps need only use the API correctly in order to work

Yes, exactly.

> they must know valid canon PNs.

W2K Kerberos is already broken.  I really want to see it fixed and
if name canonicalization goes into Kerberos revisions then if might
encourage others to ship broken implementations as well or not to
fix those that have already been shipped.

> breakage, module OS bugs and administrative errors?

I already mentioned that W2K lack true hostbased service principals,
something that is absolutely required for distributed services
because of the nature of the Kerberos 2-way authentication using
authenticators (replay caches are not shared across hosts).
It's extemely obvious for an AD-less W2K attached to a MIT Kerberos KDC.

Microsoft knew about their design flaw before they shipped W2K.
The underlying problem and the correct solution is described
the DCE documentation that I got in 1995.  I've been asking them
for fixes/workarounds even before W2K was offially released,
and I'm still waiting.

> > either by chance or intention.  W2K Kerberos is an obvious BAD example.

That's easy:
Try to make the the gss-sample server work on AD-less W2K pro attached
to an MIT Kerberos KDC run with the service principal sample/f.q.d.n.
It's impossible.

Put canonicalization in the base kerberos revisions document
and some people will say it's mandatory, breaking the installed
and all GSS-API based applications with it.

Make it optional and put it into a seperate document and it is obvious
that a Kerberos clients and servers *MUST* cope with KDCs that don't
support it and that any implementation that doesn't is obviously
and severely broken.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 14:14:12 -0500

> it may even be impossible, e.g. directory-free X.509-based SPKM-like

Another post from me today quotes the GSS-API RFC (2743) description of
gss_canonicalize_name(). It seems to me that there's little room for
mechanisms to validate the existence of an MN and indicate non-existence.

>    client to verify that the transformation is secure (authentic)?

By semi-anonymous I mean that clients can lookup up data in the name
service with host-based authentication, rather than user-based
authentication. I.e., in Windows terms, domain member hosts can lookup
anything and they can do so on behalf of less-priviledged users without
the name service knowing it.

>    wasn't modified, and that it is from an authority that the

Well, guess what, Kerberos PN canonicalization IS secure. There is no
argument about the security of Kerberos PN canonicalization in TGS
exchanges, and that's what krb5_gss_canonicalize_name() would use, if
the RFC allowed for it. But, see above.

> attached to an MIT KDC (as I mentioned before, it's impossible).

I haven't tried this myself, but I imagine you are doing something wrong
here. There's a number of things you must do to cope with the lack of
user profiles embedded in MIT Kerberos tickets (yes, *this* is an
interoperability issue with an MS extension, but that has nothing to do
with Kerberos PN canonicalization).

What exactly went wrong?

Can MS folk please pipe up?

> There is no choice how the AS_REQs and TGS_REQs are performed at

Right, the Kerberos details are hidden by the Kerberos mechanism and its
configuration.

On a platform that supports Kerberos PN canonicalization the normal
configuration would be to request canonicalization in all ticket
requests in TGS exchanges -- this is a client side issue and the client
should use gss_inquire_context() to discover that the name used
initially for the service may have changed.

The server side should be unaffected by Kerberos PN canonicalization (I
think a flag would be present in the ticket to indicate that
canonicalization of the SPN took place).

> API which the application uses.

I was referring to name-based ACLs, ones that use GSS-API names.

Members of this list have expressed concern that, essentially, Kerberos
PN canonicalization can mean that ACLs reference non-canon names that
would have to be canonicalized and how the heck does one do that.

Of course, ACLs can get out of date regardless of wether or not Kerberos
PN canonicalization is used!!

So, again, I maintain that Kerberos PN canonicalization has no
detrimental effect on name-based ACLs.

A mechanism is needed, BY ADMINISTRATORS, to validate names in ACLs, to
remove old entries, change entries that reference renamed principals,
and so on. THIS IS TRUE REGARDLESS of wether Kerberos PN
canonicalization is in use!

And administrators DO have such mechanisms: with MIT/Heimdal they can
use kadmin/kadmin.local/kdb5_util dump to obtain lists of active
principals in a given realm; with ActiveDirectory they can use
MS-provided tools (e.g., ADSI), PerlDAP, etc... to get at the list of
valid principals in a given domain.

Of course, with ActiveDirectory you can set things up so some
administrators can list only some of the valid principals and so they
cannot lookup anything about some valid principals. So what? This is an
administrative issue/feature.

I note that GSS-API has NO APIs for enumerating valid principals in any
given realm.

Therefore GSS-API alone is NOT enough to write programs that maintain
ACL databases.

...
> 100% of the applications for which I have implemented GSS-API support. ;-)

:)

God for you!

> The NFSv4 guys believe they're portable (I told them why I doubt it).

They do. SEAM (Sun's MIT-based Kerberos/GSS offering) DOES support
multiple GSS mechanisms [Kerberos v5 and several Diffie-Hellman / NIS+
based mechanisms differing only in key length]).

> or both seem to get it wrong frequently, sometimes completely wrong.

MIT folk take note!

;) ;)

> start with both, SPKM and Kerberos from the beginning.

Probably. I'm not an implementor.

> that was never passed into gss_init_sec_context().

Perfect. This is all that should be needed to cope with Kerberos v5
principal name canonicalization!

> to brag here.  Let's stick to the discussion of Kerberos revisions.

Heh. Ok. I'll believe you.

> I would have noticed if it was wrong.

I'll dig up the URLs.

...
> But my gsstest tool verifies its correct operation anyways.

The clients don't really need to care if the service name changed during
authentication and session setup. But if they did they would have to use
gss_inquire_context() to cope with Kerberos PN cacnon.

> fix those that have already been shipped.

Are the problems you ran into due to PN canon or are they due to the MS
authz data extensions? MS claims, in their docs, that what you tried
should have worked.

> It's extemely obvious for an AD-less W2K attached to a MIT Kerberos KDC.

I can't answer this without researching W2K. I do believe they can
handle hostbased service principals (e.g., host/fqdn@REALM).

> for fixes/workarounds even before W2K was offially released,

This must be a reference to the authz data extension.

> to an MIT Kerberos KDC run with the service principal sample/f.q.d.n.

I don't think this is related to Kerberos PN canon. And it's supposed to
work.

> and all GSS-API based applications with it.

No, in the case you describe it's MS breaking things, not Kerberos PN
canon.

> support it and that any implementation that doesn't is obviously

The current spec makes it optional. Putting it in a separate doc
wouldn't change that.

MS's implementation MAY indeed be broken... The Kerberos PN canon spec
is not.

This is politics. What you suggest won't achieve what you wish.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Feb 2001 20:47:24 +0100 (MET)

>    not input_name is subsequently released.

I would really appreciate if you would read *ALL* the relevant parts
in the spec before commenting.  The description in section
2.4.5 GSS_Import_Name() is particularly interesting.  The final
paragraph indicates when one could implement gss_canonicalize_name()
as a mere gss_duplicate_name() (not a no-op!).

> to indicate that the given input_name does not exist.

The correct major_status code for this situation in
gss_canonicalize_name() would be GSS_S_FAILURE, accompanied
by a meaningful mech-specific minor_status.

Your mileage may vary.

> implementation, then that must be an implementation error.

Don't jump that quickly.
Any mechanism spec is permitted to require validation of names.
Any mechanism with a spec that doesn't require or preclude validation
of names is free to do whichever it likes (provided that it is possible
at all).
rfc2743 explicitly states that creating a mechanism name (MN) can already
be done during gss_import_name().  Guess what effect this will have
on the complexity of the algorithm performed by gss_canonicalize_name().

The problem that I am talking about is maintenance/population of an ACL.
To create the identity lookup key for the ACL a portable GSS-API based
application has to do this sequence of calls:

   i_name_i       = gss_import_name(printable_name_1_supplied_by_admin);
   i_canon_name_i = gss_canonicalize_name( i_name_i, mechanism_1 );
   i_acl_key_i    = gss_export_name( i_canon_name_i );

Imagine the following scenario:
  initiator: 
     cred_i         = gss_acquire_cred(i_name_i, mechanism_1,INITIATE);
     a_name_i       = gss_import_name(printable_target_name);
     a_canon_name_i = gss_canonicalize_name(a_name_i, mechanism_1);
     a_acl_key_i    = gss_export_name(a_canon_name_i);
     ctx_i          = gss_init_sec_context(cred_i, a_name_i, MUTUAL_FLAG); 
     (i_name_iq, a_name_iq, x_mechanism) = gss_inquire_context(ctx_i);
     i_acl_key_iq   = gss_export_name(i_name_iq);
     a_acl_key_iq   = gss_export_name(a_name_iq);

  acceptor:
     i_name_a         = gss_import_name(printable_name_1_supplied_by_admin);
     i_canon_name_a   = gss_canonicalize_name(i_name_a, mechanism_1);
     i_acl_key_a      = gss_export_name(i_canon_name_a);
     a_name_a         = gss_import_name(printable_target_name);
     a_canon_name_a   = gss_canonicalize_name(a_name_a, mechanism_1);
     a_acl_key_a      = gss_export_name(a_canon_name_a);
     cred_a           = gss_acquire_cred(ACCEPT);
     (ctx_a,src_name) = gss_accept_sec_context(cred_a);
     (i_name_aq, a_name_aq, y_mechanism) = gss_inquire_context(ctx_a);
     i_acl_key_a_src  = gss_export_name(src_name);
     i_acl_key_aq     = gss_export_name(i_name_aq);
     a_acl_key_aq     = gss_export_name(a_name_aq);

For consistency GSS-API requires the following:

     memcmp(i_acl_key_i,i_acl_key_iq)   ==0
     memcmp(i_acl_key_i,i_acl_key_a)    ==0
     memcmp(i_acl_key_i,i_acl_key_a_src)==0
     memcmp(i_acl_key_i,i_acl_key_aq)   ==0

     memcmp(a_acl_key_i,a_acl_key_iq)   ==0
     memcmp(a_acl_key_i,a_acl_key_a)    ==0
     memcmp(a_acl_key_i,a_acl_key_aq)   ==0

Now tell me where can you squeeze in name canonicalization
so that it doesn't break any of the above requirements.

Are you really convinced that canonicalization can happen
and NOT get noticed by the application above GSS-API?

> "to canonicalize" in the GSS-API spec versus the Kerberos PN canon

We are talking about a transformation of an identity that will cause
us to authenticate an identity that has a different name from the
name that we started with.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 16:20:50 -0500

> > would be almost as trivial if multiple mechanisms were supported.

Notice I said, just above, that MIT's implementation copies the name,
but that's pretty close to a noop -- nothing terribly useful is done to
the name (i.e., no coversions, mapping, validation, nothing).

> as a mere gss_duplicate_name() (not a no-op!).

Shrug. The fact is, nowhere is is stated that GSS_Canonicalize_name()
validates the existence of a name.

> by a meaningful mech-specific minor_status.

Ok, I see that an implementation COULD support validation of names via
GSS_Canonicalize_name(), but my reading of the RFC is that this is not
expected and was not the function intended for GSS_Canonicalize_name().

> on the complexity of the algorithm performed by gss_canonicalize_name().

Ok, let's go through your example. And it's a very good example. This is
how we can put this controversy to rest.

Your variable names are confusing to me, so let me see if I get them
right:

 - a_*name* refer to target service principal names (a is for acceptor)
 - i_*name* refer to user principal names (i is for initiator)

 - tailing i is for names produced by administrator?

 - trailing iq is for inquire(_context)

>    i_acl_key_i    = gss_export_name( i_canon_name_i );

Here (above) let us assume that the administrator creating the ACLs
KNOWS the canonical principal names.

>      cred_i         = gss_acquire_cred(i_name_i, mechanism_1,INITIATE);

At this point, i_name_i should already be Kerberos canonicalized, since,
after all, gss_acquire_cred() depends on the credentials already being
available (there's no interface for promting a user for passwords, OTPs,
hw tokens, etc...).

If the [Kerberos] creds are available then their UPN, *by definition*
[of the Krb PN canon text] is *canonical*.

>      a_acl_key_iq   = gss_export_name(a_name_iq);

Here, a_name_iq may be different from a_name_i. That's the point of
gss_inquire_context()!

>      i_name_a         = gss_import_name(printable_name_1_supplied_by_admin);

Here, printable_name_1_supplied_by_admin, had better be canonical!

(Of course, we're talking about Kerberos, so by "canonical", in my
preceding sentence, I mean "exists" and "is not an alias").

Therefore i_name_a here MUST be the same as above, where the
administrator creates the ACL.

I.e., the admin had better be consistent.

>      a_name_a         = gss_import_name(printable_target_name);

What's the difference, here, between printable_target_name and
printable_name_1_supplied_by_admin?

>      (i_name_aq, a_name_aq, y_mechanism) = gss_inquire_context(ctx_a);

With Kerberos PN canon a_name_aq, here, should not differ from
a_canon_name_a. Nor should i_name_aq differ from src_name.

Kerberos PN canon is something that happens in AS exchanges for UPN
canonicalization, and TGS exchanges for SPN canonicalization. Thus, by
the time the initiator has the service ticket for the acceptor all PN
canonicalization has taken place.

Note that a_name_aq will NOT be the name that the initiator used for the
acceptor, but will be the same as a_acl_key_a. This is because by the
time the initiator started composing the GSS tokens to send to the
acceptor the acceptor's name has already been canonicalized.

>      memcmp(i_acl_key_i,i_acl_key_aq)   ==0

I believe the above equivalences remain true, even with Kerberos PN
canonicalization in the mix. See above.

>      memcmp(a_acl_key_i,a_acl_key_aq)   ==0

a_acl_key_i is computed on the client side only, right? Will the client
be evaluating ACLs? The first of those equivalencies need not be true

Regardless, a_acl_key_iq need not be the same as a_acl_key_i, BUT,
a_acl_key_iq will be equal to a_acl_key_aq.

So both, the initiator AND the acceptor will know each others canonical
names (in the Kerberos sense)

> so that it doesn't break any of the above requirements.

See above.

Kerberos UPN canon happens before the initiator acquires gss creds.

Kerberos SPN canon happens before the initiator sends the first
Kerberos mechanism token to the acceptor (though AFTER calling
gss_init_sec_context(), which is why the client MUST call
gss_inquire_context() to find the REAL target name).

> and NOT get noticed by the application above GSS-API?

No. I'm convinced that only the initiator is affected and that's only if
the initiator cares what the Kerberos canonical name of the acceptor is,
AND THEN the initiator can always call gss_inquire_context() to
determine the acceptor's Kerberos canonical name.

Are you not convinced of that now?

> name that we started with.

See above.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 15 Feb 2001 23:07:29 +0100 (MET)

> Your variable names are confusing to me, so let me see if I get them

Sorry, I should have included that explanation:

    a_  prefix means it identifies the acceptor 
    i_  prefix means it identifies the initiator
    _i  postfix means "as seen by initiator", an object the initiator holds
    _iq postfix means "as seen by initiator when queried from context"
    _a  postfix means "as seen by acceptor", an object that the acceptor holds
    _aq postfix means "as seen by acceptor when queried from context"

  sample:
    a_acl_key_iq   the identity of the acceptor represented as a binary
                   canonical name as seen by the initiator when queried
		   (inquired) from the established security context.

For completeness, I quote the full example again:

  acceptor:

> KNOWS the canonical principal names.

Invalid assumption.

This sequence of calls *MUST* always result in the exact same binary
canonical name for all of the possible syntaxes of a name whenever this
name is sufficient to any other gssapi call.

Actually, this single sentence is in essence the same as the above example.

> Here, a_name_iq may be different from a_name_i. That's the point of

No.  This is exactly *NOT* allowed.
The mechanism name (MN) that is the result of gss_canonicalize_name()
must be transformed exactly as if it was the result of an actual
security context establishment.  For mutual authentication, this
applies to both, the initiator and the acceptor name.

> printable_name_1_supplied_by_admin?

printable_target_name is the name of the acceptor (it's used as the
  target name parameter to gss_init_sec_context)

printable_name_1_supplied_by_admin is actually the name of the
initiator in the example (it's used to acquire the initiator credentials).

> be evaluating ACLs? The first of those equivalencies need not be true

GSS-API doesn't use the terms "client" and "server", because these are
misleading in the context of a distributed application.

Of course, the initiator may be matching the acceptors name against
an ACL, or it might have taken the name from an ACL, or it might have
pulled it from an existing established security context in order
to establish another parallel security context.  

Depending of the particular nature of the distributed application,
it may be possible that additional security contexts are established
by either one: initial initiator or initial acceptor -- depending on
whoever feels like needing a new security context.

Distributed applications may require significantly more consistency
than simple client-server applications.

Again, your mileage may vary.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 17:31:40 -0500

> 		   (inquired) from the established security context.

Thanks.

However, the names returned by gss_inquire_context() WILL MATCH THE
NAMES IN THE KERBEROS SERVICE TICKET.

How could that be otherwise. And as I stated before, by the time the
service ticket is obtained (in gss_init_sec_context()) ALL Kerberos
principal name canonicalization will have been done!

Thus the names returned by gss_inquire_context() on both sides MUST
agree.

Is this not true?

> > KNOWS the canonical principal names.

!!!

If that assumption is invalid then the example you give will break EVEN
in the absence of Kerberos PN canonicalization because the ACLs will be
wrong!!!

> name is sufficient to any other gssapi call.

I insist, the names that matter to the initiator and acceptor are the
names returned by gss_inquire_mech().

I insist, it is the repsonsibility of the administrator to make sure
valid, canonical PNs are used in ACLs and to ensure that these are
consistent with the users' and services' principal names.

Do you disagree?

> No.  This is exactly *NOT* allowed.

Let me see if I mixed up variable names... Hmmm...

This is on the initiator side. The initiator thinks the acceptor is
called a_name_i, then, after gss_init_sec_context() it calls
gss_inquire_context() to obtain the acceptor's name.

Why bother with gss_inquire_context if the acceptor's name cannot change
during gss_init_sec_context()?

This is the ONLY place where, in the Kerberos PN canon case, a name will
change as a result of PN canonicalization.

I think this is allowed and INTENDED by the GSS-API RFC.

You yourself have said you rely on this behaviour when the initiator
DOESN'T know the acceptor's name. What if the client knows an ALIAS of
the acceptor's name? Shouldn't it work then as well? I don't see why not!

> applies to both, the initiator and the acceptor name.

Quote the RFC please. gss_canonicalize_name() is definitely NOT required
to validate principal names. You said this yourself.

> initiator in the example (it's used to acquire the initiator credentials).

Why would the acceptor know printable_name_1_supplied_by_admin BEFORE
calling gss_accept_sec_context()??

Something is wrong with your example or you are confused about
printable_name_1_supplied_by_admin.

I took the two (printable_name_1_supplied_by_admin and
printable_target_name) as used on the acceptor side to be the same
thing; I thought you typoed. I still do.

> misleading in the context of a distributed application.

My bad. Initiator and acceptor.

> to establish another parallel security context.  

I see. Still, the initiator has the Kerberos canonicalized principal
names from gss_inquire_context(), thus it has the right names to use to
compare with names in ACLs.

Same for the acceptor.

> whoever feels like needing a new security context.

I understand, still, no problem there.

:)

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Feb 2001 00:32:05 +0100 (MET)

> Thus the names returned by gss_inquire_context() on both sides MUST

It is true ... but insufficient.
The transformations performed by gss_init_sec_context() and
gss_accept_sec_context() on the initiator and acceptor names
must be performed by gss_import_name()+gss_canonicalize_name().
gss_canonicalize_name() was invented for this particular reason.

> in the absence of Kerberos PN canonicalization because the ACLs will be

Huh?  Please elaborate.

> consistent with the users' and services' principal names.

Sure.

GSS-API doesn't discriminate names.  It doesn't put any burden or duties
on admins shoulders (I can't believe that I write this, it should be
so obvious).

The promise of GSS-API is that if a name is acceptable for the purpose
of authentication by any GSS-API call, then then the sequence of

   gss_import_name()+gss_canonicalize_name()+gss_export_name()

will convert it into a binary canonical representation that is constant
across time and locale and can be used to populate an ACL.  Every MN
(a canonicalized target_name for gss_init_sec_context(),
all src_name from gss_accept_sec_context() and both initiator_name
and acceptor_name from gss_inquire_context() can be directly compared
against such an ACL.

> during gss_init_sec_context()?

Correct.  The initiator doesn't ever need to call gss_inquire_context().
When a security context establishment completes successfully and
returns GSS_C_FLAG_MUTUAL, the client is guranteed that the identity
matches the name given as target name.

> I think this is allowed and INTENDED by the GSS-API RFC.

It is allowed, but *ONLY* when gss_init_sec_context() does *NOT*
return GSS_C_FLAG_MUTUAL, i.e. when gss_init_sec_context() indicates
that it has not authenticated the acceptor.

> the acceptor's name? Shouldn't it work then as well? I don't see why not!

The change that I requested for GSS-API v2 was that an initiator
should not be required to unconditionally supply a target name to
gss_init_sec_context() to "legalize" the following scenarios:

- unidirectional authentication scheme (like Microsoft's NTLM SSP),
  which can not authenticate the acceptor -- any target name supplied by
  the initiator to gss_init_sec_context() will be ignored by the mechanism
- initiator doesn't know or care about the identity of the acceptor
  and will be unable to perform mutual authentication
- HTTPS-style authentication where you don't know the acceptor a-priori,
  but the acceptor's identity will become available during context
  establishment.
- An initiator that wants to connect to an arbitrary instance of a
  distributed service and doesn't know a-priori which particular
  instance he will talk to.  Why not give the initiator the option
  to verify the resulting acceptor against an initiator-side ACL

> to validate principal names. You said this yourself.

I don't understand why you think that, in order to gurantee the same
transformation as gss_init_sec_context() and gss_accept_sec_context(),
gss_canonicalize_name() would be *required* to perform a validation?

What is true, is that when TGS_REQ or AS_REQ piggy-backed canonicalizations
are allowed for Kerberos, that in order to make gss_canonicalize_name()
work, the same lookup must be implemented in an out-of-band fashion.  
This is the what this whole discussion is about.

I mentioned it before: for directory-free X.509-based SPKM-like
gssapi mechanism there is no such thing as known set of identities.
which is why GSS-API does not offer an API to enumerate valid identities.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Feb 2001 00:51:08 +0100 (MET)

Ken Raeburn wrote:
> > Silence is not always consensus.

Silence often happens when the discussion proves fruitless and
the priorities of real life or work reclaim their attention.

>
> > I think the AS issues will only be resolved by an

Although I really like going to IETFs, my employer currently has other
priorities for me and will not cover my costs.  Already for the Pittsburgh
IETF I paid the airfare on my own.

Phone-conference is doable (although I may need to negotiate with my
wife if I have to stay in the office late into evening or night.
I got an upset homing call some minutes ago, it's 00:45 right now).  :-o

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 15 Feb 2001 18:42:15 -0500

> gss_canonicalize_name() was invented for this particular reason.

The spec does NOT say this. Quote RFC text please.

> > in the absence of Kerberos PN canonicalization because the ACLs will be

I assumed the admin would be consistent. If he wasn't there'd be no
guaarantee that the ACLs would be correct regardless of wether Kerberos
PN canon was involved.

> > names returned by gss_inquire_mech().

Ooops, I meant gss_inquire_context()! Sorry, typo.

> > consistent with the users' and services' principal names.

With which of those two statements?

Is it ok for gss_inquire_context() to return different names to the
initiator and acceptor for the same context??

Is it ok for the admin to be inconsistent with names??

> on admins shoulders (I can't believe that I write this, it should be

There's no requirement to use the correct service names?!?!

Or am I mis-reading your response?

> and acceptor_name from gss_inquire_context() can be directly compared

There's no promise that
gss_import_name()+gss_canonicalize_name()+gss_export_name() will name an
existing account if the input to gss_import_name() did not name an
existing account.

Show me where the RFC says otherwise.

> matches the name given as target name.

I think you've said otherwise before. What about when the initiator
doesn't know the target's name???

> that it has not authenticated the acceptor.

What good is knowing the target's name if it wasn't authenticated?

You must have it backwards.

>   but the acceptor's identity will become available during context

Thus you have a situation where the target's name changes during context
establishment!  Thus gss_inquire_context(), so the initiator should use
it.

>   to verify the resulting acceptor against an initiator-side ACL

Sure, it can "verify the resulting acceptor" using the name returned by
gss_inquire_context().

For God's sake, read what I'm writing.

> gss_canonicalize_name() would be *required* to perform a validation?

I must go back and read the RFC, but I believe there is no such
guarantee.

> This is the what this whole discussion is about.

See above and previous mails.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 16 Feb 2001 01:47:13 +0100 (MET)

> The spec does NOT say this. Quote RFC text please.

The spec does may not necessarily say it in an explicit small number of
words.  It is a consistency requirement for the spec as a whole,
it was the consensus of the CAT working group discussion that lead
to the addition of gss_canonicalize_name().  The discussion was
*quite* long, you can look it up in the archives.  I think to remember
that Denis Pinkas was also very slow in following the concept, and
during the discussion Ted Ts'o came up with a diagram (on 05-Jan-1996)
that contained the different types of internal names that GSS-API
knows about -- this diagram was added to Section 1.1.5 Naming of rfc2743:

                        GSS-API library defaults
                               |
                               |
                               V                         text, for
   text -------------->  internal_name (IN) -----------> display only
         import_name()          /          display_name()
                               /
                              /
                             /
    accept_sec_context()    /
          |                /
          |               /
          |              /  canonicalize_name()
          |             /
          |            /
          |           /
          |          /
          |         /
          |        |
          V        V     <---------------------
    single mechanism        import_name()         exported name: flat
    internal_name (MN)                            binary "blob" usable
                         ---------------------->  for access control
                            export_name()

Looking at it now I realize that it is incomplete in that it only
mentions the transformation of accept_sec_context() and unintentionally lacks
to list the transformation of init_sec_context() for mutual authentication.
The consensus was that gss_canonicalize_name() would perform all the
same transformations that an authentication during a real context
establishment would perform, but outside of an actual context establishment.
Add this omission to the defect list of rfc2743 if you want.

> guaarantee that the ACLs would be correct regardless of wether Kerberos

The admin can not be inconsistent.
The admin is either ambigous (in which case the gssapi mechanism should
reject the name) or wrong.

A particular gssapi mechanism (implementation) may be inconsistent
on the transformation of names.

> initiator and acceptor for the same context??

No, that is unacceptable.

> Is it ok for the admin to be inconsistent with names??

see above.

> Or am I mis-reading your response?

There is *NO* requirements on the input to gss_import_name() when
the admin populates ACLs.  Or did you see one?

> Show me where the RFC says otherwise.

With this reasoning it would be impossible to populate ACLs with
a directory-free X.509-based SPKM-like gssapi mechanism that is
unable to enumerate its users.  Show me where rfc2743 says that
gss_canonicalize_name() will not work with mechanisms that can not
enumerate users.

If gss_import_name()+gss_canonicalize_name()+gss_export_name()
creates a binary canonical name even though no such user currently
exists, then for consistency the gssapi mechanism is required
that if such a user is ever created it *MUST* match that name.

When a gssapi mechanism wants to allow canonicalization,
it will definitely have to perform this canonicalization anywhere
during gss_import_name()+gss_canonicalize_name()+gss_export_name()
and this probably means that it will have to validate the account.

It is as simple as that.

For the proposed name canonicalization this means that it would have
to be augmented to include an out-of-band canonicalization that
could be used within gss_canonicalize_name() in order to a remain
a well-behaved and compliant gssapi mechanism.  Architecturally
it looks like the *wrong* approach to me to piggy-back the name-service
onto the ticket exchange.

> doesn't know the target's name???

Then the initiator will probably be unable to authenticate the target.
With gss-api v1 mechanisms and with rfc1964-compliant Kerberos gssapi
mechanisms the initiator will simple loose if it doesn't provide
a target name to gss_init_sec_context(), no matter whether this name
gets actually used.  It is explicitly mentioned in rfc2743 that
many existing gssapi mechanism will require a target name even
for unidirectional authentication and fail if no name is supplied.

> What good is knowing the target's name if it wasn't authenticated?

Oh, it can be put to several uses.

Ask the Browser guys that play pattern matching games with the
CN= part of the subject DN of an X.509 certificate.

Bootstrapping SSH hostkeys is often done in such an insecure fashion
(I admit to have done it).

Even when not authenticated, it may still be cryptographically protected.

> establishment!  Thus gss_inquire_context(), so the initiator should use

Nope, it doesn't change.  There was no name to begin with.
I'm repeating myself: this exception is explicit in rfc2743 upon my request.

> For God's sake, read what I'm writing.

For God's sake, this is only allowed when *NOT* providing a target name to
gss_init_sec_context(), in which case there is no change from one
identity to another.  GSS-API v2 still covers all GSS-API v1 mechanisms
and those mechanism are not allowed such behaviour -- they have to fail
when passing a target_name of GSS_C_NO_NAME to gss_init_sec_context()
and do not allow the initiator to ACL-lookup the acceptor only after
security context establishment.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 16 Feb 2001 11:11:09 -0500

> knows about -- this diagram was added to Section 1.1.5 Naming of rfc2743:

I don't know how to answer this. First you claim that an initiator need
not know the acceptor's name, then you claim that the acceptor name
returned to the initiator by gss_inquire_context() must be the same the
client fed to gss_init_sec_context().

And that's my whole point: that gss_inquire_context() CAN return, to
the initiator, a different acceptor name than the initiator fed to
gss_init_sec_context().

THIS is the only possible consequence, for GSS-API, of Kerberos service
principal name canonicalization.

Kerberos user principal name canonicalization cannot affect GSS-API
because by the time an initiator starts its UPN will have been
canonicalized already and the initiator can and should know its canon
name.

[pretty picture with no bearing to the statements above removed.]
> Add this omission to the defect list of rfc2743 if you want.

Bzzzt. Wrong. The RFC says what it says. You're inventing semantics not
there and claiming they ought to be there.

> reject the name) or wrong.

Thank you. Thus admins can be relied on to feed only canonical principal
names to gss_import_name() as part of their ACL maintenance.

My point exactly.

Initiators determine canonical service (acceptor) principal names by
calling gss_inquire_context() after calling gss_init_sec_context().

All is consistent.

> on the transformation of names.

Just two days ago you agreed that there is no requirement that
gss_canonicalize_name() validate principal names' existence but
disagreed with me and said it was OK to implement a
gss_canonicalize_name() that does.

Now you say that gss_canonicalize_name() MUST validate principal names'
existence.

What gives?

> No, that is unacceptable.

Thank you. I was making a point. Namely that after calling
gss_inquire_context() the acceptor and the initiator will know each
other's and their own names.

Clearly, the purpose of gss_inquire_context() is to allow for principal
names to change during gss_init_sec_context()/gss_accept_sec_context().

> > Is it ok for the admin to be inconsistent with names??

Thank you. I was making a point. Namely that admins should feed only
canonical principal names to gss_import_name()/gss_canonicalize_name()/
gss_export_name() when using those functions to build name blobss for
use in ACLs.

Since acceptors and initiators can determine each other's and their own
names via gss_inquire_context() those names will match their mentions in
ACLs built by administrators who were consistent.

> the admin populates ACLs.  Or did you see one?

I see you claim that:

gss_import_name()+gss_canonicalize_name() == name returned by
gss_inquire_context()

Clearly, I disagree.

> gss_canonicalize_name() will not work with mechanisms that can not

Sure you can: you, the admin, get a list of all the valid principal
names and go from there, feeding them to
gss_import_name()+gss_canonicalize_name()+gss_export_name() as you go.

The mechanism for obtaining such a list is not relevant to GSS-API since
GSS-API, correctly, does not provide an API for enumerating valid entity
names in realms.

> that if such a user is ever created it *MUST* match that name.

It's the responsibility of the admin to feed canonical Kerberos
principal names to gss_import_name(). The user doesn't have to do the
same because the user (initiator) calls gss_init_sec_context() and THAT
will canonicalize the name the user used.

Remember, the verb "to canonicalize" has different meaning in GSS than
in Kerberos.

We've already seen that Kerberos GSS mechs do nothing to the name passed
in to gss_canonicalize_name() other than to copy it and strip the names
belonging to other mechanisms.

So having Kerberos libraries and KDCs that support Kerberos principal
name aliases (canonicalization) cannot have an impact on those Kerberos
GSS mech implementations!!

Or am I missing something here?

> and this probably means that it will have to validate the account.

But you've said this is not a requirement. Clearly the RFC does not
require this and clearly existing Kerberos GSS mech implementations do
not do this.

> It is as simple as that.

Please read all of what I write in this post. If you still disagree with
my point that Kerberos PN canon should not adversely affect GSS-API then
I'll give up and shut up.

> onto the ticket exchange.

No, it does not mean that any such OOB canon channel would be needed.
Existing Kerberos GSS mech implementations don't validate the existence
of principal names in gss_canonicalize_name().

Do you understand Kerberos principal name canonicalization? Have you
read the revisions?

...
> for unidirectional authentication and fail if no name is supplied.

I'm talking about GSS-API v2. I've quoted text from RFC2743.

Please, let's keep the discussion to GSS-API v2. v1 is obsolete.

> I'm repeating myself: this exception is explicit in rfc2743 upon my request.

That's a CHANGE: null name -> known name.

> security context establishment.

Quote the text please.

Here's my contention: fix the MIT, say, Kerberos v5 client libraries to
support Kerberos PN canon and all existing MIT GSS-API apps that call
gss_inquire_context() after gss_init_sec_context()/
gss_inaccept_sec_context() will still work no problem.

Modulo inane bugs in MIT code, of course.

Nico
--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 16 Feb 2001 11:34:44 -0600

Martin, 
It would benefit us all if you could attend the next IETF. Is there
any thing I could do to convince your employer to send you?
I am willing to write e-mail or a letter, stating this.
Sorry, I don't have any money.

--

---

From: [email-masked]
Date: Sat, 17 Feb 2001 16:37:04 -0500

Not everyone seems to understand what gss_cannonicalize_name() is
supposed to be doing, and this seems to be confusing the discussion.
Arguably, it's misnamed; its function is quite different from the
Kerberos principal name cannonicalization proposal.

gss_cannonicalize_name() grew out of the mess of trying to support
multiple mechanism names.  For example, suppose you do an
gss_import_name() of the ascii string "tytso", type "USERNAME".  This
might result (in a multi-mechanism system) in a gss_name which contains
the the combined bundle:

	"[email-masked]", type KRB5_PRINCIPAL 

	"/C=United States/SP=Massachusetts/OU=Massachusetts Institute of
	Technology/CN=Theodore Yue Tak Ts'o/EM=[email-masked]", type
	X509_NAME

If you use gss_export() on the above name, you'll get both internal
names.  gss_canoncalize_name() is a function which allows you to take a
compound name and select a specific mechanism specific name.  

Think of it as "collapsing the wave function; just as you're trying to
answer the question, is the photon acting as particle or a wave",
gss_canoncalize_name() is trying to answer the question "is this name a
Krb5 name or a X.509 name".  

This is especially important if you're trying to use gss_export_name()
and gss_import_nane() to implement access control lists, or use the
name returned from gss_accept_sec_context() as a lookup in a database
table.

This is then completely unrelated to the Krb5 question of trying to take
some name such as "imap/tytso", and expect it to be canoncalized to a
service principal name such as "imap/[email-masked]".

However, there is a GSSAPI question hidden with the krb5
canonicalization issue, which is that if you do a gss_import() of
something like "imap/tytso", and then do a gss_display_name(), what do
you get?  If the answer is something like
"imap/[email-masked]", then you need some way of
canonicalizing a name without necessarily doing a Kerberos
authentication exchange.  Of course, if you have a TGT, you can do this
by requesting a Krb5 ticket with the CANONICALIZE_NAME bit set.  It's
somewhat wasteful, since we're asking the KDC to generate a ticket that
may never get used.  So this may mean that it would be nice to have a
new protocol exchange which only does the secure name canonicalization,
and doesn't ask the KDC to create a ticket if it's not going to be
needed.

						- Ted

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Feb 2001 19:34:51 +0100 (MET)

> name returned from gss_accept_sec_context() as a lookup in a database

I would like to complete the picture from the discussion that happened
when gss_canonicalize_name() was invented.

gss_canonicalize_name() was _not_only_ invented to cover multi-mechanisms;
it was invented to give access to the mechanism selection *AND* name
transformation that happens during security context establishment
and results in the src_name emitted from gss_accept_sec_context().
The name transformation within gss_accept_sec_context() was clearly
addressed in the discussion and that's probably why you included it in
your diagram (now in 1.1.5 rfc2743) in the reply to Denis Pinkas.

What was not seperately discussed is the transformation of the target_name
input parameter to gss_init_sec_context() when the application requests
mutual authentication.  However when the concept to distinguish different
kinds of internal names, only *TWO* forms of internal names were
conceived: genernal internal names and mechanism-specific internal names

What GSS-API does *NOT* provide is a distinction between:

(1) internal names that can be used for authentication and
    fed to gss_canonicalize_name()+gss_export_name() to enable
    ACL-lookup for the application

(2) internal names that can be used for authentication (target_name
    parameter for gss_init_sec_context() with MUTUAL_AUTH) but
    not fed to gss_canonicalize_name()+gss_export_name() to enable
    ACL-lookup for the application

Although rfc2743 might not explicitly document each and every requirement
from gss_canonicalize_name() on the name transformations within
gss_init_sec_context() and gss_accept_sec_context(), but these
requirements are implicit for the consistency of the GSS-API
architecture and will become apparent when combining common sense
with GSS-API implementation experience.

> service principal name such as "imap/[email-masked]".

It remains unrelated only to the point where the GSS-API service
"authentication" is affected.  For unidirectional authentication of
the initiator to the acceptor it doesn't matter what the GSS-API
mechanism does with the target_name parameter passed to
gss_init_sec_context(), that is true.

But when the name transformation does in fact change an *authenticated*
identity at the GSS-API, then this transformation suddenly becomes *VERY*
relevant for the authentication service at the GSS-API level, because
this transformation will have to be available for gss_compare_name()
from GSS-API v1 as well as for the binary comparison of exported
canonical names in GSS-API v2.

> and doesn't ask the KDC to create a ticket if it's not going to be

What do you think that gss_display_name() should output for a
multi-element name from your example above?  If the multi-element
name was created by a call to gss_import_name() there would be
an obvious solution, but what if the name is the result from
gss_inquire_cred() on the default credentials?  ;-)

For gssapi single-mechanisms it is an implementation issue whether
a name in canonicalized immediately during gss_import_name() or
gss_canonicalize_name().  The only canonicalization that MIT
Kerberos 1.0 knows about is "hostname canonicalization" of
the hostname part of a hostbased service name.  This is done
locally on every machine via insecure DNS resolution (forward resolution!)
(an insecure practice that rfc2743 actually suggests to do for
 hostbased service names) and always during gss_import_name().

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 19 Feb 2001 21:41:03 +0100 (MET)

> That's a CHANGE: null name -> known name.

Use some common sense, please.

There is no such thing as an identity change when you pass GSS_C_NO_NAME
instead of a target name to gss_init_sec_context() because GSS_C_NO_NAME
is not a valid name.  Trying to feed GSS_C_NO_NAME to gss_compare_name(),
gss_canonicalize_name() or gss_export_name() will result in undefined
behaviour, therefore I didn't address these situations.

If a clerk in the office picks up the phone and answers
"Hello, this is company-so-and-so, how can I help you?"
and the voice at the other end responds "Hi, I'm Mr. Miller,
and I'd like to ..."
would you claim that by saying his name the caller changed
his name?  Well I don't -- and I hope that the others on the
list don't mind me for using common sense.

> the initiator, a different acceptor name than the initiator fed to

Under the common sense assumption, NO it can NOT.

> canonicalized already and the initiator can and should know its canon

Kerberos implementations are not required to, but they are allowed to
create credentials on the fly during gss_acquire_cred().

It would actually be useful if Kerberos would do this for
gss_acquire_cred(INITIATE) if the secret for the requested name is available
in a keytab, because the admin will no longer have to configure a cron-job
to repeatedly call "kinit -k" to provide initiating credentials to a
distributed service that needs them.

> there and claiming they ought to be there.

Pardon me, but this is silly.
Yes, I am claiming that the document could include more descriptions
and more examples to make things clearer for people who were not
present when the standard was developed.  This can probably be said
of all the standards in the IETF.

We are not at law school here.  The IETF makes standards, and most if not
all of the documents contain typos, errors and omissions.  This does not
invalidate them or suggest that everybody should go and bend the
idea as much as possible and each one in another direction.  Otherwise
there it will be impossible to make successor standards because it
will be impossible to add features without breaking at least some
of the existing implementations.

GSS-API v2 is an extension to GSS-API v1 and I'm convinced that the
v2 spec does *NOT* invalidate and v1 implemenation that didn't bend
the spec.

> ACLs built by administrators who were consistent.

Bullshit.

The admin can use whatever name he prefers or feels like
and gss_import_name()+gss_canonicalize_name()+gss_export_name()
will take care of creating a correct ACL entry from that input.

Which part of rfc2743/2744 did suggest to you that one must be very
careful in feeding gss_canonicalize_name() when maintaining ACLs?
If I ever find the time to write a BCP on GSS-API, I might need
to address pitfalls of this size.

> Now you say that gss_canonicalize_name() MUST validate principal names'

You seem to have problems in understanding what constraints the abstract
functional service-oriented specification of GSS-API will have on a concrete
specification or implementation of a GSS-API mechanism, as well as which
changes of the characteristics of a mechanism will require other changes
for consistency.

Insufficient examples and insufficient description of the architecture
in rfc2743 and rfc2744 might be one reason for that.

> gss_import_name()+gss_canonicalize_name()+gss_export_name() as you go.

Wow, you seem to be a mighty wizard!

Please enlighten us all with an algorithm to quickly enumerate through
*all* the certificates that were issued by every single CA in the
list of >100 CAs shipping with Microsoft Internet Explorer 5.0sp1.
(For simplicity, let's ignore that a real world admin might not
 able to handle the size of a full and correct response...)

> I'll give up and shut up.

I still disagree.

> Do you understand Kerberos principal name canonicalization? Have you

I have read the parts that Chris sent to the ietf-krb-wg list.

I'm not a Kerberos guru, but I do understand that it will result in
a different principal name being authenticated than the name that
was requested, and when this same transformation is not available
at the GSS-API for ACL maintenance, then the resulting Kerberos
mechanism will be broken, and portable gssapi-based distributed
applications may have severe problems using such a Kerberos.

That is the current situation with W2K-Kerberos, for which I
have built a gssapi wrapper.

> Please, let's keep the discussion to GSS-API v2. v1 is obsolete.

Not quite.  v1 gssapi mechanisms are fully covered and supported
by the GSS-API v2 spec.

> gss_inaccept_sec_context() will still work no problem.

One of the reasons why the discussion of kerberos revisions has been
taking so long is because people are trying hard not to break the
installed base.

Telling someone to fix his installed base means that you don't care for
his installed base.  I strongly hope that you will not get rough
consensus for purposely breaking installed base in this working group.

Now the interesting thing here is the following:
There is an installed Kerberos 5 base.  Microsoft has built a version
of Kerberos that has interoperability issues with the installed
Kerberos 5 base, and one of the issues is name canonicalization.

The IETF doesn't do voting to prevent vendors from "staffing" ballots
to their advantage.  I think it's similarily unethical for a vendor
to create a installed base with an on-purpose interoperability
problem and use the size of his installed base in trying to
coerce the decision which part of the installed base will be
blessed by the standard and which part needs to be fixed.

In the Kerberos 5 case, as there is a predecessor standard,
the answer to the question which part of the installed base
is broken concerning name canonicalization should be clear:
MIT Kerberos and related implementations have done quite
well for years without it.  DCE showed clean solutions
how to solve at least server name canonicalization.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 Feb 2001 11:22:50 -0500

Thank you! You have explained this more clearly than I, but I would like
to answer your concern about gss_display_name(). Inline.

On Sat, Feb 17, 2001 at 04:37:04PM -0500, [email-masked] wrote:

...

> service principal name such as "imap/[email-masked]".

Yes, my point exactly.

> you get?

You should get the same thing you would get today.

IMHO, the only impact of _Kerberos_ name canonicalization on GSS-API is
this: that the target name given to gss_init_sec_context() MAY change
during session setup IFF the Kerberos V gss mechanism requests Kerberos
SPN canonicalization, thus initiators MUST call gss_inquire_context()
after the context is established, to determine the target's real name,
but only if the initiator cares.

Note that Kerberos UPN canonicalization has noeffect on GSS-API as
GSS-API provides no appropriate API for obtaining initial credentials
(i.e., there is no prompter function interface!) and so credentials must
be cached and available (or keytabs must be available) when a GSS-API
initiator starts.

>           If the answer is something like

This would be a way of implementing a gss_display_name() which
canonicalizes, but I propose it not be done. gss_display_name() should
produce the human readable form of a GSS name without causing any
network traffic. The GSS-API function that can perform Kerberos SPN
canonicalization is gss_init_sec_context().

An ugly, but IMHO better alternative for access Kerberos SPN
canonicalization via GSS-API would be to call gss_init_sec_context() and
not bother completing the context (exchanging tokens), instead calling
gss_inquire_context() immediately to obtain the canonicalized SPN.

Granted, this is very mechanism specific. But canonicalizing Kerberos
names is obviously a Kerberos-specific proposition, so administrators
looking to create ACL lists and so on can use other mechanisms to obtain
canonicalized, valid principal names for a given realm (kadmin, LDAP,
etc...).

Admins already have a need for enumeration functionality and this
clearly cannot be done, either with GSS-API nor with AS/TGS Kerberos
exchanges.

I mentioned this last item before to make my point that: administrators
should not expect GSS-API to provide all the tools they need to maintain
GSS-API name based ACLs. Instead they should obtain lists of valid,
canonical Kerberos principal names and feed *those* to
gss_import_name()/gss_canonicalize_name()/gss_export_name().

> 						- Ted

Thanks again,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 Feb 2001 12:33:00 -0500

> clearly cannot be done, either with GSS-API nor with AS/TGS Kerberos

Not only enumeration but search functionality as well. Clearly that is
not provided by GSS-API. All Kerberos implementations to date DO indeed
provide enumeration and/or search functionality via OOB protocols
(kadmin, LDAP, etc...).

I wanted to note this because Martin Rex laughs at the notion of
enumerating users in a huge multi-realm system. He's right, but searches
have to be supported when enumeration is not available, else how do you
administer the system?!.

Responding to myself,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 Feb 2001 12:27:51 -0500

> Use some common sense, please.

See below.

> list don't mind me for using common sense.

Clearly you misunderstood how Kerberos name canonicalization works.

Here's your metaphor adapted to how Kerberos name canonicalization:

Caller: <calls directory service> "What is the 800 phone number for ACME?"
Answer: "ACME has changed its name to 'The Company Formerly Known as ACME'
	you can reach 'The Company Formerly Known as ACME' at
	1-800-TCFK-ACME"
Caller: <calls 1-800-TCFK-ACME>
Answer: "Hello! Welcome to 'The Company Formerly Known as ACME', if you
        have a touch tone phone, please enter your account number
	followed by a # now"
Caller: <dials account number#>
Answer: "what's your mother's maiden name?"
Caller: <says mother's maiden name>

Authentication complete. Note how name canonicalization happened at the
directory. That's how it works in Kerberos.

> Under the common sense assumption, NO it can NOT.

See above. Happens every day in the scenario I give...

> create credentials on the fly during gss_acquire_cred().

This only works when keytabs are available, in which case the
application had better know it's correct non-alias (canonical) name.

GSS-API does not have a prompter interface, therefore it is hard for
gss_acquire_cred() to obtain initial Kerberos credentials in the
absence of valid keytabs.

> distributed service that needs them.

There's no reason it can't be done.

IMHO, GSS-API should provide a prompter interface.

> of all the standards in the IETF.

But here we are today trying to interpret the RFC. I quoted the
definition of gss_canonicalize_name() and showed that it is NOT
required that mechanisms validate that the given name is not an alias,
that it exists, and so on and so forth, AND YOU AGREED. Now you're
claiming things not in the text.

How are the rest of us to read the RFC then if you're not at our side
to tell us about all the things you did not write in the RFC?!?!?!?!?!

I give up.

> of the existing implementations.

Of course, but you're definitely claiming things of significant
importance, not typos or simple errors, but significant deviations from
what is in the RFC. Where do we draw the line??

> v2 spec does *NOT* invalidate and v1 implemenation that didn't bend

My searches on the IETF RFCs indicate that the newer RFCs on GSS-API
have obsoleted the older ones. I'll read the text of the RFCs in
question, but you please note that Kerberos name canonicalization being
OPTIONAL there is no impact on existing v1 applications and existing
Kerberos GSS mechanisms (see other post from me with more details).

> will take care of creating a correct ACL entry from that input.

And what if the admin provides a name that is NOT valid, i.e., DOES NOT
EXIST IN HER KDC?

How can gss_import_name()+gss_canonicalize_name()+gss_export_name()
possibly GUESS what the admin must have meant?

The admin MUST know the correct names damn it!

If you still disagree I give up. Some might like to accept your
suggestion that an admin need not know what they are doing, but I
cannot accept that.

> to address pitfalls of this size.

"Common sense." See above. Admins MUST know SOME things, at least the
names of their users.

> Wow, you seem to be a mighty wizard!

No, I have been an administrator.

>  able to handle the size of a full and correct response...)

The subject here was Kerberos name canonicalization. Not PKI.

Have you EVER created ACLs referencing ALL the names in certificates
issued by all the CAs and their sub-delegations and so on and so
forth???

I didn't think so.

You must know WHO you want to give access to WHAT before you grant such
access by creating an appropriate ACL.

> > I'll give up and shut up.

See above. I give up.

> applications may have severe problems using such a Kerberos.

See all my other posts.

 - only target names change and only on the initiator side
 - GSS-API has an API for obtaining the changed target name
   (gss_inquire_context())
 - GSS-API apps can determine all the authenticated names in GSS
   security contexts, the names to check against ACLs
 - admins must know non-alias valid names to put in ACLs
 - Kerberos principal name canonicalization is OPTIONAL, as in the
   client need not request it, in which case the client MUST know
   non-alias names, which is HOW IT IS TODAY!!! And also how it could
   stay (i.e., GSS-API v2 Kerberos mechanisms could continue to not
   request canonicalization from the KDC).

> have built a gssapi wrapper.

Please answer John Brezak's questions and work out your problems with
him. I have seen posts on the [email-masked] list about getting FTP
with GSS authentication going between W2K and MIT and the only problem
was that MS chose not to implement channel bindings which MIT chose to
require; I think they got it working. And I've seen the MS docs; they
claim what you couldn't get to work works. So you go figure out what
you're doing wrong and stop blaming that which cannot be at fault
(Kerberos name canon).

How can I know that Kerberos name canon could not be at fault in the
problem you described with an MIT initiator, and MS acceptor and an MIT
KDC? Because: a) your KDC had no support for Kerberos name canon, b)
your initiator had no support for Kerberos name canon, c) Kerberos name
canon affects only the initiator and the KDC -- the acceptor sees only
that canonicalization was requested and performed, but nothing else.

This is pointless. I stop my reply here.

> -Martin

Cheers,

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 Feb 2001 11:53:19 -0500

> your diagram (now in 1.1.5 rfc2743) in the reply to Denis Pinkas.

Hold on. I have an email from you to this list from much earlier in this
thread when you claim that mechanisms are NOT required to but are FREE
to perform transformations on names when their gss_canonicalize_name()
method is called and that those transformations may include but are not
required to include name existence validation.

Clearly, existing Kerberos mechanism implementations of
gss_canonicalize_name() for GSS-API do NOT validate principal names,
they just strip out other mechanism's names. So if you feed a Kerberos
principal name which does not exist to gss_import_name() (maybe you
typoed, say), then the output of gss_canonicalize_name() will also
reference a non-existent principal name.

So, clearly, it would be ok to continue to implement Kerberos mechanism
gss_canonicalize_name() methods that way, even in the face of Kerberos
principal name canonicalization. After all, the garbage-in, garbage-out
nature of existing implementations' gss_import_name()/
gss_canonicalize_name() would be preserved.

>     ACL-lookup for the application

As long as applications DO have a way to obtain type (1) names and as
long as administrators maintain ACLs consistently there is no problem.
And guess what? GSS-API DOES provide a way for applications to obtain
type (1) names even in the face of Kerberos name canonicalization, it's
called GSS_INQUIRE_CONTEXT() (minus capitalization :).

> gss_init_sec_context(), that is true.

And for mutual authentication it is still OK for the target name given
to gss_init_sec_context() to change, as long as mutual authentication is
performed AND as long as the client obtains the authenticated target
name via GSS_INQUIRE_CONTEXT() ALL IS OK.

See above.

I don't think obsoleted data/apps need to be supported forever. Kerberos
V does not directly support obsolete Kerberos IV applications. Similarly
with GSS-API v2 and v1.

In any case, the v2 vs. v1 problem is easy to solve:

 - always setup ACLs with canonical (Kerberos sense) names only.

   It makes no sense to reference non-existent names in ACLs and it
   makes no sense to reference alias names in ACLs since alias names are
   will not be present in Kerberos tickets, thus GSS-API apps will not
   see alias names in gss_inquire_context or gss_accept_sec_context().

   So this point has to be true already everywhere and ACLs that
   reference non-existent or alias names are already being ignored.

 - Kerberos GSS mechanisms for GSS-API v1 MUST NOT request
   canonicalization when requesting tickets.

   Note that existing Kerberos GSS mechanisms for GSS-API (v1 or v2)
   already DO NOT request Kerberos name canonicalization when requesting
   tickets.

Thus NO IMPACT.

Of course, when not requesting Kerberos name canonicalization,
clients/initiators must use canonical names, meaning the user must know
and use non-alias names. Users already have this requirement now.

> gss_inquire_cred() on the default credentials?  ;-)

What then? Default credentials must already be canonical, at least in
the proposed Kerberos name canonicalization system.

>  hostbased service names) and always during gss_import_name().

Interesting. This can be done still with no changes even if in
gss_init_sec_context() Kerberos mechanisms actually request name
canonicalization by the KDC. No impact.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Feb 2001 19:27:19 +0100 (MET)

> have to be supported when enumeration is not available, else how do you

In the IETF tradition, here you find a list of running code:
"http://www.sap.com./solutions/compsoft/cspdirectory/products/certify/secunet.asp?DescID=129&ProdDesc=Network+Security"

The software products listed there interoperate with our distributed
application based on the GSS-API v2 interface.  All of these products
implement consistent authentication of communication peers (initiators
and acceptors), and that includes two Kerberos implementations.
(btw. only the two Kerberos products implement hostbased service names).

Since I settled on the robust GSS-API v2 specification, I never
had to adapt our application code to any of these products.  This 
is what GSS-API calls "portable applications".  The proposed
name canonicalization will break exactly this portability model
of GSS-API.

-Martin

PS: I'm tired of this discussion.  I will restrict my replies
    to messages with real content now.

---

From: Martin Rex <[email-masked]>
Date: Tue, 20 Feb 2001 20:27:33 +0100 (MET)

> Clearly you misunderstood how Kerberos name canonicalization works.

Well, see for yourself.  I think that the current proposal would
be something like automatic call forwarding at the destination
in a non-obvious fashion for the caller.  If the caller would get
the number of the forwarded target displayed on his phone, he might
become suspicous, hang up the phone and start investigating before
telling passwords over the line!

> Caller: <says mother's maiden name>

Thank you, that is a great example!

It matches exactly the requirements that I mentioned for how a
name service should be designed so that an abstract GSS-API extension
could be built 

The first call to the directory is in fact *out-of-band*, and the
caller receives (a) name canonicalization and (b) information how
to connect to the service.

At some *unspecified* later point in time, the caller *may* use this
information to actually call the (canonical) service.

The information from the directory is available for *everyone*, no matter
whether they're actual clients of the service and have an account
and no matter whether they have an intention of actually talking
to the service.

> directory. That's how it works in Kerberos.

RFC-1510 didn't have it, and you obviously haven't understood the
proposal that is on the table.

> have obsoleted the older ones.

While it is true that the document was obsoleted, the standard is not.

Quoting from Appendix B of rfc2743:

   APPENDIX B

   COMPATIBILITY WITH GSS-V1

      It is the intent of this document to define an interface and
      procedures which preserve compatibility between GSS-V1 [RFC-1508]
      callers and GSS-V2 providers.  All calls defined in GSS-V1 are
      preserved, and it has been a goal that GSS-V1 callers should be able
      to operate atop GSS-V2 provider implementations.  Certain detailed
      changes, summarized in this section, have been made in order to
      resolve omissions identified in GSS-V1.

X/Open published essentially GSS-API v1 functionality as their own
standard, and I don't know whether they have updated their standard yet.

>
>                                       I'll read the text of the RFCs in

The proposal *does* break interoperability, making it optional doesn't
help at all.  If you pass an alias to an old client that does not
request canonicalization, you can not authenticate.  If you pass
an alias to a new client that request canonicalization, it can
authenticate.  Now if you have a new application but for some platforms
only the installed base of an old Kerberos implementation, your
users will experience an unexplicable inconsistency.

Current tools do not allow you to enter true hostbased service
principals into the W2K KDC, these seem to be available only as
aliases to regular user principals (maybe with the exception for a
hack with the host key).  There is a real interoperability problem
with this.

> require; I think they got it working.

I know they did -- they used my gssapi wrapper for W2K Kerberos to
do it.  ;-)

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 20 Feb 2001 14:59:56 -0500

> telling passwords over the line!

I would agree, except for one thing damn it! gss_inquire_context() can
tell the caller what the "forwarded number" is.

In any case, there could be text in the Kerberos RFC prohibiting the use
of Kerberos name canonicalization with GSS-API, and, as I have already
noted countless times, because it's the initiator that has to request
Kerberos name canonicalization NO EXISTING IMPLEMENTATION OF GSS-API
COULD POSSIBLY REQUEST KERBEROS NAME CANONICALIZATION.

> Thank you, that is a great example!

You're welcome.

> to connect to the service.

It is. It's done by gss_init_sec_context(), it's done out-of-band. It
has to be done OOB. Existing implementations have to contact the KDC OOB
to get the appropriate service ticket.

> information to actually call the (canonical) service.

When the initiator sends the first GSS token to the acceptor.

> and no matter whether they have an intention of actually talking

Well, no, the service is available to everyone, but the information need
not be published for all to see. Subtle distinction...

> proposal that is on the table.

I guess not.

> standard, and I don't know whether they have updated their standard yet.

Fair enough. All that has to be done to preserve compatibility is to NOT
request Kerberos name canonicalization.

Kerberos name canonicalization is OPTIONAL. Not only in the sense that
a implementor of Kerberos is not required to implement name
canonicalization BUT ALSO in the sense that implementations that support
it need not use it all the time.

If the initiator does not request Kerberos name canonicalization then
what could possibly be the impact of Kerberos name canonicalization on
GSS-API applications, either v1 or v2?

> users will experience an unexplicable inconsistency.

Just because aliases are available doesn't mean you have to use them.
Today, if you use what you think is an alias the app won't work either.

So what?

> hack with the host key).  There is a real interoperability problem

What I do know about W2K is that MS tries to keep just one real SPN
per-host, with just one key to store on the host. Wether or not they
disallow <service>/fqdn@REALM type SPNs, wether as aliases or as
canonical names or wether you can associate more than one canonical SPN
with a single host I do not know.

Ask John Brezak about this.

It is possible that MS relies too heavily on Kerberos name
canonicalization. But that would not be a problem with Kerberos name
canonicalization the feature.

> I know they did -- they used my gssapi wrapper for W2K Kerberos to

Heh. I believe it!

Don't get me wrong. I'm defending MS here. I'm defending a useful
feature.

Nico
--