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

From: "Liqiang\(Larry\) Zhu" <[email-masked]>
Date: Mon, 3 Jan 2005 23:37:26 -0800

Thanks, to confirm this attack can be an issue *only* when integrity
protection is not provided by the established mechanism context, right?

-- Larry

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Monday, January 03, 2005 11:25 PM
To: Liqiang(Larry) Zhu; Bill Sommerfeld; [email-masked]; Russ Housley;
Sam Hartman
Subject: Re: Review: of draft-ietf-kitten-2478bis-03.txt

On Tue, Jan 04, 2005 at 01:02:16AM -0600, 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).

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
-- 

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

---

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

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

    Liqiang(Larry)> Thanks, to confirm this attack can be an issue
    Liqiang(Larry)> *only* when integrity protection is not provided
    Liqiang(Larry)> by the established mechanism context, right?

Not really.  The general attack is independent of whether the
mechanism provides per-message integrity and has a lot more to do with
whether you can manipulate the ciphertext of one mechanism into valid
ciphertext for another mechanism.  It's in the same class as
unauthenticated plaintext attacks discussed in krb-wg.

There is an interesting relation to SPNEGO in that if SPNEGO happens
to exchange MICs and SPNEGO is actually used, the attack is defeated.

I do believe addressing this as a security consideration is
appropriate.  I don't know of mechanisms today that have structurally
similar ciphertext and I believe that we can simply avoid
standardizing such mechanisms in the future.

--Sam

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 4 Jan 2005 10:57:41 -0600

> protection is not provided by the established mechanism context, right?

No.

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 04 Jan 2005 18:13:24 -0500

On Tue, 2005-01-04 at 10:30, Sam Hartman wrote:
> appropriate.

I think that's what I suggested in my initial note: document the 
requirement on mechanisms as clearly as possible and move on.

>   I don't know of mechanisms today that have structurally

IMHO, avoiding structural similarities is the wrong fix here 
(among other reasons, enforcing this assumes mechanism development
is sufficiently serialized that a mechanism developer can know 
what other mechanisms are going to do by the time their mechanism deploys).

instead, in new mechanisms, the mechanism id should be cryptographically
bound into the exchange.

						- Bill

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Jan 2005 18:33:40 -0500

>>>>> "Bill" == Bill Sommerfeld <[email-masked]> writes:

    Bill> On Tue, 2005-01-04 at 10:30, Sam Hartman wrote:
    >> There is an interesting relation to SPNEGO in that if SPNEGO
    >> happens to exchange MICs and SPNEGO is actually used, the
    >> attack is defeated.
    >> 

    Bill> I think that's what I suggested in my initial note: document
    Bill> the requirement on mechanisms as clearly as possible and
    Bill> move on.

It is.

    >> I don't know of mechanisms today that have structurally similar
    >> ciphertext and I believe that we can simply avoid standardizing
    >> such mechanisms in the future.

    Bill> IMHO, avoiding structural similarities is the wrong fix here
    Bill> (among other reasons, enforcing this assumes mechanism
    Bill> development is sufficiently serialized that a mechanism
    Bill> developer can know what other mechanisms are going to do by
    Bill> the time their mechanism deploys).

I have no problem doing this or recommending it.  In some cases it may
be difficult.  Keep in mind that you only need to worry about
mechanisms that share the same underlying credential; I don't
anticipate someone turning a Kerberos TGT into a valid PGP signature
or anything like that.

If for your family of related or semi-related mechanisms, you find it
easier to bind to something other than the OID, that's fine with me.

I do agree that the binding is cryptographic.  I'm treating this
attack as a possible chosen ciphertext attack against GSSAPI
mechanisms.  I realize that I'm using the term ciphertext loosly; what I'm calling ciphertext also includes ASN.1 wrappers and other framing, but
I find thinking of this as a CCA gets me in the right mindset to
consider what solutions are possible and what sorts of manipulations
might produce a successful attack.

--Sam