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

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

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