user-to-user counterpart of krb5_server_decrypt_ticket_keytab() ?

[Rick van Rein]

Hi Jeffrey,

Thanks for your response.

First off, I think there is a lot that can be gained from having TLS
work with Kerberos -- for both these Worlds.  We definately agree on
Kerberos to have the benefits of scalability and robustness.  I also
agree that RFC 2712 is not the right way to embed Kerberos in TLS.

I tried to embed GSS-API inside TLS, but this is not possible, due to
the unbounded number of exchanges in GSS-API and the limited number in
TLS.  So I tried to squeeze the intended Kerberos-ECDH combination (KDH
for short) into different formats.  The result is in
draft-vanrein-tls-kdh, which has really gone through a hefty learning /
adaption process.

As for API visibility; I wonder if that is a protocol design concern,
even if a direct implementation could have problems in that area.  The
protocol states what kind of messages are exchanged, and any RFC 4120
implementation should suffice to construct those.  It is quite possible
to implement an isolation of the Kerberos API from applications on the
OS, and in fact that is precisely what I am doing with the TLS Pool. 
The general idea of the TLS Pool is to extract TLS APIs from
applications, and that includes any parts of Kerberos.

Thanks for the draft reference
https://datatracker.ietf.org/doc/draft-santesson-tls-gssapi/ -- I will
look for time to read it soon!  I suspect that what you do with a PSK is
going to be close to my use of RFC 7250.  This is in fact the result of
discussions with the TLS WG (some of which interestingly suggested a
PSK-based exchange).

Cheers,
 -Rick