KRB5_MK_REQ(3)

✨ NAME ✨

okay bestie, gather round — this is the whole squad:

• krb5_mk_req
• krb5_mk_req_exact
• krb5_mk_req_extended
• krb5_rd_req
• krb5_rd_req_with_keyblock
• krb5_mk_rep
• krb5_mk_rep_exact
• krb5_mk_rep_extended
• krb5_rd_rep
• krb5_build_ap_req
• krb5_verify_ap_req

and what do they do? they create and read application authentication request 💖

🎀 LIBRARY 🎀

Kerberos 5 Library, aka libkrb5, link it with -lkrb5. slay.

🦋 SYNOPSIS 🦋

#include <krb5.h>

krb5_error_code
krb5_mk_req(krb5_context context, krb5_auth_context *auth_context,
    const krb5_flags ap_req_options, const char *service,
    const char *hostname, krb5_data *in_data, krb5_ccache ccache,
    krb5_data *outbuf);

krb5_error_code
krb5_mk_req_extended(krb5_context context,
    krb5_auth_context *auth_context, const krb5_flags ap_req_options,
    krb5_data *in_data, krb5_creds *in_creds, krb5_data *outbuf);

krb5_error_code
krb5_rd_req(krb5_context context, krb5_auth_context *auth_context,
    const krb5_data *inbuf, krb5_const_principal server,
    krb5_keytab keytab, krb5_flags *ap_req_options,
    krb5_ticket **ticket);

krb5_error_code
krb5_build_ap_req(krb5_context context, krb5_enctype enctype,
    krb5_creds *cred, krb5_flags ap_options, krb5_data authenticator,
    krb5_data *retdata);

krb5_error_code
krb5_verify_ap_req(krb5_context context,
    krb5_auth_context *auth_context, krb5_ap_req *ap_req,
    krb5_const_principal server, krb5_keyblock *keyblock,
    krb5_flags flags, krb5_flags *ap_req_options, krb5_ticket **ticket);

like, look at those signatures. so clean. so structured. iconic. ✨

💅 DESCRIPTION 💅

so the functions in this manual page? they document the functions that facilitate the exchange between a Kerberos client and a server. and ngl, they're the core functions used in the authentication exchange between the client and the server. main character energy fr fr 👑

🌸 making the request

krb5_mk_req and krb5_mk_req_extended create the Kerberos message KRB_AP_REQ, which gets sent from the client to the server as the first packet in a client/server exchange. the result you should send over to the server is stored in outbuf. 💌

auth_context should be allocated with krb5_auth_con_init(), or you can pass in NULL — and in that case it will be allocated and freed internally. so convenient bestie, no cap.

the input data in in_data will have a checksum calculated over it, and that checksum gets transported in the message to the server. 🧾

🌈 the flags, the moment you've been waiting for

ap_req_options can be set to one or more of the following flags:

• AP_OPTS_USE_SESSION_KEY — use the session key when creating the request, and this one is used for user to user authentication.
• AP_OPTS_MUTUAL_REQUIRED — mark the request as mutual authenticate required, so that the receiver returns a mutual authentication packet. reciprocal bestie behaviour 🫶

🦋 reading the request

krb5_rd_req reads the AP_REQ in inbuf, verifies it and extracts the content. if server is specified, that server will be fetched from the keytab and used unconditionally. if server is NULL, the keytab will be searched for a matching principal. 🔍

the keytab argument specifies what keytab to search for receiving principals. and the arguments ap_req_options and ticket return the content.

when the AS-REQ is a user to user request, neither keytab nor principal are used — instead krb5_rd_req() expects the session key to be set in auth_context. not me dropping that little plot twist 😭

💀 the "don't touch this" corner

krb5_verify_ap_req and krb5_build_ap_req both construct and verify the AP_REQ message — and they should not be used by external code. like, hands off, bestie, that's internal business 🙈

⭐ SEE ALSO ⭐

• krb5(3)
• krb5.conf(5)

and that's the whole page, periodt 💜 this was the HEIMDAL version, dated August 27, 2005, filed under KRB5_MK_REQ(3) — go forth and authenticate responsibly, mwah 🎀✨