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

From: Alejandro Perez Mendez <[email-masked]>
Date: Mon, 13 Apr 2015 10:25:03 +0200

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

---

From: Luke Howard <[email-masked]>
Date: Mon, 13 Apr 2015 19:00:02 +1000

I think 1) is fine.

> On 13 Apr 2015, at 6:25 pm, Alejandro Perez Mendez <[email-masked]> wrote:
> 
> 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). 

--
www.lukehoward.com
soundcloud.com/lukehoward

---

From: Simo Sorce <[email-masked]>
Date: Mon, 13 Apr 2015 10:02:02 -0400

> 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

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 13 Apr 2015 11:43:59 -0400 (EDT)

> known names ahead and then call the function only if the name is listed.

Let's see what sort of context we can put things in.

RFC 2743 explicitly calls out that the context-establishment and -deletion
calls may block pending network interactions, and the credential
management calls are also permitted to block on the network.  In contrast,
per-message calls are explicitly declared to not block pending network
interactions.

The word "block" does not appear anywhere in RFC 6680.  It would be nice
to hear from some of the original authors of 6680 about whether this was a
question they had considered.

I do not think I am opposed to (1) (i.e., letting GSS_Get_name_attribute()
block on network interaction), but if we proceed down that route, I think
we should file an erratum against 6880 to that effect.

-Ben

---

From: "Cantor, Scott" <[email-masked]>
Date: Mon, 13 Apr 2015 16:42:07 +0000

>we should file an erratum against 6880 to that effect.

+1

-- Scott

---

From: Thomas Maslen <[email-masked]>
Date: Mon, 13 Apr 2015 19:17:18 +0000

Minor nit:  for "6880" read "6680".

(Ben's message said "6680" the first couple of times but then typo'ed it once to 6880, and per Murphy's Law the latter is the part that got quoted in Scott's message).

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Apr 2015 14:09:00 -0500

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.

> 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.

See also draft-williams-kitten-generic-naming-attributes-02, which
covers the high-latency/low-latency aspect.

> 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.

> 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().

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.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Apr 2015 14:59:29 -0500

> we should file an erratum against 6880 to that effect.

I do not think that RFC6680 says or implies that only those attributes
listed by GSS_Inquire_name() may be gotten with
GSS_Get_name_attribute(), so to start with, we don't need to change
anything about RFC6680 w.r.t. that.

As for what blocking/non-blocking behavior can be expected, I'd say:

a) GSS_Inquire_name() can never "block",
b) GSS_Get_name_attribute() can, and whether it can should depend on the
   attribute being gotten, and preferably this is described by the
   attribute's documentation.

For the latter, see draft-williams-kitten-generic-naming-attributes-02,
which describes a generic attribute prefix by which the application can
request non-blocking behavior (which can fail if whatever data is not
available).

Nico
--

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 16 Apr 2015 20:08:17 +0200

> Name attributes of any MN can be queried.

That's exactly what we wanted.

>     because of additional latency that might be involved.

That's what we thought.

> covers the high-latency/low-latency aspect.

I will, thanks.

> 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.

> name service lookups, or whatever else you can think up.

Thanks

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 16 Apr 2015 20:52:24 +0200

>     attribute's documentation.

I agree with this view.

Regards,
Alejandro