Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred()

Simo Sorce <simo@redhat.com> Thu, 19 March 2015 17:04 UTC

Return-Path: <simo@redhat.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 DFBFE1A1EFF for <kitten@ietfa.amsl.com>; Thu, 19 Mar 2015 10:04:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.912
X-Spam-Level:
X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, 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 r-kEOLut08bN for <kitten@ietfa.amsl.com>; Thu, 19 Mar 2015 10:04:54 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4969F1A6EE1 for <kitten@ietf.org>; Thu, 19 Mar 2015 10:04:49 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2JH4l1V022406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 19 Mar 2015 13:04:47 -0400
Received: from [10.3.113.73] (ovpn-113-73.phx2.redhat.com [10.3.113.73]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2JH4k4N019986; Thu, 19 Mar 2015 13:04:46 -0400
Message-ID: <1426784686.2981.130.camel@willson.usersys.redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Nico Williams <nico@cryptonector.com>
Date: Thu, 19 Mar 2015 13:04:46 -0400
In-Reply-To: <20150319162847.GG8099@localhost>
References: <20150311001817.GC7286@localhost> <1426771934.2981.127.camel@willson.usersys.redhat.com> <20150319151718.GD8099@localhost> <1426778409.2981.129.camel@willson.usersys.redhat.com> <20150319162847.GG8099@localhost>
Organization: Red Hat, Inc.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/cX1h_cZGU3495nbibwdDYNL_gEk>
Cc: kitten@ietf.org
Subject: Re: [kitten] Permissible (and imp..) side-effects of GSS_Acquire_cred()
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: Thu, 19 Mar 2015 17:04:57 -0000

On Thu, 2015-03-19 at 11:28 -0500, Nico Williams wrote:
> On Thu, Mar 19, 2015 at 11:20:09AM -0400, Simo Sorce wrote:
> > I guess it may be surprising in some cases, and expected in others,
> > unfortunately.
> > If you set the KRB5_CLIENT_KTNAME variable in recent MIT releases you
> > expect a default ccache to be created with whatever is in the keytab for
> > example. But you'd be surprised otherwise.
> 
> Since it's both, sometimes surprising and sometimes expected, you get to
> pick what to end up with.  Perhaps one behavior will cause more customer
> calls than the other.
> 
> But I think there are compromises that get you (a) without breaking
> anyone.  Again:
> 
>  - have a shadow default ccache for the case of acquiring a credential
>    from a keytab when there is no default ccache
> 
>  - use the DIR ccache (does it have the option of not setting a default
>    ccache in the collection?)
> 
>  - don't cache tickets when the default ccache does not exist
> 
>  - if there are keys for only one principal in the keytab, then set
>    the default principal, else don't (and use one of the above fixes)
> 
> And you could always add yet another environment variable, and/or
> krb5.conf parameter.
> 
> To me it seems clear that GSS applications that do simple things like
> GSS_Init/Accept_sec_context() with the GSS_C_NO_CREDENTIAL, or which
> call GSS_Acquire/Add_cred(), do not cause other processes in the system
> to "break".  Actually, this should be true for all GSS apps that do not
> call GSS_Store_cred() (whose entire purpose is to have side-effects).
> 
> Even if you change nothing, I'm inclined to say that (a) is preferred
> and note that (b) is what one sometimes gets, therefore one must read
> the implementation's docs.  I'd like to see this fixed (see above).

Would you consider an explicitly set KRB5CCNAME env variable as an
indication the admin is ok with acquired credentials ending up there ?
Ie a) but using KRB5CCNAME presence as an indication a ccache can be
used ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York