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

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Mon, 3 Jan 2005 22:21:53 -0800

Bill Sommerfeld wrote:
> 1) ...
> 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.

I disagree. The security of SPNEGO-bis does not depend on whether the
optimistic token is used or not.

It is interesting to find out the implication that a mech token can be
accepted by two different mechs, but I am not sure either this can be a
security issue for SPNEGO-bis or SPNEGO-bis is not able handle it
correctly with the current protocol.

About the thought experiment, this is not strictly necessary in that:
1) the proof of the security is not difficult (it can be done using
exhaustive enumerations of different sub-cases) and 2) the description
in section 5 can be easily mapped to thought experiments you are looking
for.

Nico responded to 2, 3) and 4). I agree with him, therefore no change
will be made for those comments.

5) > This is very ambiguous as it's not clear whether it is forbidding
termination in this case or merely allowing > 
> continuation.

The normative description is in section 5.

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

This is incorrect: no attempt is made to detect alterations when it is
safe to omit the meclistMIC tokens and if an alteration is detected, the
current protocol requires the negotiation to fail.

This sentence is more of an observation therefore I can remove it from
security considerations.
 
> 6) appendix C example:
> IMHO you should also pick an example mechanism, key, etc., and include
the computed MIC.

This section is not meant to provide test-vectors; rather Wyllys'
example is used to illustrate what is the encoding of a specific ASN.1
type. I believe the point is clearly illustrated, and providing exact
values will in fact hurt the presentation.

-- larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bill Sommerfeld
Sent: Thursday, December 16, 2004 6:14 PM
To: [email-masked]
Cc: Sam Hartman; Russ Housley
Subject: Review: of draft-ietf-kitten-2478bis-03.txt

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

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

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Jan 2005 01:02:16 -0600

> in section 5 can be easily mapped to thought experiments you are looking

Bill's thought experiment is, IMO, on the money -- it just isn't
specific to SPNEGO.

Basically if the OID in the pseudo-ASN.1/DER wrapper on the first GSS
token is significant w.r.t. and if the mechanism does not provide
integrity protection for that OID, then there may exist an attack on
that mechanism involving an MITM changing that OID on the wire.

But this is not specific to SPNEGO because an acceptor doesn't need
SPNEGO in order to be able to accept contexts for multiple mechanisms at
the initiator's choice.  That's the way GSS_Accept_sec_context() works.
In a multi-mechanism GSS environment it has to route the initial token
to the code corresponding to the OID in that wrapper, if the acceptor
credential has an element corresponding to it; the mech may output a
different actual OID at the end than was used on the wire in that
wrapper, but that doesn't mean that mechanism actually provided any
integrity protection to that OID.

Yet, while I think we can dispose of Bill's thought experiment as being
general to the GSS-API, rather than specific to SPNEGO, I also think
it's still worthy of mention in the security considerations as I'd
rather it be discussed in some GSS RFC than in none at all (to be fair,
I haven't checked that it isn't mentioned in any of the GSS RFCs).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Jan 2005 01:24:48 -0600

> I haven't checked that it isn't mentioned in any of the GSS RFCs).

I propose this text for this security consideration:

   Note that the mechanism OID in the pseudo-ASN.1/DER wrapper on
   initial GSS-API context tokens may not be integrity protected by the
   actual mechanisms.  If a mechanism does not provide integrity
   protection for the OID in the initial token wrapper and if there
   exists more than one OID for that mechanism such that the OID used in
   the wrapper is significant to the mechanism, then there may exist
   attack against the mechanism where a man in the middle modifies the
   OID in the mechanism's initial context token wrapper.  Since SPNEGO
   does not provide any additional integrity protection for the
   mechanism context tokens it transports than any negotiated mechanism
   would SPNEGO does nothing to prevent this attack.

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Jan 2005 10:27:13 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Tue, Jan 04, 2005 at 01:02:16AM -0600, Nicolas
    Nicolas> Williams wrote:
    >> Yet, while I think we can dispose of Bill's thought experiment
    >> as being general to the GSS-API, rather than specific to
    >> SPNEGO, I also think it's still worthy of mention in the
    >> security considerations as I'd rather it be discussed in some
    >> GSS RFC than in none at all (to be fair, I haven't checked that
    >> it isn't mentioned in any of the GSS RFCs).

Your text is overly specific.  The problem can also happen if one
mechanism's tokens can be converted into the tokens of another
mechanism.  I think you are focusing too much on the OID, although I
agree integrity-protecting the OID does fix the problem.

    Nicolas> I propose this text for this security consideration:

    Nicolas>    Note that the mechanism OID in the pseudo-ASN.1/DER
    Nicolas> wrapper on initial GSS-API context tokens may not be
    Nicolas> integrity protected by the actual mechanisms.  If a
    Nicolas> mechanism does not provide integrity protection for the

How about
and if an attacker can convert the token of that mechanism into the token of some other mechanism by making structural changes to the token.

Note that if the OID changes, the mechanism changes by definition.

    Nicolas> OID in the initial token wrapper and if there exists more
    Nicolas> than one OID for that mechanism such that the OID used in
    Nicolas> the wrapper is significant to the mechanism, then there
    Nicolas> may exist attack against the mechanism where a man in the
    Nicolas> middle modifies the OID in the mechanism's initial
    Nicolas> context token wrapper.  Since SPNEGO does not provide any
    Nicolas> additional integrity protection for the mechanism context
    Nicolas> tokens it transports than any negotiated mechanism would
    Nicolas> SPNEGO does nothing to prevent this attack.

    Nicolas> Nico --

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Jan 2005 10:37:44 -0500

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)> 5) > This is very ambiguous as it's not clear
    Liqiang(Larry)> whether it is forbidding termination in this case
    Liqiang(Larry)> or merely allowing >
    >> continuation.

    Liqiang(Larry)> The normative description is in section 5.

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

    Liqiang(Larry)> This is incorrect: no attempt is made to detect
    Liqiang(Larry)> alterations when it is safe to omit the meclistMIC
    Liqiang(Larry)> tokens and if an alteration is detected, the
    Liqiang(Larry)> current protocol requires the negotiation to fail.

I actually like text similar to what's there to stay in the document.
    Let's see if we can come up with wording that is more clear.  How
    about: Alterations to SPNEGO messages that do not affect the
    results of the negotiation are not always detected.  For example,
    an attacker could add the OID of some mechanism to the end of the
    initiator's list of proposed mechanisms.  If the rules in section
    5 do not require MICs be exchanged for the negotiation in
    question, the initiator will not discover that the message is
    altered.  Since this can only happen in cases where the alteration
    has no affect no the result of the negotiation, the attacker does
    not gain an advantage by making the alteration.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Jan 2005 11:31:02 -0600

> agree integrity-protecting the OID does fix the problem.

Right.  Second try:

   Note that where there exist multiple mechanisms with similar context
   tokens, but different semantics, such that some or all of the
   mechanisms' context tokens can be easily altered so that one
   mechanism's context tokens may pass for another of the similar
   mechanism's context tokens, then there may exist downgrade or similar
   attacks.  For example, if a given family of mechanisms uses the same
   context token syntax for two or more variants and depends on the OID
   in the initial token's pseudo-ASN.1/DER wrapper, but does not provide
   integrity protection for that OID, then there may exist an attack
   against those mechanisms.  SPNEGO does not generally defeat such
   attacks.

Nico
--