user-to-user counterpart of krb5_server_decrypt_ticket_keytab() ?

[Jeffrey Altman]

On 7/3/2016 1:45 PM, Rick van Rein wrote:
>
> Wish I'd had the space in TLS to pack a simple AP-REQ / AP-REP exchange, and that's certainly how this all started, but the AP protocol was not possible I found; also it's less natural to TLS which passes "raw public keys" and that sounds more like a Ticket than like an AP-REQ.
> 
> 
> I don't suppose I could convince you to add the higher-up krb5_server_decrypt_ticket_creds() to the public API, could I?

TLS should not be using Kerberos protocol directly.   We went down that
road with RFC 2712.   Using Kerberos directly requires that
implementations be available and that private non-standardized
interfaces be used.  There has been consensus for almost two decades
that Kerberos APIs should not be exposed on operating systems.  Instead
the GSS-API should be used.   Using anything other than the GSS-API
prevents portable implementation of TLS using the extension on Windows,
OSX, Solaris, and other operating systems that follow the consensus best
practice.

The last effort I was involved in to provide GSS authentication and key
exchange for TLS was nearly a decade ago.   Take a look at

  https://datatracker.ietf.org/doc/draft-santesson-tls-gssapi/

That draft "defines extensions to RFC 4279, "Pre-Shared Key Ciphersuites
for Transport Layer Security (TLS)", to enable dynamic key sharing in
distributed environments using a Generic Security Service Application
Program Interface (GSS-API) mechanism, and then import that shared key
as the "Pre-Shared Key" to complete the TLS handshake. This is a modular
approach to perform authentication and key exchange based on off-shelf
libraries. And it obviates the need of pair-wise key sharing by enabling
the use of the widely-deployed Kerberos alike trust infrastructures that
are highly scalable and robust. Furthermore, conforming implementations
can provide server authentication without the use of certificates."

It was a joint effort of Microsoft and Secure Endpoints to move the
concept forward but it failed because of objections within the TLS
working group.  From my perspective it is much cleaner because it
permits a TLS implementation to be produced that doesn't require any
access to private Kerberos APIs and will work with any GSS-API mechanism
that provides a shared secret key or supports the GSS PRF.

Jeffrey Altman




-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4349 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20160703/d57d2054/attachment.bin