Subject: Name canonicalization still a WIP

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 15 Feb 2001 17:43:45 -0500 (EST)

Folks, it seems clear that the jury is still out on name canonicalization. 
We do not have concensus on whether doing this at the Kerberos layer is a
good idea.  We do not have concensus on whether the current spec has
fundamental security holes.  It appears that we do not have concensus on
whether kerberos-revisions should specify name canonicalization for
AS_REQ's without also specifying it for TGS_REQ's. 

Baed on the above, it also seems clear that we cannot proceed with moving
kerberos-revisions forward with name canonicalization at that time.  We
need to either remove it, or accept that kerberos-revisions is not ready
to move forward.  While I have clear preference for the former (which I
will explain below), either is better than moving a specification to draft
standard that contains controversial features on which there is no clear
concensus.

Personally, I believe we should remove name canonicalication from the
kerberos spec altogether.  It's not an essential feature, as is shown by
the large installed base of site using Kerberos without it.  This feature
does not belong in the core specification; it belongs in its own document,
where it is easy to understand and clearly optional.  Of course, there is
also the obvious advantage of being able to move revisions forward without
waiting for concensus on name canonicalization.

Some will point out that Microsoft has an implementation which uses name
canonicalization and already has a large and growing installed base.  I
have even heard the argument that because of this, we should "bless" that
implementation as a part of the standard in order to avoid "marginalizing
the standards body".  That's just wrong.  The IETF is not a rubber-stamp
organization that "blesses" existing protocol designs regardless of their
flaws.  It is clear that there are members of the working group who feel
that this design has flaws, and we would be remiss in our responsibilities
as a standards body to include it without resolving those concerns.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

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

I think we're close to getting at the root of the disagreement. Please
allow Martin Rex to respond to my last response to him and please allow
John Brezak to respond as well.

And it was I who made the argument that to make Kerberos PN canon
optional in this RFC or in another makes no difference, and that as long
as we can determine that indeed there is no problem with Kerberos PN
canon then to not "approve" it is to get marginalized.

Folks, we must determine wether there is something wrong with Kerberos
PN canon. If there is then MS ought to stop using it or fix it and
re-submit the fixed spec.

If, on the other hand, there is nothing wrong with Kerberos PN canon,
wither from a security point of view, or from a GSS-API point of view,
then no harm can come from "approving" it as an optional feature of
Kerberos.

To NOT approve Kerberos PN canon when there is nothing wrong with it
will simply keep some (pedantic? :) implementors from implementing a
useful feature, and it will NOT prevent (less scrupulous?) others from
implementing it.

So, if there's nothing wrong with Kerberos PN canon, what good is it to
exclude it from the RFC??

The only question is one of timeliness. If we exclude Kerberos PN canon
now then we should include it later when you're satisfied that it's
secure and doesn't break GSS-API.

And if you exclude it now you should exclude Kerberos PN canon in AS and
TGS exchanges both.

Good day,

Nico

--

---

From: Sam Hartman <[email-masked]>
Date: 16 Feb 2001 16:32:52 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> I think we're close to getting at the root of the
    Nicolas> disagreement. Please allow Martin Rex to respond to my
    Nicolas> last response to him and please allow John Brezak to
    Nicolas> respond as well.

You also need to wait for the rest of us to read through the
discussions, make sure we understand and agree with the consensus.
Honestly, I would rather be working on the non-optional parts of Kerberos like making sure we have interoperability with old implementations at the ASN.1 level and making sure we have multi-cryptosystem support specified clearly.

    Nicolas> And it was I who made the argument that to make Kerberos
    Nicolas> PN canon optional in this RFC or in another makes no
    Nicolas> difference, and that as long as we can determine that
    Nicolas> indeed there is no problem with Kerberos PN canon then to
    Nicolas> not "approve" it is to get marginalized.

Great!  So you don't object to moving it out of the core spec,
provided that we do intend to evaluate it and approve it if it is
reasonable?

---

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

> Honestly, I would rather be working on the non-optional parts of Kerberos like making sure we have interoperability with old implementations at the ASN.1 level and making sure we have multi-cryptos…

Ok.

> provided that we do intend to evaluate it and approve it if it is

Well, now that other well-known and trusted contributors to Kerberos/GSS
is commenting on this issue I think we can make some progress quickly.

In any case I've said my piece. I won't push inclusion of Kerberos name
canonicalization any further. I would, however, prefer that it be
included, even if with warnings of its "experimental" nature, or not to
mix it with GSS-API and even not to include cross-realm referrals in
AS_REPs.

DISCLAIMER: I am not a Kerberos or GSS implementor, I do not work for an
implementor, nor do I have any commercial interest in how this RFC turns
out nor do I work for anyone who does.

Cheers,

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: 24 Feb 2001 19:26:31 -0500

Jeffrey Hutzelman <[email-masked]> writes:
> to move forward.

More to the point, I think we need to explicitly ask the question that
hasn't explicitly been asked of the group in general, although Sam put
it to Nico:

Does anyone object to moving all the name canonicalization and
referral stuff out of the core Kerberos spec, with the understanding
that we do intend to separately evaluate it and approve it if the
issues get resolved to everyone's satisfaction (based on "rough
consensus")?

I think we did discuss it at the San Diego meeting, and I don't recall
what degree of consensus we might've had, but I don't think it's been
asked on the list so as to include those not at San Diego.

I believe doing this will get us much closer to being able to get
kerberos-revisions to a last call that *won't* start up these endless
discussions again.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 26 Feb 2001 08:50:09 -0600

> asked on the list so as to include those not at San Diego.

At the San Diego meeting, we had a rough consensus to move most of the 
name canonicalization and referrals out of the revisions. But leave in the AS 
request processing. As the discusions on this list indicate, even the AS 
processing has questions, and maybe it should also be removed form the 
revisions. I would still like to see the revisions to at least have the 
definitions of the flags.      

> kerberos-revisions to a last call that *won't* start up these endless

As many of you may know, M. Swift, J. Brezak, J. Trostle and K. Raeburn 
are submitting " Generating KDC Referrals to locate Kerberos realms"
draft-ietf-krb-wg-kerberos-referrals-01.txt  

This should allow us to pin down the issues, separately from the revisions. 

-- 

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 26 Feb 2001 12:04:09 -0500

> definitions of the flags.      

I would argue that cross-realm referrals in the AS should be left out,
yes, if the feature is also left out of the TGS.

> This should allow us to pin down the issues, separately from the revisions. 

Good! I have found an argument that for leaving Kerberos V name
canonicalization out of the revisions that actually convinces me, namely
that the onus is placed on implementors who implement name canon to
maintain compatibility with implementations that don't support name
canon.

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: 26 Feb 2001 13:44:35 -0500

> request processing.

I think I may have said this before, but my recollection was that it
was the other way around -- some of the TGS canonicalization would be
left in.  Either way, the breakdown into AS vs TGS and not client-name
canonicalization vs server-name canonicalization was one of my issues
with it....

>   As the discusions on this list indicate, even the AS 

Yes, certainly.
Probably the SMTP name type definition should go (but have the
number/name reserved) as well, since it's intended for use with name
canonicalization.