IETF Logo Mail Archive

Re: [kitten] draft-ietf-kitten-iakerb-02

Greg Hudson <ghudson@mit.edu> Mon, 27 October 2014 15:25 UTC

Return-Path: <ghudson@mit.edu>
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 09CC11A8897 for <kitten@ietfa.amsl.com>; Mon, 27 Oct 2014 08:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 CcHLlWQSpBvv for <kitten@ietfa.amsl.com>; Mon, 27 Oct 2014 08:25:23 -0700 (PDT)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1A41A888E for <kitten@ietf.org>; Mon, 27 Oct 2014 08:25:22 -0700 (PDT)
X-AuditID: 1209190d-f79c06d000006f95-42-544e63e16060
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id CC.A8.28565.1E36E445; Mon, 27 Oct 2014 11:25:21 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s9RFPG0A008927; Mon, 27 Oct 2014 11:25:16 -0400
Received: from [18.101.8.220] (vpn-18-101-8-220.mit.edu [18.101.8.220]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s9RFPEkw028284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 27 Oct 2014 11:25:15 -0400
Message-ID: <544E63DA.2030102@mit.edu>
Date: Mon, 27 Oct 2014 11:25:14 -0400
From: Greg Hudson <ghudson@mit.edu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Benjamin Kaduk <kaduk@mit.edu>
References: <alpine.GSO.1.10.1410141053220.27826@multics.mit.edu> <54402CAC.3010209@mit.edu> <alpine.GSO.1.10.1410241543520.27826@multics.mit.edu>
In-Reply-To: <alpine.GSO.1.10.1410241543520.27826@multics.mit.edu>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrfsw2S/EoOGGjcXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8f3aHLaC3RwVN3t72RsY77B1MXJySAiYSJxf+J0RwhaTuHBv PVCci0NIYDaTxNcNz5kgnI2MEm/mHmOHcI4wSfRvOMQM0sIroCZxa2ozC4jNIqAq0dGyFSzO JqAssX7/VqA4B4eoQJjE1KU8EOWCEidnPgErFxFQklh8tgXsCmYBYYkL2/eygtjCAoYSzyf8 ZoTYNYlRYvXDDrCZnAJOEt0dk6Ea9CR2XP/FCmHLS2x/O4d5AqPgLCQ7ZiEpm4WkbAEj8ypG 2ZTcKt3cxMyc4tRk3eLkxLy81CJdI73czBK91JTSTYzgcJXk3cH47qDSIUYBDkYlHt4Jxb4h QqyJZcWVuYcYJTmYlER5p8b6hQjxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4T0VAJTjTUmsrEot yodJSXOwKInzbvrBFyIkkJ5YkpqdmlqQWgSTleHgUJLgnZIE1ChYlJqeWpGWmVOCkGbi4AQZ zgM0vBekhre4IDG3ODMdIn+KUVFKnPdiIlBCACSRUZoH1wtLJ68YxYFeEebNA2nnAaYiuO5X QIOZgAYbTfMBGVySiJCSamCM4GANkdyeHjtp16yETE3n0IMyqyK+PC5XNItetXnygrTOYKFb C59db8lz2a6w0+6C9+QNkXduPRMyT+ItrTy3VkuNaferjEs9CS832/7Mk3lQMSlpymaT2R3i kYGLgjsk6s8JJ688cqvs3tFjP6z1Wh7ucdvV0lanPkn4Xiv3wRL+dw7bsyOUWIozEg21mIuK EwHdIzYCAgMAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Nro0czY4sM8LJJzFAuSx4XIRmV0
Cc: kitten@ietf.org
Subject: Re: [kitten] draft-ietf-kitten-iakerb-02
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, 27 Oct 2014 15:25:25 -0000

On 10/24/2014 06:08 PM, Benjamin Kaduk wrote:
> Well, it has at least one realm that it knows exists.  (I guess it need
> not strictly speaking know where the KDCs for that realm are...)  This
> case where the client needs to resolve an enterprise name but doesn't have
> a local realm may not be terribly common, so it might be okay to just fail
> the GSS negotiation at this point.  Alternately, the acceptor could pick
> an arbitrary realm it can accept tickets from.  The latter seems to allow
> things to work in more cases than the former, and I don't think it would
> make any cases worse than the former, so I'll probably go with the latter.

As an implementor, I would generally want to just call
krb5_get_default_realm() and return an error if that fails.  But the RFC
should say what error to return.

(I don't think MIT krb5 currently implements this part of IAKERB, since
it wasn't present in the earlier draft that we used.)

> So, "including the generic token framing of the InnerContextToken type
> from [RFC 2743]", then?

I think that's right.

v2.23.0 | Report a Bug | By Email