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

Alejandro Perez Mendez <alex@um.es> Mon, 13 April 2015 08:25 UTC

Return-Path: <alex@um.es>
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 CD4851B2EC5 for <kitten@ietfa.amsl.com>; Mon, 13 Apr 2015 01:25:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.09
X-Spam-Level:
X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 yZD7-iOlPjjZ for <kitten@ietfa.amsl.com>; Mon, 13 Apr 2015 01:25:09 -0700 (PDT)
Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id DFA2D1B2ECB for <kitten@ietf.org>; Mon, 13 Apr 2015 01:25:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 6E9F448222 for <kitten@ietf.org>; Mon, 13 Apr 2015 10:25:04 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon21.um.es
Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mW65ygpmGuXI for <kitten@ietf.org>; Mon, 13 Apr 2015 10:25:04 +0200 (CEST)
Received: from [155.54.204.2] (alex.inf.um.es [155.54.204.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id 55DD33FA96 for <kitten@ietf.org>; Mon, 13 Apr 2015 10:25:03 +0200 (CEST)
Message-ID: <552B7D5F.3000006@um.es>
Date: Mon, 13 Apr 2015 10:25:03 +0200
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: kitten@ietf.org
Content-Type: multipart/alternative; boundary="------------050504090102000709040600"
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/I_iPdLJ5oeAMjkQXKoVgioYH_VY>
Subject: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes
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: Mon, 13 Apr 2015 08:25:12 -0000

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 
http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10, 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.

Regards,
Alejandro