Subject: [abfab] Session Naming on GSS-API

From: "Jim Schaad" <[email-masked]>
Date: Wed, 9 Feb 2011 16:14:36 -0800

I have been looking at what would be required to using the PLASMA concepts
with ABFAB and I came up with the following issue which I think might need
to be addressed, despite the fact that the general issue is going to be
considered to be out of scope.

Consider the following scenario:

Client talks to the service provider (for me the key service) using SOAP
messages wrapped in GSS-API
The service provider says - I never heard of you but you say this ID service
will vouch for you.  Setup the  EAP connection.
Client talks to the ID service using EAP wrapped in GSS-API
Service provider says I need some additional information and you need to
talk to ID service 2 Setup the EAP connection
Client talks to ID service #2 using EAP wrapped in GSS-API
.... and so forth....

While we don't want to address the problems associated with the question of
dealing with the second EAP session, I think that we do need to have a
discussion on the naming convention that needs to occur for the attributes
of EAP session.  How would we distinguish between the same attribute for
each of the two different EAP sessions.  Remember that they may have
different attributes as the EAP methods could be separate.  Also I wonder if
we need to consider that the two different EAP sessions could be
authenticating to the same ID service, but named differently.

Jim

---

From: Josh Howlett <[email-masked]>
Date: Thu, 10 Feb 2011 09:23:51 +0000

> authenticating to the same ID service, but named differently.

There is some discussion of this issue in section 5 of gssapi-naming-exts.

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Feb 2011 07:27:14 -0500

Why wouldn't these two separate EAP sessions belong to separate gssapi
context and thus separate initiator names?
Also, Nico had been considering proposing adding a mechanism to add an
issuer to a name attribute which may help here.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Thu, 10 Feb 2011 15:17:31 +0000

> issuer to a name attribute which may help here.

I'm strongly in favor of that, though obviously if you change the draft APIs, any number of improvements become possible.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Feb 2011 10:54:43 -0500

>>>>> "Cantor," == Cantor, Scott E <[email-masked]> writes:

    >> Also, Nico had been considering proposing adding a mechanism to
    >> add an issuer to a name attribute which may help here.

    Cantor,> I'm strongly in favor of that, though obviously if you
    Cantor,> change the draft APIs, any number of improvements become
    Cantor,> possible.

I think the plan was to add a new API as the existing APIs have shipped.
So, get_name_attribute_issuer.
The problem there is how to handle multi-valued name attributes with
different issuers.

---

From: "Cantor, Scott E." <[email-masked]>
Date: Thu, 10 Feb 2011 15:59:21 +0000

> The problem there is how to handle multi-valued name attributes with

I think I'd want to see a new type created to represent a handle to a specific name attribute, and then the ability to get those handles, and pass them back into new APIs for getting values, metadata, etc.

IOW, I don't think the current APIs are right to reference them by name only, and I'd deprecate them in favor of getting it right. The old ones would still work as is, just without the ability to make such distinctions.

-- Scott

---

From: Sam Hartman <[email-masked]>
Date: Thu, 10 Feb 2011 11:37:43 -0500

>> I think the plan was to add a new API as the existing APIs have
    >> shipped.  So, get_name_attribute_issuer.  The problem there is
    >> how to handle multi-valued name attributes with different
    >> issuers.

    Cantor,> I think I'd want to see a new type created to represent a
    Cantor,> handle to a specific name attribute, and then the ability
    Cantor,> to get those handles, and pass them back into new APIs for
    Cantor,> getting values, metadata, etc.

    Cantor,> IOW, I don't think the current APIs are right to reference
    Cantor,> them by name only, and I'd deprecate them in favor of
    Cantor,> getting it right. The old ones would still work as is, just
    Cantor,> without the ability to make such distinctions.

I'm fine with this plan for the future.  However if we're going to do
that we should publish the existing naming exts document roughly as-is
so people have something to work with while we futz.

(I note we're kind of in the wrong WG for this discussion.)

---

From: "Cantor, Scott E." <[email-masked]>
Date: Thu, 10 Feb 2011 16:59:09 +0000

>(I note we're kind of in the wrong WG for this discussion.)

Yes, I was just seeing if there was general agreement about the fix.

-- Scott

---

From: Nico Williams <[email-masked]>
Date: Thu, 10 Feb 2011 11:01:30 -0600

> (I note we're kind of in the wrong WG for this discussion.)

There are API designs that do less violence to the existing one, so
that's something to discuss at KITTEN WG, as you point out.  For now
it's good enough to know that we have to deal with this problem.

Nico
--

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 10 Feb 2011 16:45:51 -0800

I apparently have a lack of understanding here.  I had the assumption that I
would be creating a single gss-api session to talk to the service provider
and all conversations would be occurring in this single context.  If they
are different contexts then I think that architecture document needs to make
this much clearer.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sam Hartman
> Sent: Thursday, February 10, 2011 4:27 AM
> To: Josh Howlett
> Cc: Jim Schaad; [email-masked]
> Subject: Re: [abfab] Session Naming on GSS-API
> 
> _______________________________________________
> abfab mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/abfab

---

From: Luke Howard <[email-masked]>
Date: Fri, 11 Feb 2011 11:56:30 +1100

> are different contexts then I think that architecture document needs to make

GSS-API has no concept, correct me if I'm wrong, of a session. Instead it has contexts, nothing is stopping you multiplexing multiple contexts over a single underlying session (DCE does this).

-- Luke

---

From: Sam Hartman <[email-masked]>
Date: Fri, 11 Feb 2011 06:04:36 -0500

I'd expect a GSS context to involve exactly one EAP conversation for the
gss-eap mechanism.

---

From: Luke Howard <[email-masked]>
Date: Fri, 11 Feb 2011 23:16:56 +1100

> I'd expect a GSS context to involve exactly one EAP conversation for the

That is certainly what the Moonshot implementation does!

-- Luke