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

Greg Hudson <> Tue, 02 August 2016 16:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE36212D0E8 for <>; Tue, 2 Aug 2016 09:25:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.508
X-Spam-Status: No, score=-5.508 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yuvTxKnLrk5J for <>; Tue, 2 Aug 2016 09:25:23 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BB6512D0C7 for <>; Tue, 2 Aug 2016 09:25:23 -0700 (PDT)
X-AuditID: 12074422-adfff70000001f37-4b-57a0c971e9c6
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 47.72.07991.179C0A75; Tue, 2 Aug 2016 12:25:22 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id u72GPLlZ008654 for <>; Tue, 2 Aug 2016 12:25:21 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id u72GPKGl005703 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <>; Tue, 2 Aug 2016 12:25:21 -0400
References: <>
From: Greg Hudson <>
Message-ID: <>
Date: Tue, 2 Aug 2016 12:25:19 -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: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixCmqrVt0ckG4way/bBZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvnrNxkLTglWrDx/h7GB8RpvFyMHh4SAiUTDw+QuRi4OIYE2 JokLv88xQjjHGCUmnfnIBuHcZJKY1TWJvYuRk0NYwFXi0/V+MFtIwFFi0tOHzCC2iICwxO6t 78BsNgFlifX7t7KA2LwCahLXVv9kBbFZBFQkpn1uBasRFYiQmLX9BxNEjaDEyZlPwOo5BZwk pi3pYgOxmQX0JHZc/8UKYctLbH87h3kCI/8sJC2zkJTNQlK2gJF5FaNsSm6Vbm5iZk5xarJu cXJiXl5qka6pXm5miV5qSukmRlDwsbso7WCc+M/rEKMAB6MSD29g7vxwIdbEsuLK3EOMkhxM SqK8dYcWhAvxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4Y3aC5TjTUmsrEotyodJSXOwKInzbv/W Hi4kkJ5YkpqdmlqQWgSTleHgUJLgdToB1ChYlJqeWpGWmVOCkGbi4AQZzgM0vBSkhre4IDG3 ODMdIn+KUVFKnFcHJCEAksgozYPrBSeHVI6ZrxjFgV4R5l0JUsUDTCxw3a+ABjMBDT5hADa4 JBEhJdXA2Nxy8aZCwKHK7Iucia07/xUWqG6cwuWwwlPVpvgHS8IysS67w//UjRcIfrcqe3Vw 1wMpxc3rmb3+eGVs9MqafCpjTvDsmi2zmi746orLOdudWflvabahuRtj1KXkyG5vyec96vGa xxvKymbvv828y0EkReebeUhmOadO+g61tX9llzj8jdVUYinOSDTUYi4qTgQA5Q9T2ekCAAA=
Archived-At: <>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-01.txt
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Aug 2016 16:25:25 -0000

On 07/26/2016 03:38 PM, 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.