Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes

Simo Sorce <> Mon, 13 April 2015 14:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3EB6C1A7008 for <>; Mon, 13 Apr 2015 07:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.912
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N6FJx3CxO_zY for <>; Mon, 13 Apr 2015 07:02:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C9D211A6F2D for <>; Mon, 13 Apr 2015 07:02:06 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id t3DE233A005239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 13 Apr 2015 10:02:04 -0400
Received: from [] ( []) by (8.14.4/8.14.4) with ESMTP id t3DE22bN027209; Mon, 13 Apr 2015 10:02:03 -0400
Message-ID: <>
From: Simo Sorce <>
To: Alejandro Perez Mendez <>
Date: Mon, 13 Apr 2015 10:02:02 -0400
In-Reply-To: <>
References: <>
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
Archived-At: <>
Subject: Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Apr 2015 14:02:17 -0000

On Mon, 2015-04-13 at 10:25 +0200, Alejandro Perez Mendez wrote:
> Hi,
> I have a question regarding the GSS-API Naming Extensions (RFC 6680). As 
> the document is written, it seems to assume that the attributes of a 
> name are locally stored and available in the GSS Acceptor at the very 
> moment the GSS context is established. In this way, when the GSS 
> Acceptor calls the GSS_Inquire_name(), it obtains the complete set of 
> attributes of the name, and it must stick to them.
> However, in relation with the work we are doing in 
>, what I'd like 
> is to allow the GSS Acceptor to request name attributes that might not 
> be available at the moment the GSS context is established (i.e. not 
> listed in the results of GSS_Inquire_name()), but that can be obtained 
> by interacting with another entity afterwards (e.g. SAML IdP, LDAP 
> server, SQL database...).
> I see two approaches to achieve this:
> 1) Use the GSS_Get_name_attribute() call to request the desired 
> attribute. By modifying the implementation of this call in the 
> mechanism, instead of returning an error when the requested attribute is 
> not available yet, the mechanism can get it from the source and return 
> it. The main advantage of this approach is that it transparent from the 
> point of view of the GSS Acceptor, that just uses the same call as it 
> always does. Besides, it does not require an  standardization effort, as 
> it is solved in the implementation of each mechanism.
> 2) The second approach consists on defining a new GSS-API call: e.g. 
> GSS_Request_name_attribute(). This call would allow the GSS acceptor to 
> explicitly request an attribute that is not listed in the results of 
> GSS_Inquire_name(). The advantage of this approach is that is does not 
> modify the semantics or the code associated to the 
> GSS_Get_name_attribute() call. However, it would require standardization 
> effort to define such a new call.
> In my opinion, approach 1) seems to offer a better solution. I don't see 
> a reason by which a GSS Acceptor cannot call the 
> GSS_Get_name_attribute() to obtain the value of a name attribute that 
> does not appear in the results of GSS_Inquire_name(). This is something 
> that can be handled by the mechanism (or the specific implementation of 
> the mechanism).
> However, before moving forward with any of these approaches, I wanted to 
> receive some feedback from the GSS-API experts.

The advantage of a new API is that applications can use
GSS_Get_name_attribute() with the implicit knowledge that the call will
not block or generate traffic, however I guess that apps can list all
known names ahead and then call the function only if the name is listed.
So perhaps 1) is fine.


Simo Sorce * Red Hat, Inc * New York