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:40:48 -0700

inline

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]] 
> Sent: Thursday, May 10, 2001 9:42 AM
> To: John Brezak
> Cc: [email-masked]
> Subject: Re: Working Group Last call - 
> draft-ietf-cat-kerberos-set-passwd-05.txt
> 
> 
> 
> John Brezak wrote:
> > 
> > From: Johan Danielsson [mailto:[email-masked]]
> > 
> > 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. 
> 
> 
> 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.
[JBrezak] As an implementor, this spec is 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.
[JBrezak] You can mess up extensibility with anything - ASN.1 isn't
A prerequisite.

> 
> 
> > 
> > > 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.
> 
> What is the difference between the spec that was published as 
> informational and this current draft?  Will implementations 
> of either be interoperable?
[JBrezak] The versioning in the protocol should allow for backward
compatability.
The version numbers are present in the first few octets of the message
and not
ecoded with ASN.1.

> 
> -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.
[JBrezak] Sorry.

> 
> 
> 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.
[JBrezak] ASN.1 has been around for a long time. There are plenty of
good
commercial ASN.1 compilers and runtimes.

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 10 May 2001 17:29:31 -0400

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

>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: Nicolas Williams <[email-masked]>
Date: Thu, 10 May 2001 18:21:48 -0400

> experience) make use of commercial ASN.1 compilers.

There's also Heimdal's ASN compiler. And there's other open source ASN
compilers, e.g., SNACC (GPL). There's also a Perl module (Convert::ASN1)
which compiles ASN1 into Perl.

Also, MIT has plenty of reasearch going in dynamic languages which
should find ASN compilation right up their alley, no? (where's my
asbestos suit? I need to find it -- in the meantime, take this
particular suggestion with some salt...).

> but I'm wondering - what exactly are they being used for?

Heimdal uses Heimdal's compiler... Mind you, it core dumps on the PKINIT
ASN.1 spec included with Heimdal.

> --Ken

Nico
--

---

From: Ken Hornstein <[email-masked]>
Date: Thu, 10 May 2001 19:07:48 -0400

>There's also Heimdal's ASN compiler.

I'm not sure if that's an argument for or against ASN.1 ... none of the
other ASN.1 compilers were useful enough, so they had to roll their
own? :-/  (I mean no disrespect to the Heimdal guys; I'm sure they had
a good reason).  I'm not sure if packages using their own ASN.1 compilers
versus hand-written ASN.1 parsers are really that different for the
purposes of this discussion.

>And there's other open source ASN

Fair enough; so, what protocol implementations use SNACC or Convert::ASN1?

--Ken

---

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

> There's also Heimdal's ASN compiler.

I would say that it's a compiler for something that closely resembles
a subset of ASN.1, and that can handle what's required for RFC1510++.

It felt better than doing a macro-based parser a la MIT.

> Heimdal uses Heimdal's compiler... Mind you, it core dumps on the
> PKINIT ASN.1 spec included with Heimdal.

`Don't do that.' :-)

/Johan