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

From: "John Brezak" <[email-masked]>
Date: Wed, 16 May 2001 17:40:32 -0700

I cannot see why a commercial ASN.1 compiler is required before ASN.1
can be used in an implementation. Of 4 widely available Kerberos V5
implementations - Windows 2000, OSF/DCE, MIT Kerberos V5 and Heimdal
Kerberos V5, only MIT chooses not to use an ASN.1 compiler. So it is
possible to implement protocols specified in ASN.1 without the aid of a
commercial compiler.

Speaking as an implementor, use of ASN.1 in a standard has not stopped
Microsoft from building an implementation of a protocol. Microsoft will
implement the kerberos-set-password-05 protocol if it is published as an
RFC in a future version of Windows using ASN.1.

I cannot see how a bits on the wire specification produced from an ASN.1
description would speed implementations. It does have instructional
purposes for those who what to understand ASN.1. But that is not the
purpose of this I-D.

Also I don't see a need to single out this I-D in its use of ASN.1 when
other I-Ds and standards are also using ASN.1 (including CHOICE) - there
are even multiple implementations of those protocols.

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]] 
> Sent: Wednesday, May 16, 2001 11:36 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: Working Group Last call - 
> draft-ietf-cat-kerberos-set-passwd-05.txt
> 
> 
> 
> Wyllys Ingersoll wrote:
> > 
> > I dont have any objections to the data or the protocol 
> itself at this 
> > point.  Whether or how soon it gets implemented here is a 
> function of 
> > customer demand, time, and resource availability.  In principal, I 
> > think the proposal has merit and should go forward.
> > 
> > As for the ASN.1 discussion:
> > 
> > -  Im inclined to agree that the ASN.1 should be kept in 
> the I-D since
> >    its already used in other parts of Kerberos.  However if 
> someone has a
> >    strong case for easier-to-implement, non-ASN.1 messages 
> that wouldnt 
> >    clash horribly with the rest of the Kerberos protocol 
> then I would like 
> >    to hear it (I guess its getting late for that though).
> 
> Using the existence of ASN.1 in other parts of Kerberos 5 is 
> IMHO a very poor excuse for using it here.
> 
> rfc1964 didn't add any ASN.1 to Kerberos and for good.
> 
> For the complexity of the task at hand and with at least two 
> independent Kerberos 5 implementations that don't use a 
> commercial ASN.1 compiler we shouldn't blindly add more ASN.1 
> to Kerberos just for the sake of the fun of it. 
> 
> What I don't like is not that the proposal uses ASN.1 
> structures, but that it does *NOT* include the 
> bits-on-the-wire equivalent definition.
> 
> The clear advantage that the bits-on-the-wire spec would give:
> 
> - it would reveal the complexity of the current proposal
>   (or the absence thereof, i.e. its elegance), allowing the
>   whole community to participate the discussion
> 
> - it would facilitate the implemenation of the proposal
>   for those implementations that do not use a commercial
>   ASN.1 compiler and a much quicker adoption of that
>   Kerberos extension.
> 
> - it would provide a significantly more reliable
>   ground for interoperability among independent implementations
> 
> 
> >    
> > -  If the ASN.1 is kept, then definitely specify the encoding rules
> >    in the I-D.
> 
> That the authors forgot to include this "little detail" makes 
> me really wonder about other hidden features that are 
> non-obvious to ASN.1 illiterates like me.  I haven't seen any 
> explanation from the ASN.1 fanciers yet that explain how the 
> CHOICE element used in this spec can be quickly implemented 
> by the non-ASN.1 guys so that this issue can be simply ignored.
> 
> -Martin
>

---

From: [email-masked] (Johan Danielsson)
Date: 17 May 2001 15:19:36 +0200

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

> Of 4 widely available Kerberos V5 implementations - Windows 2000,
> OSF/DCE, MIT Kerberos V5 and Heimdal Kerberos V5, only MIT chooses
> not to use an ASN.1 compiler.

I wouldn't call what we (Heimdal) use an ASN.1-compiler. It takes
input that resemble a subset of ASN.1 and converts it to c-code. We
have implemented just enough to make it work with 1510++, but nothing
more. Specifically we don't support CHOICE, as that turned out to be a
hard problem.

Does DCE still use MAVROS, or have they imported newer code from the
MIT camp?

I would take the use of MAVROS as an example of why you shouldn't use
ASN.1.  MAVROS had the interesting feature that it encoded data in the
forward direction, which has it's problems, since you have no idea how
long the data will be until after you're done. MAVROS solved this by
reserving one byte for length, and later, if the actual length was
longer, it reverted to indefinite, BER style, lengths. The version of
MAVROS used by the DCE people could apparently generate X.509 DER
encodings, and did this by making space for the length after encoding,
but unfortunately this feature wasn't used with Kerberos.

> Speaking as an implementor, use of ASN.1 in a standard has not
> stopped Microsoft from building an implementation of a protocol.

If you didn't work for Microsoft, would you still implement protocols
using ASN.1?

> I cannot see how a bits on the wire specification produced from an
> ASN.1 description would speed implementations. It does have
> instructional purposes for those who what to understand ASN.1. But
> that is not the purpose of this I-D.

If we happen to use ASN.1 I agree with you. The bits-and-bytes are too
complex to describe in a simple RFC like this.

> Also I don't see a need to single out this I-D in its use of ASN.1
> when other I-Ds and standards are also using ASN.1 (including
> CHOICE) - there are even multiple implementations of those
> protocols.

Someone has to start. I have a feeling that IETF has turned into
something that commercial companies use to get a standards-compliance
stamp on their favourite protocol. Many new protocols are way to
complicated, if you ask me. Using ASN.1 doesn't make it easier.

/Johan

---

From: Martin Rex <[email-masked]>
Date: Thu, 17 May 2001 19:43:48 +0200 (METDST)

> RFC in a future version of Windows using ASN.1.

Although it is possible and even quite common (in particular in the
Open Source community) to implement ASN.1 without an ASN.1 compiler,
it is *significantly* more difficult for those without an ASN.1 compiler
to do the implementation, and it has caused interoperability problems
as far as I recall from the Kerberos revisions discussion.

I know (evidenced by the Halloween document) that Microsoft aggressively
jumps on everything that makes competition by Open Source implementors
more difficult and less likely to happen.  And if interoperability
problems arise, they like to blame it to poor OpenSource quality.

The original I-D from Marc Horowitz that you used as a starting point
didn't use any ASN.1, and you even retained the non-ASN.1 data definitions
from that original I-D.  Personally, I think the current result is a mess
from an engineering standpoint, significantly more complex that
what it could and should be and an clear offense to OpenSource.

> purposes for those who what to understand ASN.1. But that is not the

Because people without ASN.1 will have to implement the bits-on-the-wire
spec, whether you include it or not.  By leaving it out you camouflage
the excess complexity in the proposal and put yourself in advantage
over the non-ASN.1 guys that have (1) to translate the structures
into bits-on-the-wire themselves and (2) write that extra code.

> are even multiple implementations of those protocols.

What you see is the attempt of a hostile takeover of the IETF.

btw. the current I-D doesn't mention what character encoding
the following structure uses:

    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
    }

Probably it should say that the passwords are UTF8 strings.

Since I really don't see any real progress here, I propose to
rewrite over the weekend the data payload from current I-D with
simple to implement non-ASN.1 bits-on-the-wire spec as a counter-proposal,
so that it will be equally simple to implement for every Kerberos
implementor and result in much smaller and much faster code.

-Martin

---

From: "Charles Stephens" <[email-masked]>
Date: Thu, 17 May 2001 14:23:02 -0700

> From: Martin Rex
> Sent: Thursday, 17 May 2001 10:44
> 
> John Brezak wrote:
> > 
> > possible to implement protocols specified in ASN.1 without 
> the aid of 
> > a commercial compiler.
> > 
> > Microsoft from building an implementation of a protocol. Microsoft 
> > will implement the kerberos-set-password-05 protocol if it is 
> > published as an RFC in a future version of Windows using ASN.1.
> 
> Although it is possible and even quite common (in particular 
> in the Open Source community) to implement ASN.1 without an 
> ASN.1 compiler, it is *significantly* more difficult for 
> those without an ASN.1 compiler to do the implementation, and 
> it has caused interoperability problems as far as I recall 
> from the Kerberos revisions discussion.

The question that is rolling around in my bleeding, spinning head is if
there is a open source-ish ASN.1 compiler available to the masses?  If
so, why not just use that in a reference implementation?  Problem
solved.

cfs