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

From: "John Brezak" <[email-masked]>
Date: Thu, 10 May 2001 14:54:38 -0700

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

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

>[Jbrezak] You might want to read PKINIT, it also > uses CHOICE. ASN.1 
>is a useful tool for these protocols. Like it or not, it is used in 
>many places in the core Kerberos protocols and ancillary Kerberos 
>related protocols. The use of ASN.1 in the set/change passwords 
>protocol was discussed at length previously. If there is a new 
>objection being raised of a technical nature, please bring this up now.

>Otherwise please refer to the old thread on this topic of using ASN.1 
>in Kerberos (related) protocols.

My recollection from this the last time it was brought up was that the
use of ASN.1 in this protocol was a bad idea.  I'd be glad to be
corrected if my memory of the consensus was wrong.

>[JBrezak] ASN.1 has been around for a long time. There are plenty of 
>good commercial ASN.1 compilers and runtimes.

But very few of the protocol implementations that use them (in my
experience) make use of commercial ASN.1 compilers.

The other "big" protocol I know that uses ASN.1 is SNMP.  When I talked
with the SNMP folks about their use of ASN.1, they were all unamious in
their opinion that nearly all SNMP implementations out there today use
hand-coded ASN.1 parsers and coding routines.

So there _may_ be a whole lot of ASN.1 compilers and runtimes out there,
but I'm wondering - what exactly are they being used for?

--Ken

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 10 May 2001 18:57:23 -0400

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

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: "Charles Stephens" <[email-masked]>
Date: Thu, 10 May 2001 17:10:29 -0700

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Ken
> Hornstein
> Sent: Thursday, 10 May 2001 15:57
> To: [email-masked]
> 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.

Not the ones I've seen.

> like "Using ASN.1 because there are lots of compilers for it" seems
> like a particular good argument to me.

ASN.1 makes my head bleed.  Why have all of this explicit typing over the
wire if two sides have agreed what the protocol is supposed to be.  Then it
goes through the hassle of counted integers.  Uugh, it also causes my head
to spin.  Suffice to say, my coworkers don't want to be around someone with
a spinning bleeding head!

XML's serialization format (aka "the angle brackets") seems to have way too
much overhead simple to tag data in a protocol.

My vote is for ONC XDR/RPC.  It has KISS appeal: implicit typing makes for
tight encoding over the wire and supports GSS!  There are compilers and
reference libraries around that make it a cinch to write implementations for
most client/server apps.  Heck Sun has implemented two password changing
protocols using it (for two versions of an authentication + directory
service that will go nameless).

However, I suspect that Kerberos probably WAAAAY to entrenched to go back
from ASN.1 now, for better or worse.  It has parity with the other parts of
the Kerberos enchilada.  And parity is sometimes more desirable than
technology.

cfs

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 11 May 2001 09:56:50 -0400

BER/DER (ASN.1), NDR (DCE RPC), XDR (ONC RPC), XML, home-rolled
encodings, take your pick -- you'll one of those or something similar
for many sufficiently complex protocols.

Of those ASN.1 may the superior choice -- it's specification is
reasonably comprehensible and complete and protocols built with ASN.1
have some extensibility built-in because of the type/element tagging.
OTOH, I bet many of you would agree that ONC RPC/XDR has a better track
record than ASN.1/DER, even considering the extensibility of ASN.1.

ASN.1/DER, ONC RPC/XDR and XML are probably easier to compile into
encoding/decoding functions than DCE RPC/NDR (because of the way
pointers and values pointed to are handled by DCE RPC/NDR). In fact, a
continuation passing style compilation of ASN.1/DER/ONC RPC/XDR/XML
seems quite plausible to me... this would have the added benefit that
encoded buffers and decoded structures could be allocated on the stack,
simplifying memory management and preventing leaks. The hard part is
mapping ASN.1 definitions to useable C structures, particularly with
respect to INTEGERs since there is no standard bigint library for C.

Considering the widespread use of ASN.1 in standard protocols, the lack
of compiler tools or use thereof is perplexing. Is there anything about
ASN.1/DER that makes it much harder to build compilers for than, say,
ONC RPC/XDR? Besides large INTERGERs? Have I missed something?

That said, I do think it's easier to write ONC RPC protocol definitions
and it's certainly easy to compile them into encoding decoding
functions, particularly since ONC RPC/XDR more closely models types
available to C programmers than ASN.1/DER. Also, Sun has made much use
of ONC RPC and extensibility has not been much of a problem for them
(and not because Sun never extended ONC RPC-based protocols!).

It's probably safe to say ONC RPC/XDR has a better track record than
ASN.1/DER, but ASN.1/DER seems more entrenched in standard protocols.

MIT would probably need to spend much effort to retrofit an ASN.1
compiler into its Kerberos software too.

Personally, I like ASN.1 and I think the change password/set key
protocol is simple enough that its use of ASN.1 does not make it too
hard to implement for those without access to an ASN.1 compiler (is
SNACC in a useable state for this protocol?).

But who would object to using ONC RPC/XDR instead of ASN.1/DER? :)

Nico

--

---

From: Ken Raeburn <[email-masked]>
Date: 11 May 2001 12:03:19 -0400

> compiler into its Kerberos software too.

Indeed.  As far as I'm aware, the ASN.1 (and RPC) compilers out there
want to dictate to me what the data structure definitions and memory
allocation strategies will be.  We've already got data structures,
some of them (unfortunately) part of our API; I want to tell the ASN.1
compiler how to use them, rather than having to use hand-coded
routines to copy data between lots of mostly-similar data structures.

> But who would object to using ONC RPC/XDR instead of ASN.1/DER? :)

Anyone who doesn't want to include two support libraries for data
encoding schemes instead of just one?  (I'm blithely ignoring for the
moment the fact that MIT Kerberos uses RPC/XDR in its admin protocol.
BTW, we don't use rpcgen either.)

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

Depends on the implementors as much as the specs, I think.  You can
write a poor implementation of just about anything. :-)

> Formal, compilable protocol definitions are preferable to
> bits-on-the-wire specs, IMHO.

IMNSHO, too, at least for higher-level protocols; probably not for
very low-level protocols.  (As Martin points out, it wouldn't be very
appropriate for IPv6, but AFAIK IPv6 is relatively simple bit-wise,
with no complicated data types.)  Alas, I've had far too few
opportunities to work with formal, compilable protocol definitions to
say it with much authority; my main experience is with MIT Kerberos,
which with its hand-maintained parsers is not a shining example of how
to deal with them.

And clearly you need to be able to find good language for the spec,
and good implementations of the compilers and support libraries, and
just what "good" means is going to vary depending on context.  Data
type definitions, error handling, memory management schemes, memory
use, code size, speed, naming schemes, target languages supported,
operating systems supported, thread safety, ease of comprehension and
other factors may come into play.  No one implementation is likely to
satisfy everyone.

I see it as being sort of like assembly language versus higher-level
languages.  C sucks in a lot of ways, but I prefer it to writing
assembly.  Sometimes the C compiler doesn't do things as well as I'd
like in terms of space or performance, but it's correct and it does
well enough most of the time that the convenience is worth it.  Yet
there are times when assembly code is the way to go.  And sometimes a
crucial factor is *which* high level language you're thinking of
using.

Give it another few years, and we might have a language and tools for
network protocol specs that don't suck much worse than C. :-)

And in case it wasn't clear, I'm not commenting either way on the
specific cases of ASN.1 or its use in set-passwd.

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

Sounds like a nice theory.

The statement "A compiler can be thoroughly tested" sounds naive to
someone who's worked on C and C++ compilers, but for a relatively
simple problem like network protocol translation it may in fact be
within the realm of possibility -- still, it'd be very difficult.
Remember that a compiler is more general than any specific application
you use it for; that widens the scope of the testing considerably.  If
you only test it in the context of your current spec, then you haven't
demonstrated that it can handle future extensions.

More interesting might be to see if the compiler can be *proven* to be
correct.  But I think that's still a research topic mostly.

---

From: [email-masked] (Johan Danielsson)
Date: 11 May 2001 19:28:21 +0200

Nicolas Williams <[email-masked]> writes:

> Considering the widespread use of ASN.1 in standard protocols, the
> lack of compiler tools or use thereof is perplexing. Is there
> anything about ASN.1/DER that makes it much harder to build
> compilers for than, say, ONC RPC/XDR?

There's an extreme lot of it.  Writing a compiler for any given subset
of ASN.1 isn't too hard.

How many on this list can honestly say they know 90% of the ASN.1
spec? I probably don't know 90% of the XDR spec off hand, but I'm
pretty certain that I can extrapolate from what I know without missing
the target by much. On the other hand I regularly find new ASN.1
constructs that I didn't knew of, and it's usually not obvious what
they mean.  And if I haven't misunderstood the situation, there are
things you *still* can't express in the grammar (like the 32-bit
bit-strings we use).

/Johan