Re: [kitten] Clarification of gss_add_cred() behavior

Benjamin Kaduk <kaduk@MIT.EDU> Thu, 19 March 2015 18:48 UTC

Return-Path: <kaduk@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 3C6C51A879E for <kitten@ietfa.amsl.com>; Thu, 19 Mar 2015 11:48:51 -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 4Ohr6OLK9D-x for <kitten@ietfa.amsl.com>; Thu, 19 Mar 2015 11:48:49 -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 239131A8792 for <kitten@ietf.org>; Thu, 19 Mar 2015 11:48:48 -0700 (PDT)
X-AuditID: 1209190d-f79676d000000da0-e7-550b1a0f792f
Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 52.14.03488.F0A1B055; Thu, 19 Mar 2015 14:48:47 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t2JImlN7015546; Thu, 19 Mar 2015 14:48:47 -0400
Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t2JImiDF013103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Mar 2015 14:48:46 -0400
Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t2JImiGb013196; Thu, 19 Mar 2015 14:48:44 -0400 (EDT)
Date: Thu, 19 Mar 2015 14:48:44 -0400
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: Nico Williams <nico@cryptonector.com>
In-Reply-To: <20150319025202.GB8099@localhost>
Message-ID: <alpine.GSO.1.10.1503191446260.3953@multics.mit.edu>
References: <20150319025202.GB8099@localhost>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6nrssvxR1qcPmtpcXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGUsfLeZteCbYEXzmqUsDYzL+LoYOTkkBEwk Oq6vZoawxSQu3FvPBmILCSxmklhzkr+LkQvI3sgocezxYxYI5xCTRMPsBmYIp4FR4kr3ObAW FgFtiS3Xe8BGsQmoSMx8sxEsLiKgKXF93lIwm1lAWGL9uRlANRwcwgJ2EtumOoGEOQX0JN5e 7GIDCfMKOEjsOFMHcYSuRNvpw2ATRQV0JFbvn8ICYvMKCEqcnPmEBWKilsTy6dtYJjAKzkKS moUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGukV5uZoleakrpJkZQmHJK8u5gfHdQ6RCj AAejEg/vTwHuUCHWxLLiytxDjJIcTEqivIvEgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeO+J AeV4UxIrq1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4j0sANQoWpaanVqRl 5pQgpJk4OEGG8wANfwZSw1tckJhbnJkOkT/FqCglzqsjCZQQAElklObB9cLSyCtGcaBXhHkN QKp4gCkIrvsV0GAmoMH/arlABpckIqSkGhiXHDkgyHa/tHKj1LmLzU8jl9WcfV/dcOQ+t8nM buNzR6uvXXxd8a3kpq+zVljtJ4GMidusdSulZ+i2H7zf5v7nXpHZ7Z7m3xcclh7Ud5TL2nlz crVxNQtLEcuBWQxr/v2051l7UneBP2/rRtMIAWG9FWe+VPA+3iOptWnrxt9u6udTz082Wdet xFKckWioxVxUnAgAHFGNov4CAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/W3k-OxatIOLw4X4Ai0pzUO3nF-k>
Cc: kitten@ietf.org
Subject: Re: [kitten] Clarification of gss_add_cred() behavior
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 18:48:51 -0000

On Wed, 18 Mar 2015, Nico Williams wrote:

> I need a clarification of RFCs 2743 and 2744 as to GSS_add_cred().
>
>     Is it really the case that calling GSS_Add_cred() with no
>     input_cred_handle (GSS_C_NO_CREDENTIAL) must ignore desired_name
>     even when it is not the GSS_C_NO_NAME??
>
> I think the answer is that this text in RFC2743 section 2.1.4, page 39:
>
>    If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL
>    output_cred_handle must be supplied.  For the case of
>    GSS_C_NO_CREDENTIAL as input_cred_handle, GSS_Add_cred() will create
>    the credential referenced by its output_cred_handle based on default
>    behavior.  That is, the call will have the same effect as if the
>    caller had previously called GSS_Acquire_cred(), specifying the same
>    usage and passing GSS_C_NO_NAME as the desired_name parameter
>    (thereby obtaining an explicit credential handle corresponding to
>    default behavior), had passed that credential handle to
>    GSS_Add_cred(), and had finally called GSS_Release_cred() on the
>    credential handle received from GSS_Acquire_cred().
>
> and the corresponding and matching text in RFC2744 section 5.3, are
> subtly wrong.  This text should have read thusly:
>
>    If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL
>    output_cred_handle must be supplied.  For the case of
>    GSS_C_NO_CREDENTIAL as input_cred_handle and desired_name as
>    GSS_C_NO_NAME, GSS_Add_cred() will create
>    the credential referenced by its output_cred_handle based on default
>    behavior.  ...
>
> That is, it should be possible to call GSS_Add_cred() with
> input_cred_handle == GSS_C_NO_CREDENTIAL and a
> desired_name != GSS_C_NO_NAME, and get a CREDENTIAL HANDLE for that
> desired_name.
>
> Otherwise GSS_Add_cred() is mostly useless.
>
> I think this must have been a drafting error.  It's obvious to me, but
> maybe someone has a very different opinion as to this (Martin?).

But a GSS credential can only represent a single identity ("entity", see
1.1.1.1)!  Identities are represented by (non-mechanism) names, so it is
not clear to me that this is a drafting error.  If you know what name you
want credentials for, you should use it.

-Ben