Subject: SPNEGO at IETF 56

From: Wyllys Ingersoll <[email-masked]>
Date: Fri, 31 Jan 2003 08:13:46 -0500

Does anyone think that the issues discovered with the SPNEGO implementations
merit further discussions at the upcoming meeting ?

Microsoft's SSPI "Negotiate"  implementation is not RFC compliant and it is
impossible to implement an RFC-compliant SPNEGO mech of your own and still
be able to interoperate with MS.  These problems were documented on this list
back in early December.    One must adopt the same "broken" parts in any new
mechanisms that are developed in order to be interoperable.

one possible solution:   update RFC-2478 to clear up any ambiguities and release
SPNEGO v2 with a new OID so that one could then differentiate between the 2 versions.

[ another solution:  Microsoft could issue a fixed mechanism, but that would likely break
compat with their older releases and would not help people who need to negotiate
with the existing broken systems and is thus probably not likely to happen. ]

I am not necessarily advocating this approach, merely suggesting it as a possible solution.
I'm not even sure that enough people are aware or care about the problem at this point.
Any thoughts?

-Wyllys Ingersoll

---

From: Sam Hartman <[email-masked]>
Date: Fri, 31 Jan 2003 10:07:15 -0500

>>>>> "Wyllys" == Wyllys Ingersoll <[email-masked]> writes:

    Wyllys> Does anyone think that the issues discovered with the
    Wyllys> SPNEGO implementations merit further discussions at the
    Wyllys> upcoming meeting ?

Only if you can phrase the discussions in terms of activities that are
within the scope of this WG.  Otherwise have the discussion on the CAT
list and possibly have a hallway meeting and then summarize discussion
back to the cat list.

I ceartainly do think spnego needs to be dealt with.

---

From: Wyllys Ingersoll <[email-masked]>
Date: Fri, 31 Jan 2003 11:11:24 -0500

> list and possibly have a hallway meeting and then summarize discussion

I thought that the CAT list was dead and most GSS-API related discussions
were handled by krb-wg.

> I ceartainly do think spnego needs to be dealt with.

Agreed, we just need to find the proper channels to address the problem.
If KRB-WG is inapproriate and CAT-WG is no longer "alive", then where
should this discussion be handled ?

Doug - do you have any suggestions on how to handle this?

-Wyllys

---

From: Martin Rex <[email-masked]>
Date: Fri, 31 Jan 2003 17:52:01 +0100 (MET)

> merit further discussions at the upcoming meeting ?

Depends on who of those that participate any discussion around
SPNEGO will actually be going to the IETF Meeting.  I'm not going.

> one possible solution: update RFC-2478 to clear up any ambiguities and
> release SPNEGO v2 with a new OID so that one could then differentiate
> between the 2 versions.

I'm confused: which ambiguities are there in RFC-2478 that need
clarification?  As far as I understand the spec is crystal clear
and Microsoft completely foobar'ed their implementation.

> 
> [ another solution:  Microsoft could issue a fixed mechanism, but that
> would likely break compat with their older releases and would not help
> people who need to negotiate with the existing broken systems and is thus
> probably not likely to happen. ]

Microsoft MUST fix their implementation.  Their current implementation
doesn't provide the "(P)rotection" part of SPNEGO at all and is incompatible,
so it would be totally useless to standardize such broken behaviour.

IIRC you mentioned that their current implementation can be recognized
because it is using an invalid Kerberos mechanism OID
1.2.840.48018.1.2.2 instead of 1.2.840.113554.1.2.2 in the mechanism 
list so as a workaround other implementations that may want to
interoperate with Microsofts broken implementation could use that
to recognize the broken peer and use the broken incompatible handshake.

Microsoft themselves should use the exact same approach.  I hope that
they don't release a new version with the correct OIDs and the broken
handshake.  QA testing (or interop testing) BEFORE they ship would be
*REALLY* helpful this time around.

> I'm not even sure that enough people are aware or care about the problem

I do care somewhat.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 31 Jan 2003 17:58:44 +0100 (MET)

> I ceartainly do think spnego needs to be dealt with.

CAT is no longer.

Most of the CAT fanciers that are actually still participating
IETF activities may be on the ietf-krb mailing list, but
I actually don't know what the following people are up to
these days:  John Linn, Marc Horowitz, Bill Sommerfeld, Ted Ts'o.

SNEGO was a proposal from Denis Pinkas and was enriched
with "(P)rotection" by Marc Horowitz and Bill Sommerfeld.

I don't know whether the mail exploder still exists,
but IETF-wise the working group was concluded after it had
been "dormant" for quite some time.

-Martin

---

From: Wyllys Ingersoll <[email-masked]>
Date: Fri, 31 Jan 2003 12:08:25 -0500

Martin Rex wrote:
...
> to recognize the broken peer and use the broken incompatible handshake.

That only works if you are the acceptor.   If you are the initiator, you must
know before you send your initial token that you are talking to MS so you
can make sure NOT to send the MechListMIC field because it causes problems
later if you do.

-Wyllys

---

From: Sam Hartman <[email-masked]>
Date: Fri, 31 Jan 2003 12:10:48 -0500

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

    Martin> Wyllys Ingersoll wrote:

    Martin> I'm confused: which ambiguities are there in RFC-2478 that
    Martin> need clarification?  As far as I understand the spec is
    Martin> crystal clear and Microsoft completely foobar'ed their
    Martin> implementation.

No, RFC 2478 is one of the most confusing IETF documents I have ever
had the displeasure to work with.  I wish that I had been more
involved at the time to block consensus on it.

The only critical flaw is that the document does not describe what
should be checksummed in the mechlistmic; is it the DER encoding of
the sequence?  With or without tag?
 Etc.  

Everyone who has tried to implement has been confused by this.
Microsoft clearly got it wrong, although it is not clear how much a
correct spec would have helped them.  I know Sun was unsure what to
do; I certainly was and the Heimdal people also ran into problems with
this.

To respond to Wyllys, the cat list is not dead--if you send mail there
we'll get it, but the working group is unfortunately dead.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 31 Jan 2003 11:23:40 -0600

> I thought that the CAT list was dead and most GSS-API related discussions

No, these are not in our domain. The CAT is just not meeting. 

-- 

 Douglas E. Engert  <[email-masked]>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

---

From: Martin Rex <[email-masked]>
Date: Fri, 31 Jan 2003 18:26:06 +0100 (MET)

> can make sure NOT to send the MechListMIC field because it causes problems

OK, I think I see what you mean about the ambiguity.

Don't send a MechListMIC in the initial NegTokenInit message from
the client to the acceptor.  When the initial NegTokenInit doesn't
carry the optimistic token it can NEVER contain a MechListMIC,
so I really don't see a problem to never send one with the
initial NegTokenInit.  That is clearly permitted by the current
spec.

What the current SPNEGO spec requires is, that *AFTER* the negotiation
is *COMPLETE* the final NegToken(Init|Targ) *MUST* contain a MechListMIC
when the negotiated mechanism supports integrity protection.

This handshake flaw reminds me of the TLS protocol feature to prevent
a downgrade attack which MSIE implemented in just the wrong way...

-Martin

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 31 Jan 2003 11:30:21 -0600

> > Doug - do you have any suggestions on how to handle this?

Yes, if there are enough people who feel the CAT should be resurrected, 
(it should have 9 lives) then those requesting it suggest this to the 
area directors.

I would suggest that the CAT mailing list be used. Sam indicated that 
it does.  

--

---

From: Martin Rex <[email-masked]>
Date: Fri, 31 Jan 2003 18:41:07 +0100 (MET)

> involved at the time to block consensus on it.

I only hated it because it was ASN.1 all over.
The document itself doesn't seem to be that complicated to me,
even though my ASN.1 skills are basically RSA's Layman's Guide to ASN.1...

> the sequence?  With or without tag?

OK, you win.  :)

DER encoding of the MechTypeList -- but the text says a GetMIC on
"mechTypes", which comes from the initial NegTokenInit.  I don't
know whether that means an additional tag...

NegTokenInit ::= SEQUENCE {
                            mechTypes       [0] MechTypeList  OPTIONAL,
                            reqFlags        [1] ContextFlags  OPTIONAL,
                            mechToken       [2] OCTET STRING  OPTIONAL,
                            mechListMIC     [3] OCTET STRING  OPTIONAL

-Martin

> do; I certainly was and the Heimdal people also ran into problems with

I requested several times that the SPNEGO spec ASN.1 stuff should
be accompanied by bits-n-bytes descriptions of the tokens so that
non-ASN.1 implementors would have less hazzles but noone listened.

Denis responded that he's an "architect" and doesn't care about
implementation and bits-n-bytes...

> we'll get it, but the working group is unfortunately dead.

OK, then give it a try.
I never unsubscribed from cat-ietf -- so if the list is still
functioning and none of the others unsubscribed then it may
be worth trying...

-Martin