Subject: RE: Working Group Last call - draft-ietf-cat-kerberos-set-passwd-05.txt

From: "John Brezak" <[email-masked]>
Date: Thu, 10 May 2001 17:53:10 -0700

Compilers are available. If there isn't a good one that meets your
needs, you
can find one that does - create one or buy one. My point is that plenty
of other
protocols have been specified using ASN.1 - it is pervasive.

-----Original Message-----
From: Ken Hornstein [mailto:[email-masked]] 
Sent: Thursday, May 10, 2001 3:57 PM
To: [email-masked]
Subject: Re: Working Group Last call -
draft-ietf-cat-kerberos-set-passwd-05.txt 

>A few other protocols using ASN.1 - LDAP, CMS, SPNEGO, H.323 to name a 
>few.

Fair enough ... but to pick your first example, are LDAP implementations
being written that use commercial ASN.1 compilers, or are they rolling
their own?  The only one I have source code access to (OpenLDAP) looks
like it's rolling their own ASN.1 library, and it's been my experience
that this is extremely common.

I'm perfectly willing to be convinced otherwise, it just doesn't seem
like "Using ASN.1 because there are lots of compilers for it" seems like
a particular good argument to me.

--Ken

---

From: Michael Thomas <[email-masked]>
Date: Thu, 10 May 2001 18:41:58 -0700 (PDT)

> protocols have been specified using ASN.1 - it is pervasive.

Sure. At about 100-200kb code space per interpreter.

One perspective I can spin on all of this is that
from an embedded standpoint, ASN.1 usually equals
Big Code Footprint. I think that Ken gets it right
especially when you are talking about embedded
devices. There's no surer way to get a hardware
dev manager's face to turn ashen than to tell them
that they need x100 KB for feature X. If the
feature is related to security, it is usually
accompanied with a dismissive eyeroll.

It would really, really be nice to get Kerberos
into the next generation of all of these widgets,
but the fact of the matter is that its code
footprint makes it a very hard sell, especially
when you consider that it really only buys you the
authentication piece. When you factor in all of
the other goodies of crypto libraries, base level
transport, and heaven forfend CMS and public
stuff, you do not make many friends with the
hardware folks who still enshrine Bill Gate's 640k
comment as revealed truth.

From my poking around in the MIT sources, a very
significant portion of the entire code budget for
a Kerberized Hello World program is the ASN.1 part
of the libraries. Some of this is just inevitable
overhead of format/parsing messages, but from my
poking, it looked like it would be pretty easy to
halve the size of the ASN.1 footprint -- probably
more. While that may sound like a groovy idea, it
comes at the same cost as all code squeezes:
casting into stone the optimization and the
concommitant inability to be resilient to changes.

So, there really are more issues at play here than
just finding an ASN.1 compiler.

     Mike, waxing existential again

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 13:08:41 +0200 (METDST)

John Brezak wrote:
> 
> Compilers are available. If there isn't a good one that meets your needs,
> you can find one that does - create one or buy one. My point is that plenty
> of other protocols have been specified using ASN.1 - it is pervasive.

Pardon me, but that is a non-point.

There is at least one Kerberos implementation that doen't require and
doesn't use an ASN.1 compiler, and the password change protocol is simple
enough that it can be done without ASN.1 making it *SIGNIFICANTLY* easier
to update that code.

Suggesting people to get a $$$-spec and $$$-tools to implement a simple
protocol isn't very nice (or resonable).  It's an IETF tradition that
people can download all relevant RFC documents and start implementing
a spec.  It is really bad that recently there have been put documents
on the standards track that do not allow this because of their use
of ASN.1!  It is definitely against the IETF spirit.

In the IETF, we should avoid both ASN.1 and complexity in a spec
as much as possible.  For the given task of changing a password,
this should be extremely simple.  The proposed spec utterly fails
this task...

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 14:56:09 +0200 (METDST)

> protocols have been specified using ASN.1 - it is pervasive.

There's another word beginning with perv* that I use when referring
to ASN.1 ...

When it is necessary, in order to implement this change+set password procotol,
to first write one's own ASN.1 compiler, then this spec is far out of
scope from IETF standards track.

Besides requiring a $$$-ASN.1 spec and a $$$-ASN.1-compiler and the
$$$-time to learn ASN.1 you will often not get a compiler for all of
one's platforms and all of one's programming languages (on those platforms).

The only thing that is truely portable to all platforms and all programming
languages is a bits-on-the-wire spec.  And by coincidence it is the
easiest to understand and discuss format for the majority of software
developers.

>A few other protocols using ASN.1 - LDAP, CMS, SPNEGO, H.323 to name a 

Looks familiar.  Aren't these all protocols that a large anti-OpenSource
software company implements and ships...

John Brezak wrote:
>
> Martin Rex wrote:
> >
> > If all of the Kerberos implementers (particularly those that
> > don't use an ASN.1 compiler) think that they can handle this
> > spec then everything should be fine.
>
> [JBrezak] As an implementor, this spec is fine.

It's not uncommon for (co-)authors of a document to like their own spec.
Although I do acknoledge that you are an actual implementor,
I don't feel like this is sufficient for IETF proposed standard.

> that this is extremely common.

Most of the implementors are probably rolling their own.  That is the
only chance to remain portable to all existing platforms as well as
yet unknown platforms of the future, to have the same codebase accross all
these platforms (and therefore the same bugs everywhere) and the best way
to make Software self-contained.

> a particular good argument to me.

There is probably not a single commercial ASN.1 compiler avaible that
supports all the platforms for which my code ships.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 May 2001 10:04:18 -0400

> of ASN.1!  It is definitely against the IETF spirit.

But has this "tradition" generally and consistently lead to robust
implementations of those specs? :)

Formal, compilable protocol definitions are preferable to
bits-on-the-wire specs, IMHO. And the use of compilers for
encoding/decoding protocol data should lead to safer programs by
avoiding buffer overruns in decoding routines (a compiler can be
thouroughly tested, whereas future implementations of future extensions
to a bits-on-the-wire spec can't be checked until, well, until they're
coded).

Would you object to the use of ONC RPC/XDR for this protocol?
Open-source and commercial compilers are available for ONC RPC/XDR, even
for languages other than C/C++ (such as Perl, Tcl, and probably others
as well).

> -Martin

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 16:56:27 +0200 (METDST)

> implementations of those specs? :)

I surely doubt that the use of ASN.1 to define the IPv6 protocol
would have improved things.  However it would have prevent many people
from participating the discussion and understanding the spec.

> to a bits-on-the-wire spec can't be checked until, well, until they're

That really depends on the programmer.  ASN.1 is mostly favoured by
people with little or no programming experience.  Btw. how much code do
you write?

The code that *I* write is extremely robust and secure, and I will always
prefer it to any commercially available encoding compiler.  It's also easier
to handle and *extremly* portable, fast and small, and it produces
meaningful error messages for bad encodings!

> Would you object to the use of ONC RPC/XDR for this protocol?

I object to the *lack* of bits-on-the-wire in the spec.
Replacing ASN.1 with ONC RPC/XDR but omitting the bits-on-the-wire
definition is not any better.

The key here is not to *force* anyone to use ASN.1.

The spec should really define the bits-on-the-wire in a fashion
that it can be described with ASN.1 syntax and the ASN.1 description
should be moved into the Appendix.  That way, the implementors will
have the freedom of choice.

> for languages other than C/C++ (such as Perl, Tcl, and probably others

Please no more of this "compilers are available" BS.

Every once in a while people show up in the Open Plenary and ask
why they cannot get word documents published as RFCs, pointing
to the widespread use of Microsoft Word in the population.
Some people simply don't get it.

IA5 is the best encoding for RFCs, it is easy to learn and understand,
doesn't need any additional compiler, is extremely portable across
platforms, and the best of all: all the various independent
implementations over the decades show an extremely good interoperability.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 May 2001 11:08:51 -0400

> from participating the discussion and understanding the spec.

Good point. I was thinking of higher-level protocols.

> people with little or no programming experience.  Btw. how much code do

Not much that you'll find. Mostly I work with other people's source
code, and mostly it's proprietary. So far, I'd say I've written on th
order of 10k loc -- not much.

> meaningful error messages for bad encodings!

I don't question that.

> definition is not any better.

Hmmmm. Well, it's not very hard to get to bits-on-the-wire from ONC
RPC...

> have the freedom of choice.

Ah. Yeah, that's quite reasonable.

> Please no more of this "compilers are available" BS.

Well, ONC RPC is rather different in this respect -- Sun's compiler
(rpcgen) has been available for many years. MIT even uses an internal
implementation of ONC RPC heavily based on Sun's. Plenty of protocols,
even non-Sun ones use ONC RPC (e.g., NetInfo (NeXT/Apple, NFS/NIS/NIS+
(Sun), etc...). In fact, Sun's implementation is available as open
source (under the SISSL license). And ONC RPC has been ported to many
platforms (all the Unix ones, including Unix-like systems like OpenStep,
and non-Unix-like systems such as VMS and Windows). And it's very
light-weight.

> Some people simply don't get it.

Eeck! Point taken.

> implementations over the decades show an extremely good interoperability.

I'm trying to imagine the Kerberos V spec written like that...

Nico
--

---

From: "Booker C. Bense" <[email-masked]>
Date: Fri, 11 May 2001 08:18:59 -0700 (PDT)

> implementations of those specs? :)

- If you look at the history, I think the answer is definitely
yes. Look at the history of ISODE vs. TCP/IP. Large formally
defined rpc mechanisms have a long history of failure, their
complexity always overwhelms the ability to create robust code.

> bits-on-the-wire specs, IMHO.

- Have you written either? ASN.1 sounds great until you actually
have to get something working. In the long run, to implement
something you have to have the bits-on-the-wire specs, ASN.1
just makes figuring that out much more complicated.

> And the use of compilers for

- Neither can compilers, it's all code in the long run and having a
formal spec doesn't really make the code any better. Putting all
your eggs in a single encoding basket makes all your protocols
vulnerable to a single error in the compiler.

> for languages other than C/C++ (such as Perl, Tcl, and probably others

- I think this whole debate is rather pointless. The camel's nose is
in the tent and the best we can hope for at this point is to get
Microsoft to at least document what they are doing. For good or
ill we no longer get to make these decisions[1], the bits on the
wire are the final arbitrators of protocol decisions. By adopting
these protocols MS has dominated the "bit market" so to speak,
and in the long run whoever has the biggest "bit market" share
determines the protocol. Regardless of whether this RFC becomes
a standard or not, if you have W2K in your infrastructure you're
going to have to support it. I'd rather see the RFC go forward
since then I'd at least have a chance of making it work.

- Booker C. Bense

[1]- In reality, the IETF never has had the power to make these
decisions. It's always been up to the implementors. It was just
in the past that the implementors were the majority of people
in IETF discussions.

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 May 2001 17:44:06 +0200 (METDST)

> since then I'd at least have a chance of making it work.

Not that fast.

John mentioned that there is a W2K implementation of
"draft-trostle-win2k-cat-kerberos-set-passwd-02.txt"
which is going to be published as an informational RFC.

The only ASN.1 structure that I see in that document is

      ChangePasswdData ::=  SEQUENCE {
                          newpasswd[0]   OCTET STRING,
                          targname[2]    PrincipalName OPTIONAL,
                          targrealm[3]   Realm OPTIONAL
                          }

The document that is currently in WG last call
"draft-ietf-cat-kerberos-set-passwd-05.txt"
defines significantly more ASN.1 structures:

    ChangePasswdData :: =  SEQUENCE {
                        newpasswdorkeys[0]   NewPasswdOrKeys,
                        targname[1]          PrincipalName OPTIONAL,
                          -- only present in set password/key: the
                          -- principal which will have its password
                          -- or keys set. Not present in a set request
                          -- if the client principal from the ticket is
                          -- the principal having its passwords or keys
                          -- set.
                        targrealm[2]         Realm OPTIONAL,
                          -- only present in set password/key: the realm
                          -- for the principal which will have its
                          -- password or keys set. Not present in a set
                          -- request if the client principal from the
                          -- ticket is the principal having its
                          -- passwords or keys set.
                        flags[3]             RequestFlags OPTIONAL
                          -- 32 bit string
                        }

    NewPasswdOrKeys :: = CHOICE {
                       passwords[0]  PasswordSequence, -- chg/set passwd
                       keyseq[1]     KeySequences      -- chg/set key
    }

    KeySequences :: = SEQUENCE OF KeySequence

    KeySequence :: = SEQUENCE {
                     key[0]        EncryptionKey,
                     salt[1]       OCTET STRING OPTIONAL,
                     salt-type[2]  INTEGER OPTIONAL
    }

    PasswordSequence :: = SEQUENCE {
                        newpasswd[0]  OCTET STRING,
                        oldpasswd[1]  OCTET STRING OPTIONAL
                          -- oldpasswd always present for change
                          -- password but not present for set
                          -- password, set key, or change key
    }

    RequestFlags :: = BIT STRING {
                      reserved(0),
                      request-srv-gen-keys(1)
                           -- only in change/set keys
                           -- if the client desires
                           -- server to contribute to
                           -- keys;
                           -- server will return keys
    }

       KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
                                    containing at least one etype that
                                    is not supported by the KDC. The
                                    response edata contains an ASN.1
                                    encoded PKERB-ETYPE-INFO type that
                                    specifies the etypes that the KDC
                                    supports:

                                    KERB-ETYPE-INFO-ENTRY :: = SEQUENCE
                                    {
                                         encryption-type[0]  INTEGER,
                                         salt[1]        OCTET STRING
                                           OPTIONAL -- not sent, client
                                                    -- ignores if sent
                                    }

                                    PKERB-ETYPE-INFO ::= SEQUENCE OF
                                                  KERB-ETYPE-INFO-ENTRY

Since it uses a different "procotol version number" in the
non-ASN.1 protocol header than the existing W2K-predecessor,
there shouldn't be any problem with changing this spec --
as far as I understand from the current discussion.

Btw. does rfc1510 require a specific ASN.1 encoding (like DER)?
I didn't see a requirement for a specific encoding in this draft,
doesn't this add even more unnecessary complexity?

-Martin