user-to-user counterpart of krb5_server_decrypt_ticket_keytab() ?

[Rick van Rein]

Hello,

I'm pretty far with piecing together my TLS += Kerberos-DH [1]
implementation in GnuTLS [2] and my TLS Pool [3]. Simo's hint to look
at kvno.c and kinit.c really helped, thanks!

Since it was a straightforward extension, I added user-to-user Kerberos
to the spec [4]. Adding the 2nd ticket to the ticket request in the
client was all handled by the library. Nice!

But on the server I run into a missing u2u counterpart for
krb5_server_decrypt_ticket_keytab(); I need something along the lines of
krb5_server_decrypt_ticket_creds() that would use a TGT (krb5_creds)
rather than a keytab to decrypt a ticket.

Is there a function in the libkrb5 API to do just that? If not, how is
user-to-user normally implemented? Is there a clever bypass, or will I
have to strip down the ticket with application code?

Thanks!
-Rick


[1] http://tls-kdh.arpa2.net/tls-kdh.html
[2] http://github.com/arpa2/gnutls-kdh
[3] https://github.com/arpa2/tlspool/blob/tls-kdh/src/starttls.c
[4] https://tools.ietf.org/html/draft-vanrein-tls-kdh-04#section-4.3
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Rick van Rein]

Ah!

Post by Rick van Rein
on the server I run into a missing u2u counterpart for
krb5_server_decrypt_ticket_keytab(); I need something along the lines of
krb5_server_decrypt_ticket_creds() that would use a TGT (krb5_creds)
rather than a keytab to decrypt a ticket.

I think I found it: krb5_decrypt_tkt_part() takes a keyblock.
That ought to work!

Sorry for not finding it straight away; I was looking on the web interface,
which doesn't mention it, but I found it in libkrb5.exports, which is the
more convincing place to have it :)

Pfew!
-Rick
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Greg Hudson]

Post by Rick van Rein
I think I found it: krb5_decrypt_tkt_part() takes a keyblock.
That ought to work!
Sorry for not finding it straight away; I was looking on the web interface,
which doesn't mention it, but I found it in libkrb5.exports, which is the
more convincing place to have it :)

libkrb5.exports is the library export list; it contains functions which
are exported for the sake of test programs, or the GSS-API library, or
the KDC. Not everything in there is a public API.
krb5_decrypt_tkt_part() is not prototyped in krb5.h, so it is not a
public API.

You don't need to explicitly decrypt the ticket in a user-to-user
program; rd_req will take care of it for you. Have a look at
src/appl/user_user for an example.
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Rick van Rein]

Thanks Greg,

Post by Greg Hudson
libkrb5.exports is the library export list; it contains functions which
are exported for the sake of test programs, or the GSS-API library, or
the KDC. Not everything in there is a public API.

That's why I found it indirectly, I see.

Post by Greg Hudson
krb5_decrypt_tkt_part() is not prototyped in krb5.h, so it is not a
public API.

Yes, I had to add its prototype manually to my own header files, which of course foregoes the advantage of type checking the library call!

Post by Greg Hudson
You don't need to explicitly decrypt the ticket in a user-to-user
program; rd_req will take care of it for you. Have a look at
src/appl/user_user for an example.

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?


Thanks,
-Rick
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

[Jeffrey Altman]

Post by Rick van Rein
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

[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
_______________________________________________
krbdev mailing list ***@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev