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

[Greg Hudson <[e-mail]>]

On 08/24/2016 01:20 AM, Shawn M Emery wrote:
> On 08/17/16 09:58 AM, Greg Hudson wrote:
>> On 08/16/2016 12:12 AM, Shawn M Emery wrote:
>>>> 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.
>>> 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.
>> 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."
> 
> 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.

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.