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

From: "John Brezak" <[email-masked]>
Date: Thu, 10 May 2001 08:45:50 -0700

below

-----Original Message-----
From: Johan Danielsson [mailto:[email-masked]] 
Sent: Thursday, May 10, 2001 2:39 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: Working Group Last call -
draft-ietf-cat-kerberos-set-passwd-05.txt

Martin Rex <[email-masked]> writes:

> Personally, I totally agree.  There's enough ASN.1 in Kerberos already

> and it has proven to cause misunderstandings and interoperability 
> problems.

Very much so since this draft uses CHOICE that isn't used anywhere else
(in Kerberos).
[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. 

> I don't know if there is already an installed base implementing this 
> particular spec, or if there is an installed base implementing a 
> different spec.

Not that I know of. We all use Marc's protocol to change passwords, but
that doesn't handle the case of setting someone elses password. I assume
there is an implementation of this, but I don't think it has any wide
use. The MS people will have to answer this.
[Jbrezak] 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.

/Johan

---

From: Martin Rex <[email-masked]>
Date: Thu, 10 May 2001 18:42:09 +0200 (METDST)

> thread on this topic of using ASN.1 in Kerberos (related) protocols. 

Well, the point was that those implementations that do not use a
generic (commercial) ASN.1 parser but have their homegrown ASN.1
parsing code might face significant extra implementation complexity
and effort in order to implement a spec that uses new constructs.

AFAIK MIT Kerberos uses a home-grown ASN.1 parser and I don't know
whether they can deal with CHOICE at this time.  I don't know about
Heimdal.

This really is a question for the Kerberos implementors.
I'm no Kerberos implementor and I'm close to ASN.1 illiterate,
so I will not even try to read and understand the proposed spec
to see whether its correct or useful.

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.

My favourite example why ASN.1 is a bad idea is rfc2025 the
SPKM gssapi mechanism.  If it hadn't used ASN.1 all over the
place probably some more people would have read it, commented
it and improved it considerably before it was published.
I would certainly have done it.  The result is that there
are now several independent implementations with
interoperability problems and none of them can be used with
(TCOS) SmartCards in a distributed environments because of
the awkward performance impacts (22-37 seconds per authentication).

The use of ASN.1 in SPKM didn't provide the necessary extensibility,
however it prevented people from participating the discussion to
notice the flaws and improving the spec...
The use of ASN.1 might be one way of getting IETF rubber stamps,
i.e. getting a proprietary development standarized with litte
discussion and even less changes.

> That version also has ASN.1 used in it and is a precursor to the current

What is the difference between the spec that was published as informational
and this current draft?  Will implementations of either be interoperable?

-Martin

PS: John, your Mail User Agent quotes Emails in a fashion that
    makes it extremly hard to visually distinguish the quoted
    text from your reply, and it also produces non-standard
    line wrapping that visually corrupts formatting of paragraphs.

PPS: I'm getting the impression that commercial software companies
     prefer ASN.1 polluted specs because this will make it significantly
     less likely for the Open Source community to come up with competing
     implementations (quickly).  XML is heading the same way.

---

From: [email-masked] (Johan Danielsson)
Date: 10 May 2001 18:50:25 +0200

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

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

> 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: Sam Hartman <[email-masked]>
Date: 17 May 2001 21:22:25 -0400

>>>>> "John" == John Brezak <[email-masked]> writes:
    John> related protocols. The use of ASN.1 in the set/change
    John> passwords protocol was discussed at length previously. If

And I do not believe a consensus was reached at that discussion.  I
believe several people objected, and several people thought it was a
good idea.