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

[Alejandro Perez Mendez <[e-mail]>]

FYI, I have sent the following question to the Kitten WG mailing list.

Regards,
Alejandro

-------- Mensaje reenviado --------
Asunto: 	[kitten] Use of GSS_Get_name_attribute() to obtain further 
attributes
Fecha: 	Mon, 13 Apr 2015 10:25:03 +0200
De: 	Alejandro Perez Mendez <[e-mail]>
Para: 	[e-mail]



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