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

Nico Williams <> Wed, 15 April 2015 19:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ED4871A8850 for <>; Wed, 15 Apr 2015 12:09:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G2azLdvH14XH for <>; Wed, 15 Apr 2015 12:09:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9A2851A882E for <>; Wed, 15 Apr 2015 12:09:03 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 5307B21DE6A; Wed, 15 Apr 2015 12:09:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=b3JBveYZ4q19lv fh3X3DVg+Se20=; b=sv7Byu6zP66Xd1NbQE4xRxVPeu12kfuzgURVe2oKNNtAmu /QvEUlBxJ80GJBXJqBXCUyY5ZBT5uib2OkDQdtnKOm47NTEFvdVrZ0SKOeQ4ge4/ PoPn+OTpn2DGPDOFIEBTS5+WwKYcO9Iyx48bDZnjjt7nSQGv+2Hqk/ydZAD3U=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 28F4B21DE77; Wed, 15 Apr 2015 12:09:01 -0700 (PDT)
Date: Wed, 15 Apr 2015 14:09:00 -0500
From: Nico Williams <>
To: Alejandro Perez Mendez <>
Message-ID: <20150415190859.GA29890@localhost>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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: Wed, 15 Apr 2015 19:09:05 -0000

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

Name attributes of any MN can be queried.

> 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.

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

> 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.

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().

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.