Subject: RE: generic token framing in gssapi-cfx-02

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 10 Oct 2003 13:12:15 -0700

Martin Rex wrote:
>> The four most probable application errors that happen are:
 >> 1. message truncation
 >> 2. message with trailing garbage
 >> 3. message corruption
 >> 4. not a message

>> With the generic framing recognizing and distinguishing these
>> errors is straight-forward and quite reliable.
 
>> GSS-API tokens are designed to be embedded into higher level
>> protocols prior to transmission.  When looking at a hex dump
>> of an application layer protocol it is extremely helpful if you
>> can visually recognize and decode the boundaries of the
>> gssapi token, in particular when you yourself didn't write
>> the application but have to debug the problem.
 
my experience is that application protocols that use the embeded Wrap/MIC tokens *always* carry information that describes the token itself. 
 
That is in other words, without the pseduo ASN.1 header, all of your 4 classes of errors are diagnoseable too. If I use your very own word against yourself, portable GSS-API applications should not rely on the generic GSS-API frame to diagonse these issues, because the use of such framing is optional in non-initial tokens.
 
I agree that by having the framing the GSS-API token is self-described, but I am doubtful in the value of having such reduncy in per-message token where efficiency has the ultimost importance.

Repeating an error that was made a decade ago is not sufficiently justified here.  Can you accept having the generic framing only in context level tokens?
 
thanks,
 
Larry

________________________________

From: Martin Rex [mailto:[email-masked]]
Sent: Fri 10/10/2003 8:32 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]
Subject: Re: generic token framing in gssapi-cfx-02

Liqiang\ wrote:
> Martin Rex wrote:
> >> The wording in rfc2743 2a+b only describes the ASN.1 DER encoding
> >> which is a canonical encoding.  We don't need the encoding to be
> >> canonical here, so it is really not necessary to take this part
> >> of the spec literally, REALLY.
>
> You implicitly assume that the encoding is in ASN.1 (thus the
> canonization talk). But my understanding is that only the notation is
> ASN.1 alike, not the encoding.

I didn't make an assumption.
I carefully read the rfc2743 spec I drew a logical conclusion.
Really, I know how to read this spec, I've read it so many times
and I implemented it in an extremely generic fashion.
gsskrb5.dll was derived from that generic implementation,
and it does contain a parser for the generic gssapi framing.

rfc2743 specifies then ENcoding of the length field, not the decoding.
Think about what a DEcoder of the length field must be prepared to
handle.  I cannot think of a length field decoder that is NOT able to
decode a fixed 4-byte length field like I proposed and NOT a seriously
braindead piece of code at the same time.  Even 16-bit CPUs will
have to deal with larger than 16-bit quantities in several places
of the Kerberos protocol, so I don't count that either.

> 
> We are going circles here; I still do not see specifics on what is the
> backward capability issue you refer to.
>
> We are talking about carrying 10+ extra bytes completely useless here
> and these constant bytes were repeated for every single per-message
> tokens! Is your GSS-API wrapper for SSPI using these OIDs currently?
> Please help us to understand the concern here.

I agree.  You haven't raised any remotely technically convincing
argument why that part of rfc1964's design should be changed.

Those 17 extra bytes are visible, but nowhere near as significant as
you make them appear, and in almost all practial use they will
be marginal enough to become unmeasurable.
Several years ago when rfc-1964 was originally discussed
the 10+ bytes were substantially more significant than they're now,
and still the benefits in debugging errors was considered significantly
more important than the size of this header.
Since that time the network bandwidth, CPU horsepower and available
memory (volatile and nonvolative storage) has increased more than
10-fold each, so your size argument really is a moot point.

If you had more experience in the field, analyzing erroneous behaviour
that is NOT cause by your own code but by other's code, then you would
know useful that header where it is.
The participants of the IETF CAT working group certainly knew about it.

That generic framing adds some very useful redundancy.  It makes it
much easier to distinguish the probable kind of error when an
alleged protected message is passed to gssapi but cannot be processed
correctly (or not at all).

I hope you do realize that the inner tokens for wrap and sign do
not contain a length field.  The length field of the generic token
framing is perfectly sufficient to correctly recognize whether
a token was truncated or carries trailing garbage, and that
can be distinguished and reported to the application caller
(does section 4.1.2 GSS_KRB5_S_KG_BAD_LENGTH ring a bell?).

The four most probable application errors that happen are:
 1. message truncation
 2. message with trailing garbage
 3. message corruption
 4. not a message

With the generic framing recognizing and distinguishing these
errors is straight-forward and quite reliable.

GSS-API tokens are designed to be embedded into higher level
protocols prior to transmission.  When looking at a hex dump
of an application layer protocol it is extremely helpful if you
can visually recognize and decode the boundaries of the
gssapi token, in particular when you yourself didn't write
the application but have to debug the problem.

A difference in size between 5 and 25 bytes total would be significant.
A difference in size between 64 and 84 bytes (an ethernet frame is
at least 64 Bytes) is noticable, however a difference in size
between 1400 and 1420 bytes is marginal.

(A personal note: it's funny to see someone from Microsoft make such
 a noise about 17 bytes.  *I* get annoyed if someone sends
 me a multimegabyte MS-Word document, when I have to (world wide) wait
 when my browser loads a Word- or Frontpage-generated Web-Page
 or if I receive a (sometimes even HTML-polluted) Email quoting
 150 Lines+ original content and containing <10 lines actual content.)

The "memory alignment" issue should be sufficiently addressed by
using a fixed 0x84 0xYY 0xYY 0xYY 0xYY length field in the generic
token header.  The actual application data that is passed to
any of the message protection and unprotection calls has NO alignment
requirements (neither in gssapi nor in SSPI), and newly defining
such constraints would be inefficient and seriously break the
abstraction of both gssapi and SSPI, so we don't need
to care about such kind of alignment (the protected message token
passed to gss_unwrap() or gss_verify_mic() is not aligned to
anything, with and without the generic framing).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 10 Oct 2003 23:45:07 +0200 (MET DST)

Do you have at least ONE reason to drop the header?

I've brought up so many reasons why the header is useful where it is,
and I've shown how you can sufficiently solve the problems that
you claimed to have.

Liqiang wrote:
> That is in other words, without the pseduo ASN.1 header, all of your
> 4 classes of errors are diagnoseable too. If I use your very own word
> against yourself, portable GSS-API applications should not rely on
> the generic GSS-API frame to diagonse these issues, because the use
> of such framing is optional in non-initial tokens.

Portable applications should be able to rely on gssapi mechanism
designers and implementors to come up with mechanism that produce
helpful error messages -- because portable applications programmers
will have access to only very few of the mechanisms on which
the end users (customers) are going to put that application into production.
But each time the applications aborts with an authentication error,
the end user (customer) will go and ask the application vendor
to tell him why the application doesn't work.

The amount of plausibility tests and the error reporting in Microsofts SSPI
is poor.  That's why my gsskrb5.dll does a lot of additional checks and
reports problems that it finds.

If you look at GSSTEST, the tool that we also use to certify interoperability
with our application, it tries to simulate all the most common configuration
errors.  For certification I manually review all the error messages
that are returned for the various scenarios and by which calls they're
reported.  In order to succeed the certification those error messages
need to give a strong hint as to why an operation failed, so that
a customer has at least a chance of finding and fixing the error
by himself before opening a support call.  And if I still get the
support call, I hardly ever have to run debuggers or network monitors
to figure out what's going on, the errors reports that my code
writes plus the error message of the gssapi mechanism are all
that I need in 95% of the time.

I have the impression that you never had to support code.

I explicitly said that this was about bugs in the application code and
clueless application programmers that get an error from the gssapi
and then the security guys (like me) get the problem on their
table: "Your security API aborts with an error - you fix it".

In that situation it is extremely valuable if the gssapi mechanism
produces good enough error messages that I don't even have to capture
and look at network traces to see why that stupid application breaks.

>  
> I agree that by having the framing the GSS-API token is self-described,
> but I am doubtful in the value of having such reduncy in per-message
> token where efficiency has the ultimost importance.

ROTFL.

The performance impact of parsing that small piece of framing
is NIL compared to the crypto stuff.  REALLY, I know what I'm
talking about.  Btw. gsstest does very detailed performance
statistics on every single GSS-API call -- I know the results
for a large variety of gssapi mechanism and implementations,
including NTLM and Kerberos SSP.  Maybe you should look at those
performance measurements before trying to impress people.

We've discussed this to death now, the small size increase of 17 Bytes
is definitely a moot point, it is negligable in ALL practical environments
and completely in the noise and unmeasurable performance-wise.

>  
> Repeating an error that was made a decade ago is not sufficiently
> justified here.

Why do you keep saying this nonsense.
It was a counscious design decision to put the header at the beginning
of every token with valuable and significant advantages.

>
> Can you accept having the generic framing only in context level tokens?

With each Mail it seems less and less likely.

Maybe if you raised a real and convincing technical point.
I haven't seen any so far.

"Taste" was the most plausible explanation I got so far,
but I consider that entirely insufficient to justify why an extremely
useful and well-engineered characteristic should be ripped from
the successor Kerberos5 gssapi mechanism.

-Martin