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

From: "John Brezak" <[email-masked]>
Date: Thu, 10 May 2001 11:33:07 -0700

inline

> -----Original Message-----
> From: Johan Danielsson [mailto:[email-masked]] 
> Sent: Thursday, May 10, 2001 9:50 AM
> To: John Brezak
> Cc: [email-masked]; [email-masked]
> Subject: Re: Working Group Last call - 
> draft-ietf-cat-kerberos-set-passwd-05.txt
> 
> 
> "John Brezak" <[email-masked]> writes:
> 
> > You might want to read PKINIT, it also uses CHOICE.
> 
> True, but it's not as central as changing ones password.
[JBrezak] Initial authentication seems pretty essential. Also add to the
list SPNEGO.

> 
> > 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.
> 
> Maybe that was on a forum I don't read, but I've seen very 
> little of it. I know I've objected to wider use of ASN.1 
> before, and it's usually been shrugged off with an `ASN.1 is 
> very useful' argument.

[JBrezak] So far that seems to be the only technical issue. This doesn't
seem like something to condemn its use. As an implementor of ASN.1 based
protocols and given its pervasive use in many standards area, an
investment
in a good asn.1 toolset is essential and extends far beyond Kerberos.

> 
> > Microsoft implemented the change/set password protocols recently 
> > posted by Jonathan that was moved to the informational track.  That 
> > version also has ASN.1 used in it and is a precursor to the current 
> > I-D.
> 
> Ok, good to know.
> 
> /Johan
>

---

From: [email-masked] (Johan Danielsson)
Date: 11 May 2001 09:27:42 +0200

"John Brezak" <[email-masked]> writes:

> Initial authentication seems pretty essential. Also add to the list
> SPNEGO.

We have lived happily without public key support in the past ten years
or so. (slightly off-topic: are there any publicly available PK-INIT
implementations).

Sure there are lots of protocols out there that use ASN.1, but that
does not mean it's a good idea.  I would be happy if GSS-API, PKINIT
and SPNEGO didn't use ASN.1, but they do and there isn't much point in
trying to change them now. At least for GSS-API the use is limited,
and you can easily cope without an ASN.1 parser.

My point is that an administrative protocol (which we're talking about
here) is so central to Kerberos that it would be a big mistake to use
anything more complex than necessary.

ASN.1 is more complex than necessary in most (and some would say all)
cases. That it's a standard does not automatically make it good.

> As an implementor of ASN.1 based protocols and given its pervasive
> use in many standards area, an investment in a good asn.1 toolset is
> essential and extends far beyond Kerberos.

We're getting a bit off-topic here, but anyway.

Writing a generic ASN.1 parser is not an easy task. First you have to
*buy* the specification for a lot of money. If you manage to
understand what it really means (which I'm sure most people who work
with ASN.1 doesn't fully do), writing the code will not be very easy
either.  Much more so if you want the resulting code to be efficient
(which is one area where the available tools, such as ISODE, fail).

And if you want it to be really useful, you have to make it easy to
extend with support for broken ASN.1, such as we have (had) in
Kerberos.

We have to live with the protocols that already use ASN.1, but that
does not mean we should just continue to use it for more.

/Johan

---

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

> [JBrezak] Initial authentication seems pretty essential. Also add to the

People who use PKINIT also use public key crypto, X.509 certs and
a lot of other stuff that requires a large amount of ASN.1 and
has an enourmous implementation complexity and memory footprint.

SPNEGO is a bad example.  I was always opposed to the use of ASN.1
in SPNEGO and you can clear evidence in the CAT mailing list archives. :-)

There are two reasons why you won't see much of SPNEGO anywhere:

1) SPNEGO is *not* backward compatible to an installed base therefore
   "portable" applications will normally avoid SPNEGO even where it
   is available.

2) it uses ASN.1 -- this is why it is unlikely in Open Source implementations
   (I would have provided an Open Source implementations years ago if it
    didn't use ASN.1 and MIT Kerberos might have shipped it years ago.
    I have been complaining about ASN.1 in SPNEGO without the accompanying
    bits&bytes spec that the GSS-API spec has since Pinkas originally
    submitted the first SNEGO draft.)

The funny thing: the sample snego (without "P=Protection") implementation
announced by Denis Pinkas did actually use/require the SNACC compiler ...
I don't know whether this code is still available, the licensing and
whether the code was ever updated to the final SPNEGO spec.

: From: [email-masked] (Denis Pinkas)
: To: [email-masked] (IETF CAT WG)
: Subject: Simple GSS-API negotiation available
: Date: Tue, 27 Feb 1996 17:37:43 +0100 (NFT)
:
: An implementation of the Simple GSS-API negotiation mechanism
: (Internet-Draft draft-ietf-cat-snego-01.txt, 19 February 1996)
: is now available at the following URL :
:
:       ftp://ftp.enst-bretagne.fr/pub/security/gssneg.tar.gz
:
: It uses SNACC 1.1 libraries for encoding and decoding of PDUs
: described in ASN.1. The SNACC compiler can be found at:
:
: ftp.denet.dk:/pub/snmp.
:
: The directory structure is :
:
:     - lib : SNACC libraries
:     - include : SNACC headers

> investment in a good asn.1 toolset is essential and extends far beyond
> Kerberos.

IMHO it is a significant issue because it will make adoption of the spec
and several independent implementations significantly more unlikely.

For the issue at hand, the use of ASN.1 is clear and obvious overkill.

All the sources that I have seen didn't use an ASN.1 compiler.  The
usually started off with ISODE and replaced the code with their
own (MIT Kerberos, SECUDE).

My personal preference would be that the spec should use a
bits&bytes spec in an ASN.1 compatible fashion, just like the
GSS-API spec does it with the token framing.

This would allow everyone to read and understand the spec and
join the discussion and it would encourage quick adoption and
multiple independent implementations, in particular in the
Open Source area.

-Martin