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

Alejandro Perez Mendez <> Thu, 16 April 2015 18:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 57E381B2EE1 for <>; Thu, 16 Apr 2015 11:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tWR_3OYLgvCh for <>; Thu, 16 Apr 2015 11:08:24 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5A4921B2ED4 for <>; Thu, 16 Apr 2015 11:08:24 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA9D7D460; Thu, 16 Apr 2015 20:08:20 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id JuMahpWcmADO; Thu, 16 Apr 2015 20:08:20 +0200 (CEST)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by (Postfix) with ESMTPSA id 014F29554; Thu, 16 Apr 2015 20:08:18 +0200 (CEST)
Message-ID: <>
Date: Thu, 16 Apr 2015 20:08:17 +0200
From: Alejandro Perez Mendez <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Nico Williams <>
References: <> <20150415190859.GA29890@localhost>
In-Reply-To: <20150415190859.GA29890@localhost>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
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: Thu, 16 Apr 2015 18:08:27 -0000

El 15/04/15 a las 21:09, Nico Williams escribió:
> On Mon, Apr 13, 2015 at 10:25:03AM +0200, Alejandro Perez Mendez wrote:
>> 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.
> They need neither be "locally stored", nor be available only on the
> acceptor side for that matter.
> Name attributes can be set ahead of calling GSS_Init_sec_context() or
> GSS_Acquire_cred().
> Name attributes of any MN can be queried.

That's exactly what we wanted.

>> 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...).
> The API permits this for GSS_Get_name_attribute(), but such attributes
> should probably not be listed by GSS_Inquire_name() because:
> a) the set of such attributes might not be possible to list,
> b) some such attributes might not be appropriate to get unless needed
>     because of additional latency that might be involved.

That's what we thought.

> See also draft-williams-kitten-generic-naming-attributes-02, which
> covers the high-latency/low-latency aspect.

I will, thanks.

>> 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.
> Right.
>> 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.
> See above.  The imporant thing is that GSS_Get_name_attribute() already
> functions as a requestor API, but you might not want to list all
> possible attributes in GSS_Inquire_name().

Sure. The acceptor will not know whether the IdP will provide a specific 
attribute until it tries to request it.

> GSS_Inquire_name() should list the name attributes that are explicitly a
> part of the name (e.g., authorization-data elements, in the Kerberos
> case).  GSS_Get_name_attribute() should be able to produce many more
> name attributes' values, depending on composition of name attributes,
> name service lookups, or whatever else you can think up.


> Nico