[secdir] Security review of draft-ietf-kitten-gssapi-channel-bindings-06

canetti <canetti@post.tau.ac.il> Wed, 01 April 2009 09:19 UTC

Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0566628C10A for <secdir@core3.amsl.com>; Wed, 1 Apr 2009 02:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.67
X-Spam-Level:
X-Spam-Status: No, score=-3.67 tagged_above=-999 required=5 tests=[AWL=2.929, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Wmiiv-rjLHt for <secdir@core3.amsl.com>; Wed, 1 Apr 2009 02:19:20 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id EBCC428C16A for <secdir@ietf.org>; Wed, 1 Apr 2009 02:19:19 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n319KJbl019812 for <secdir@ietf.org>; Wed, 1 Apr 2009 05:20:19 -0400
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n319KIsf019809 for <secdir@PCH.mit.edu>; Wed, 1 Apr 2009 05:20:18 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id n319KAht004901 for <secdir@mit.edu>; Wed, 1 Apr 2009 05:20:10 -0400 (EDT)
Received: from doar.tau.ac.il (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 4DC9715B6476 for <secdir@mit.edu>; Wed, 1 Apr 2009 05:20:09 -0400 (EDT)
Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by mit.edu with ESMTP id 4v9WlSVc9nedQ63L for <secdir@mit.edu>; Wed, 01 Apr 2009 05:20:09 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of canetti@post.tau.ac.il designates 132.66.16.26 as permitted sender) receiver=mit.edu; client_ip=132.66.16.26; envelope-from=canetti@post.tau.ac.il;
Received: from [132.67.110.213] (lap-canetti1.cs.tau.ac.il [132.67.110.213]) by doar.tau.ac.il (Postfix) with ESMTP id F09BCBEFB; Wed, 1 Apr 2009 12:20:08 +0300 (IDT)
Message-ID: <49D331C6.7000407@post.tau.ac.il>
Date: Wed, 01 Apr 2009 12:20:06 +0300
From: canetti <canetti@post.tau.ac.il>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: secdir@mit.edu, kitten@ietf.org, Ran Canetti <canetti@csail.mit.edu>
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
Subject: [secdir] Security review of draft-ietf-kitten-gssapi-channel-bindings-06
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Apr 2009 09:19:21 -0000

   *I have reviewed this document as part of the security directorate's
   *ongoing effort to review all IETF documents being processed by the
   *IESG.  These comments were written primarily for the benefit of the
   *security area directors.  Document editors and WG chairs should treat
   *these comments just like any other last call comments.


This is a very short document. It describes a more generic way of 
formatting the API for channel bindings. The move to a more generic format 
is welcome. One potential objection here, however, is to the requirement 
that compliant implementations MUST interpret the API as having the new 
format. This may have backwards compatibility issues, and for no apparent 
good reason. It might be better to specify the format so that an 
implementation will be able to take also older API formats.
(Since this is not an interoperability or security-sensitive issue, there 
seems to be no reason for the IETF to MANDATE one way over another.)

Best,
Ran


_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir