Subject: RE: Comments on Larry's SPNEGO draft

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 25 Oct 2004 13:56:58 -0700

Martin Rex wrote,
> Except for the situation where the optimistic negotiation is used, 
> security context establishment consists of at most 2 > 
> token exchanges and actually succeeds -- in all other situations the 
> would be interference.

This is incorrect when you use user2user. GSSAPI-CFX has updated RFC
1964 to allow Kerberos mechanisms with 3+ tokens.

About whether we should demote the "SHOULD" on the optimistic token, I
will need to talk with Wyllys and Nico, to see if we should settle on
the protocol such that the "basic form" of the protocol is actually what
we use. Right now, we are deploying an "optional" form of the 2478
SPENGO, and if what is also what Sun does, it means this draft has done
the right thing. Do you agree? 

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Monday, October 25, 2004 12:22 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: Comments on Larry's SPNEGO draft

Sam Hartman wrote:
> 
>  In section 3.2 you claim:
> 
>     On receipt of a negotiation token on the target side, a GSS-API
>     implementation that does not support negotiation would indicate
>     the GSS_S_BAD_MECH status as if a particular basic security
>     mechanism had been requested but was not supported.
> 
> That's actually not true; a mechanism could just as easily return 
> GSS_S_BAD_TOKEN in this state.  Actually there is a possibility 
> involving non-standards-track mechanisms that look a lot like the 
> SPNEGO mechanism where you could get other responses as well, but that

> will not happen in practice.

I'm sorry to disagree with you, Sam, but the quote paragraph seems to be
perfectly correct.

The initial context token MUST use the generic framing with the
mechanism OID for the precise reason that a gssapi mechanism will be
able to recognize whether it supports communication with the peer or
not.  If not, then GSS_S_BAD_MECH is the required major status response.

Btw. GSS_S_BAD_TOKEN does not exist, did you mean GSS_S_DEFECTIVE_TOKEN?
If mechanism does not recognize the SPNEGO mechanism OID, then it can
not know what the rest of the token means, so GSS_S_DEFECTIVE_TOKEN
would be a mere guess and probably the wrong guess in 99.8%.
So it is not only prohibited to return GSS_S_DEFECTIVE_TOKEN, it is also
a pretty bad idea.

> 
> There seem to be several significant semantic changes I'd like to call

> to the attention of the IETF.  I believe we need explicit consensus 
> for these changes:
> 
> 1) The use of optimistic negotiation is promoted to a SHOULD.  This
>     simplifies the description of the protocol because you can
>     generally assume that the client does support including the
>     optimistic token.

The reasoning is maybe that Microsoft has architected some protocols
with SPNEGO that need it badly (it must fail without optimistic
negotiation because the embedding protocol doesn't support an additional
round trip...).

When Denis Pinkas originally proposes SNEGO (without P for "protected")
they had a free sample implementation.  They didn't need the "P" for
their purposes back then, and I think they also didn't need the
optimistic negotiation either.

I have strong reservations against a SHOULD instead of a MAY, because in
the next round someone could try to turn this into a MUST, and I
definitely don't ever want to see a MUST there!

One of the easiest approaches to test whether an embedding protocol that
uses SPNEGO isn't entirely broken is to switch off the optimistic token
(adding another roundtrip to the security context establishment) and
checking whether everything still works just as smooth as it is required
to by the existing spec (which, as I mentioned, isn't true for some uses
architected by Microsoft).

SPGENO is only useful when it is allowed to negotiate, i.e. when it is
allowed to add round-trips to the security context exchange to
accomodate the negotiation.  If the embedding protocol doesn't have
provisions to accomodate that, then it is pointless to call SPNEGO, it
just adds complexity with zero value.

Essentially what I wanted to say:  The benefit of the optimistic token
should be obvious to implementors of SPNEGO.  The absence does not give
applications the permission to fail.  Technically, the MAY is perfectly
sufficient.

> 
> 2) The mechanism requires that all target mechs support integrity
>     protection.  This is a significant change and is
>     non-backward-compatible.

Wasn't that already sufficiently addressed in the security
considerations of the existing spec?  I do NOT see a need to require
integrity protection either.

> 
> 3) prot_ready is forbidden.  I believe this is required for things to
>    work out correctly.

prot_ready was never easy, not even for the regular GSS-API.

The problem with prot_ready is the message sequencing interference of
SPNEGO's use of the get_mic() primitive with the applications use of
message protection facilities.

Except for the situation where the optimistic negotiation is used,
security context establishment consists of at most 2 token exchanges and
actually succeeds -- in all other situations the would be interference.

... and I need to read the document before commenting on the rest.

-Martin

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

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

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 5 Nov 2004 01:08:51 -0800

Martin Rex wrote:
> So you're correct, implementations of SPNEGO that receive an initial 
> security context token from a non-IETF >(gssapi) mechanism that lacks 
> the generic framing will likely return GSS_S_DEFECTIVE_TOKEN rather 
> than > 
> GSS_S_BAD_MECHANISM.

The decision clearly should not be made by SPNEGO but by the underlying
mechanisms.

Please stay on the track, and the current draft only dicusses mechanisms
that are fully compliant with 2743/2744.

-- Larry
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Thursday, November 04, 2004 1:18 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: Comments on Larry's SPNEGO draft

Ooops -- blush.  You're correct, Sam.

Sam Hartman wrote:
> 
>     Martin> The initial context token MUST use the generic framing
>     Martin> with the mechanism OID for the precise reason that a
>     Martin> gssapi mechanism will be able to recognize whether it
>     Martin> supports communication with the peer or not.  
> 
> Section 3.1 of RFC 2743 requires a specific context token framing for 
> IETF standards-track mechanisms.  However no such requirement is made 
> for non-standards-track mechanisms.  We're aware of non-standards 
> track mechanisms that do not use the framing described in this 
> section.

And if I'm not mistaken, then there is actually a large installed base
of an SPNEGO implementation that may send security context tokens from a
non-IETF "mechanism" which does not use the generic token framing.  That
"mechanism" is also known as Microsoft "NT Lan Manager" (NTLM).

So you're correct, implementations of SPNEGO that receive an initial
security context token from a non-IETF (gssapi) mechanism that lacks the
generic framing will likely return GSS_S_DEFECTIVE_TOKEN rather than
GSS_S_BAD_MECHANISM.

-Martin

---

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Fri, 5 Nov 2004 09:30:05 -0800

Martin Rex wrote:
> SPNEGO should *NEVER* rely on trial and error. 

I agree, but is this relevant to the current draft? It is certainly not
what our current implementations do either.

I would be happy to explain to you what are the additional mechanisms we
have in order to be backward compatible with NT4, but please take that
kind of discussions off the list.

-- larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, November 05, 2004 5:44 AM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Comments on Larry's SPNEGO draft

> > security context token from a non-IETF >(gssapi) mechanism that 
> > lacks the generic framing will likely return GSS_S_DEFECTIVE_TOKEN 
> > rather than > GSS_S_BAD_MECHANISM.
> 
> The decision clearly should not be made by SPNEGO but by the 
> underlying mechanisms.

I disagree.

SPNEGO should *NEVER* rely on trial and error.  When
gss_accept_sec_context is called for the first time, SPNEGO does not
know to which underlying gssapi mechanims it should pass the received
initial context token, because the input security context handle is
still undefined.

So SPNEGO MUST try to decode the token to get the hands on the mechanism
OID in order to decide which mechanism to pass the data to.  And only if
an SPNEGO knows about a non-IETF gssapi mechanism which it serves then
it could blindly pass on a token that lacks the generic framing.

> 
> Please stay on the track, and the current draft only dicusses 
> mechanisms that are fully compliant with 2743/2744.

Which is no longer practical, since some vendor created a large
installed base of SPNEGO that will pass on security context token which
lacks the generic context token framing...

-Martin

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Fri, 5 Nov 2004 16:30:21 -0800

Martin, the current draft only discusses mechanisms that are fully
compliant with RFC2744/2743.  I CAN NOT discuss the implementation
details of NTLMSSP because 1) it is not relevant here, 2) one needs a
protocol license to get the information you are asking for.

-- Larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Friday, November 05, 2004 3:42 PM
To: Liqiang(Larry) Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Comments on Larry's SPNEGO draft

Liqiang\ wrote:
> 
> > And, frankly, I think having the latitude to implement things so as 
> > to test for broken assumptions makes a lot of sense, particularly in

> > what's supposed to be a generic framework.
> 
> But this is not specific to SPNEGO and it dose not belong to here.
> furthermore, the word SHOULD does allow you test applications
properly.

It's nice to have and it doesn't hurt.

> 
> > So even if generating the token for the preferred mech is an 
> > expensive operation or involves prompting the user for input, and is

> > known only to be supported by a couple of servers out of the dozens 
> > that the client will use, you think the token should be generated 
> > before negotiating whether the mech will be used?
> 
> Using the optimistic token allows you to select the next available
mech.
> It is a broken design if your gss_init_sec_context involves a prompt 
> (and that is not part of 2743/2744), even worse without letting the 
> users know what the credentials will be used for. This is a security 
> weakness on your side, and we do not have this in SSPI.

Pardon me -- which SSPI are we discussing.

According to my MSDN documentation, Microsoft's SSPI has the following
context attribute flag that can be requested from
InitializeSecurityContext():

  PROMPT_FOR_CREDS   If the client is an interactive user, the security
                     package must, if possible, prompt the user for the
                     appropriate credentials. 

And My VS98\VC98\INLCUDE\SSPI.H file dated 24-Apr-1998 contains the
following definition:

  #define ISC_REQ_PROMPT_FOR_CREDS        0x00000040

I never tried this, so I don't know whether Microsoft's SSPs are
conforming with Microsoft's SSPI spec, however I don't see how that
popup could possibly inform the user about the purpose of the password
prompt.

With NTLM, one doesn't have to supply a target name, and with Kerberos
User2User (which Microsoft's Kerberos SSP offers) it should not
_technically_  be necessary to provide a target name, although I haven't
tested what happens if I do not supply the peers name.

-Martin

---

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Fri, 5 Nov 2004 16:59:26 -0800

Ken Raeburn wrote:
> If it's the preferred method for use with the servers that support it,

> and known to be supported only by a few servers of 
> the many the user is likely to contact, the work should still be 
> done for every server anyways?

You want to avoid/delay these expensive operations till we know for sure
what is the common mech. This should be allowed. In that case, I would
reluctantly agree to demote the "SHOULD" to "MAY", but as a compromise I
would add that the receiver MUST process the optimistic token if one is
included. Do you agree?

-- larry

-----Original Message-----
From: Ken Raeburn [mailto:[email-masked]] 
Sent: Friday, November 05, 2004 4:34 PM
To: Liqiang(Larry) Zhu
Cc: <[email-masked]>
Subject: Re: Comments on Larry's SPNEGO draft

On Nov 5, 2004, at 18:23, Liqiang((Larry)) Zhu wrote:
>> that the
> client
>> will use, you think the token should be generated before negotiating 
>> whether the mech will be used?
>

Well, forget the prompting then.  Expensive operations (big
calculations, excessive directory queries, etc), then.  If it's the
preferred method for use with the servers that support it, and known to
be supported only by a few servers of the many the user is likely to
contact, the work should still be done for every server anyways?

Ken