Subject: Do we have rough consensus to drop ASN.1. headers in GSSAPI-CFX

From: [email-masked] (Sam Hartman)
Date: Mon, 20 Oct 2003 19:54:29 -0400 (EDT)

Two weeks ago there was a heated discussion of dropping the ASN.1
header from the tokens in the GSSAPI-CFX draft.  Mart made a fairly
strong case that we want the header in the context level tokens.

It's my understanding that he is still objecting to removing the the
ASN.1 header from the per-message tokens.

Several people actively support the proposal and no one else has
objected to the removal of the ASN.1 headers.

Could I get those involved in the discussion to look at the WG archive
and make sure that the major points of their arguments were copied to
the list and not just in personal mail?

Could I request the chairs review the discussion and see if we have a
rough consensus to drop the header for per-message tokens?

Thanks,

--Sam

---

From: Martin Rex <[email-masked]>
Date: Tue, 21 Oct 2003 12:47:34 +0200 (MET DST)

Sam, all,

> ASN.1 header from the per-message tokens.

There were so many messages that you may have missed the compromise
that Larry proposed and which I accepted.  However I just noticed
that the receipient list didn't include ietf-krb-wg ... I have just
resent the message to the list.

The most serious problem with dropping the ASN.1 generic framing
is that it would remove the length field from the protected message PDU,
which is a very bad idea any way you look at it.

> objected to the removal of the ASN.1 headers.

Where those several active supporters 2 or 3 individuals?
Sam, Larry, Nico?

> rough consensus to drop the header for per-message tokens?

I haven't seen any real engineering reason why it should be dropped,
but there are significant reasons why it should be there.
So the current consensus would be to keep it.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 21 Oct 2003 08:18:41 -0700

> which is a very bad idea any way you look at it.

Applications don't just send a token as is without further
encapsulation.  At least not applications that I know of.

> Where those several active supporters 2 or 3 individuals?

All three of us, and maybe more?

> So the current consensus would be to keep it.

I haven't seen any significant reasons for keeping them there.

Cheers,

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 21 Oct 2003 13:22:23 -0400

> On Tue, Oct 21, 2003 at 12:47:34PM +0200, Martin Rex wrote:

[...]

> I haven't seen any significant reasons for keeping them there.

Well, I was planning on reviewing the previous discussion today, and trying 
to come to some answer to Sam's question.  I think I will still need to do 
so.  Just based on the traffic I've seen in the last 24 hours, it's clear 
to me that we don't have unanimous agreement on this issue, but the process 
doesn't require that -- only "rough concensus" is required, and I don't 
know yet if we have that.

What I see so far...
- I think we have pretty much unanimous agreement to keep the ASN.1 headers 
on context tokens.  I still need to review the discussion, but if someone 
disagrees with this statement, please speak up.

- Sam, Larry, Nico would like to drop the ASN.1 headers from per-message 
tokens.  It's no longer clear to me whether the issue is space, processing 
time, or implementation complexity.  Martin objects, on the grounds that he 
finds the extra encapsulation useful in debugging authentication problems 
with application protocols that don't provide suitable framing of their own.

- Martin and Larry have agreed to a compromise, which is to allow the 
sender to choose, presumably on a per-message basis, whether to include the 
ASN.1 encapsulation or not; receivers would be required to be able to 
process either form.  Nico objects, on the grounds that this approach 
involves unnecessary extra complexity.

So there are two alternate proposals to make per-message tokens in CFX 
differ from those used by RFC1964.  Each has a small number of proponents 
and one main objector.  One of them has been publically on the table for 
less than 24 hours.

I think I want to watch how the present discussion plays out.

-- Jeff

---

From: Love <[email-masked]>
Date: Wed, 22 Oct 2003 09:51:34 +0200

Jeffrey Hutzelman <[email-masked]> writes:

> sender to choose, presumably on a per-message basis, whether to
> include the ASN.1 encapsulation or not; receivers would be required to
> be able to process either form.  Nico objects, on the grounds that
> this approach involves unnecessary extra complexity.

I really don't like two formats of per-message tokens. Other then that I
can't say I if I like or dislike asn1 encapsulation on per-message
tokens. If I have to pick one, I would say without.

Love

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 13:02:58 -0500

I'd also like to join the set of people who find the compromise
unacceptable.  I don't like having two formats for per-message tokens.
I think this is one of those compromises like the ATM cell size that
benefits no one and is worse than either alternative.

--Sam

---

From: Martin Rex <[email-masked]>
Date: Mon, 27 Oct 2003 19:45:13 +0100 (MET)

> benefits no one and is worse than either alternative.

Oh fine!

Since the rfc-1964 token format for protected messages includes the
generic gssapi framing and is eternally frozen and *required*
for any successor Kerberos gssapi mechanism with the same mechanism OID,
we'll stick with the format defined in rfc-1964.

That's perfectly fine with me.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Mon, 27 Oct 2003 14:34:10 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Since the rfc-1964 token format for protected messages
    Martin> includes the generic gssapi framing and is eternally
    Martin> frozen 

I agree with you up to this point.

    Martin> and *required* for any successor Kerberos gssapi
    Martin> mechanism with the same mechanism OID, we'll stick with
    Martin> the format defined in rfc-1964.

I disagree with this part of your statement.  I believe that
GSSAPI-CFX without the ASN.1 header will work in practice even though
it uses the same OID.

I don't believe that the IETF has established guidelines for when an
OID must be changed.  There is the implicit guideline that we do not
revise protocols to break existing implementations without good
reason.  I don't think either Larry or I believes that GSSAPI-CFX with
its guidelines on when it can be used will break existing
implementations.

If you were to present such evidence I'd find your assertion more
compelling in this case.  I believe you had made such a claim
regarding testing; I believe that issue has adequately been addressed
by multiple vendors saying they would do appropriate interop tests.

--Sam