Subject: [kitten] What happened to simplifying the API in the charter

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 16:38:58 -0500

Is it my imagination or did there use to be text in the charter for
this?  Or was it text for a tutorial or introduction Informational
RFC(s)?

I looked in the archived charters but didn't see it, so it must have
been in my imagination :(

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 11 Jul 2013 15:25:34 -0700

> been in my imagination :(

I do recall some discussions along that line, but I don't think they made it all the way into the charter.  I think Tom Yu was collecting the input.

I have advocated such a thing in the past.  In particular, I think if we had an API which hid the lower level tokenization and transport details so the developer just did open()/send()/receive()/close() it would be easier to gain adoption into new applications.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 17:32:29 -0500

> I have advocated such a thing in the past.  In particular, I think if we had an API which hid the lower level tokenization and transport details so the developer just did open()/send()/receive()/cl…

Roland's libknc does this.  I don't think it's released yet, and it
only covers the ordered octet stream case, but that, I think, is what
you meant.  libknc has an empty context + mutators/accessors, like the
new API for the channel bound flag.  IMO that's much easier to use.

I also think that the extended naming API also makes it easier to deal
with complex naming problems (as in the TLS server PKI, and PKIX in
general) -- easier than dealing in raw, mechanism-specific naming.

Nico
--

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 11 Jul 2013 15:50:50 -0700

Is that krb5-specific, or is it GSSAPI in general?

On Jul 11, 2013, at 3:32 PM, Nico Williams <[email-masked]> wrote:

> Roland's libknc does this.

---

From: Luke Howard <[email-masked]>
Date: Fri, 12 Jul 2013 08:59:23 +1000

> new API for the channel bound flag.  IMO that's much easier to use.

https://github.com/elric1/knc

--
Luke Howard / [email-masked]
www.padl.com / www.lukehoward.com

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 18:00:08 -0500

> Is that krb5-specific, or is it GSSAPI in general?

The 'k' in it is for "Kerberos", but in fact it uses the GSS-API in a
completely generic way.  It uses these GSS functions only:

gss_accept_sec_context
gss_delete_sec_context
gss_display_name
gss_display_status
gss_import_name
gss_init_sec_context
gss_release_buffer
gss_release_buffer
gss_release_cred
gss_release_name
gss_unwrap
gss_wrap

and does not interpret principal names in any way, leaving that to the
application.  (Note that it uses gss_display_name() and not
gss_export_name().  IMO it should output all of: display name,
exported name token, and exported composite name token if available.
I'll file an issue with it.)

Also, it should support credential export (where available, and apps
should be able to gss_store_cred() delegated creds, also where
available).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 11 Jul 2013 19:20:15 -0500

> completely generic way.  It uses these GSS functions only:

Also, the libknc API gives the application the actual gss_name_t
values, so the application can do what it likes.

So, yes, libknc is very much generic, not Kerberos-specific.  Perhaps
Roland should rename it :)

The knc(1) program only deals in display names.  It could export the
initiator's name and give it to the application; since the protocol by
which knc(1) talks to the server program is textual, the exported name
token would have to be hex encoded.

So knc(1) the program isn't quite generic enough, but it's very close.

Nico
--

---

From: "Roland C. Dowdeswell" <[email-masked]>
Date: Fri, 12 Jul 2013 09:54:33 +0100

On Thu, Jul 11, 2013 at 07:20:15PM -0500, Nico Williams wrote:

> Roland should rename it :)

I was certainly thinking of renaming it.  When originally written, quite
a long time ago, I was only thinking about Kerberos but since then I've
made things quite a bit more generic.

> So knc(1) the program isn't quite generic enough, but it's very close.

Definitely.  Lately, I've been putting more work into the library
interface which is much more generic than the command line utility
at this point, but the plan is to rewrite the command line utility
in terms of the library and expose more of the functionality.  For
naming, on the server side, the command line will set environment
variables such as KNC_CREDS which is the gss_display_name() of the
other end of the connexion.  It would be very easy to add something
like KNC_EXPORT_NAME being the base64 encoded export name.  I'll
probably also make KNC_CREDS specific to the Kerberos case as the
gss_display_name() semantics in that case are well understood.
(This is similar to the approach that I am using to add Negotiate
support to bozohttpd, i.e. set REMOTE_USER to gss_display_name()
if Kerberos is used for compatibility with apache and set EXPORT_NAME
to the export name in all cases for something with a bit more in
the way of correctness for other mechanisms.)

--
    Roland Dowdeswell                      http://Imrryr.ORG/~elric/