Subject: Review: of draft-ietf-kitten-2478bis-03.txt

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 16 Dec 2004 21:14:09 -0500

Sam Hartman asked me to look at the 2478bis-03 draft.

I should first say that it's been a long time since i've looked at
anything GSSAPI related at this level of detail.  My review is largely
confined to higher level details; I'll leave it to someone else to
determine if the bits-on-the-wire encodings match reality.

1) safety of omitting mechlistMIC:

The safety, or lack there of, of making the mechlistMIC optional
appears to depend in part on all of the acceptable mechanisms sharing a
property: they will never mistake a token for another mechanism as if
it were intended for them.  this property needs to be explicitly
spelled out in the spec.

The safety of omitting the mechlistMIC when the first choice is picked
depends on mechanisms reliably rejecting tokens not intended for them;
this property needs to be documented.

A thought experiment: 

Consider a pair (or larger sized sets) of mechanisms with different
semantics but identical syntax, which share a common underlying
credential mechanism.

here's a slightly twisted example: a server-authentication-only
variant of kerberos where mutual authenticaton is done as usual but 
where the identity presented to the target application is anonymous/"nobody".

assume the client is juggling multiple kerberos identities, and would
present one with the server-auth-only mech and a different one to the
regular kerberos mechanism.

It seems like it would be possible in this case for a MITM to mess up
the negotiation unless the mechanism OID is cryptographically linked
to the exchange.

2) excessive optimistic negotiation flexibility.

Excessive numbers of options and configuration knobs present a real
cost to implementors and users.

whether or not to send an optimistic token should perhaps be a
property of the mechanism, either in the mechanism spec (for new
mechanisms) or in a separate spec.

3) a potential race condition (page 6: client "MUST NOT" include mechs
it doesn't't have creds for in the list of acceptable mechanisms).

Credentials could be administratively deleted between the first
message and the response.  when the server responds accepting an
option no longer open to the client, the client will essentially be
forced to abort the negotiation (at application level?) and retry.

It could also be the case that mechanisms requiring an interaction
with an on-line service to produce or validate a token could encounter
a soft failure due to connectivity problems.

the net result of this is an exchange which looks to the server or an
external third-party observer as if the client violated this MUST
NOT...

4) This statement in appendix B needs more detail.

   "Even if there are such implementations, it is
   unlikely that they will interoperate because of a critical flaw in
   the description of the encoding of the mechanism list in RFC 2478."

what was this flaw?  if there are multiple possible interpretations,
an implementation could well try multiple reformulations of the input
to the hash function..

overall:
	allow implementations to cache state and/or policy about peer
	capabilities, as a better interoperability solution than
	failing to interop with the RFC?

5) vague material in sec-cons (page 18):

   The negotiation may not be terminated if an alteration was made but
   it had no material impact.

This is very ambiguous as it's not clear whether it is forbidding
termination in this case or merely allowing continuation.  I think you
mean:

   If the receiver detects an alteration, but the alteration had no
   material impact on the negotiation, the reciever MAY opt to continue
   the session.

It's also the case that "material alteration" is not defined.

6) appendix C example:

IMHO you should should also pick an example mechanism, key,
etc., and include the computed MIC.

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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 20 Dec 2004 14:45:20 -0600

> this property needs to be documented.

Bill's right.  Some of you may remember a similar issue when we
considered how the new Kerberos V mechanism might be extended in the
future.

And Bill's thought experiment is not so far fetched.  The OID in the
initial token outer wrapper could be used to select different semantics
for mechs with similar syntax and credentials, though that be
inadvisable unless those mechanisms actually provide integrity
protection for that OID (note that none of the mechs defined by IETF
documents do).

> mechanisms) or in a separate spec.

Unfortunately changing the SPNEGO's OID is out of the question -- how
would one negotiate which version of SPNEGO to use?  How would new
implementations interop with currently deployed Windows implementations?

> forced to abort the negotiation (at application level?) and retry.

Credentials can expire in the middle of the context negotiation; when
that happens the context negotiation may (should) fail.  Tough luck.

> a soft failure due to connectivity problems.

That's true with or without SPNEGO in the mix.

That said, for some mechanisms it'd be a good optimization for SPNEGO to
call GSS_Init_sec_context() to determine, prior to offering a mechList,
whether the initiator actually would fail to setup a context with the
given target acceptor in spite of having credentials.  For other
mechanisms this be not be an optimization at all, but worse.

> external third-party observer as if the client violated this MUST

But is that a problem?  I don't think so.

> 	failing to interop with the RFC?

If interop with legacy implementations means reduced security then
caching knowledge about legacyness of peers seems dangerous.  Policy,
OTOH, is different; OOB policy should be allowed, but if there's no
standard mechanism for distributing such policy then it should probably
not be encouraged.

Nico
--