[19443] in Kerberos_V5_Development
Re: user-to-user counterpart of krb5_server_decrypt_ticket_keytab() ?
daemon@ATHENA.MIT.EDU (Rick van Rein)
Sun Jul 3 13:45:58 2016
Message-ID: <57794F37.2050301@openfortress.nl>
Date: Sun, 03 Jul 2016 19:45:27 +0200
From: Rick van Rein <rick@openfortress.nl>
MIME-Version: 1.0
To: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <5777D979.7020906@mit.edu>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
Thanks Greg,
> 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.
> 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!
> 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 krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
