Subject: Open Issues on draft-ietf-kitten-2478bis

From: Jeffrey Altman <[email-masked]>
Date: Wed, 24 Nov 2004 00:19:51 -0500

Folks, I am back from vacation.  There are some open issues which
I need to have a resolution to based upon the discussion at IETF61
and the e-mail communication on this list over the last ten days.

(1) At IETF61 there was a consensus call in the meeting room asking
     whether it was more important to maintain backward compatibility
     then to add new features to the protocol.  There was unanimous
     consensus in the room that backward compatibility was more
     important.

(2) At IETF61 there was a consensus call in the meeting room asking
     whether or not the use of mechanisms which do not support integrity
     protection should be prohibited in 2478bis.  There was a very
     strong feeling in the room that these mechanisms should be
     prohibited.  Is this the consensus of the participants of
     this mailing list?

     My concerns about adding this prohibition are that it may break
     backward compatibility for some implementations of 2478 which
     we are not aware of.  As such I believe doing so would be in
     conflict with (1).

(3) At IETF61 there was a consensus call in the meeting room asking
     whether the use of optimistic tokens will be specified in 2478bis
     as a "SHOULD" or a "MAY".  There was no consensus in the room.
     Is there consensus on the mailing list?

(4) Martin raised the possibility that implementations of SPNEGO outside
     of the current list participants might be broken by the new SOMIC
     rules or other changes.  In the absence of additional data it is
     very hard to make a determination as to how great a risk this is.
     What I am wondering is what we can do to try and track down some
     of these additional implementations?  Martin, do you have any
     ideas?

(5) There was discussion on the list on the subject of whether or
     not there should be explicit text added to the draft recommending
     that implementations replace a SPNEGO token with a mech specific
     token when only one mech is available in the initiator.  It seems
     to me that doing so would improve the security of the protocol
     as well as improve the performance.  I did not see the discussion
     reach a conclusion one way or the other.  Does anyone have some
     proposed text for this or should it be dropped?

(6) There was a discussion on the history of the term "mechanism
     variants".  I would prefer to either see undefined terms be removed
     from documents or be defined.  Martin, could you propose some text
     to be added to the document which can be used to define the meaning
     of this term?

(7) There was discussion on the list of the "multi-layer negotiation is
     considered harmful argument" and whether or not text should be added
     to this document on the subject.   Does anyone have some proposed
     text for this or should it be dropped?

I realize that the holidays are fast approaching.  It is my hope to be 
able to get this document to the IESG before the end of the year.  To
meet that goal I must ask that folks who have been putting off reviewing
the document until it becomes stable do so now.

The process I would like to follow in this group is that proposed
changes to published documents be sent to the mailing list and only
be incorporated into the documents by the editor after consensus on
the proposed text has been reached on the list.  I believe this
process will allow us to move documents ahead at a faster pace with
more consistent review.

Thanks.

Jeffrey Altman

P.S. - Happy Thanksgiving to all.

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Nov 2004 10:28:56 -0600

>     of these additional implementations?  Martin, do you have any

This is very important.  I suspect that currently any implementations
that are faithful, modulo spec ambiguities, to rfc2478 wouldn't interop
with MS's implementation -- or Sun's when in MS interop mode (which is
the default).  Further, I suspect that such implementations aren't being
used with Windows peers as otherwise Larry surely would be aware of such
implementations.

Just because we have disjoint sets of implementations doesn't mean we
shouldn't consider interop between them, but I fear that the worst case
scenario will bring us back to flag days and out-of-band configuration
mechanisms.

It would be good to hear from Martin about how the implementations he's
aware of handle the "mechListMIC request" in Larry's proposal.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Wed, 24 Nov 2004 14:38:05 -0500

>>>>> "Jeffrey" == Jeffrey Altman <[email-masked]> writes:

    Jeffrey> (3) At IETF61 there was a consensus call in the meeting
    Jeffrey> room asking whether the use of optimistic tokens will be
    Jeffrey> specified in 2478bis as a "SHOULD" or a "MAY".  There was
    Jeffrey> no consensus in the room.  Is there consensus on the
    Jeffrey> mailing list?

Interesting.  Who in the meeting spoke in favor of may not should.

I favor should.  Martin has given a good explanation for why we need
should not must.  Ken also gave some arguments for should.  So far I
have seen no justification that successfully explained why should
isn't good enough.

    Jeffrey> (4) Martin raised the possibility that implementations of
    Jeffrey> SPNEGO outside of the current list participants might be
    Jeffrey> broken by the new SOMIC rules or other changes.  In the
    Jeffrey> absence of additional data it is very hard to make a
    Jeffrey> determination as to how great a risk this is.  What I am
    Jeffrey> wondering is what we can do to try and track down some of
    Jeffrey> these additional implementations?  Martin, do you have
    Jeffrey> any ideas?

Given the confusion about encoding of the MIC in 2478, I don't think
it all that likely we have interoperable implementations of that spec
at all.

    Jeffrey> (5) There was discussion on the list on the subject of
    Jeffrey> whether or not there should be explicit text added to the
    Jeffrey> draft recommending that implementations replace a SPNEGO
    Jeffrey> token with a mech specific token when only one mech is
    Jeffrey> available in the initiator.  It seems to me that doing so
    Jeffrey> would improve the security of the protocol as well as
    Jeffrey> improve the performance.  I did not see the discussion
    Jeffrey> reach a conclusion one way or the other.  Does anyone
    Jeffrey> have some proposed text for this or should it be dropped?

I think it should be dropped.  I don't see how it improves security.

    Jeffrey> (6) There was a discussion on the history of the term
    Jeffrey> "mechanism variants".  I would prefer to either see
    Jeffrey> undefined terms be removed from documents or be defined.
    Jeffrey> Martin, could you propose some text to be added to the
    Jeffrey> document which can be used to define the meaning of this
    Jeffrey> term?

This sounds like a big rathole to me.  I'd rather manage to avoid this
discussion somehow.

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 24 Nov 2004 14:45:54 -0500

> have seen no justification that successfully explained why should

In the meeting when I asked the question no one offered an opinion
one way or another.  Therefore, I feel obliged to ask the question
on the list.  I agree that the consensus appears to be "SHOULD".
If there are objections I want to hear them.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Nov 2004 13:55:22 -0600

I agree with all of Sam's comments, but I think we may have to do a bit
more work to see that (4) is not an issue -- though even if it is, I
don't see what we can do about it other than require configurable
support for one way or the other.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 24 Nov 2004 23:31:26 +0100 (MET)

>      consensus in the room that backward compatibility was more

Now I'm a little confused.  The new document contains a few clearly
backwards incompatible changes, and some of them are neither necessary
nor sensible.

Reading the current document and following the discussion I get the
impression that we're heading to standardize Microsoft's defective
installed based and create a significantly more complex and backward
incompatible standard.

Personally, I would appreciate if we kept the original standard,
added clarifications where necessary, and as an appendix listed
a few protocol-violating changes if one intends to interoperate
with Microsofts broken implementation and the security implications
of not requiring or not sending the mechListMIC token in those
scenarios.

>      we are not aware of.  As such I believe doing so would be in

Not only does it break backwards compatibility, it artificially limits
SPNEGO to a subset of mechanisms allowed by GSS-API v2 (rfc2743/44),
and is therefore the entirely wrong place for such a limitation.

If GSS-API doesn't prohibit mechanisms that lack integrity, then
SPNEGO should do it either.  I would agree to a SHOULD NOT include
gssapi mechanisms lacking integrity protection, but I will NOT agree
to MUST NOT. 

>      Is there consensus on the mailing list?

NOPE!

It is NOT necessary to change the MAY, it will not improve interoperability
in any way, and the MAY will not discourage anyone from implementing it
(for anyone with common sense implementing SPNEGO -- and for those who
don't understand the possible benefit, the MAY should make it easier
to idenify implementations that we should avoid ... :)

But what I really dislike is the suprising "MUST process" of the
optimistic token for the acceptor -- while rfc2478 said MAY ignore.

This is is entirely against IETF conventions of rev'ing standard
track protocol specs, a SHOULD process is the only sensible
(and the only backwards compatible) change we could do here.

>      of these additional implementations?  Martin, do you have any

Sorry, I don't.

I don't know whether Denis Pinkas or Eric Baize (listed as authors on
the original SPNEGO document) still work for Bull and one SESAME issues
and can provide feedback on the evolution of their former SNEGO implementation
on which the SPNEGO spec was founded. 

I was surprized how many independent (mostly proprietary) implementations
of gssapi mechanism exist.  I got to know then only because the vendors
asked for interoperability certification of their product with our
application.  I don't know how many of them (if any) are or have
ever participated in IETF activities.  Here's a quick list of companies:

ietf mechanism:         Company (Country)

    Kerberos 5             MIT, CyberSafe, CA/Platinum, Microsoft, heimdal
    SPKM                   Entrust (CA), Shym (US), Baltimore (US)

proprietary mechanisms:

    AM-DCE                 Bull (FR)
    (propr.)               Sagem (FR)
    sdti,rsakeon,trustnet  TFS-Tech (SE) former RSA/SDTI 
    safelayer              Safelayer (SP)
    NEC Secureware         NEC (JP)
    itsec                  UBS/ITsec (CH)
    Adnovum GSSv2          UBS/Adnovum (CH)
    ISign/secui            Penta Security Systems (South Korea)
    Sisler                 Siemens India (India)
    cpro                   Mecomp (RU)
    lissi                  Lissi (RU)
    kobil                  Kobil GmbH (DE)
    T-Secure               secunet/Telekom (DE)

how many do you recognize?

>      proposed text for this or should it be dropped?

In addition,
the explicit requirement for an SPNEGO acceptor to dispatch an
initial non-SPNEGO security context token correctly to the
corresponding mechanism (if available) should be added, because the
existing implicit requirement seems not to be obvious for everyone.

>      to be added to the document which can be used to define the meaning

I can only come up with "hear-say" and the text from the originally
circulated SNEGO proposal from Denis Pinkas and Eric Baize.  But that
really isn't a lot.  Most of the variants issue was discussed in
person, maybe even in break or hallway discussion that did not get
captured in any minutes.

-Martin

PS: Lacking time, I still have only glanced through the document.
    It's 11:30pm here now, and I gotta go home.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Nov 2004 17:20:16 -0600

> installed based and create a significantly more complex and backward

Well, that's the thing, we have at least one implementation, MS', that
is widely deployed and not faithful to rfc2478, broken in a particular
way such that recovering from it will require flag days or sacrifice of
some degree of interop.  If there are other widely deployed
implementations we need to hear about them and figure out what we can
do, if anything, to recover from this.

> of not requiring or not sending the mechListMIC token in those

This is worth considering, and if we do this we ought to have a
requirement for a configuration knob for selecting which behaviour to
use.

> gssapi mechanisms lacking integrity protection, but I will NOT agree

SHOULD NOT is fine by me.

> to idenify implementations that we should avoid ... :)

I don't care if it's MAY or SHOULD, but do see Love's note about
Heimdal's implementation -- evidently saying 'SHOULD' would help interop
with Heimdal.

> optimistic token for the acceptor -- while rfc2478 said MAY ignore.

If the acceptor selects that mechanism then it should be MUST process --
how is the initiator to know that the acceptor didn't process its
optimistic token even though it accepted that mechanism?

> how many do you recognize?

None, and I worked for a subsidiary of one of those companies :/

That list is surprisingly -- and satisfyingly -- long.

> existing implicit requirement seems not to be obvious for everyone.

I'm not sure I follow (5).  But the acceptor should reply with a token
for the mechanism named in the initiator's initial token's frame, which
would be SPNEGO if the initiator used SPNEGO.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 25 Nov 2004 00:22:32 +0100 (MET)

> I think it should be dropped.  I don't see how it improves security.

I do not think it improves security either.

That was only to improve interoperability with gssapi mechanisms
that don't have an accompanying SPNEGO.

-Martin

---

From: Luke Howard <[email-masked]>
Date: Thu, 25 Nov 2004 10:27:55 +1100

>Heimdal's implementation -- evidently saying 'SHOULD' would help interop

Taking my implementor's hat off, I don't think the specification should
be relaxed just because one implementation isn't fixed, particularly if
it is not widely deployed (correct me if I'm wrong but I don't know too
many people using Heimdal's SPNEGO).

-- Luke

--

---

From: Martin Rex <[email-masked]>
Date: Thu, 25 Nov 2004 00:39:27 +0100 (MET)

> optimistic token even though it accepted that mechanism?

How do you understand the following text from rfc2478, under
NegTokenTarg/NegResult, page 8:

                                         this feature allows to make a
          difference between a mechToken sent by the initiator but not
          processed by the target (accept_incomplete) and a mechToken
          sent by the initiator and processed by the target
          (accept_completed).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Nov 2004 17:48:37 -0600

>           sent by the initiator and processed by the target

That works only for mechs with one-token exchanges and...  See the rest
of that paragraph:

          Note: For the case where (a) a single-token context setup is
          used and (b) the preferred mechanism does not support the
          integrity facility which would cause a mechListMIC to be
          generated and enclosed, this feature allows to make a
          difference between a mechToken sent by the initiator but not
          processed by the target (accept_incomplete) and a mechToken
          sent by the initiator and processed by the target
          (accept_completed).

Nico
--