Subject: NegoEx Feed-back Requested

From: "Shawn M. Emery" <[email-masked]>
Date: Mon, 04 Aug 2008 13:19:50 -0600

Looking feed-back from Larry's individual submission on Extended GSS-API 
Negotiation Mechanism, that he presented in Dublin:

http://tools.ietf.org/html/draft-zhu-negoex-01

Slides presented can be found here:

http://www3.ietf.org/proceedings/08jul/slides/kitten-2.pdf

We were running out of time for our one hour slot during the session and 
the chairs wanted to continue the discussion on the list, if needed.

Chairs, Alexey and Shawn.
--
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Michael B Allen <[email-masked]>
Date: Sat, 9 Aug 2008 19:27:40 -0400

On Mon, 04 Aug 2008 13:19:50 -0600

> http://tools.ietf.org/html/draft-zhu-negoex-01

What advantage does using explicitly encoded little-endian blobs have
over the much more common DER?

Mike

---

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Aug 2008 10:28:16 -0400

I think that having a standards track mechanism in this space would be
a good idea.

My main objection based on the presentation is that I think the
negotiation key and use of RFC 3961 is an unnecessary abstraction
violation.

I think that gss_getmic or gss_wrap would be better.  I do agree that
you'll have to carefully think about prot_ready implications.

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Aug 2008 22:20:35 +0200 (MEST)

> over the much more common DER?

Independent of the particular document that is referenced,
the most significant advantages should be obvious:

 - easier to implement, less code

 - more efficient implementations (the variable sized length fields
   and variable sized integers in ASN.1 DER are a real pain in encoding)

 - the spec can be reviewed by a MUCH larger audience
   (I know very few people whom I think are capable to seriously
    review an ASN.1-ladden spec, actually I can not think of a name
    besides Tom Yu at the moment).
 
I've been saying that since SNEGO was orignally proposed by Denis Pinkas
on the CAT mailing list more than 10 years ago.  ASN.1 was probably
the primary reason why there so few implementations over years and
the interoperability problems in the original SPNEGO spec weren't
noticed and fixed.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 27 Aug 2008 22:52:42 +0200 (MEST)

Having briefly looked at the document, there are a couple
of unecessary hurdles in the chosen notation:

All integer types ought to carry the length in their names 
to facilitate reading.  (UCHAR and ULONG64 are fine,
ULONG, USHORT GUID and enums are not).
Additionally, nothing is said about the alignment of the listed integer
types, which is most confusing with respect to the type GUID.

A "4 octet number encoded in little endian" does NOT have
alignment requirements, an ULONG is very likely supposed to
have it.

Lack of explicit structure padding.  A C-Compiler is going to
add padding after members of structures and at the end of
structures as necessary to accomodate the alignment requirements
of the structure members and the largest structure member.

A spec for on-the-wire data ought not to rely on unnamed/non-obvious
padding, but instead spell out each and every octet on the wire,
its value and its semantics.

This is an obvious defect for simple structures like
AUTH_SCHEME_VECTOR and EXTENSION_VECTOR,

and in particular for the complex structures like
MESSAGE_HEADER, NEGO_MESSAGE, EXCHANGE_MESSAGE and VERIFY_MESSAGE

The lack of explicit alignment and padding requirements for
the message formats has caused interop problems in one particular
network file system protocol, so lets try to avoid it this
time around...

-Martin

---

From: Michael B Allen <[email-masked]>
Date: Wed, 27 Aug 2008 16:56:14 -0400

On Wed, 27 Aug 2008 22:20:35 +0200 (MEST)

> the interoperability problems in the original SPNEGO spec weren't

Well you're assuming people are hand-wrangleing DER which is usually
not true. Unfortunately sometimes it is true and I agree with you 100%
about the efficiency of DER encoding.

I guess I'm indifferent.

Mike

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Michael B Allen <[email-masked]>
Date: Wed, 27 Aug 2008 17:24:49 -0400

On Wed, 27 Aug 2008 22:52:42 +0200 (MEST)

> network file system protocol, so lets try to avoid it this

I see no mention of "alignment" or "padding" in the document. The
structure definitions use "'C' conventions" and are "much like that of
C". That does not mean compiler artefacts like alignment and padding
are a factor. Meaning there is no alignment or padding.

I think the days of casting structures into network buffers are long over.
And I would hope that any standard that proposed such a thing would be
stricken down with prejudice.

Mike

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 27 Aug 2008 17:28:09 -0400

> of the structure members and the largest structure member.

My first thought on glancing at this draft was that we don't need  
another data layout specification language if we can avoid it.  If ASN. 
1 has already been shot down, why not XDR (RFC 4506)?  Aside from  
missing a primitive GUID type, which is easy enough to work around, I  
think it covers all the bases, doesn't it?

Ken