[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
- [kitten] Use of GSS_Get_name_attribute() to obtai… Alejandro Perez Mendez
- Re: [kitten] Use of GSS_Get_name_attribute() to o… Luke Howard
- Re: [kitten] Use of GSS_Get_name_attribute() to o… Simo Sorce
- Re: [kitten] Use of GSS_Get_name_attribute() to o… Benjamin Kaduk
- Re: [kitten] Use of GSS_Get_name_attribute() to o… Cantor, Scott
- Re: [kitten] Use of GSS_Get_name_attribute() to o… Thomas Maslen
- Re: [kitten] Use of GSS_Get_name_attribute() to o… Nico Williams
- Re: [kitten] Use of GSS_Get_name_attribute() to o… Nico Williams
- Re: [kitten] Use of GSS_Get_name_attribute() to o… Alejandro Perez Mendez
- Re: [kitten] Use of GSS_Get_name_attribute() to o… Alejandro Perez Mendez