IETF Logo Mail Archive

Re: [kitten] Kerberos preauth negotiation techniques

Nico Williams <nico@cryptonector.com> Mon, 23 February 2015 21:37 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D11A6F2F for <kitten@ietfa.amsl.com>; Mon, 23 Feb 2015 13:37:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 t6PHYjD5S6ss for <kitten@ietfa.amsl.com>; Mon, 23 Feb 2015 13:37:54 -0800 (PST)
Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E5D6D1A3B9C for <kitten@ietf.org>; Mon, 23 Feb 2015 13:37:54 -0800 (PST)
Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id B85AF2004EE09 for <kitten@ietf.org>; Mon, 23 Feb 2015 13:37:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Kqn1BINK8kAeE2PyTVJN DqH/yMM=; b=GR6gyaZni5+zsRIzZ50WlpgEpk9ZCyZ2Ic/NYyBVKj/tkHu0iFxy pcrDSog6+MAio1NB4QUsrMmSh6JFx1uHg6oOfBY5YMXnzgNwSyqGan/uytoN3eMn NYPowTSE60xg/tc3ARtwWZhlocw9nGWVNJ5LPtBTX8Mt2TXdj9Z9oJ0=
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id AA7462005D82D for <kitten@ietf.org>; Mon, 23 Feb 2015 13:37:54 -0800 (PST)
Received: by iecrl12 with SMTP id rl12so27126327iec.2 for <kitten@ietf.org>; Mon, 23 Feb 2015 13:37:54 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.43.198 with SMTP id y6mr16020897igl.16.1424727474418; Mon, 23 Feb 2015 13:37:54 -0800 (PST)
Received: by 10.64.130.66 with HTTP; Mon, 23 Feb 2015 13:37:54 -0800 (PST)
In-Reply-To: <1424726541.2604.82.camel@redhat.com>
References: <x7da90k47ox.fsf@equal-rites.mit.edu> <1424189675.2645.23.camel@redhat.com> <54E4F31D.5080103@mit.edu> <20150218204339.GR5246@localhost> <1424722422.2604.77.camel@redhat.com> <CAK3OfOjMWrCgS7aSN4-dVv-cBdo2YS+NL-Vs66utBX+KMKoZhg@mail.gmail.com> <1424726541.2604.82.camel@redhat.com>
Date: Mon, 23 Feb 2015 15:37:54 -0600
Message-ID: <CAK3OfOgn9g+8pXB3tj++BPkf0RBTQWgxN1XVVJCsYQ434Y+eXQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/vBiTjfEaKql_AtUHYR3gwzKBgEU>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Subject: Re: [kitten] Kerberos preauth negotiation techniques
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 23 Feb 2015 21:37:55 -0000

On Mon, Feb 23, 2015 at 3:22 PM, Nathaniel McCallum
<npmccallum@redhat.com> wrote:
> On Mon, 2015-02-23 at 15:12 -0600, Nico Williams wrote:
>> On Mon, Feb 23, 2015 at 2:13 PM, Nathaniel McCallum <
>> npmccallum@redhat.com> wrote:
> No. I'm saying that the first message from the client to the server
> contains ONLY a SEQUENCE OF OBJECT IDENTIFIER. The reply contains the
> server's choice from that list, the public key from that chosen group,
> and 2FA parameters.
>
> I'm saying the OID bloat isn't really a problem.

I agree.

BTW, if this were a GSS mech we might have a single mech OID for the
entire {enctype, PAKE, group} negotiation (but not second factor), and
for an IANA registry where one each of three arms of the OID
correspond to enctype, PAKE, group.

Here that would mean that the client advertises multiple PAs, and
would get us into the business of having a registry.

What you propose is fine.

Nico
--

v2.23.0 | Report a Bug | By Email