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

Greg Hudson <ghudson@mit.edu> Wed, 24 August 2016 06:08 UTC

Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F3A12D151 for <kitten@ietfa.amsl.com>; Tue, 23 Aug 2016 23:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.749
X-Spam-Level:
X-Spam-Status: No, score=-4.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlpCUhMZNszg for <kitten@ietfa.amsl.com>; Tue, 23 Aug 2016 23:08:33 -0700 (PDT)
Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FAD12D0FD for <kitten@ietf.org>; Tue, 23 Aug 2016 23:08:33 -0700 (PDT)
X-AuditID: 12074423-d2fff70000004044-35-57bd39df3264
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 94.67.16452.FD93DB75; Wed, 24 Aug 2016 02:08:32 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u7O68Vic013732; Wed, 24 Aug 2016 02:08:31 -0400
Received: from [18.101.8.219] (vpn-18-101-8-219.mit.edu [18.101.8.219]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u7O68T5D019193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 24 Aug 2016 02:08:30 -0400
To: Shawn M Emery <shawn.emery@oracle.com>, kitten@ietf.org
References: <20160726193833.30872.31544.idtracker@ietfa.amsl.com> <57A0C96F.3010606@mit.edu> <cea4402d-728c-f6e2-6685-b8874cf8ea00@oracle.com> <57B48997.7080207@mit.edu> <0a3add89-c32a-2451-d229-e29fba32bf28@oracle.com>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <57BD39DD.3000702@mit.edu>
Date: Wed, 24 Aug 2016 02:08:29 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <0a3add89-c32a-2451-d229-e29fba32bf28@oracle.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6nrvvAcm+4we5vzBZHN69iseh7fYjd gcljyZKfTB4fn95iCWCK4rJJSc3JLEst0rdL4Mr42HmNtWCKSEXLyuOMDYztAl2MnBwSAiYS j3YsZOpi5OIQEmhjkjgzaRIjhLORUeLIsV1sEM4RJol5f16wgrQIC7hKfLrezw5iiwhYS8zc c5YFoug+o8Tvy61MIAk2AWWJ9fu3AiU4OHgF1CSWTI0ACbMIqEr8ed0N1isqECExa/sPsHJe AUGJkzOfsIDYnAJ2ErfuXWMEsZkF9CR2XP/FCmHLS2x/O4d5AiP/LCQts5CUzUJStoCReRWj bEpulW5uYmZOcWqybnFyYl5eapGumV5uZoleakrpJkZwSLoo72B82ed9iFGAg1GJh7cjZE+4 EGtiWXFl7iFGSQ4mJVHem6p7w4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8HaYA+V4UxIrq1KL 8mFS0hwsSuK827+1hwsJpCeWpGanphakFsFkZTg4lCR4WyyAGgWLUtNTK9Iyc0oQ0kwcnCDD eYCGbwap4S0uSMwtzkyHyJ9iVJQS51UBSQiAJDJK8+B6wSkjleP2K0ZxoFeEed+AVPEA0w1c 9yugwUxAg1vu7wYZXJKIkJJqYDSWflbvfImRUXiTVRWD4yflyTW/bKzaF2xY3Gq8/+jqOdc0 3JuEA3paNTvDzN3PlH/+q3eq7vlGTtlH5mq5btZWf0QcA5imzwmpVgqLYZ/Od+9lxbr8qN2N ehO7hE906V93Ol6Ub2R/3Mj2rcjXa00+Zss8woy9Vh99fcfbXv1Z2MFHpf1ySizFGYmGWsxF xYkACHcpEfQCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/QhBq5PjHOPCptItBa7CelHLgy7U>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-01.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Aug 2016 06:08:34 -0000

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.