Subject: Re: GSS-API-Easy mechanism

From: Martin Rex <[email-masked]>
Date: Fri, 5 Mar 1999 11:59:37 +0100 (MET)

Denis Pinkas wrote:
> 
> The GSS-API-Easy mechanism will help application programmers
> to develop applications making use of GSS-API tokens and
> can be seen as a first step before adopting techniques making
> use of security infrastructures or security servers.
> 
> It is easy to deploy since it does not rely on the existence of a
> security infrastructure nor the existence of a security server.

Do you have a freely available implementation in source to go with
your specification?  Since it is full of ASN.1 stuff, I *personally*
consider it a pain to implement this mechanism.  If it contained a
clear definition of the data structures and on the wire representation,
it would probably take me a week or two to implement it with the codebase
that I have; with that ASN.1 it is closer to several months and
I'm simply unable to take this much of my spare time away from
my family.  When do we get the ASN.1 spec published in the
RFC document series anyway??

-Martin
==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 05 Mar 1999 13:30:00 +0100

Martin Rex wrote:

> your specification?

A standard means "rough consensus and running code". Once we will have a
reasonable concensus then it makes sense to speak of a running code. The
document has been introduced just one week ago and the traffic on the mailing
list has had a major increase since then. This proves that there is an
interrest. I hope we can achieve a consensus in a reasonable time, but let us
continue the discussion on the mailing list and at the next meeting.

> Since it is full of ASN.1 stuff, I *personally*

The GGS-API series of document contain ASN1 as does Kerberos, thus the
motivation to use ASN1. I do know that this is not the panacea.

Regards,

Denis

---

From: Martin Rex <[email-masked]>
Date: Fri, 5 Mar 1999 13:58:06 +0100 (MET)

> motivation to use ASN1. I do know that this is not the panacea.

The GSS-API spec (high-level and C-Bindings) can be understood and
implemented even if one is ASN.1 illiterate (which I am).
There are two free-source Kerberos 5 implementations (one with
US-crypto export restrictions). 

It is extremely unfortunate that SPNEGO was submitted for standardization
without augmenting the ASN.1 stuff with concrete on-the-wire spec of
the data structures.  I assume that this will make free-source
implementations of SPNEGO unlikely -- which is definitely a bad thing.

The worst thing about ASN.1 is that it's extremely hard to figure
out what it means and where the hell it is actually documented.
From what I gathered during a 2-hour WWW-odyssey is that there are
different versions of the specification and that for each version
there are several $$$-documents that comprise the specification.
And it looks like one either needs a $$$-ASN.1 compiler or quite
a lot of time to learn and implement a parser ...

-Martin

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Fri, 5 Mar 1999 14:02:47 -0500 (EST)

Date: Fri, 05 Mar 1999 13:30:00 +0100
   From: Denis Pinkas <[email-masked]>

   A standard means "rough consensus and running code". Once we will have a
   reasonable concensus then it makes sense to speak of a running code. 

True, but the point Martin raises is that it may be easier to get
running code if we avoid the use of ASN.1 and use a raw form.  Certainly
our experience with Kerberos is that there were a lot of
interoperability problems caused by the use of people misunderstanding
ASN.1, and if the protocol data units are simple enough, it's not clear
that ASN.1 adds sufficient value to be worth its cost in implementation
complexity.  If we were doing Kerberos V5 all over again, we would *not*
have used ASN.1.  It has caused us far more problems than it has ever
saved us, and it is continueing to cause us problems even today as we
discuss RFC 1510bis.

I believe it would be appropriate to discuss whether we should take
steps to make the standard more easily implementable, and eschewing the
use of ASN.1 in favor of explicitly designed packet forms is one of the
ways that we might make the standard much more successful.

						- Ted

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 08 Mar 1999 11:08:09 +0100

Ted,

I am capturing the various comments in order to present a summary of them at
the next meeting. This is one has been well noticed and will be discussed at
the meeting (and in the corridors ...).  :-)

Denis

FYI, I will be away from my office nearly the remaining of this week, so don't
be surprised if you get no quick answer.