Re: KITTEN: IETF 75 - 76

[Love Hörnquist Åstrand <lha at kth.se>]

17 aug 2009 kl. 01:51 skrev Nicolas Williams:

On Sun, Aug 16, 2009 at 12:26:34AM -0600, Shawn M Emery wrote:

Love had given a set of new work items that would be of interest, as

follows:

  1. initialization/new credentials

  2. listing/iterating credentials

  3. exporting/importing credentials

(1) is a complex matter as it requires interaction with users and needs
to cover such things as principal name, password, new password, PIN, PIN
change and other prompts.  A design is certainly possible.

(2) is really listing of principal names for which the caller has
credentials (we can already list mechanisms for which the caller has
credentials).  This is likely a difficult thing to design since we will
want to be able to control what principals GSS_Accept_sec_context() can
accept sec contexts for, and that means a significant revamp of the
semantics of CREDENTIAL HANDLEs _or_ a replacement for
GSS_Accept_sec_context().

accept sec context is not really intresting since it doesn't make thinks not work. init sec context however it mostly useless since the consumers don't know about what credentials they have.

have a list of mechs there is credentials for is also mostly useless, i have lha at SU.SE (Kerberos), SU.SE\lha (NTLM), KTH.SE (Kerberos) E.KTH.SE (sasl-digest-md5), lha at LKDC.SHA1:EA35DAB08BD8EC833C160FAFCDF03E4B13F72D6B (Kerberos) any many other, knowing that I have some Kerberos credentals is mostly useless.

Its not even possible to build ui to do specific selection, or selection other then providing a text field that you can do gss_import_name(GSS_C_NT_USER) on and hope that it work.

  4. error message reporting

Yes.  (I still believe in the "PGSSAPI" idea where, in the C bindings,
we change the semantics and type of the minor_status argument, though in
a binary backwards compatible way.  I can expand if desired.)

Lets redo the api, ISC is broken as it since there is no way to add new tokens.

  5. asynchronous calls

Developers can use threads to work around the lack of these, so it seems
to me that these should be a lower priority.

I disagree, threads consume lots of resources that and are very complicated to use.

...along with Alexey's recent request for policy/encryption strength.

Yes.  This should be, IMO, a high priority.

And not over engineered. Let's solve the SASL problem and nothing more.

We are looking for authors and editors for any of these new items or

something else that you would like to see developed within KITTEN.

I'll edit, but I need co-authors who'll contribute text, API designs,
and energy to the list.

Love