Subject: Re: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-01.txt

From: Greg Hudson <[email-masked]>
Date: Tue, 2 Aug 2016 12:25:19 -0400

On 07/26/2016 03:38 PM, [email-masked] wrote:
> 	Filename        : draft-ietf-kitten-rfc6112bis-01.txt

This revision appears to be editorial, and would be unlikely to affect
an implementation.  I do not have any substantive protocol concerns, but
I do have some minor issues with some of the new wording.

In section 7, "To ensure that an attacker cannot create a channel with a
given name" was changed to "To ensure that an attacker cannot create a
channel by observing exchanges."  The original wording may have used
"name" in a non-intuitive way, but I think the new wording is more
wrong.  The threat is that a MITM attacker might create two channels
with the same ticket session key (known to the attacker); the new
wording suggests that the threat comes from a passive attacker.

In this text:

    Such authorization data, if included in the anonymous ticket, would
    disclose the that the client is a member of the group observed.	

After the changes, there is an extra "the" before "that".

In this new block of text:

    This protocol provides a binding between the party which
    generated the session key and the DH exchange used to generate
    they reply key.  Hypothetically, if the KDC did not use
    PA-PKINIT-KX, the client and KDC would perfrom a DH key
    exchange to determine a shared key, and that key would be used
    as a reply key.  The KDC would then generate a ticket with a
    session key encrypting the reply with the DH agreement.  A MITM
    attacker would just decrypt the session key + ticket using the
    DH key from the attacker and KDC DH exchange, and re-encrypt it
    using the key from the attacker and client DH exchange, while
    keeping a copy of the session key and ticket.  By requiring the
    session key in a way that can be verified by the client, this
    protocol binds the ticket to the DH exchange and prevents the
    MITM attack.

"perfrom" should be "perform".  "session key + ticket" should be
"session key and ticket".  It might be clearer to say "attacker-KDC DH
exchange" than "attacker and KDC DH exchange", and similarly
"attacker-client DH exchange".

"By requiring the session key in a way that..." is not grammatical.

---

From: Shawn M Emery <[email-masked]>
Date: Mon, 15 Aug 2016 22:12:47 -0600

Thanks for your review.  Comments in-line.

On 08/ 2/16 10:25 AM, Greg Hudson wrote:
> On 07/26/2016 03:38 PM,[email-masked]  wrote:

Yes, the key word "observing" indicates a passive state.  How about?:

To ensure that an attacker cannot create a channel by obtaining key 
exchanges between the client and KDC, it is desirable that neither the 
KDC nor the client unilaterally determine the ticket session key.

> After the changes, there is an extra "the" before "that".

Done.

> "session key and ticket".

Done.

> It might be clearer to say "attacker-KDC DH

Agreed.

> "By requiring the session key in a way that..." is not grammatical.

How about?:

This protocol binds the ticket to the DH exchange and prevents the MITM 
attack by requiring the session key in a way that can be verified by the 
client.

Thanks again for your review.

Shawn.
--

---

From: Greg Hudson <[email-masked]>
Date: Wed, 17 Aug 2016 11:58:15 -0400

> KDC nor the client unilaterally determine the ticket session key.

That still suggests a passive attacker to me.  I suggest:

"To ensure that an active attacker cannot create separate channels to
the client and KDC with the same known key, it is desirable that neither
the KDC nor the client unilaterally determine the ticket session key."

> attack by requiring the session key in a way that can be verified by the

I believe that change just reverses the two main clauses of the sentence
without eliminating the grammar error.  You could say "requiring the
session key to be created in a way...".

---

From: Shawn M Emery <[email-masked]>
Date: Tue, 23 Aug 2016 23:20:56 -0600

> the KDC nor the client unilaterally determine the ticket session key."

I don't think "channels" is the right word in the updated sentence. I 
interpreted the original text to indicate that an active attacker can 
not snoop key exchanges between the client and KDC in order to 
compromise a subsequent secure channel.

> session key to be created in a way...".

Sorry, was focused on the entire sentence.  Done.

Shawn.
--

---

From: Greg Hudson <[email-masked]>
Date: Wed, 24 Aug 2016 02:08:29 -0400

> compromise a subsequent secure channel.

The attack being thwarted is described in the last paragraph of the section:

    A MITM attacker would just decrypt the session key + ticket using the
    DH key from the attacker and KDC DH exchange, and re-encrypt it using
    the key from the attacker and client DH exchange, while keeping a
    copy of the session key and ticket.

To add more detail: the scenario we are trying to protect is that a
client preauthenticates with unverified anonymous PKINIT to obtain a
TGT, then uses that TGT as FAST armor for encrypted challenge (or
another FAST factor with similar properties).  Without the mechanism in
section 7, an attacker in the middle could:

1. Perform its own anonymous PKINIT authentication to the real KDC to
get a ticket with a known session key.

2. Impersonate the KDC to the real client, performing the KDC side of
the anonymous PKINIT.

3. Issue a ticket to the client using the same session key as the one it
got in step 1.

4. Decrypt the subsequent FAST-protected AS exchange using the session
key from step 1.