Subject: Importing from the Kerberos ASN.1 module

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 15 Jul 2003 16:10:00 +0200 (CEST)

I'm a bit concerned with the text in the first paragraph of section 4.4 in
draft-ietf-krb-wg-kerberos-set-passwd-00.txt:

   This protocol makes use of messages defined in [RFC1510] and
   [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
   KRB-PRIV.  Because of the proposed extensions to Kerberos V which
   will require a new ASN.1 module, and because of the ways that the
   Kerberos V ASN.1 types will change, this protocol cannot safely
   import any types from the Kerberos V module, therefore the Kerberos
   PDUs are encoded as OCTET STRINGs herein.

This text indictates that the reason you are not importing Kerberos PDU's
into your protocol's ASN.1 module is because you happen to know that the
Kerberos protocol will be chaning in nontrivial ways in the near future.

This is doing the right thing for the wrong reason.

It doesn't matter whether the Kerberos protocol spec is going to change a
little or a lot, or sooner or later, or not at all.  Kerberos application
protocols, including this one, should NOT import the Kerberos messages
into their own ASN.1 structure.  Kerberos is a separate, independent
protocol and should be treated as such.

Doing otherwise not only ties your protocol to a specific version of
Kerberos; it requires that implementors read and understand the Kerberos
specification, and compile its ASN.1 module, in order to use yours.  This
is silly -- implementors should almost always be using a Kerberos library,
which will provide suitable operations to construct and parse Kerberos
protocol messages.

I think this paragraph should be removed.  It is misleading -- it
essentially says "we would have imported messages from the Kerberos ASN.1
module, except we happen to know they're changing soon", which encourages
application authors to do so in their protocols.  Also, it gives the
impression that the Kerberos protocol is unstable, which I don't believe
is an impression we want to create.

-- 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: Tue, 15 Jul 2003 08:18:30 -0700

> This is doing the right thing for the wrong reason.
[...]

Actually, that paragraph doesn't make sense anyways.  The ASN.1 in
draft-ietf-krb-wg-kerberos-set-passwd-00.txt does not reference Kerberos
PDUs.  I think that paragraph ended up there as a result of a
conversation I had with Sam Hartman and Tom Yu about whether or not
Kerberos types which are needed by set-passwd (e.g., PrincipalName)
ought to be imported, but those types are not mentioned in that
paragraph anyways.

The ASN.1 in draft-ietf-krb-wg-kerberos-set-passwd-00.txt needs to use
some Kerberos types, which are not imported and are instead, hmm, copied
from clarifications.

I'll remove it.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 16 Jul 2003 17:12:25 +0200 (CEST)

On Tue, 15 Jul 2003, Nicolas Williams wrote:

> PDUs.

... nor should it, as I think you agree.

>   I think that paragraph ended up there as a result of a

Hm.  OK; I can see how the text in that paragraph makes sense with respect
to those types.  I guess I'd remove it anyway, since I think the value of
the clarification of intent is outweighed by the harm of giving the
impression that Kerberos is unstable and should be avoided...

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Jul 2003 09:49:57 -0700

> ... nor should it, as I think you agree.

Agreed.

> impression that Kerberos is unstable and should be avoided...

I don't think there's any harm.  For example, it's true that neither
rfc1510 nor clarifications have internationalized types which might be
appropriate for importation into the set-pw module which does need to be
properly internationalized.  That Kerberos V is not internationalized is
well established and was the original motivation for the extensions
work.  If there be harm to Kerberos V here the harm has been done long
ago :)

Put another way, if set-pw came after extensions it might be reasonable
to import such types as PrincipalName from extended Kerberos V (thoguh
we might still agree not to).

In any case, the paragraph is not needed - it will go.

Nico
--