IETF Logo Mail Archive

Re: [kitten] [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_*

Sam Hartman <hartmans-ietf@mit.edu> Wed, 08 June 2011 16:57 UTC

Return-Path: <hartmans@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 D5A2A11E8116 for <kitten@ietfa.amsl.com>; Wed, 8 Jun 2011 09:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxpg8i0DYtvY for <kitten@ietfa.amsl.com>; Wed, 8 Jun 2011 09:57:13 -0700 (PDT)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7868211E8189 for <kitten@ietf.org>; Wed, 8 Jun 2011 09:57:13 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 59EFD20115; Wed, 8 Jun 2011 12:52:45 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 98CC94426; Wed, 8 Jun 2011 12:57:07 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Nico Williams <nico@cryptonector.com>
References: <201106071831.p57IVNmb010502@fs4113.wdf.sap.corp> <201106071900.p57J0uCN012135@fs4113.wdf.sap.corp> <D5847DD823005F4E9DB94FE77DCEDF680FEE75C2@ALVMBXW01.prod.quest.corp> <87oc29xrtn.fsf@latte.josefsson.org> <BANLkTinvrZioQjwgqy9_jmFqHFvFMyCyaw@mail.gmail.com>
Date: Wed, 08 Jun 2011 12:57:07 -0400
In-Reply-To: <BANLkTinvrZioQjwgqy9_jmFqHFvFMyCyaw@mail.gmail.com> (Nico Williams's message of "Tue, 7 Jun 2011 16:23:48 -0500")
Message-ID: <tslvcwg2rdo.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: kitten@ietf.org, Simon Josefsson <simon@josefsson.org>, "ietf-krb-wg@anl.gov" <ietf-krb-wg@anl.gov>
Subject: Re: [kitten] [Ietf-krb-wg] Channel bindings -- interop issue with GSS_C_AF_*
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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, 08 Jun 2011 16:57:14 -0000

I think RFC 2744 chose the wrong constant for nulladdr; it should have
been 0 not 255.  I think we need to update RFC 2744 and 5554.
I believe that

1) Mechanism implementations should collapse unspecified address with no
actual data and null address together

2) The Kerberos mechanism should do so in a manner compatible with
Microsoft

3) We need to explicitly specify what applications should do here.

If someone argues that we cannot make incompatible changes to 2744, I
respond that compatibility with the implementations we know about is
more important to me than compatibility with the spec and if forced to
choose I will choose the implementations.

v2.46.0 | Report a Bug | By Email | System Status