Subject: Re: [kitten] Asynchronous operation

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Apr 2011 03:32:41 -0400

>>>>> "Love" == Love Hörnquist Åstrand <[email-masked]> writes:

    Love> 31 mar 2011 kl. 10.50 skrev Nico Williams:

    >> Last time I talked to Love I convinced him, I think (Love,
    >> correct me if I'm misremembering please!) that we could do
    >> something like this:

    Love> Standardizing on libevent is a non starter for me.

Why?  At one level it's interesting to know you don't like it.  At
another level, it's a lot more constructive if you actually give your
design constraints.

---

From: Volker Lendecke <[email-masked]>
Date: Fri, 1 Apr 2011 10:00:03 +0200

> another level, it's a lot more constructive if you actually give your

Stepping in here, although I'm not directly being asked.

Concerns about standardizing on a particular async
implementation depend on what you actually mean by exactly
that. If it means that all applications which want to use
async GSSAPI must have their central event loop in libevent
for Samba it would also be a non-starter. We have our own
event infrastructure (tevent.samba.org) that makes async
programming really easy due to the virtues of talloc. We
could plug in libevent as a backend for tevent, but this
would be a very strong requirement in particular for
platforms where that's not easily available.

It's ok if you model your internal implementation along what
libevent does, but the core socket and timeout operations
should be pluggable to be generally useful.

With best regards,

Volker Lendecke

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 01 Apr 2011 10:06:40 +0200

Love Hörnquist Åstrand <[email-masked]> writes:

> 31 mar 2011 kl. 10.50 skrev Nico Williams:
>
>> Last time I talked to Love I convinced him, I think (Love, correct me
>> if I'm misremembering please!) that we could do something like this:
>
> Standardizing on libevent is a non starter for me.

Same for me.

It may be that defining an async interface at the C level is not
sufficient, and we want it at the GSS-API abstract level.

/Simon

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Apr 2011 04:10:31 -0400

Nico, I agree that it would be nice to make GSS-API asynchronous, but
fixing that problem  is not what I'm asking for here.

I see three concerns:

1) Making GSS-API asynchronous does not inherently mean the application
will know about the desire to get a password.
This simply needs we need such a callback.

2) We don't have implementation energy available to shift the entire
control flow of GSS to be fully asynchronous.

3) We need a solution that is easy to integrate into applications that
already have GSS support. So, something that is easy to use in a thread
that is specific to GSS.

So, while I support your general idea, I'm looking for something that is
more of a point solution. Even if I had your general approach I'd
probably still want the point solution to work with  existing
applications.

I think I'm looking for something simple like an error that indicates
that if a password were available it would have been used and a way to
signal that UI should not be presented just to collect a password.  So
an error code and a cred option.

---

From: Volker Lendecke <[email-masked]>
Date: Fri, 1 Apr 2011 10:12:14 +0200

> control flow of GSS to be fully asynchronous.

Ok, that's pretty much what I wanted to know :-)

Thanks,

Volker

---

From: Sam Hartman <[email-masked]>
Date: Fri, 01 Apr 2011 05:01:09 -0400

>>>>> "Volker" == Volker Lendecke <[email-masked]> writes:

    Volker> On Fri, Apr 01, 2011 at 04:10:31AM -0400, Sam Hartman wrote:
    >> 2) We don't have implementation energy available to shift the
    >> entire control flow of GSS to be fully asynchronous.

    Volker> Ok, that's pretty much what I wanted to know :-)

    Volker> Thanks,

remember here I'm speaking as someone involved in one minor GSS
mechanism.  I'm not speaking about what resources MIT, Heimdal or any of
the krb5 mechanisms have.  If there is energy for an async gss approach,
that's great.  I'm involved in www.project-moonshot.org, and we'd like
something sooner for the password case than that will bring us.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Apr 2011 11:29:27 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> However, we could have a mechanism attribute that indicates
    Nico> whether the initial gss_init_sec_context() call succeeds only
    Nico> if there are target-specific credentials cached (I don't have
    Nico> time to check, but, IIRC, we do have such an attribute).

That's also not good enough for my use case.
It is a prerequisite for my use case sort of.

I effectively want to ask the mechanism if it  needs a password to
contact a possibly unconstrained target with a possibly unconstrained
initiator identity.
If so, I'd prefer to give it the password.
If not, I'd prefer not to ask the user in the app context.