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

[Simo Sorce <[e-mail]>]

On Mon, 2015-04-13 at 10:25 +0200, Alejandro Perez Mendez wrote:
> 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.

The advantage of a new API is that applications can use
GSS_Get_name_attribute() with the implicit knowledge that the call will
not block or generate traffic, however I guess that apps can list all
known names ahead and then call the function only if the name is listed.
So perhaps 1) is fine.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York