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

Alejandro Perez Mendez <alex@um.es> Thu, 16 April 2015 18:08 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 57E381B2EE1 for <kitten@ietfa.amsl.com>; Thu, 16 Apr 2015 11:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWR_3OYLgvCh for <kitten@ietfa.amsl.com>; Thu, 16 Apr 2015 11:08:24 -0700 (PDT)
Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4921B2ED4 for <kitten@ietf.org>; Thu, 16 Apr 2015 11:08:24 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id CA9D7D460; Thu, 16 Apr 2015 20:08:20 +0200 (CEST)
X-Virus-Scanned: by antispam in UMU at xenon24.um.es
Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JuMahpWcmADO; Thu, 16 Apr 2015 20:08:20 +0200 (CEST)
Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id 014F29554; Thu, 16 Apr 2015 20:08:18 +0200 (CEST)
Message-ID: <552FFA91.8010908@um.es>
Date: Thu, 16 Apr 2015 20:08:17 +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: Nico Williams <nico@cryptonector.com>
References: <552B7D5F.3000006@um.es> <20150415190859.GA29890@localhost>
In-Reply-To: <20150415190859.GA29890@localhost>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/460NUpQaXmPTHqE7MuVPfoJZYCw>
Cc: kitten@ietf.org
Subject: Re: [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: 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
>> 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...).
> 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.

Thanks

>
> Nico